[Dnssec-deployment] Comcast

[Mark Andrews]

In message <6B59C7B8-7BBD-402E-B4F1-4FB3095CBC96 at cable.comcast.com>, "Griffiths
, Chris" writes:
> On Jan 16, 2012, at 9:43 PM, Jimmy Hess wrote:
> 
> On Thu, Jan 12, 2012 at 2:03 PM, tlhackque <tlhackque at yahoo.com<mailto:tlha=
> ckque at yahoo.com>> wrote:
> 
> protocols that use reverse mapping today will need reverse mappings with IP=
> V6.  Perhaps the recommendations on all unused addresses having a reverse m=
> apping need to be rethought - but that is a different subject for a differe=
> nt forum.
> 
> I believe the recommended  DNS response for a PTR query to the reverse zone=
>  regarding an unused IP address is a response
> with RCODE=3D3, No such domain,  no RRs to be in the zone for the unused IP=
> ,  should stay that way with IPv6.
> 
> And DNSSEC provides useful means for the resolver to authenticate denial of=
>  existence.
> 
> 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.

> I think it is important to note that IPv6 PTR zones will certainly be handl=
> ed differently based  on the individual use case of hosts and/or services, =
> as well as complexity of how these zones are managed.  I don't think we can=
> just simply assume we do the same as we did for IPv4 zones because that ma=
> y not make operational sense when we actually implement in large scale DNS =
> environments.
> 
> The requirement to sign the zone over again, introduced by DNSSEC securing =
> reverse zones, complicates matters tremendously.
> DNSSEC tools really must rise to the challenge and provide this level of au=
> tomation, dynamic DNS registrations with immediate
> automatic signing,   otherwise maintaining signed reverse DNS  zones would =
> become a manual process, and therefore just be too burdensome.

It exists today.  ISP's just need to turn it on.
 
> Necessitating that DNSSEC be relegated towards use in forward zones only.
> 
> This is something we are looking at and may bring to standards bodies like =
> the IETF and other locations to weigh in on complexity and need to define a=
> pproach.
> 
> 
> Barring replacement of SMTP with a new protocol,  I am sure that relegation=
> would happen long before common MTA  implementations consider abandoning R=
> DNS checks,  which serve as a de-facto  validation of a host being "right" =
> and potentially authorized to send mail.
> 
> Any legitimate SMTP host should have valid RDNS data for identification in =
> message headers.
> The presence of RDNS doesn't mean "good e-mail", but the absence of RDNS is=
> considered a good indication of likely abuse.
> RDNS implementation difficulties with DNSSEC and IPv6  do not diminish or o=
> verrule the need for RDNS queries and the need to check RDNS data before ac=
> cepting mail.
> 
> 
> I think this thinking may have made sense in an all IPv4 world, but again, =
> I think we need to look at all alternatives and decide if we stay the same =
> course, or make other recommendations as we transition to a dual stack envi=
> ronment.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org