Firewall, split dns and the forwarders directive

[André Pirard]

Joseph S D Yao <jsdy at cospo.osis.gov> wrote:

>Andr PIRARD ecrit:
>> And if zardos forwards requests for names in fx.movie.edu zone to a
>> forwardee that's neither authoritative for fx.movie.edu nor for
>> movie.edu, the forwardee may well send the request back to zardos
>> because zardos is authoritative for movie.edu.
>> It's a mistake for a name server to make requests to servers that are
>> "further away from the answer" than they are.
>> It's not always possible to avoid such loops by configuration (to make
>> the forwarder or forwardee authoritative for all subzones).
>> BIND should not not forward requests for its subzones, at least at an
>> option.
>
>Andr, let me pose you a non-hypothetical question.
>
>Zone movie.edu is behind a firewall.  Thus its name server must forward
>non-local DNS requests to the firewall to be resolved.  The firewall is
>not in our direct control, and is not used as a zone name server (only
>as a cacheing name server).
>
>Because of {work overload, political concerns, inertia, whatever}, the
>domain fx.movie.edu is served by a separate name server within the
>firewall.
>
>Now, the order of operation is either {zone, forward} or {zone,
>forward, lookup}, depending on whether the "forward only" option is on
>or not.  This is BY DEFINITION - a part of BIND, you can't change that
>without breaking a good many things.  But we never want to forward
>requests for "fx.movie.edu" to the firewall.  We always want to ask the
>name server, which we KNOW [it's our subdomain, remember?].
>
>Andr, WITHOUT forwarding requests for our subdomain, which is a zone on
>a different server ... tell me how I may do this.  Demonstrate.
>
>Thank you.

Joseph,

In cases such as when a site is forwarding requests to its provider
and -- using the example again -- zardos is authoritative for
movie.edu but not for fx.movie.edu, then two cases exist:

a) The provider is not authoritative for fx.movie.edu zone, zardos
will forward requests to provider's forwardee and this forwardee will
try to query  zardos (not by "forwarding", because NS for movie.edu).
But the provider may also be able to successfully query another,
non-forwarding server authoritative for movie.edu "half of the time".
The site's user is caught in a trap visible only if the provider
checks his server log for loops. The cure, I suppose, is a nonobvious
zone fx.movie.edu { type forward; };
to cancel forwarding for that particular zone.

b) The provider *has to* be authoritative for fx.movie.edu zone (an
unusual case) for the "forward" option to work "unadorned" and without
surprises.

The problem is because "forward" tweaks the normal path of DNS queries
in a way that can be incorrect regarding the location of subzones
(querying "upwards" when the only valid way is "down").

If however requests for "subzones" (fx.movie.edu) of one (movie.edu)
the forwarding server (zardos) is authoritative for were *not*
forwarded by default, then both cases become:

A) would no longer be a trap, requests would follow NS and succeed

B) would work by itself too because forwardee is normally defined in a
NS (for fx.movie.edu) too

C) if the user had any reason to counteract the natural working of A
and B, that will probably be because he clearly sees that names are
not resolved (instead of not seeing DNS loops), and he can always use
zone fx.movie.edu { type forward; forwarders ...};
which is more obvious that the cancel form in (a).

No misdirects of DNS queries seem to remain unless the user goofs with
explicit misforwarding.

Please note that I encountered the above problem with some 4* release
(which was without the (a) solution and hence was crying for A-B) and
that I still have to practice 8* very soon.
My conclusions come from close documentation reading only.

So, if I understand you well, you concur by sitting in the trap I
describe and you hopefully haul yourself out with command A.
Unless a future BIND agrees with removing obscure DNS loops and hence
you just upgrade.

Hoping this can help, best regards.