Niall my problem is the name server that delegated the reserve does look up the record correctly.
I have this in the zone, DNAME 0/24 ;; ;;; delegate to server ;; 0/24 NS ns.someserver.com ;; At the ns.someserver.com the looks ups work with no problems. However at the main name server the PTR look up does not work. Not sure what im missing. ;; ANSWER SECTION: x.x.x.in-addr.arpa. 172800 IN DNAME 0/24.x.x.x.IN-ADDR.ARPA. 2.x.x.x.in-addr.arpa. 172800 IN CNAME 2.0/24.x.x.x.IN-ADDR.ARPA. 2.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.x.x.x.IN-ADDR.ARPA. 2.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA. 2.0/24.0/24.0/24.x.x.x.IN-ADDR.ARPA. 172800 IN CNAME 2.0/24.0/24.0/24.0/24.x.x.x.IN-ADDR........... But the looking up the record on ns1.someserver.com works fine. ;; ANSWER SECTION: 13.7.69.in-addr.arpa. 172229 IN DNAME 0/24.x.x.69.IN-ADDR.ARPA. 2.13.7.69.in-addr.arpa. 172229 IN CNAME 2.0/24.x.x.69.IN-ADDR.ARPA. 2.0/24.13.7.69.IN-ADDR.ARPA. 172800 IN PTR x-x-x-x.rev.XXX.com. Thanks, p -----Original Message----- From: Niall O'Reilly [mailto:niall.orei...@ucd.ie] Sent: Tuesday, October 13, 2015 6:29 PM To: Paul A <ra...@meganet.net> Cc: bind-users@lists.isc.org Subject: Re: dname reverse delegation On Tue, 13 Oct 2015 21:40:30 +0100, Paul A wrote: > > I have a few /24 that I want to delegate using DNAME. Are you expecting to save yourself trouble by doing so? If not, you should probably reconsider. If you decide DNAME is a useful trick, bear in mind that what DNAME does is not really delegation, but just a trick for the lazy. I'm actually one of those lazy people, so please understand that I don't mean the word offensively. Besides, cleverer people than I have recognized laziness as a virtue. I have persuaded the administrator of the 1.0.0.7.7.0.1.0.0.2.ip6.arpa. zone to use a DNAME rather than a delegation for f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa. Yes, this is for IPv6, but it's conveniently to hand, and the principles are the same. I have actually had second thoughts about this, and more than once, but never felt worried enough that making the change needed priority before the other things on my do-list. The trouble I save by doing this is that of maintaining two zone files for my AAAA and corresponding PTR records. Instead, I can keep both together in one file, like this: $ORIGIN no8.be. bode 3600 IN AAAA 2001:770:13f:0:5054:ff:fe00:d978 8.7.9.d.0.0.e.f.f.f.0.0.4.5.0.5.0.0.0.0.f.3.1.0.0.7.7.0.1.0.0.2.ip6 3600 IN PTR bode Using 'dig', you can explore how it works, and what zones are involved, by using commands such as these: dig bode.no8.be aaaa dig -x 2001:770:13f:0:5054:ff:fe00:d978 dig +trace -x 2001:770:13f:0:5054:ff:fe00:d978 dig f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa ns dig no8.be ns You can do the same for your /24's, if the administrator of the parent reverse zone is minded to co-operate. Alternatively, you can use a normal delegation and set up your zone as follows, filling in the gaps appropriately. $TTL 3600 ;; or whatever $ORIGIN 13.168.192.in-addr.arpa. @ IN SOA ... IN NS ... IN DNAME whatever.example.net. Then, you populate the whatever.example.net. zone with the PTR records: $TTL 3600 ;; or whatever $ORIGIN whatever.example.net. @ IN SOA ... IN NS ... 0 IN PTR base-addr.whatever-else.example.net. 1 IN PTR some-host.whatever-else.example.net. 2 IN PTR anor-host.whatever-else.example.net. ;; and so on ... 255 IN PTR bcast-addr.whatever-else.example.net. > 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 Don't be distracted by RFC2317. It describes the trickery you need when you're dealing with a longer prefix (fewer addresses) than a /24. If you have "a few /24", you can deal with them without needing any of that. > ;; > > ;;; delegate to server > > 0/24 NS ns.someserver.com. > > 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. > > 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. I'm not sure what in what sense you're using the term "forwarding server". If you mean the authoritative server where the DNAME record is sitting, then I believe that this is normal. An authoritative server should return just the DNAME and synthesized CNAME, as it's not responsible for chasing down the CNAME reference. That's the job of a recursive resolver. > 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. I'm sorry. I don't understand what you think you're trying to achieve. I hope this helps. Best regards, Niall O'Reilly _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users