I haven't changed
anything related to the DNS entry for
serverfault.com, but some users were reporting today that href="https://meta.stackexchange.com/questions/7070/serverfault-down-how-to-get-into-superuser-beta/7079#7079">the
serverfault.com DNS fails to resolve for
them.
I ran a href="http://just-ping.com/index.php?vh=serverfault.com&c=&s=ping!"
rel="nofollow noreferrer">justping query and I can sort of confirm this --
serverfault.com dns appears to be failing to resolve in a handful of countries, for no
particular reason that I can discern. (also confirmed via href="http://www.whatsmydns.net/" rel="nofollow noreferrer">What's My DNS
which does some worldwide pings in a similar fashion, so it's confirmed as an issue by
two different sources.)
href="https://i.stack.imgur.com/pu7UO.png" rel="nofollow noreferrer"> src="https://i.stack.imgur.com/pu7UO.png"
alt>
Why
would this be happening, if I haven't touched the DNS for serverfault.com
?our registrar is (gag) GoDaddy, and
I use default DNS settings for the most part without incident. Am I doing something
wrong? Have the gods of DNS forsaken
me?is there anything I can do to fix
this? Any way to goose the DNS along, or force the DNS to propagate correctly
worldwide?
Update:
as of Monday at 3:30 am PST, everything looks correct.. JustPing reports site is
reachable from all locations. Thank you for the many very informative responses, I
learned a lot and will refer to this Q the next time this
happens..
This is
not directly a DNS problem, it's a network routing problem between some parts of the
internet and the DNS servers for serverfault.com. Since the nameservers can't be reached
the domain stops resolving.
As far as I can tell
the routing problem is on the (Global Crossing?) router with IP address
204.245.39.50
.
As href="https://serverfault.com/questions/42678/dns-failing-to-propagate-worldwide/42686#42686">shown
by @radius, packets
to ns52 (as used by href="http://stackoverflow.com">stackoverflow.com) pass from here to
208.109.115.121
and from there work correctly. However packets
to ns22 go instead to
208.109.115.201
.
Since
those two addresses are both in the same /24
and the
corresponding BGP announcement is also for a /24
this
shouldn't happen.
I've done
traceroutes via my network which ultimately uses MFN Above.net instead of Global
Crossing to get to GoDaddy and there's no sign of any routing trickery below the
/24
level - both name servers have identical traceroutes from
here.
The only times I've ever seen
something like this it was broken href="http://en.wikipedia.org/wiki/Cisco_Express_Forwarding" rel="nofollow
noreferrer">Cisco Express Forwarding (CEF). This is a hardware level cache
used to accelerate packet routing. Unfortunately just occasionally it gets out of sync
with the real routing table, and tries to forward packets via the wrong interface. CEF
entries can go down to the /32
level even if the underlying
routing table entry is for a /24
. It's tricky to find these
sorts of problems, but once identified they're normally easy to
fix.
I've e-mailed GC and also tried to speak to
them, but they won't create a ticket for non-customers. If any of you
are a customer of GC, please try and report
this...
UPDATE at 10:38
UTC As Jeff has noted the problem has now cleared. Traceroutes to both
servers mentioned above now go via the 208.109.115.121
next
hop.
Comments
Post a Comment