Subject: [dnsext] Naked domain resolution with DNSSEC

From: Kumar Ashutosh <[email-masked]>
Date: Thu, 3 Oct 2013 15:59:28 +0000

Hi 

In a scenario where,

Server NS1 hosts myzone.com (myzone.com is not DNSSEC signed) with an A record at zone apex { myzone.com A 10.0.0.1 }
And 
COM server hosts NS for myzone.com pointing to NS1

If the Query for A record of type myzone.com goes to  ROOT server from a DNSSEC validating resolver

Now as ROOT ( "." ) zone is signed. Root says that COM is signed by replying with DS record for COM.
A DNSSEC aware resolver with this data will conclude that COM is signed. Hence a record under COM should be signed unless it's a delegation NS record (at the zone cut).
COM replies with NS record pointing to NS1 without any RRSIG and NSEC3 (as DS for myzone.com is absent indicating an insecure delegation), which is expected.

Next the DNSSEC validating resolver asks NS1 for myzone.com. To this resolver a record under COM MUST have RRSIG.
But NS1 that hosts the myzone.com responds for the A query with an A record without any RRSIG.
The resolver was expecting a signed response for everything under COM, gets an unsigned response and marks them as BOGUS and returns a SERV_FAIL
Some resolvers, do let the response pass but with AD bit set to 0 which a DNSSEC aware end client may not accept.

Is there any guidance around this?

Thanks
Ashu

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Oct 2013 17:32:15 +0100

Kumar Ashutosh <[email-masked]> wrote:
>
> Now as ROOT ( "." ) zone is signed. Root says that COM is signed by
> replying with DS record for COM. A DNSSEC aware resolver with this data
> will conclude that COM is signed. Hence a record under COM should be
> signed unless it's a delegation NS record (at the zone cut).

Records under .com can also be unsigned if they are under a provably
insecure delegation.

> COM replies with NS record pointing to NS1 without any RRSIG and NSEC3
> (as DS for myzone.com is absent indicating an insecure delegation),
> which is expected.

No: if myzone.com is unsigned the referral will include a proof of
insecurity, like this:

; <<>> DiG 9.9.4rc1 <<>> +dnssec +norec myzone.com in a @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42648
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;myzone.com.            IN A

;; AUTHORITY SECTION:
myzone.com.             2d IN NS ns1.myzone.com.
myzone.com.             2d IN NS ns2.myzone.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 1d IN NSEC3 1 1 0 - (
                                CK0RFQAOES8CTVNVNH4G6Q85NOQAQ8I9
                                NS SOA RRSIG DNSKEY NSEC3PARAM )
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 1d IN RRSIG NSEC3 8 2 86400 (
                                20131009044051 20131002033051 8795 com.
                                JCPiPpefxwjdDLZFWX2Wab+EthcL8zhDJdT7hykL1w0v
                                8PlkE0wqQiCJMp1DG0AZITP9sk9YcNyhCK3cZz6SAjl7
                                DtR/yhqi9zY9Ra/bESrmrLHI7Iw8boG7Us9UPebdMU4o
                                vhe4nNLqwnf6GGJw3lSAzzFpr5UDeIVmS5EdDzs= )
KQ2VMKJAFRRU1S029E7TDJ2ARQAE2DEQ.com. 1d IN NSEC3 1 1 0 - (
                                KQ33P6J6S3E7AUT6M20OD79E277MR85S
                                NS DS RRSIG )
KQ2VMKJAFRRU1S029E7TDJ2ARQAE2DEQ.com. 1d IN RRSIG NSEC3 8 2 86400 (
                                20131008044035 20131001033035 8795 com.
                                jYuq/3PGoVYECWWDT6ZrxBPEbQjEjQa5CmRa1s7mJDz4
                                ULJBCA5gubj3nRTmx93mf/1DoHZoq/5ZIwl9SvzQXCKl
                                Q79NsVRXWuZOU5CuvNefNsf/RVL5nMjp5rLOk8MvaYNR
                                duZj8hJaHz3cP4nLwg0wv7JmjAO0WCiBSLwiF9s= )

