Re: Naked domain resolution with DNSSEC

Hi

Thanks for the responses. 
We dug a little deeper and we found that the scenario was happening ONLY  for the cases where the zones have a CNAME at the zone apex

In Setup where Parent zone (.com) is Signed and Child zone (contoso.com) is Unsigned. CNAME record is present at apex (.) of Child zone ( contoso.com CNAME new_contoso.com) The Resolver responded with SERV_FAIL.
The packet flow is in following order:
	- Query is sent from client for contoso.com of type A to the resolver.
	- Resolver asked the same from .com server.
	- .com server replied back with NS record (for delegation) with name server as Child Server, NSEC3 record (to prove that DS does not exist) and A/AAAA records for Child Server
	- Based on the delegation response above, Resolver asked Child Server for contoso.com and got a reply for the same with CNAME pointing to new_contoso.com. 
	- Now Resolver still asks for DS Record of contoso.com (probably because CNAME record in the response overwrites everything else present at that node) and it could not get response as the zone is unsigned.
	- Resolver replied back to the client with server failure


We have observed the same behaviour with BIND resolvers as well. Is this behaviour correct?

Coming back to the original question, the migration from contoso.com to new_contoso.com is a fairly common scenario. Are there any guidance on how to achieve such a migration. One argument can be that the authoritative server for contoso.com should not keep CNAME records at (.) zone apex. In that case how is the admin supposed to handle such migrations and still support Naked domain resolutions.

Thanks
Ashu




-----Original Message-----
From: Dave Lawrence [mailto:[email protected]] 
Sent: Monday, October 7, 2013 11:03 PM
To: Sourav Sain
Cc: Kumar Ashutosh; [email protected] Group
Subject: RE: [dnsext] Naked domain resolution with DNSSEC

Sourav Sain writes:
> Presented below is a name resolution for "facebook.com, type=A". In 
> the first name resolution against "218.248.240.179" we see that 
> "69.171.239.12#53(a.ns.facebook.com)" ends up returning an A record 
> for QName=facebook.com. Since COM is signed A record for facebook.com 
> needs to have an RRSIG(A) in the response, which, obviously is missing 
> as a.ns.facebook.com cannot return the signature for A using keys 
> owned by COM. Our concern is, a security aware validating server, 
> having root or COM's Trust Anchor, will expect an RRSIG in the 
> response for facebook.com, type=A, not having which, will conclude the 
> response as BOGUS.

To expand a little on the answer that Jim Reid gave, it is important to remember the principle that for records at a zone cut, almost all records are authoritatively owned by the delegated zone, not the delegator.  The only exception to this is the DS record.  Therefore this sentence from above, and the crux of your problem, is not
correct:

> Since COM is signed A record for facebook.com needs to have an
> RRSIG(A) in the response

A properly written, standards-compliant validating resolver will recognize that when it originally asked the GTLD servers for facebook.com it got a provably insecure delegation to the facebook.com nameservers.  Therefore it will know that all records within the zone, including those at the apex, will not come with signatures.

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext