Forward external queries

[Kevin Darcy]

Kris wrote:

>Hi,
>
>I'm looking for the simplest way to forward all external (public)
>queries to an external DNS server. What I did in named.conf is this
>(see below), but the problem is that when I'm trying to resolve a
>public name like google.com it doesn't work when querying my server.
>If I define a specific forward zone for "org" or "com", and specify
>that external DNS server as the master for that zone, it works fine
>(that's what I did as a [stupid] workaround for the common tld names).
>What do I have to configure in order to make it work without adding a
>zone statement for every top level domain name ?
>
>named.conf
>
>(...)
>view "internalview1" {
>        match-clients {any;};
>        notify yes;
>        allow-query { internal-networks; 127.0.0.1;};
>
That's a little unorthodox. Usually, in a view-based config, the earlier 
views are restricted to your own networks, and then everything else, 
i.e. external clients, "falls through" to the "match-clients { any; };" 
view at the end. But here, you have a restrictive (via allow-query) view 
at the very end. Is there any particular reason to do it that way? Would 
an external client ever fall through to this view? What do the other 
view definitions look like (you elided them)?

>        forwarders {
>                10.1.1.1;
>                10.1.1.2;
>        };
>        recursion yes;
>
Note that "forward first" is the default, i.e. opportunistic forwarding, 
or forward-if-possible-but-if-timeout-resolve-iteratively. Hopefully 
that's what you wanted. If you lack direct connectivity to the Internet 
DNS, and your only way of resolving DNS is through those forwarders, 
then you'd want "forward only" rather than the default "forward first". 
Otherwise, you may get into a thrashing situation if your forwarders 
become unavailable (named will hammer away trying to talk to the 
Internet DNS)

>
>zone "myzone.example.com" in {
>        type master;
>        file "myzone.example.com.hosts";
>        allow-transfer { 192.168.1.2; };
>};
>
Now I'm starting to get even more confused. Why define a master zone in 
your internal view? Are you in a NAT situation where the addresses in 
here are *different* than what is published to the Internet? I could 
understand it if that were the case. Otherwise, it baffles me.

>
>zone "." IN {
>        type hint;
>        file "named.ca";
>};
>
I don't think this is strictly speaking necessary, even in "forward 
first" mode, since named can get the root-zone information via the 
forwarders when it "primes" at startup.

>
>zone "localdomain" IN {
>        TYPE master;
>        file "localdomain.zone";
>};
>
>zone "0.0.127.in-addr.arpa" IN {
>        type master;
>        file "named.local";
>};
>
>zone "255.in-addr.arpa" IN {
>        type master;
>        file "named.broadcast";
>};
>
>zone "0.in-addr.arpa" IN {
>        type master;
>        file "named.zero";
>};
>
>zone "168.192.in-addr.arpa" in {
>        type master;
>        file "192.168.rev";
>        allow-transfer { 192.168.1.2; };
>};
>
>};
>
>Also, are these zone really necessary (".", "localdomain",
>"0.in-addr.arpa", ...) ?
>
Good question. Do you have any apps that look up names in any of those 
zones?

Offhand, despite the questions I raised, it looks to me like this config 
should work for resolving Internet names *without* having to define TLD 
zones, assuming the query comes from one of the "internal-networks" 
ranges, and that the forwarders are available and resolving Internet 
DNS. What kind of error did you get? A SERVFAIL? A timeout? What? 
"Doesn't work" isn't very specific...

                                                                         
                                                      - Kevin