;; ADDITIONAL SECTION:
ns1.myzone.com.         2d IN A 204.244.181.149
ns2.myzone.com.         2d IN A 204.244.181.150

;; Query time: 146 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Thu Oct 03 17:27:34 BST 2013
;; MSG SIZE  rcvd: 592

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 3 Oct 2013 12:49:44 -0400

Kumar Ashutosh writes:
> The resolver was expecting a signed response for everything under
> COM, gets an unsigned response and marks them as BOGUS and returns a
> SERV_FAIL Some resolvers, do let the response pass but with AD bit
> set to 0 which a DNSSEC aware end client may not accept. 

You've observed these behaviours?  With which nameservers?

---

From: Sourav Sain <[email-masked]>
Date: Sun, 6 Oct 2013 16:16:35 +0000

Hi Dave

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.

Regarding resolvers which lets the response PASS but with AD bit unset, please see the 2nd and 3rd name resolutions. In the 2nd name resolution, I have tried to resolve "QName=COM, QType=DS" and I can see that 8.8.8.8 responds with "flags: qr rd ra ad; Hence the response is Authenticated Data. But in the third name resolution for facebook.com, type=A, asking 8.8.8.8 for validated responses, we do get the response but without "ad" in flags. Shouldn't there be a Serv Fail in this case (third name resolution for "facebook.com, type=A")?

----------------------------------------------------------------------------------------------------------
c:\dig\dig-files3>.\dig @218.248.240.179 facebook.com A +trace +dnssec

; <<>> DiG 9.3.2 <<>> @218.248.240.179 facebook.com A +trace +dnssec
; (1 server found)
;; global options:  printcmd
.                       438113  IN      NS      j.root-servers.net.
.                       438113  IN      NS      f.root-servers.net.
.                       438113  IN      NS      c.root-servers.net.
.                       438113  IN      NS      a.root-servers.net.
.                       438113  IN      NS      m.root-servers.net.
.                       438113  IN      NS      l.root-servers.net.
.                       438113  IN      NS      i.root-servers.net.
.                       438113  IN      NS      d.root-servers.net.
.                       438113  IN      NS      h.root-servers.net.
.                       438113  IN      NS      g.root-servers.net.
.                       438113  IN      NS      k.root-servers.net.
.                       438113  IN      NS      b.root-servers.net.
.                       438113  IN      NS      e.root-servers.net.
.                       438113  IN      RRSIG   NS 8 0 518400 20131010000000 20131002230000 59085 . J77jB7Y61aBLsNMii8XphtUr1OwjIlzgwVz2W7FFzf1Yh0gKp1vyJ7G6 j9
MY3r/1TKEvOup6t/4Gnp4U32P8JP9FS6CzyoJYKOWCE8vSMekgcAr 4zwiBHfhhYndIJKJGpqpaF0GwnubiEREyXG7c5n53CCMjRh6ZB5/2FN0 V7E=
;; Received 857 bytes from 218.248.240.179#53(218.248.240.179) in 172 ms

com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    86400   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20131013000000 20131005230000 59085 . BWF4iHvXMlOSY8AAhufgQuBOqt2kM7KRC5fnUJ14el+t75BKfas67coq luq
MPJFiXb1ON6SidUE+asWVnVFcRU0FU+503+A/bhSvRcvtncKTSAA LOCd/68q6nvw1+mG3P3IDJVxDDEfBS3gpSctqZ73S1Y9dpSLhzjqhuY6 KYM=
;; Received 736 bytes from 192.58.128.30#53(j.root-servers.net) in 172 ms

