Simon,
Thank you again.
For reasons I can't understand we are now able to do # nslookup vly and get a result. The dig axfr worked correctly and my secondaries all see the information.
Oddly I can't get a result from
# nslookup 10.57.39.242
The IP of vly, though I do see it in the tables, and I can use dig axfr for 39.57.10.in-addr.arpa and I see it when the zones transfers to my screen.
Very odd...
Resolving in primary after restarting the daemon.
Resolving on old primary (now a slave for these new zones) after restarting on that machine, or rather, after removing zone file and restarting the server.
I must have jammed something, not sure what.
Thank you very much for talking me through this. I will remove the zone files and restart the daemons on the rest of the dns slave servers.
Brian
-----Original Message-----
From:
[hidden email] [mailto:
[hidden email]] On Behalf Of Simon Hobson
Sent: Thursday, March 26, 2015 2:03 PM
To: Users of ISC DHCP
Subject: Re: dynamic dns tables, missing "IN"
"Cuttler, Brian (HEALTH)" <
[hidden email]> 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.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
