This is a discussion on Re: IPv6 Pattern Based Forward/Reverse Mappings - DNS ; On 11/09/2008, at 11:46 AM, Mark Andrews wrote: > > In message , > Matthew Moyle-Cro > ft writes: >> Hi, >> My apologies if this has been covered before. If this isn't the >> right >> place then let ...
On 11/09/2008, at 11:46 AM, Mark Andrews wrote:
> In message
> Matthew Moyle-Cro
> ft writes:
>> My apologies if this has been covered before. If this isn't the
>> place then let me know.
>> I work for a largish ISP - we've started rolling out IPv6 to
>> and at some point will be offering dual stack broadband. One of the
>> issues is working out how to do generic IPv6 forward and reverse
> This is one area where IPv4 think is not a solution. Let
> the end user machines update their PTR records. Vista
> already does this.
I wish you'd read my comments below before saying that.
I don't actually want to scale our nameservers to have to cope with an
extra million or so updates per day - what happens if something breaks
and suddenly I get 200,000 update requests in a minute? I don't
necessarily want domestic customers to be able to arbitrarily set
reverse mappings - I want to prepopulate so that no matter how broken
the customer's machines/firewalls/CPE are that they have useful
Being an ISP we're not able to enforce policy in the same way a
corporate does - we don't get to choose really how broken customers
own networks are.
> BIND 9.6 has "tcp-self" and "6to4-self" to provide weak
> authenication (tcp connection) to prevent third party abuse.
>> Currently for IP pools on our LNSes we just populate generic entries
>> for forward/reverse like:
>> BIND has some support for this in IPv4 with the $GENERATE directive
>> which allows quick and easy population of forward/reverse mappings.
>> Obviously handing our subnets (/64s or whatever becomes the answer)
>> customers means this becomes more complex - we don't really want most
>> customers dynamically updating these (99% of customers don't want to,
>> don't care or don't have the skills to anyway) and it represents a
> scaling issue as we're talking 150k+ ranges. So I want to be able to
>> have a similar directive for AAAA and ip6.arpa ranges so that I can
>> populate our reverse mapping files quickly, easily and without
>> large amounts of disk. (Please don't start and argument about
>> customers being able to have static ranges and delegate it themselves
>> - we've got solutions for those customers, this is for the mum and
>> customers who don't care and don't want to know - they want to not
>> care and have us do the work).
>> If an LNS has a /48 then I want to be able to specify something like:
>> $GENERATE6 <#bits> lhs [ttl] [class] type rhs [comment]
>> So instead of the range being a simple decimal increment it's a fill
>> of nibbles upto X bits. I know that forward mappings might be nice
>> be quads, but this keeps it to one directive.
>> So, we could do reverse mappings for a /64 with:
>> $ORIGIN c.b.a.220.127.116.11.18.104.22.168.22.214.171.124.2.ip6.arpa
>> $GENERATE6 64 $ IN PTR $.lns1.pop1.myisp.net.
>> and we'd get entries like:
>> 126.96.36.199.188.8.131.52.184.108.40.206.2.ip6.arpa. IN PTR
>> 220.127.116.11.18.104.22.168.9.10.a.b.c.d.e.f.lns1.pop1.myisp.n et.
>> (Sorry if I've got the nibbles wrong - it's not important really to
>> the story here :-)
>> And hopefully just the directive would be stored in memory and a
>> on a covered IP address would cause it to be looked up and resolved
>> Best Regards,
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org