facebook.com.           172800  IN      NS      a.ns.facebook.com.
facebook.com.           172800  IN      NS      b.ns.facebook.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN TYPE50 \# 35 0101000000146501B7E9587710CEFEFFBC49036905BE34AD22490007 22000000000290
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG TYPE50 8 2 86400 20131013044124 20131006033124 8795 com. H3vUWw6JkfKMP0xebYmX3dZBrsFWew3z46qhsGw04P+xTexV/
vlHu2e g8w3WUiPMmE8tf+BZsPp3ssV3Ptoybv1h6atVFmbndBg1KxEpBpEM3ui HbEXeC+tR9foRz9A7LnsTerG7OdEloyRKgHxRN+OkX4DLy3Q8tgj1XWl Fhs=
I287JBU8MGU307S65H71L34A9JJD947E.com. 86400 IN TYPE50 \# 34 010100000014909129C805FD2BEE60532B8E319B6CDC0D7AF5660006 200000000012
I287JBU8MGU307S65H71L34A9JJD947E.com. 86400 IN RRSIG TYPE50 8 2 86400 20131013043923 20131006032923 8795 com. hOj0Qr4RA/BmXNPO0qQsLkg5GFHW8UrLdXctCNFRgwYO9wK7O
aSSBmm Zk4SKjqr8gWosPtwHJYKgSzuXacCUHIv/g8LOz3MliRstmMtJwWR2KXG GHk89e8EDO4Hd1BjZsqiArXYmq3PZ1gyQjO6omHP1AtGbdJgTI8qC2+Z fWk=
;; Received 593 bytes from 192.12.94.30#53(e.gtld-servers.net) in 406 ms

facebook.com.           900     IN      A       173.252.110.27
facebook.com.           172800  IN      NS      a.ns.facebook.com.
facebook.com.           172800  IN      NS      b.ns.facebook.com.
;; Received 124 bytes from 69.171.239.12#53(a.ns.facebook.com) in 641 ms
----------------------------------------------------------------------------------------------------------
c:\dig\dig-files3>.\dig @8.8.8.8 COM DS +dnssec

; <<>> DiG 9.3.2 <<>> @8.8.8.8 COM DS +dnssec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 932
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;COM.                           IN      DS

;; ANSWER SECTION:
COM.                    19029   IN      DS      30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
COM.                    19029   IN      RRSIG   DS 8 1 86400 20131013000000 20131005230000 59085 . BWF4iHvXMlOSY8AAhufgQuBOqt2kM7KRC5fnUJ14el+t75BKfas67coq luqB
MPJFiXb1ON6SidUE+asWVnVFcRU0FU+503+A/bhSvRcvtncKTSAA LOCd/68q6nvw1+mG3P3IDJVxDDEfBS3gpSctqZ73S1Y9dpSLhzjqhuY6 KYM=

;; Query time: 187 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Oct 06 19:58:11 2013
;; MSG SIZE  rcvd: 239
----------------------------------------------------------------------------------------------------------
c:\dig\dig-files3>.\dig @8.8.8.8 facebook.com A +dnssec

; <<>> DiG 9.3.2 <<>> @8.8.8.8 facebook.com A +dnssec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 367
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;facebook.com.                  IN      A

;; ANSWER SECTION:
facebook.com.           834     IN      A       173.252.110.27

;; Query time: 406 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Oct 06 19:58:26 2013
;; MSG SIZE  rcvd: 57

-----Original Message-----
From: Dave Lawrence [mailto:[email-masked]] 
Sent: 03 October 2013 22:20
To: Kumar Ashutosh
Cc: [email-masked] Group; Sourav Sain
Subject: Re: [dnsext] Naked domain resolution with DNSSEC

Kumar Ashutosh writes:
> The resolver was expecting a signed response for everything under COM, 
> gets an unsigned response and marks them as BOGUS and returns a 
> SERV_FAIL Some resolvers, do let the response pass but with AD bit set 
> to 0 which a DNSSEC aware end client may not accept.

---

From: Jim Reid <[email-masked]>
Date: Mon, 7 Oct 2013 16:21:26 +0100

On 6 Oct 2013, at 17:16, Sourav Sain <[email-masked]> wrote:

> 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.

Your concern would be valid if that was how DNSSEC works. But it doesn't. facebook.com is not signed. The zone has no DNSKEYs or RRSIGs. There are no DS records in .com for facebook.com either: hardly surprising because facebook.com is not signed and has no key-signing keys.

