dname reverse delegation

[Mark Andrews]

Why are you trying to complicate the lookup process unnecessarially?

Just delegate 13.168.192.IN-ADDR.ARPA.  People over use stuff that
really isn't needed and by doing so turn a relatively simple
proceedure into a complicated mess.

RFC 2317 delegation techniques really should only be used for /25
-> /32 sized address assignments.  Despite what RFC 2317 says,
you can delegate down to the individual reverse name.  RFC 2317
main purpose is reducing the number of delegations that need to
be made.

Forwarders are overused when a simple delegation is all that is
needed.

People forget that not all nameservers are configured to recurse
when testing.

In message <005001d105f7$664cdf70$32e69e50$@meganet.net>, "Paul A" writes:
> 
> I have a few /24 that I want to delegate using DNAME.
> 
> Lets says I have 192.168.13.0/24 how would I go about doing reserve on the
> forwarding server using DNAME.
> 
> Currently on the forwarding server I have 
> 
>                         NS ns.isp.com
> ;;
>                         DNAME 0/24
> ;;
> 
> ;;; delegate to server
> 
> 0/24    NS      ns.someserver.com.

If the zone fragment above expands out to below then the NS record
is hidden by the DNAME record during normal resolution.

13.168.192.IN-ADDR.ARPA.	NS ns.isp.com.
13.168.192.IN-ADDR.ARPA.	DNAME 0/24.13.168.192.IN-ADDR.ARPA.
0/24.13.168.192.IN-ADDR.ARPA.	NS ns.someserver.com.

Looking up 1.13.168.192.IN-ADDR.ARPA will result in this set of
CNAMES.  I suspect you got away with this due to the local server
also serving 0/24.13.168.192.IN-ADDR.ARPA which resulted in you
hitting a different zone.

1.13.168.192.IN-ADDR.ARPA CNAME 1.0/24.13.168.192.IN-ADDR.ARPA
1.0/24.13.168.192.IN-ADDR.ARPA CNAME 1.0/24.0/24.13.168.192.IN-ADDR.ARPA
1.0/24.0/24.13.168.192.IN-ADDR.ARPA CNAME 1.0/24.0/24.0/24.13.168.192.IN-ADDR.ARPA
....

> On the server handling the PTRs (ns.someserver.com) I have:
> 
> zone "0/24.13.168.192.IN-ADDR.ARPA" {
>         type master;
>         file "/slvdb/db.13.168.192";
>         };
> 
> In the PTR server the zone file looks like a normal PTR file and when I
> query on this server its working, I get the DNAME/CNAME and PTR. 

See above about the local zone preventing the looping which would normally
happen.
 
> However when I query on the forwarding server it's not working, I just keep
> getting the CNAME over and over again but not actual PTR.

Which is what happens when you don't have the second zone.
 
> Shouldn't the forwarding server query the PTR server since it has a 0/24 NS
> RR? It seems like because of the above DNAME RR it expects and zone file for
> the 0/24. However I just want to forward this. 

No.
 
> I know I can probably just slave off the PTR server but I rather try and do
> it this way unless someone suggests otherwise. 
> 
> Any ideas, thanks Paul

Stop trying to be overly smart.  If you really must use a DNAME do something
like this.

13.168.192.IN-ADDR.ARPA. DNAME in-addr.arpa.example.net.

zone "in-addr.arpa.example.net" {
        type master;
        file "/masterdb/db.in-addr.arpa.example.net";
};

And don't forget to slave the zone with the DNAME record so that local
resolution works when the external network is down.

zone "13.168.192.IN-ADDR.ARPA" {
	type slave;
	masters { ..... };
	file "/slvdb/db.13.168.192";
};

or

zone "168.192.IN-ADDR.ARPA" {
	type slave;
	masters { ..... };
	file "/slvdb/db.168.192";
};

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org