[Dnssec-deployment] Comcast

[tlhackque]

> Now, when using DHCPv6 or other dynamic IP address assignment mechanisms li=
> ke SLAAC, there should be provisions in place to ensure an IP address dy=
> namically configured is appropriately registered with the correct 
> hostname,= and that the new zone gets signed.
> The same for manually assigned IPs, at the time of manual assignment; 
> SLAA= C alone makes that difficult, establishing valid RDNS could be 
> a reason to= implement DHCPv6.
>> Or just let the client register its own PTR record using UPDATE over TCP and the TCP connection's source address as the validator.
>> Let the CPE register a DNAME/NS records for the reverse of the delegated prefix using TCP as the authenticator.
>> Support for this already exists.
 
Yes: Inside my network, I use dynamic update / signing with IPv4 reverse zones (including DHCP)  today.  bind 9.7 just works.  It is no
more difficult than handling DNSSEC for forward zones.  DHCP doesn't do anything special; it just sends UPDATEs and bind handles
the signing.  Remember that with DHCP clients, the forward zone is often dynamically updated too.  
What doesn't exist - as far as I know - is support for the case where the ISP has delegated 
part of a reverse zone to the customer's nameservers; the customer has signed the reverse zone; and the customer
rolls the DNSSEC key.  How does the the customer nameserver update (install/remove) the DS records in the ISP parent?  (Assuming they get there in the first place, which ISPs don't support today.)
 
Strictly from bind's point of view, you could have the customer nameserver send a TSIG-signed update to the ISP nameserver, but now you've introduced
yet another key distribution/rollover problem.  Today this seems to be handled for forward zones by a registrar-specific web GUI
that requires users to manually install/remove DS records.  Registrars are (sortof) equipped for this.  But in my experience ISPs are not.  And the GUI approaches I've seen today don't scale and are not automation friendly.  Bind can't use them to update the DS records in the parent as it rolls keys.
  
> Best common practices should be re-evaluated time to time to make sure they make operational sense as deployments change. While this may have made sense a few years ago in the IPv4 only world, I tend to lean the other way and say IPv6 networks that manage and validate email should look at other options than simply seeing a PTR record. 
 
I am not an IPv6 expert (yet).  However, I expect the transition to be long (actually, never complete), and for most software to see IPv6 mapped to internal IPv4 thru the standard APIs for the remainder of my lifetime.  So today's applications (e.g. sendmail) will still do a getaddrinfo call and expect a sensible string to be returned - and someone has to have data to map from the external IPv6 reverse zone to that API.  People won't migrate until there is a significant benefit to them - and for (e.g.) a mailserver host, seeing the world mapped doesn't represent a hardship.
 
  > This is not how we currently manage commercial subs PTR zones, and we would need to look at the overall population and see what makes sense so we can scale any desired approach.

Yes, exactly my point.  Like most ISPs, comcast does delegate reverse zones to customer nameservers (typically rfc2317 - as documented on this list at http://dnssec-deployment.org/pipermail/dnssec-deployment/2011-December/005552.html) - but that's a one-time, low overhead event.  DNSSEC introduces a need to update the parent zone with DS record adds/removes during every key rollover.  This requires a new mechanism - or ISPs will be swamped.
 
Thanks to the comcast folks for starting to think about this.  I agree that there will be operational issues - though they are simpler inside my network than inside ISPs', if the same mechanisms can be made to work, technologies such as bind ought to be able to make the transitions seamless.
 
---------------------------------------------------------
This communication may not represent my employer's views,
if any, on the matters discussed.