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