authoritative "forward" zone - possible?

[phn at icke-reklam.ipsec.nu]

Justin Mason <jm at jmason.org> wrote:
> Hi there -- I'm trying an unusual situation here, and it doesn't
> seem to be working.


> I have a dynamic zone, and a daemon that will act as a nameserver,
> generating data in that zone based on queries coming from clients.
> rbldnsd is a good example of this.

> I don't want to dedicate an IP address to this zone, so I thought
> a good way to do this would be to use BIND's "type forward" zone
> support:

>   zone "v.yerp.org" IN {
>           type forward;
>           forward first;
>           forwarders {
>                   127.0.0.1 port 55;
>           };
>   };

> IOW, run the non-BIND ns on port 55, and let clients access it through
> BIND's forwarded zone.   This means I can keep BIND running on that
> machine, great!

> So: this works if I point clients at the nameserver directly; but if I let
> them use the normal TLD delegation lookup, it fails.

> The 2LD zone delegates to the v.yerp.org subdomain correctly (afaik):

>   yerp.org. IN SOA ns1.boxhost.net. jm.jmason.org. (
>                                           2004000021
>                                           3600 600 604800 3600 )
>   yerp.org.       IN NS   ns1.boxhost.net.
>   ns1.boxhost.net. IN A   195.218.96.101
>   yerp.org.       IN NS   ns6.gandi.net.
>   ns6.gandi.net.  IN A    217.70.177.40

>   v.yerp.org.     IN NS   ns2.yerp.org.
>   ns2.yerp.org.   IN A    64.142.3.174


> (Note: that's on another server entirely, ns1.boxhost.net.)

> A "dig +trace", however, seems to indicate that the ns2 host (where the
> forward zone is running) doesn't want to be authoritative for the zone:

>   : jm 1726...; dig test.com.v.yerp.org TXT +trace

>   ; <<>> DiG 9.2.4rc5 <<>> test.com.v.yerp.org TXT +trace
>   ;; global options:  printcmd
>   .                       517766  IN      NS      H.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      I.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      J.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      K.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      L.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      M.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      A.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      B.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      C.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      D.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      E.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      F.ROOT-SERVERS.NET.
>   .                       517766  IN      NS      G.ROOT-SERVERS.NET.
>   ;; Received 436 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

>   org.                    172800  IN      NS      TLD1.ULTRADNS.NET.
>   org.                    172800  IN      NS      TLD2.ULTRADNS.NET.
>   ;; Received 119 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 96 ms

>   yerp.org.               86400   IN      NS      ns6.gandi.net.
>   yerp.org.               86400   IN      NS      ns1.boxhost.net.
>   ;; Received 90 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 41 ms

>   v.yerp.org.             3600    IN      NS      ns2.yerp.org.
>   ;; Received 72 bytes from 217.70.177.40#53(ns6.gandi.net) in 186 ms

>   org.                    170720  IN      NS      TLD1.ULTRADNS.NET.
>   org.                    170720  IN      NS      TLD2.ULTRADNS.NET.
>   ;; Received 87 bytes from 64.142.3.174#53(ns2.yerp.org) in 34 ms


> So the request never gets forwarded to the forwardee nameserver daemon --
> this happens within BIND.  Is there any way to make BIND think it's
> authoritative for that zone?   Am I missing something?  Have I screwed up
> my delegation there?

> (BTW, the v.yerp.org zone is currently down, so any queries to that
> will fail.)

I think that part of your problems is that other nameservers asking your 
nameserver does this with Recursion off. Thus your nameserver does not
forward.


You might think of running the dynamic zone on bind instead, changing 
your daemon to inject dyndns requests to bind instead of running the
zone itself. Or you should do a full delegation (but then you need
another IP as you correctly observed(unless that can be done with NAT tricks)


> --j.


-- 
Peter Håkanson         
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out,
	   remove "icke-reklam" if you feel for mailing me. Thanx.