A validating resolver would not expect to find an RRSIG for facebook.com's A record RRset. It would not be able to validate that RRSIG if it was present because the zone does not have signed delegation. [Well, not unless it had some other out of band TA for facebook.com.] It would know from the metadata in the .com zone that facebook.com was not signed and continue to resolve names in that domain, albeit without doing any validation. The answers that validating resolver returned to its clients will have the AD (Authentic Data) bit set in the DNS header to indicate if the answer had been sucessfully validated or not validated at all.

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 7 Oct 2013 13:33:19 -0400

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.

---

From: Kumar Ashutosh <[email-masked]>
Date: Wed, 23 Oct 2013 09:00:20 +0000

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-masked]] 
Sent: Monday, October 7, 2013 11:03 PM
To: Sourav Sain
Cc: Kumar Ashutosh; [email-masked] Group
Subject: RE: [dnsext] Naked domain resolution with DNSSEC

> response for facebook.com, type=A, not having which, will conclude the 

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

> Since COM is signed A record for facebook.com needs to have an

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.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Oct 2013 05:17:12 -0400

> 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 w…

It should respond with SERVFAIL in that case.  You have an invalid
zone on the child side.  You can't have a CNAME at the apex of a zone.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 23 Oct 2013 10:55:27 -0400

Kumar Ashutosh writes:
> 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. 

Unfortunately the best practice answer here is still to maintain the
two zones in parallel.  "Use DNAME!" should be the answer, but
unfortunately there are a sufficient number of issues with operational
deployment of DNAME that it can't really be relied upon, at least not
during an active migration.  As Andrew Sullivan said, CNAME is right out.

Depending on the hosting server software, there are some easy ways to
keep both zones absolutely in sync.  I realize I'm replying to folks
@microsoft.com right now, and unfortunately my knowledge of MS's auth
DNS service is not current.  However, with other servers (BIND for
example) you can just point two different zone names at the same
master file.  Names in rdata that point within the zone can just be
made to be fully qualified by the destination zone name.

---

From: Joe Abley <[email-masked]>
Date: Wed, 23 Oct 2013 12:18:59 -0400

Hey,

On Oct 23, 2013, at 10:55, Dave Lawrence <[email-masked]> wrote:

> during an active migration.

Geoff Huston and George Michaelson did an experiment on this the other week, and their findings were that DNAME support is as near universal as they can measure.

A description of the experiment can be found in an appendix to draft-jabley-dnsop-as112-dname-01.

Joe

---

From: Kumar Ashutosh <[email-masked]>
Date: Wed, 23 Oct 2013 17:39:03 +0000

Hi 
Thanks for the quick responses.
The Microsoft authoritative DNS servers prevent adding CNAMEs at the zone apex. But there may be other DNS servers which may be allowing this and the validating resolvers are returning Serv_fail, As Andrew suggested.

I agree that CNAME should not be used for such migrations and DNAME may be used but *might* have deployment issues. But DNAME has a limitation that if you add DNAME at zone apex then you cannot have any other record in the zone, except at the zone apex (like NS records).

One more scenario where naked domain issue becomes evident is when the authoritative servers try to point a few of their records at some third party DNS hosting services

Contoso.com
{
www 	CNAME 	contoso.dnsprovider.com (owned by a third party)
internal A		1.1.1.1
}

How does it set out to achieve the naked domain resolution. It cannot add CNAME at the apex. Also it cannot add DNAME to the loadbalancer.net at the zone apex as then it can't host internal records and also resolution for www will point to www.dnsprovider.com

How will such a customer ensure that both www.contoso.com and contoso.com get pointed to contoso.provider.com.

Much appreciated!
Thanks
Ashu

