1.1.1.1 not responding in Vultr Chicago

Zero Trust 1.1.1.1
,
1

I noticed smtp response times going up on my backup MX, and noticed that 1.1.1.1 is not responding to queries (however, DoT appears to work fine, and I am able to ping the IP). 1.0.0.1 seems to work fine. The server is a VM in Vultr’s Chicago datacenter. Thanks!

btw - I seem to be seeing the same behavior over ipv6. I can include the output of that as well if requested.

troubleshooting output:

d$ dig example.com @1.1.1.1

; <<>> DiG 9.4.2-P2 <<>> example.com @1.1.1.1
;; global options:  printcmd
;; connection timed out; no servers could be reached

d$ dig example.com @1.0.0.1 

; <<>> DiG 9.4.2-P2 <<>> example.com @1.0.0.1
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11874
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            9533    IN      A       93.184.216.34

;; Query time: 7 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Wed Jun 19 22:23:43 2019
;; MSG SIZE  rcvd: 45

d$ dig example.com @8.8.8.8 

; <<>> DiG 9.4.2-P2 <<>> example.com @8.8.8.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26125
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            18231   IN      A       93.184.216.34

;; Query time: 2 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jun 19 22:24:00 2019
;; MSG SIZE  rcvd: 45

d$ dig +short CHAOS TXT id.server @1.1.1.1
;; connection timed out; no servers could be reached

d$ dig +short CHAOS TXT id.server @1.0.0.1 
"ORD"

d$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 40 byte packets
 1  * * *
 2  vl199-ds1-b5-IO99.chi2.choopa.net (104.207.137.33)  1.039 ms  1.067 ms  3.88 ms
 3  * * *
 4  one.one.one.one (1.1.1.1)  0.319 ms  0.39 ms  0.254 ms

d$ traceroute 1.0.0.1                                                                                    
traceroute to 1.0.0.1 (1.0.0.1), 64 hops max, 40 byte packets
 1  * * *
 2  vl199-ds1-b5-IO99.chi2.choopa.net (104.207.137.33)  0.924 ms  0.907 ms  0.893 ms
 3  * * *
 4  13335.chi.equinix.com (208.115.136.180)  3.15 ms  2.952 ms  2.338 ms
 5  one.one.one.one (1.0.0.1)  1.186 ms  1.193 ms  1.176 ms

d$ dig +tcp @1.1.1.1 id.server CH TXT

; <<>> DiG 9.4.2-P2 <<>> +tcp @1.1.1.1 id.server CH TXT
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

d$ dig +tcp @1.0.0.1 id.server CH TXT

; <<>> DiG 9.4.2-P2 <<>> +tcp @1.0.0.1 id.server CH TXT
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52948
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;id.server.                     CH      TXT

;; ANSWER SECTION:
id.server.              0       CH      TXT     "ORD"

;; Query time: 12 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Wed Jun 19 22:28:51 2019
;; MSG SIZE  rcvd: 43
2

I’m mobile right now and can’t dig deep into this, but my Vultr server in Los Angeles responds to your example.com lookup. Can you post a traceroute?

P.s. it also works from my New Jersey VPS.

3

Hi,

My instance in Dallas can use 1.1.1.1 fine - only instances in Chicago are affected. I spun up a new CentOS box to confirm and experience the same issue in the Chicago datacenter (the report was made from OpenBSD).

The first post contains a traceroute, and curiously 1.1.1.1 and 1.0.0.1 have different hops/path. However I am able to use 1.1.1.1 with DoT, which is interesting.

4

Vultr has resolved the issue.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.