some fundamental delegation concept questions...

Kevin Darcy kcd at daimlerchrysler.com
Tue Aug 22 22:21:38 UTC 2000


The trouble is that the Internet 168.192.in-addr.arpa can't have any
meaningful delegations. So if you want to use anything under
168.192.in-addr.arpa, you have to make your own arrangements to do so, since
normal iterative querying on the Internet won't help you find the
nameserver(s) for any of its subzones.

Having said that, it's not clear how your internal nameservers resolve
queries outside of their authoritative data. Do they

1) Use an internal root?
2) Use a forwarder?
3) Talk to Internet nameservers (presumably through some sort of filtering
router)?

If (1), then just delegate 2.168.192.in-addr.arpa directly from the internal
root or from whatever subzone (arpa, in-addr.arpa, 192.in-addr.arpa or
168.192.in-addr.arpa) is appropriate.

If (2) or (3), you could define 2.168.192.in-addr.arpa or
168.192.in-addr.arpa on *every* internal nameserver as either master or
slave, so that they all have this data locally and don't need to ask any
other nameserver about it. With BIND 8, you also have the option of
per-domain forwarding or stub zones, which are more sophisticated forms of
"zone override".

With (2), you have additional options, which could save you the hassle of
having to reconfigure every internal server: you could maintain
2.168.192.in-addr.arpa or 168.192.in-addr.arpa directly on the forwarder, or
you could make it a slave to proxy01 for the zone. With BIND 8, again, you
have the per-domain forwarding and stub options. This approach is somewhat
perverse, however, since it means your internal servers will be obtaining
internal data through your forwarder which they could just as easily get
directly.


- Kevin
Palmer, Neal wrote:

> Hi all,
>
> Thanks to those who helped earlier - I'm still stuck and I think it's a
> problem with understanding and wires getting crossed, or my just being =
> more
> suited to strawberry picking.
>
> Anyway, can I throw some queries past you, see what you think... =
> forgive my
> lack of site specific information, but I tried that...
>
> - Our main domain (uwic.ac.uk) holds all its A (forward) and PTR =
> (reverse)
> records for itself, as I would expect all other domains do.
>
> - Our intended subdomain (internal.uwic.ac.uk) proxy01 nameserver hold =
> lots
> of A and PTR records for the 192.168.2.x range (in their proper files). =
> This
> also works fine.
>
> - I want to delegate all queries re: the internal range, to the =
> internal
> nameserver (proxy01). I guess that we are using a private range is =
> annoying
> but, er, out of my hands...
>
> - Therefore I should not have to hold any PTR records for an internal =
> domain
> (internal.uwic.ac.uk) on my external nameserver (csu1). Otherwise, as
> mentioned, csu1 will resolve queries and my internal nameserver =
> (proxy01)
> will never know anything about the query.
>
> - Trouble is, a HP course I've just been on, the course notes, and the =
> DNS
> O'Reilly book all suggest you should have a x.x.in-addr.arpa reverse =
> lookup
> file on your 'parent' nameserver. This is confusing me. My forward =
> lookups
> are being resolved properly by the internal server because of my glue
> records and the named.boot record on csu1.
>
> ;db.hosts:
> internal                        IN      NS      =
> proxy01.internal.uwic.ac.uk.
> proxy01.internal                IN      A       192.168.2.3             =
>    =20
>
> ;named.boot:
> secondary       2.168.192.in-addr.arpa
> internal.llandaff.hosts.rev.2
>
> - If I remove the reverse lookup file (internal.llandaff.hosts.rev.2) =
> from
> the external (csu1) setup, the reverse query timeout's (as it cant find =
> the
> specified file).
>
> - If I leave it in and use any combination of the following, I still =
> get
> 'host/domain not known'=20
>
> ;                               IN      NS      csu1.uwic.ac.uk.   =20
> ;                               IN      NS      =
> proxy01.internal.uwic.ac.uk.
>
> ;3                              IN      NS      =
> proxy01.internal.uwic.ac.uk.
>
> ;3                                      PTR     =
> proxy01.internal.uwic.ac.uk.
>
> So, do I need the reverse lookup file on csu1 or should it only exist =
> on the
> on the internal nameserver. If it does only exist on the internal, how =
> do
> the reverse lookups get resolved as there is no ip-to-address reference =
> to
> the internal from external.
>
> At the end of the day, all I need to do is pass reverse lookup queries, =
> say
> 192.168.2.4, down to the internal and get the correct answer. The =
> external
> should know nothing of the internal's IP records aside from the =
> internal
> nameserver itself (?).
>
> If I win the lottery, I'll buy the plane and fly you all to Elja=EF =
> Salim's
> for beer (maybe ;)
>
> Cheers again all,
>
> Neal.






More information about the bind-users mailing list