[dns-wg] Reverse DNS operational considerations in an IPv6 environment

On Tuesday 15 June 2010 21:59:12 Jim Reid wrote:
> On 15 Jun 2010, at 17:18, David Freedman wrote:
> > We use wildcard records and then the customer can insert any custom
> > content
> > to override these (but beware that the deprovisioning fairy must
> > visit your
> > database tables when the customer leaves in order to keep this stuff
> > clean)
>
> Hmmmm. IMO deployment of wildcarding in the DNS is usually an
> indication that something has gone very wrong. It always gives me the
> heebie-jeebies.
>

I can't imagine of a senario that this would be a problem, but I tend to 
believe you Jim :) Of course IPv6 produces a totally different world in many 
things and I guess reverse DNS is one of them.
 
One of my thoughts on this is having wildcard records per customer vlan. If 
you chose a /56 customer assignment, that leaves you with 256 different /64 
vlans. The main idea is to use them for different services (if we ever come 
to that many offerings). Internet access, VoIP/SIP and IPTV would be the 
first obvious choices in providers giving these services.

> Reverse lookups for IPv6 addresses is a bit of a religious issue. IIRC
> someone (Johan Ihren?) gave a presentation at a RIPE meeting a few
> years ago and said it was best not to bother with any PTRs in the
> reverse zones for IPv6 space. I think his argument was the world was
> moving away from name-based access controls to things based on crypto
> tokens, making reverse lookups pointless. That said, my mail server
> does not accept inbound SMTP if the connecting host fails to have a
> working reverse DNS entry: this is remarkably good at spam suppression.
>

My guess is that the world will take a much longer time for such a change to 
occur. Although reverse DNS is used as a weak authentication mechanism today 
(if it can be characterized like that) it is not the only use. It is very 
convenient to see names instead of ugly IPv6 addresses in log files for 
instance.  

> Provisioning these IPv6 reverse zones is a problem for ISPs and I'm
> not sure what (if anything) is the Right Thing to do here. Perhaps
> this is something for the WG to consider and possibly work on: eg
> compare and contrast approaches, document use cases and so forth?

This is a good idea.

> Aside from Claranet, what are the other ISPs doing about provisioning
> reverse DNS for their IPv6 customers? DDNS with DHCPv6? Anyone care to
> share?
>

Now DDNS is another thought. Can you imagine that working however in an 
environment of multi-million mobile and consumer devices powering up often, 
in a secure and scalable way? I find it a challenge, though never say 
never :)

> My personal preference would be to delegate the /80 (or whatever) to
> the end-user/customer and leave them to choose how to provision that
> zone. [Your mileage may vary...] This might work fairly painlessly
> with the tcp-self and 6to4-self hooks to the update-policy{} clause in
> BIND 9.7. Though that's still messy. It also relies on well-behaved
> clients which is perhaps unwise.

The hooks you are referring to in BIND are DDNS stuff?
Delegating the reverse space of the assignment to the end user sounds like a 
good idea, provided you have fixed customers with static assignments. You 
also have to address the issue for mobile one-off address users. 
The problem is not so much the address space used for servers and network 
elements. The provider can populate and maintain this space prety much as it 
does today. Consider home equipment, PCs with Windows 7 or any other 
operating system with similar behaviour, which as we noticed, apart from the 
autoconfiguration address, produce random IPv6 addresses used in outgoing 
connections that change every couple of hours or so.

Add to all that some DNSSEC sugar ;-)

Kostas