dynamic dns tables, missing "IN"

[Simon Hobson]

"Cuttler, Brian (HEALTH)" <brian.cuttler at health.ny.gov> wrote:

> This is working fine, was working fine?
> 
> Oddly, I'm finding that my current Forward tables is miswritten.
> 
> The SOA looks ok, but the records look like this.
> 
> Namename  A   ip.number.octet.here
>          Txt machine fingerprint
> 
> The "IN" Internet record flag is missing, queries to the server are failing.

The former is perfectly OK, the later is not a result of it !
BIND defaults to IN as the namespace type if it's not specified, and I can assure you that leaving it out has no bad effects (it's not in most of the zone files (around 600 !) I manage at work)

> At this point I might also say that our dynamic IP range is 10.57.36.10 (because we leave a little room at the bottom for routers, etc) to 10.57.39.150, because I left 100 IPs at the very end of the range for static addresses, as not all machines on the network do proper DHCP. For those machines I've manually added some records manually from 10.57.39.250 and counting backwards.
> 
> I may have caused my own problems, don't know.
> 
> Manually added the "IN" to all of the A and TXT records, but they have disappeared again, breaking nslookup results.
> 
> My reverse tables show the same result.

Try a few things :
what do you get if you do "dig @localhost <yourdomainnamehere> axfr" on the DNS server ? You should get a dump of the forward zone.
what do you get from "dig @localhost 36.57.10.in-addr.arpa axfr" ? Should get a dump of that part of your IP space reverse lookup. Repeat with 37.57.10.in-addr.arpa, 38.57.10.in-addr.arpa, and 39.57.10.in-addr.arpa.

If you get failures due to zone transfer restrictions, you may need to tweak the restrictions a little - also try replacing localhost with the server's actual IP address.

Next, I'd normally suggest (ideally from a different machine), doing "dig +trace <yourdomainnamehere> ns" and "dig +trace <yourreversedomainhere> ns". But that doesn't work for "private" DNS space.

SO check the DNS resolvers configured on your clients, and make sure that all of them have correctly defined your forward and reverse zones. If the resolvers are not the same servers as your DNS, then failure to correctly specify either forwarders, secondary zones, or stub zones for each of your private DNS zones will result in lookup failures.