Alternatively you could just use update-policy and tcp-self and
allow the clients that want PTR records to add them for the addresses
they are using with nsupdate or similar.
zone 3.0.0.0.1.0.0.A.8.B.D.0.1.0.0.2.IP6.ARPA {
type master;
file "3.0.0.0.1.0.0.A.8.B.D.0.1.0.0.2.IP6.ARPA";
update-policy {
grant * tcp-self * PTR;
};
};
sh-3.2$ address=2001:DB8:A001:3:18A3:9904:B9C3:8195
sh-3.2$ reverse=`arpaname $address`
sh-3.2$ nsupdate -v << EOF
> local $address
> update delete $reverse PTR
> update add $reverse 3600 IN PTR host.example.net
> send
> EOF
sh-3.2$
This tells nsupdate to send the update message using TCP from the
address specified and named to accept update requests that are sent
using TCP from the address that matches the name to be updated.
6to4-self is similar and works at the /48 level and can be used to
delegate reverse zones on demand.
update-policy {
grant * 6to4-self * NS DS KEY;
};
6to4-self was developed to allow 6to4 sites to add delegations
though it was never used. 48-self ... 64-self would be how to do
this for PD delegation sizes from /48 to /64. Adding that to named
would be 1/2 a hour of coding to add support for non- nibble sizes.
It would be about 5 minutes to add all the nibble sizes (48-self
(synonym for 6to4-self), 52-self, 56-self and 64-self).
Mark
In message
<a05b583c828c614ebad1da920d92866bd07ec...@podcwmbxex501.ctl.intranet>,
"Woodworth, John R" writes:
> >
> >
> >
> >
> > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bob
> > Harold
> > Sent: Friday, February 03, 2017 4:15 PM
> > To: Cathy Almond
> > Cc: bind-users@lists.isc.org
> > Subject: Re: Reverse IPv6
> >
> >
> > On Thu, Feb 2, 2017 at 5:44 AM, Cathy Almond <cat...@isc.org> wrote:
> >
> >
> > On 02/02/2017 02:52, Filho Arrais wrote:
> > > Hi,
> > >
> > > Hello,
> > > Excuse me the question, is there anything native to IPv6 like in IPv4
> > > for PTR input?
> > >
> > > $GENERATE 1-254 $ PTR 100.200.236.$.examplae.com <http://examplae.com>.
> > >
> > > --
> >
>
> Hi Filho,
>
> Apologies such a delayed response. I am one of the authors of the mentioned
> draft (BULK RRs). We are still moving this through its paces and are hopeful
> it will eventually become a standard. One advantage for IPv6 use of our draft
> is the minimal memory footprint for storing the necessary "tons" of
> $GENERATE-like RRs.
>
> I have made a note of your email address and will contact you once our
> solution gets adopted and/ or has working implementations.
>
>
> Best regards,
> John
>
> >
> > Bear in mind that that reverse populating your IPv6 space in entirety is
> > potentially going to hurt you (the $GENERATE command actually generates
> > an RR for each record which will be held in the zone in memory). Think
> > about how many records your $GENERATE is going to create. You don't
> > want to have named failing to start because it does not have enough
> > memory (or the machine on which it is running does not have enough
> > memory) to hold all of the PTR RRsets in the zone.
> >
> > Please also think about whether you need to do this or not, especially
> > as the names are going to follow a generic pattern and not provide any
> > useful intelligence about the host using that address.
> >
> > Instead, I would suggest that you just create PTR entries for the IPv6
> > hosts that actually need them for some reason, or to use dynamic DNS to
> > add/replace/delete them as addresses are used/discarded by dynamic clients.
> >
> > Note that there is future work being done to solve the 'too many entries'
> > issue with GENERATE (does not solve the other concerns):
> > https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-03.txt
> >
> > --
> > Bob Harold
> >
> >
> -- THESE ARE THE DROIDS TO WHOM I REFER:
> 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 no
> tify the sender by reply e-mail and destroy all copies of the communication
> and any attachments.
> _______________________________________________
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
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