-----Original Message-----
From: Dave Lawrence [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 8:25 PM
To: Kumar Ashutosh
Cc: Sourav Sain; [email-masked] Group; Thirunadha Reddy
Subject: RE: [dnsext] Naked domain resolution with DNSSEC

> migrations and still support Naked domain resolutions.

Unfortunately the best practice answer here is still to maintain the two zones in parallel.  "Use DNAME!" should be the answer, but unfortunately there are a sufficient number of issues with operational deployment of DNAME that it can't really be relied upon, at least not during an active migration.  As Andrew Sullivan said, CNAME is right out.

Depending on the hosting server software, there are some easy ways to keep both zones absolutely in sync.  I realize I'm replying to folks @microsoft.com right now, and unfortunately my knowledge of MS's auth DNS service is not current.  However, with other servers (BIND for
example) you can just point two different zone names at the same master file.  Names in rdata that point within the zone can just be made to be fully qualified by the destination zone name.

---

From: Jim Reid <[email-masked]>
Date: Wed, 23 Oct 2013 19:05:27 +0100

> The Microsoft authoritative DNS servers prevent adding CNAMEs at the zone apex. But there may be other DNS servers which may be allowing this and the validating resolvers are returning Serv_fail, A…

This is how it should be. If a name exists as a CNAME, it cannot exist as any other RRtype. Except of course for any RRSIGs and NSEC or NSEC3's if the zone is signed. Adding a CNAME at the zone apex fails because that name must at by definition already have at least a SOA and some NS records.

---

From: Kumar Ashutosh <[email-masked]>
Date: Wed, 23 Oct 2013 18:29:26 +0000

Hi Jim
I agree on CNAME behaviour. My concern here is what option does the customer have in case he needs contoso.com and www.contoso.com both to be redirected to say contoso.dnsprovider.com

Recapturing this from my previous mail
" One more scenario where naked domain issue becomes evident is when the authoritative servers try to point a few of their records at some third party DNS hosting services

Contoso.com
{

How will such a customer ensure that both www.contoso.com and contoso.com get pointed to contoso.provider.com."

Thanks
Ashu

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 23 Oct 2013 15:03:00 -0400

Kumar Ashutosh writes:
> I agree on CNAME behaviour. My concern here is what option does the
> customer have in case he needs contoso.com and www.contoso.com both to
> be redirected to say contoso.dnsprovider.com 

The customer in this case needs special handling by the authoritative
server to hand out address records at the apex instead.  Several DNS
providers handle this in their own software; for example, Akamai has a
feature called "toplevel name redirection" to do it.  DNS Made Easy
has what they call an "ANAME record", described at
http://www.dnsmadeeasy.com/services/aname-records/.  It isn't really
an IETF/IANA acknowledged DNS record, but rather just the way they
describe how to configure it into their system.

This is a fundamental limitation of the DNS protocol.  To achieve the
desired effect you must use some mechanism that is outside the scope
of current DNS standards documents.

---

From: Kumar Ashutosh <[email-masked]>
Date: Wed, 23 Oct 2013 19:19:19 +0000

Thanks Dave!

-----Original Message-----
From: Dave Lawrence [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 12:33 AM
To: Kumar Ashutosh
Cc: Jim Reid; Thirunadha Reddy; [email-masked] Group; Sourav Sain
Subject: RE: [dnsext] Naked domain resolution with DNSSEC

> be redirected to say contoso.dnsprovider.com

The customer in this case needs special handling by the authoritative server to hand out address records at the apex instead.  Several DNS providers handle this in their own software; for example, Akamai has a feature called "toplevel name redirection" to do it.  DNS Made Easy has what they call an "ANAME record", described at http://www.dnsmadeeasy.com/services/aname-records/.  It isn't really an IETF/IANA acknowledged DNS record, but rather just the way they describe how to configure it into their system.

This is a fundamental limitation of the DNS protocol.  To achieve the desired effect you must use some mechanism that is outside the scope of current DNS standards documents.

---

From: "John Levine" <[email-masked]>
Date: 23 Oct 2013 19:54:47 -0000

>How will such a customer ensure that both www.contoso.com and
>contoso.com get pointed to contoso.provider.com."

I've done it by provisioning.  My DNS management software has a hack
that says that one name has the same A/AAAA as some other name.  Every
few hours a daemon runs down the list, and if the target address has
changed, it updates the local name.

This is a hack, but it's the least bad one I know in this situation.

Note that this also makes it a lot easier handle the fairly common
situation that the web server is hosted one place and the mail is
hosted in another, and the web host has no way to install MX records
that point anywhere other than itself.

R's,
John

---

From: Kumar Ashutosh <[email-masked]>
Date: Wed, 23 Oct 2013 20:20:49 +0000

Thanks John!
Dave has pointed about certain 'special' records like ANAME. I think Amazon route53 also has similar 'alias' records.
It would be great if the working group could drive a standardized handling of this scenario.

Thanks
Ashu

-----Original Message-----
From: John Levine [mailto:[email-masked]] 
Sent: Thursday, October 24, 2013 1:25 AM
To: [email-masked]
Cc: Kumar Ashutosh
Subject: Re: [dnsext] Naked domain resolution with DNSSEC

>contoso.com get pointed to contoso.provider.com."

I've done it by provisioning.  My DNS management software has a hack that says that one name has the same A/AAAA as some other name.  Every few hours a daemon runs down the list, and if the target address has changed, it updates the local name.

Note that this also makes it a lot easier handle the fairly common situation that the web server is hosted one place and the mail is hosted in another, and the web host has no way to install MX records that point anywhere other than itself.

R's,
John

---

From: "Dickson, Brian" <[email-masked]>
Date: Wed, 23 Oct 2013 20:27:14 +0000

>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.

I think _this_ question is the one that actually needs to be answered.

There are relatively simple ways, which might need a bit more work if
there is a need for DNSSEC signing of the zone in question.

There are actually possibly two elements - moving DNS provider, and
migrating from one domain to another.

If you ignore the moving DNS provider, there is a fairly simple way of
doing this.

First, let's be sure you actually want the result to be:

every query for something.old-name.com
	and for something.new-name.com

must always return the same results. (And at some point in future,
old-name will disappear.)

Here's how you can achieve the desired result:
Run old-name and new-name on the same set of DNS authority servers.
Have the same zone file imported for both zones, with all names relative
to the parent zone name.
In BIND syntax, it would look something like:
zone "new-name.com" {
  type master;
  file "master/db.old-name-new-name.com";
  }
zone "old-name.com" {
  type master;
  file "master/db.old-name-new-name.com";
  }

If you need to do signed zones, it becomes a bit more tricky, in that the
name of the signer (in the RRSIG) would be different, and would also
impact DS and RRSIG(DNSKEY) records.
In this case, you could either have a "merged" zone file (one set of
names, two sets of signatures, with the names in "relative" format), or
you could have two signed zone files.

Automating the signing of the zone files, via some kind of script, would
make it automatic, whenever changes are made to the zone (e.g. it could
also ensure the SOA serial number gets updated, among other things.)

On the other hand, if you also need to move DNS providers, you would need
to augment this with something like:
- set up the above, on both the old DNS provider, and the new DNS provider
- swing things from the old provider to the new provider (by doing changes
on the registrar to update the delegation NS set).
- keep things running in parallel for at least 2 x max-TTL
- shut down the old DNS provider's stuff (and be SURE they remove all
remnants, or anyone using them for resolution might get stale data).

I think this is likely good enough for anyone doing what you are trying to
do, and avoids messing with CNAME or DNAME or anything similar.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Oct 2013 07:32:06 +1100

This really should be handled by SRV or seperate MX like record.

Unfortunately http server operators, http browser developer and
http proxy developers misused/abused CNAME as it nearly provided
what was needed and never asked a appropriate record to say "this
site is hosted on this server" despite MX records existing to do
exactly this for SMTP.

Mark

In message <[email-masked]
c.corp.microsoft.com>, Kumar Ashutosh writes:
> The customer in this case needs special handling by the authoritative server 
> to hand out address records at the apex instead.  Several DNS providers handl
> e this in their own software; for example, Akamai has a feature called "tople
> vel name redirection" to do it.  DNS Made Easy has what they call an "ANAME r
> ecord", described at http://www.dnsmadeeasy.com/services/aname-records/.  It 
> isn't really an IETF/IANA acknowledged DNS record, but rather just the way th
> ey describe how to configure it into their system.
> 
> This is a fundamental limitation of the DNS protocol.  To achieve the desired
>  effect you must use some mechanism that is outside the scope of current DNS 
> standards documents.
> 
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 23 Oct 2013 23:03:24 +0200

> I agree on CNAME behaviour. My concern here is what option does the customer have in case he needs contoso.com and www.contoso.com both to be redirected to say contoso.dnsprovider.com

Done out of band is probably the only viable solution; traverse the
DNS to find which IP address is pointed to by "contoso.dnsprovider.com"
and add AAAA and/or A records to suit at the zone apex.

(The following code is ugly and untested but should give an idea. 
 Please copy and use it if you're brave but don't blame me if it 
 eats your homework.)

dig www.contoso.com CNAME +short | while read canon ; do 
	dig $canon A +short
	done | awk '
	{ printf "update add contoso.com. 84600 IN A %s\n\n", 
		$1; 
	}' | nsupdate -k verysecretkey.txt

On a related[0]¸ note, when we've got people from Microsoft here, why for
crying out loud does AD require a number of A records at the AD zone
apex pointing to the DC's for the AD? Wouldn't it be better to do that
with a SRV record pointing to the host names of the DC's?

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
HELLO, everybody, I'm a HUMAN!!

[0] "related" as in dealing with apex A records in a Microsoft context..

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Oct 2013 22:37:25 -0400

> I agree on CNAME behaviour. My concern here is what option does the customer have in case he needs contoso.com and www.contoso.com both to be redirected to say contoso.dnsprovider.com

You have to maintain the zones in parallel.  There's no getting around this.

DNAME, note, doesn't work because it doesn't redirect the name itself.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 25 Oct 2013 17:25:48 +0800

From: Dave Lawrence
Date: 2013-10-24 03:03
To: Kumar Ashutosh
CC: Sourav Sain; [email-masked] Group; Thirunadha Reddy
Subject: Re: [dnsext] Naked domain resolution with DNSSEC
> be redirected to say contoso.dnsprovider.com 

BNAME, which directs both itself and its children, may solve it. the draft about BNAME was discussed 3 years ago.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Oct 2013 05:36:50 -0400

Yes, and if it were compatible with DNSSEC, perhaps people would have
pursued it.  But it won't work with DNSSEC.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 26 Oct 2013 00:14:31 +1100

> pursued it.  But it won't work with DNSSEC.

And you know as well as I do that it can be made to work with DNSSEC
the same way as NSEC3 was made to work with DNSSEC.

---

From: "Jiankang Yao" <[email-masked]>
Date: Sun, 27 Oct 2013 10:23:08 +0800

I think that BNAME is compatible with DNSSEC. If you say BNAME is not compatible with DNSSEC, I think that it is due to protocol overhead.
 I suggest the following upadting to BNAME to reduce the protocol overhead:

If the query is a DNSSEC query, the BNAME enabled resolvers MUST set the UB (understand BNAME) bit in the query. The server receiving the UB bit MUST not issue synthesized CNAMEs or DNAME. Servers copy the UB bit to the response, and should delete the synthesized CNAMEs and DNAME from the answer if there has one. If the query is the DNSSEC query but the UB bit is not set, the server should follow the rules below:
 
a. If the owner name of the BNAME is same with the name queried, when preparing a response, a DNSSEC enabled server performing a BNAME substitution will not include the relevant BNAME  RR and its RRSIG RR in the answer section unless the type queried is BNAME . A CNAME RR with TTL=0 and its signed record will be included in the answer section unless the type queried is BNAME .
 
 b. If the owner name of the BNAME is the suffix of the name queried but not identical with the suffix, when preparing a response, a server performing a BNAME substitution will in all cases include the relevant BNAME RR in the answer section. A DNAME RR synthesized with TTL=0 and its signed DNAME RR are included in the answer section. This will help the client to reach the correct DNS data.

 Jiankang Yao

 ------------------ Original ------------------
  From:  "Andrew Sullivan";<[email-masked]>;
 Date:  Fri, Oct 25, 2013 05:36 PM
 To:  "Jiankang Yao"<[email-masked]>; 
 Cc:  "Dave Lawrence"<[email-masked]>; "Kumar Ashutosh"<[email-masked]>; "Thirunadha Reddy"<[email-masked]>; "[email-masked] Group"<[email-masked]>; "Sourav Sain"<[email-masked]>; 
 Subject:  Re: [dnsext] Naked domain resolution with DNSSEC

Best,

A

-- 
Andrew Sullivan
[email-masked]