[TriLUG] DNS problems

[Aaron S. Joyner]

Brian Henning wrote:

> Yep, about the time I got Rick's answer, I checked again and all was
> well with the world.  Well, at least as far as my DNS is concerned.
>
> I kept my mouth shut because I knew Joyner would have words of wisdom
> worth keeping around for posterity (or future hair-pulling moments).
> ;-)  In this case, it was the +trace option to dig that I needed to know.
>
> Cheers,
> ~Brian
>
> Aaron S. Joyner wrote:
>
>> Rick DeNatale wrote:
>>
>>> On 4/13/06, Brian Henning <brian at strutmasters.com> wrote:
>>>  
>>>
>>>> Hi Folks!
>>>>   We just registered a domain in the .com.mx TLD.  Wahoo.  Here's the
>>>> problem:
>>>> ... lots snipped ...
>>>> % dig www.strutmasters.com.mx
>>>> --snip--
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10002
>>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>>>
>>>> ;; QUESTION SECTION:
>>>> ;www.strutmasters.com.mx.       IN      A
>>>>
>>>> ;; AUTHORITY SECTION:
>>>> com.mx.                 465     IN      SOA     a.ns.mx.
>>>> hostmaster.nic.mx. 446764 3600 300 604800 1800
>>>> --snip--
>>>
So the question that begs to be asked is, did you try and run this query
right after registering the domain?  Or did you just have the really bad
fortune of going to look moments before they put the zone entry into
place?  I'm still at a loss to explain why you got the answer displayed
above, other than a NXDOMAIN (sorry, not NACK, was sleepy last night
apparently), which just seems so very unlikely.  Have you seen any
anomalous behavior since then?  Who runs your resolver?  Do you run it,
or does your ISP?  I suppose it's possible if it's your ISP's name
server and they have the NXDOMAIN timeout artificially / aggressively
cranked up really high for all NXDOMAIN queries (would require custom
hackery?), you might see this behavior over a longer window of time. 
Hmmm... the TTL on the com.mx SOA is 86400 (one day).  In that Authority
section above your nameserver is going to expire it in 465 seconds (~7
mins), and the negative caching time (the last value of the 2nd line,
because it's wrapped, above) as 1800 seconds (aka 30 mins).  So that
expands the window some of how long you had to make this error (to 30
mins), and confirms that in the last day people had been trying to look
up things in the com.mx domain.  In fact, it looks like you really did
pick the worst time, ie. I suppose you have to had tried looking up
strutmasters.com.mx some time less than 30 mins before they added
strutmasters.com.mx to the com.mx zone, started troubleshooting after it
was enabled, and then discovered the strange situation before that 30
min window of negative caching expired.  Perhaps if you were looking for
it through out the day every few mins, and then saw it added in dig, or
maybe even a remote colleague or the registrar itself let you know that
it was live now, but were confused why you still couldn't resolve it
locally, that would lead you to this situation?

Aaron S. Joyner