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 <[EMAIL PROTECTED]> 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 -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
