1

Yesterday I switched DNS hosting for the domain bagtheweb.com from Godaddy to CloudFlare. Cloudflare says the transfer was successful and DNS resolution works great everywhere EXCEPT from my office. Sometimes it works, sometimes I get SERVFAIL responses using dig bagtheweb.com.

My office computer is using my AT&T gateway for DNS. I looked at the gateway control panel and it says it's using 68.94.156.9 and 68.94.157.9 for DNS.

I tried digging using both of those DNS resolvers directly: dig @68.94.156.9 bagtheweb.com and dig @68.94.157.9 bagtheweb.com.

Roughly half the time the result is good (I see A records pointing to IP addresses), and half the time I get SERVFAIL responses. I tried a bunch of times and I keep seeing both responses seemingly randomly. It's been about 20 hours since I did the transfer and I'm still seeing this.

I tried digging CloudFlare's DNS servers theo.ns.cloudflare.com. and vita.ns.cloudflare.com. and it works great every time. I also tried digging Google's DNS server 8.8.8.8 also works perfectly.

So my only conclusion is that AT&T sucks, and each of those DNS server IPs is backed by a pool of servers, some that updated properly and some that are confused. I'm hoping 24 hours will be the magic threshold for those bad servers to update.

Any idea why this is happening? Is there anything else I can do to investigate or force an update (besides call AT&T and waste 4 hours of my life)? Is there something I could have done before the zone transfer to eliminate this problem? I know that I can fix the problem for myself by using Google's DNS, but I wonder if other users out there could be experiencing the same problem.

2 back to back commands:

Marcels-iMac:~ marcel$ dig @68.94.157.9 bagtheweb.com

; <<>> DiG 9.9.7-P3 <<>> @68.94.157.9 bagtheweb.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58515
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bagtheweb.com.         IN  A

;; Query time: 131 msec
;; SERVER: 68.94.157.9#53(68.94.157.9)
;; WHEN: Fri Mar 02 12:01:07 CST 2018
;; MSG SIZE  rcvd: 42

Marcels-iMac:~ marcel$ dig @68.94.157.9 bagtheweb.com

; <<>> DiG 9.9.7-P3 <<>> @68.94.157.9 bagtheweb.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31350
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bagtheweb.com.         IN  A

;; ANSWER SECTION:
bagtheweb.com.      60  IN  A   184.73.200.185
bagtheweb.com.      60  IN  A   23.23.171.5
bagtheweb.com.      60  IN  A   50.17.234.140
bagtheweb.com.      60  IN  A   174.129.203.239
bagtheweb.com.      60  IN  A   204.236.236.192
bagtheweb.com.      60  IN  A   107.22.233.200
bagtheweb.com.      60  IN  A   23.21.55.239
bagtheweb.com.      60  IN  A   23.23.215.144

;; Query time: 54 msec
;; SERVER: 68.94.157.9#53(68.94.157.9)
;; WHEN: Fri Mar 02 12:01:09 CST 2018
;; MSG SIZE  rcvd: 170

1 Answer 1

2

Is there anything else I can do to investigate or force an update (besides call AT&T and waste 4 hours of my life)?

Nope. You've done your part by setting up the records with the provider and the provider performed the requested zone transfer.

Is there something I could have done before the zone transfer to eliminate this problem?

Maybe? You might have been able to set a REALLY low TTL, like 5-minutes, but even that has to replicate throughout the DNS infrastructure before it really matters.

AT&T sucks

It's more specific that most ISP hosted DNS is generally crap. They're not built for speed, but to help eliminate the unnecessary transfer of data through other networks (which typically costs money); which means really large and heavy caching . It's also easier for them to host their own DNS and provide these values to their customers via DHCP. Par for the course.

I wonder if other users out there could be experiencing the same problem

This is likely something specific to the AT&T DNS infrastructure and I'm betting after their DNS servers finish their refreshes, they'll like be fine.

I know that I can fix the problem for myself by using Google's DNS, but

You should probably already do this. By the way, IBM's new DNS service is typically VERY fast: 9.9.9.9

1
  • I noticed my NS records had TTLs of 24 hours. I'm thinking I should have set that really small a day before doing the change. But then again I'm not sure it would have actually helped, because nothing changed after 24 hours. AT&T's DNS still returned fail half the time. Now that it's been several days everything works. I'm pretty sure AT&Ts DNS simply ignores the TTL and goes with something like 48 hours. To me that constitutes "sucking".
    – mpoisot
    Mar 5, 2018 at 18:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .