9.3.0rc2 and External Queries

[Kevin Darcy]

In order to troubleshoot a caching nameserver (technically, a "caching 
resolver"), you need to step through the algorithms that the resolver 
goes through. The first thing it does is read the hints file and then 
sends a non-recursive query for the root zone NS records to one of the 
root servers listed in the hints file. It then stores the results of 
that "priming" query for future reference. So mimic the nameserver and 
send a non-recursive root NS query (using "dig", that would be "dig 
+norec . ns @xxx.xxx.xxx.xxx") to one of the hints-file servers. If it 
doesn't work, try another server. If *none* of them work, then you have 
some sort of basic connectivity problem that you need to fix before your 
caching resolver will work. Maybe something in your setup is discarding 
all DNS packets (which are usually UDP). Or maybe your upstream provider 
is blocking or discarding for some reason.

If you are able to do the root NS query, that proves that you have at 
least _some_ connectivity to the Internet DNS. Next, try mimicing what 
the caching resolver does for a regular query. Send a non-recursive 
A-record query for some normal name -- you could use your 
"www.yahoo.com" test case if you want -- to the root servers. From a 
root server you should get back a referral (barring the exceptional case 
where that "normal" name happens to be the name of a server which hosts 
a TLD zone). Follow the referral (if any) down to the next level of the 
hierarchy, and send the same query to one of those servers. Repeat until 
you finally get an answer, an NXDOMAIN response (which means the name 
doesn't exist), a referral, or some response code besides NOERROR or 
NXDOMAIN. Note that the "+trace" option to "dig" is a convenient way to 
follow that whole algorithm. If you get to a point where you can't reach 
*any* of the delegated nameservers for a particular level of the 
hierarchy, then again, you have some sort of basic connectivity problem, 
although in this case, since it is specific to certain addresses or 
address ranges, I'd be more likely to suspect a routing or firewall 
issue (yes, I know you said you stopped ipchains, but circumstantial 
evidence is circumstantial evidence all the same...)

It's possible that while tracing queries in this way you may run across 
a level of the hierarchy where all of the delegated servers are giving 
error responses, e.g. SERVFAIL, REFUSED or something like that. This 
indicates a problem at the remote end, and is nothing you can fix in 
your configuration, unless the other side has some sort of weird 
source-port or source-address restriction, which you might be able to 
work around...

- Kevin

Scott Moseman wrote:

>I setup 9.3.0rc2 to be a secondary nameserver for some domains.
>It would resolve those domains just fine, but nothing external.
>So I followed the documentation and did a very basic cache-only
>setup (see my named.conf below), and external queries still do
>not work properly.  Any ideas?
>
>PS- I stopped ipchains to make sure it was not the problem.
>
>
># /usr/local/sbin/named -v
>BIND 9.3.0rc2
>
># cat /etc/named.conf
>
>options {
>        directory "/var/named";
>};
>
>zone "." {
>        type hint;
>        file "named.root";
>};
>
>zone "0.0.127.in-addr.arpa" {
>        type master;
>        file "db.0.0.127.in-addr.arpa";
>        allow-update { none; };
>        notify no;
>};
>
># cat /etc/resolv.conf 
>nameserver [my_ip_address]
>domain [my_domain_name]
>
># /etc/init.d/ipchains stop
># /usr/local/sbin/named -c /etc/named.conf
>
># nslookup -sil www.yahoo.com
>;; connection timed out; no servers could be reached
>
>
>Thanks,
>Scott Moseman
>
>
>
>
>
>  
>