dname reverse delegation

[Woodworth, John R]

> 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.
>


Niall, apologies I am new to the mailing list and am still getting acclimated.

I agree with the consensus a few /24s are handled much easier via standard
delegation than via RFC2317.

I am confused about your example.  It would seem a simple delegation would
work in this scenario assuming you are running bind and are admin on the
nameserver.  The way I see it appending '.arpa.' to the PTR's owner would
negate the need for the DNAME style delegation but I confess my assumptions
could be off.  Could you please explain your setup in more detail?


Thanks,
John


>   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
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151017/c6b3ca5a/attachment.html>