1.1.1.1 Not Reachable on CenturyLink - United States

Hello Community,

I’m currently having a problem reaching 1.1.1.1 through CenturyLink in Eastern Iowa, United States. But the secondary 1.0.0.1 is reachable and working without a problem.

I have been able to reach and resolve DNS through 1.1.1.1 for the past several months. But since 12:15pm CST (-06:00) today, I have not been able to reach it.

A CloudFlare forum post suggested I include the following info with my report. Please let me know if I can provide any further information.

(Including the info through external link because forum would not let me post “more than 2 links” as a new user)
https://storage.googleapis.com/jhed9/cloudflare_centurylink_troubleshooting_commands_2020-01-15T14-57-28-0600.txt

Now I can post it in-line since this is not my first post :^)

traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets 1 192.168.0.2 (192.168.0.2) 3.576 ms 1.469 ms 1.615 ms 2 dvnp-dsl-gw14.dvnp.qwest.net (65.103.57.14) 30.377 ms 28.181 ms 95.845 ms 3 65-103-58-105.dvnp.qwest.net (65.103.58.105) 39.925 ms 30.811 ms 31.086 ms 4 roc2-edge-04.inet.qwest.net (67.14.104.102) 65.577 ms 54.416 ms 52.436 ms 5 cer-brdr-02.inet.qwest.net (67.14.8.73) 50.509 ms * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * ^C traceroute 1.0.0.1
traceroute to 1.0.0.1 (1.0.0.1), 64 hops max, 52 byte packets
1 192.168.0.2 (192.168.0.2) 192.908 ms 1.815 ms 2.151 ms
2 dvnp-dsl-gw14.dvnp.qwest.net (65.103.57.14) 31.151 ms 61.382 ms 29.634 ms
3 65-103-58-105.dvnp.qwest.net (65.103.58.105) 39.428 ms 31.341 ms 30.365 ms
4 * * *
5 * * *
6 * * *
7 ace-world-w.edge3.chicago2.level3.net (4.26.120.122) 36.838 ms 33.450 ms 36.124 ms
8 one.one.one.one (1.0.0.1) 37.959 ms 31.254 ms 34.121 ms

dig +short CHAOS TXT id.server @1.1.1.1 ;; connection timed out; no servers could be reached dig +short CHAOS TXT id.server @1.0.0.1
“ORD”

dig +tcp @1.1.1.1 id.server CH TXT ;; Connection to 1.1.1.1#53(1.1.1.1) for id.server failed: host unreachable. dig +tcp @1.0.0.1 id.server CH TXT

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;id.server. CH TXT

;; ANSWER SECTION:
id.server. 0 CH TXT “ORD”

;; Query time: 34 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Wed Jan 15 14:35:46 CST 2020
;; MSG SIZE rcvd: 54

I’m having this same issue at our site with client teams leveraging 1.1.1.1 for DNS on our CenturyLink circuits. I have a ticket in with CenturyLink now.

I just noticed that 1.1.1.1 is reachable again. In case anyone is interested, here is what the commands show now that it is working.

$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
1 192.168.0.2 (192.168.0.2) 171.163 ms 2.166 ms 2.050 ms
2 dvnp-dsl-gw14.dvnp.qwest.net (65.103.57.14) 30.526 ms 27.132 ms 29.678 ms
3 65-103-58-105.dvnp.qwest.net (65.103.58.105) 30.440 ms 28.960 ms 27.854 ms
4 cer-brdr-02.inet.qwest.net (67.14.8.73) 33.215 ms 36.316 ms 138.674 ms
5 * * *
6 * * *
7 ace-world-w.edge3.chicago2.level3.net (4.26.120.122) 35.387 ms 58.802 ms 35.265 ms
8 one.one.one.one (1.1.1.1) 35.867 ms 31.568 ms 33.204 ms

$ traceroute 1.0.0.1
traceroute to 1.0.0.1 (1.0.0.1), 64 hops max, 52 byte packets
1 192.168.0.2 (192.168.0.2) 182.338 ms 2.760 ms 1.816 ms
2 dvnp-dsl-gw14.dvnp.qwest.net (65.103.57.14) 29.384 ms 27.417 ms 30.594 ms
3 65-103-58-105.dvnp.qwest.net (65.103.58.105) 31.284 ms 28.899 ms 28.880 ms
4 cer-brdr-02.inet.qwest.net (67.14.8.73) 55.228 ms 56.443 ms 109.283 ms
5 * * *
6 * * *
7 ace-world-w.edge3.chicago2.level3.net (4.26.120.122) 60.244 ms 37.568 ms 35.295 ms
8 one.one.one.one (1.0.0.1) 34.790 ms 32.356 ms 32.891 ms

$ dig +short CHAOS TXT id.server @1.1.1.1
“ORD”

$ dig +short CHAOS TXT id.server @1.0.0.1
“ORD”

$ dig +tcp @1.1.1.1 id.server CH TXT

; <<>> DiG 9.10.6 <<>> +tcp @1.1.1.1 id.server CH TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23645
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;id.server. CH TXT

;; ANSWER SECTION:
id.server. 0 CH TXT “ORD”

;; Query time: 33 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jan 15 18:13:59 CST 2020
;; MSG SIZE rcvd: 54

$ dig +tcp @1.0.0.1 id.server CH TXT

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;id.server. CH TXT

;; ANSWER SECTION:
id.server. 0 CH TXT “ORD”

;; Query time: 35 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Wed Jan 15 18:14:00 CST 2020
;; MSG SIZE rcvd: 54

Working for us now too. CenturyLink made sure to blame Cloudflare.

Chance,

Carrier Update:

Upon further review, this issue was isolated to a routing configuration change made by CenturyLink.
 
CenturyLink was able to find and correct the issue to restore services and they have taken steps to ensure this issue will not recur and believe the network to be stable at this time. Disregard the last update where they previously said to contact CloudFlare. CenturyLink ended up fixing the issue on their end.
 
Can you confirm DNS is now resolving though?

Thanks,

1 Like