Revers Zone
eastk
eastk at gte.net
Tue Aug 17 03:04:34 UTC 1999
QIP 5 will allow me to delegate to other servers for reverse DNS and any bit
boundary. It creates zones in the format of 22-4.10.in-addr.arpa. The
problem I have is with the use of these zones. Tools such as NSlookup and
ping -a fail to resolve against the reverse zones? I will go look at RFC
3127 and see if I need to do something more.
Thanks for your response...
Kevin
Jim Reid <jim at mpn.cp.philips.com> wrote in message
news:9080.934804765 at kludge.mpn.cp.philips.com...
> >>>>> "kevin" == eastk <eastk at gte.net> writes:
>
> kevin> I have a internal network running Bind 8.X. I am using the
> kevin> network 10.0.0.0 using VLSM. Masks are 255.254. and
> kevin> 255.255.252. I am using the 255.254 mask for areas and
> kevin> 255.255.252 for user subnets. The question has to do with
> kevin> reverse DNS. I want to setup Reverse DNS primary servers
> kevin> for each area. When I attempt to set them up the resulting
> kevin> domains are in the following format 22-4.10.in-addr.arpa,
> kevin> 22-6.10.in-addr.arpa, 22-8.10.in-addr.arpa. When I run
> kevin> tools like NSLookup they don't resolve in these domains.
> kevin> If I configure the entire 10 network for reverse it creates
> kevin> a file like 10.in-addr.arpa. I am using Lucent
> kevin> technologies QIP to create these files.
>
> This is probably the source of your problem. IIUC, QIP does not allow
> delegations of the reverse number space under its control. [Perhaps
> they have fixed that in a later version of the software. It wasn't
> done in the one I encountered.] If you tell QIP it "owns" network 10,
> it can only generate one monolithic zone file for the 10.in-addr.arpa
> domain and populate the zone file with PTR records. This is because
> QIP assumes that since it owns this network and all the hostnames and
> addresses are in its database, hosts will only be added or removed
> using their tool. You may be able to partition slices of your number
> space so that the network administrators for each slice can update the
> QIP database each time they add or remove hosts from their bit of the
> network. This should work OK, though you still get a monolithic zone
> file for 10.in-addr.arpa.
>
> I think that the model of QIP's database will make it difficult -
> perhaps even impossible - to do RFC3127-style reverse zone delegation.
> I'm presuming you want to set up zones like 22-6.10.in-addr.arpa and
> 22-8.10.in-addr.arpa and make A.B.C.10.in-addr.arpa a CNAME for some
> PTR record in say 22-6.10.in-addr.arpa.
>
> Disclaimer: I am not a QIP admin. However I have been on the receiving
> end of all sorts of nasty problems with zones and name servers that
> are under QIP control.
>
More information about the bind-users
mailing list