marka at isc.org
Tue Jan 17 00:27:50 EST 2012
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=
> 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 =
> 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=
> 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=
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the Dnssec-deployment