I'm soo close...but still having problems

[Kevin Darcy]

Jason wrote:

>I'm working on setting up a private internal name for our company LAN. I 
>went ahead and setup BIND 8.3.2. It is working perfectly as a caching 
>server. No problems resolving domains using dig.
>
>The problem arises when I try to setup a zone to hold internal hosts so 
>my private LAN can access them by name, and not by IP address.
>
>In my named.conf, I added my ISP's IP addresses to the forwarders 
>section to take advantage of their cache.
>
>Snips of named.conf:
>
>zone "." {
>         type hint;
>         file "named.root";
>};
>
>zone "0.0.127.IN-ADDR.ARPA" {
>         type master;
>         file "localhost.rev";
>};
>
>
>I then added this:
>
>zone "internal.huggybear.com" {
>    type master;
>    file "huggybear.db";
>};
>
>zone "192.168.in-addr.arpa" in {
>    type master;
>    file "192.168.db";
>};
>
>Here are the contents of huggybear.db:
>
>$TTL 3h
>internal.huggybear.com.  IN  SOA  scarydaemons.huggybear.com. 
>root.scarydaemons.huggybear.com. (
>                                 1   ;
>                                 3h  ;
>                                 1h  ;
>                                 1w  ;
>                                 1h )
>
>internal.huggybear.com.   IN  NS  scarydaemons.huggybear.com.
>
>localhost.internal.huggybear.com.    IN  A  127.0.0.1
>scarydaemons.huggybear.com.          IN  A  192.168.1.92
>loanblade.internal.huggybear.com.    IN  A  192.168.1.207
>
>
>Scarydaemons is the box im setting bind upon (FreeBSD 4.9)
>
>The contents of 192.168.db:
>
>$TTL 3h
>168.192.in-addr.arpa.  IN  SOA  scarydaemons.huggybear.com. 
>root.scarydaemons.huggybear.com. (
>                                 1h
>                                 3h
>                                 1h
>                                 1w
>                                 1h )
>
>168.192.in-addr.arpa.  IN  NS  scarydaemons.huggybear.com.
>
>92.1.168.192.in-addr.arpa.  IN PTR  scarydaemons.huggybear.com.
>
>207.1.168.192.in-addr.arpa  IN PTR  loanblade.internal.huggybear.com.
>
>
>I think im very close, but can't figure it out.
>
>Contents of /etc/resolve.conf:
>
>search internal.huggybear.com
>nameserver      192.168.1.92
>
>But, I fail when I try and do a dig for loanblade for example:
>
>scarydaemons# dig loanblade
>
>; <<>> DiG 8.3 <<>> loanblade
>;; res options: init recurs defnam dnsrch
>;; got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23683
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>;; QUERY SECTION:
>;;      loanblade, type = A, class = IN
>
>;; AUTHORITY SECTION:
>.                       2h52m11s IN SOA  a.root-servers.net. 
>nstld.verisign-grs.com. (
>                                         2004030201      ; serial
>                                         30M             ; refresh
>                                         15M             ; retry
>                                         1W              ; expiry
>                                         1D )            ; minimum
>
>
>;; Total query time: 0 msec
>;; FROM: scarydaemons.huggybear.com to SERVER: 192.168.1.92
>;; WHEN: Wed Mar  3 17:07:05 2004
>;; MSG SIZE  sent: 27  rcvd: 102
>
"dig" doesn't do domain-searching (thank goodness, since 
domain-searching is an evil feature that leads inevitably to Shortname 
Disease), so your nameserver rightfully replies that the name 
"loanblade" doesn't exist in the root zone.

>Another output:
>
>scarydaemons# dig loanblade.internal.huggybear.com
>
>; <<>> DiG 8.3 <<>> loanblade.internal.huggybear.com
>;; res options: init recurs defnam dnsrch
>;; got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30739
>;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>;; QUERY SECTION:
>;;      loanblade.internal.huggybear.com, type = A, class = IN
>
>;; AUTHORITY SECTION:
>courtesymortgage.com.   2h38m5s IN SOA  ns1.aspadmin.com. 
>domain_control.huggybear.com. (
>                                         1075334555      ; serial
>                                         12H             ; refresh
>                                         2H              ; retry
>                                         2W              ; expiry
>                                         12H )           ; minimum
>
>
>;; Total query time: 0 msec
>;; FROM: scarydaemons.huggybear.com to SERVER: 192.168.1.92
>;; WHEN: Wed Mar  3 17:07:32 2004
>;; MSG SIZE  sent: 57  rcvd: 121
>
Are you editing this output? The SOA record in the response above 
implies that you queried a name in the "courtesymortgage.com" zone, not 
the "huggybear.com" zone. It also happens to be the case that an 
NXDOMAIN response for "loanblade.internal.courtesymortgage.com" is 
exactly 121 bytes, but an NXDOMAIN response for 
"loanblade.internal.huggybear.com" would be 107 bytes. Just a coincidence?

It's very hard to troubleshoot problems when stuff is being obscured 
and/or changed around.

In any case, assuming that all of the "huggybear.com" stuff is really 
"courtesymortgage.com", then it would appear that your 
internal.courtesymortgage.com zone is not loading properly. Since it's 
not loading properly, your nameserver is therefore forwarding the query 
to your ISP's nameserver which is responding with the NXDOMAIN (and your 
nameserver will cache that negative response).

Look in the logs for why the zone isn't loading properly.

Another outside possibility is that the zone is not defined properly in 
named.conf (although the snippet you showed appeared to be syntactically 
correct). You didn't accidentally include the zone definition in a 
comment, did you? And you did do some form of reload or reconfig+reload 
after modifying named.conf, right?

- Kevin