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:
Our current domestic web host provides our DNS for our
strutmasters.com.mx domain name, and is properly configured:
% dig www.strutmasters.com.mx @ns5.esosoft.net
--snip--
;; ANSWER SECTION:
www.strutmasters.com.mx. 43200 IN CNAME strutmasters.com.mx.
strutmasters.com.mx. 43200 IN A 161.58.166.59
--snip--
However, if I do a top-down dig of www.strutmasters.com.mx, I get:
% 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--
(but if I dig for just strutmasters.com.mx, I get the correct authority
section:
;; AUTHORITY SECTION:
strutmasters.com.mx. 41836 IN NS ns5.esosoft.net.
strutmasters.com.mx. 41836 IN NS ns6.esosoft.net.
strutmasters.com.mx. 41836 IN NS ns7.esosoft.net.
)
That smells to me (a complete novice in the DNS world) like the .com.mx
TLD authority (a.ns.mx) is misconfigured and doesn't realize that
*.strutmasters.com.mx should fall to the same authority as
strutmasters.com.mx.
I think that what it really means is that you've got a default dns
server which has cached an entry before your domain got to the tld
servers which hasn't expired yet.
If I look for www.strutmasters.com.mx I get:
$ dig www.strutmasters.com.mx
---snip---
;; QUESTION SECTION:
;www.strutmasters.com.mx. IN A
;; ANSWER SECTION:
www.strutmasters.com.mx. 42859 IN CNAME strutmasters.com.mx.
strutmasters.com.mx. 42859 IN A 161.58.166.59
;; AUTHORITY SECTION:
strutmasters.com.mx. 42859 IN NS ns7.esosoft.net.
strutmasters.com.mx. 42859 IN NS ns5.esosoft.net.
strutmasters.com.mx. 42859 IN NS ns6.esosoft.net.
;; ADDITIONAL SECTION:
ns5.esosoft.net. 56208 IN A 38.118.200.5
ns6.esosoft.net. 56208 IN A 38.118.200.6
ns7.esosoft.net. 55992 IN A 66.159.208.230
So I'd look closer to home for the problem. Are you running a local
caching name server? Had you done a lookup of www.strutmasters.com.mx
which failed earlier?
If you can't get whatever upstream dns server to flush the cache, the
solution might be just to wait for the cache entry to expire.
Rick's assessment is mostly correct. I don't know why you're not seeing
the correct answer back from what ever local resolver you're using (what
ever is in your resolv.conf, which is what's used when you don't specify
a server). All I know from the output you've provided is that a) it'll
work for everyone who's not using that local resolver, and b) that local
resolver can't chase past com.mx, because it probably got an
authoritative NACK (ie. no such record) from com.mx when it first tried
to chase strutmasters.com.mx. That negative caching shouldn't last long
though, probably not long enough for you to gather the information to
compose your email above (like, 5-10 mins). Another possibility is that
you've horribly misconfigured the local resolver, and it thinks it's
responsible for com.mx, and doesn't know about strutmasters.com.mx, but
that's also rather unlikely. It's even more unlikely because the TTL on
the SOA isn't a round number (465), indicating it's probably in the
process of expiring as you were writing the above email, which wouldn't
happen if it were authoritative for com.mx. So I'm at a loss to explain
the dig output you pasted w/o more info.
So in short, as Rick suggested, things are fine from the outside world,
look at your local resolver more closely. An `rndc flush` or analysis
of the output from `rndc dump_db` might prove useful if the problem
still exists.
Here's what the outside world sees, as a +trace:
[EMAIL PROTECTED]:~$ dig +trace www.strutmasters.com.mx
; <<>> DiG 9.3.1 <<>> +trace www.strutmasters.com.mx
;; global options: printcmd
. 113105 IN NS M.ROOT-SERVERS.NET.
. 113105 IN NS A.ROOT-SERVERS.NET.
. 113105 IN NS B.ROOT-SERVERS.NET.
. 113105 IN NS C.ROOT-SERVERS.NET.
. 113105 IN NS D.ROOT-SERVERS.NET.
. 113105 IN NS E.ROOT-SERVERS.NET.
. 113105 IN NS F.ROOT-SERVERS.NET.
. 113105 IN NS G.ROOT-SERVERS.NET.
. 113105 IN NS H.ROOT-SERVERS.NET.
. 113105 IN NS I.ROOT-SERVERS.NET.
. 113105 IN NS J.ROOT-SERVERS.NET.
. 113105 IN NS K.ROOT-SERVERS.NET.
. 113105 IN NS L.ROOT-SERVERS.NET.
;; Received 244 bytes from 10.0.5.1#53(10.0.5.1) in 1 ms
mx. 172800 IN NS D.NS.mx.
mx. 172800 IN NS A.NS.mx.
mx. 172800 IN NS B.NS.mx.
mx. 172800 IN NS C.NS.mx.
;; Received 172 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 118 ms
strutmasters.com.mx. 86400 IN NS ns5.esosoft.net.
strutmasters.com.mx. 86400 IN NS ns6.esosoft.net.
strutmasters.com.mx. 86400 IN NS ns7.esosoft.net.
;; Received 106 bytes from 207.248.64.1#53(D.NS.mx) in 83 ms
www.strutmasters.com.mx. 43200 IN CNAME strutmasters.com.mx.
strutmasters.com.mx. 43200 IN A 161.58.166.59
strutmasters.com.mx. 43200 IN NS ns5.esosoft.net.
strutmasters.com.mx. 43200 IN NS ns6.esosoft.net.
strutmasters.com.mx. 43200 IN NS ns7.esosoft.net.
;; Received 184 bytes from 38.118.200.5#53(ns5.esosoft.net) in 21 ms
Good luck storming the castle... erm, chasing the problem!
Aaron S. Joyner
--
----------------
Brian A. Henning
strutmasters.com
336.597.2397x238
----------------
--
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/
