Subject: Re: [DNSOP] A different question

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 13:22:41 +1000

> Mark,
> 
> On Aug 21, 2008, at 5:25 PM, Mark Andrews wrote:
> > 	I'm not hoping for the best.  I'm confident that there won't
> > 	be major issues.
> ...
> > 	Yes change is scary.
> 
> This is, perhaps, a question of perspective.
> 
> The Internet is now a basic infrastructure upon which trillions of  
> dollars (no data, I'm guessing) in transactions and increasingly  
> _national_ economies depend.  I suspect folks who have a higher level  
> of responsibility for that infrastructure, e.g., ICANN/IANA and  
> VeriSign, view mucking with it in fundamental ways somewhat  
> differently than you.
> 
> Given the general level of 'just barely working' on the Internet, it  
> is safe to assume that any change at the root of the DNS will break  
> _something_.  The question is how much and what impact will that  
> breakage have.  ISC, like every software vendor, has frequently  
> released code that has had negative impact on the users of that code,  
> but the impact has pretty much been limited to the users of the code  
> and they have 'opted in' by installing and running that code.  In the  
> case of signing the root, ICANN/IANA and VeriSign will be taking an  
> action that has the potential of impacting pretty much everyone  
> without the folks impacted actually taking any action.  An 'oops' here  
> would likely result in rather strikingly negative repercussions.
> 
> As such, I personally believe these sorts of things require extra  
> ordinary levels of care.  You may feel differently.
> 
> > 	Every machine that is setting DO is asserting that it can
> > 	handle the responses the roots will generate.
> 
> True.  However, becauseFrom [email-masked]  Thu Aug 21 20:22:41 2008
To: David Conrad <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 13:22:41 +1000
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

> Mark,
> 
> On Aug 21, 2008, at 5:25 PM, Mark Andrews wrote:
> > 	I'm not hoping for the best.  I'm confident that there won't
> > 	be major issues.
> ...
> > 	Yes change is scary.
> 
> This is, perhaps, a question of perspective.
> 
> The Internet is now a basic infrastructure upon which trillions of  
> dollars (no data, I'm guessing) in transactions and increasingly  
> _national_ economies depend.  I suspect folks who have a higher level  
> of responsibility for that infrastructure, e.g., ICANN/IANA and  
> VeriSign, view mucking with it in fundamental ways somewhat  
> differently than you.
> 
> Given the general level of 'just barely working' on the Internet, it  
> is safe to assume that any change at the root of the DNS will break  
> _something_.  The question is how much and what impact will that  
> breakage have.  ISC, like every software vendor, has frequently  
> released code that has had negative impact on the users of that code,  
> but the impact has pretty much been limited to the users of the code  
> and they have 'opted in' by installing and running that code.  In the  
> case of signing the root, ICANN/IANA and VeriSign will be taking an  
> action that has the potential of impacting pretty much everyone  
> without the folks impacted actually taking any action.  An 'oops' here  
> would likely result in rather strikingly negative repercussions.
> 
> As such, I personally believe these sorts of things require extra  
> ordinary levels of care.  You may feel differently.
> 
> > 	Every machine that is setting DO is asserting that it can
> > 	handle the responses the roots will generate.
> 
> True.  However, becau setting DO is the default, the fact that  
> caching servers set DO says essentially nothing about the  
> infrastructure in which those machines reside.
> 
> While I might agree that it is unlikely that there will be major  
> issues if the root is signed, a lot depends on what you define as  
> 'major'. The impact if you are wrong can be ... substantial.  I  
> personally would prefer to have actual data rather than assertions of  
> confidence.

	Which is why I said look at SE and BR.  Their response
	profile to DO queries will be the same as the roots assuming
	you choose similar key sizes.

	Fragmentation shouldn't be a issue except for DNSKEY queries
	and only clients that are validating are likely to make
	such queries.

	You already have referrals falling into the 512-1200 band
	today, all COM referrals fall into this band.  The addition
	of a DS or NSEC and its signatures just going to change the
	percentage of referrals that fall into this band.  This
	band should not result in fragmentation under IPv4 or IPv6.
	No referrals will exceed 1200 bytes as long as you manage
	your zsk's so that only one signature is generated.

; <<>> DiG 9.3.4-P1 <<>> foo.se @a.ns.se +dnssec +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1651
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3

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

;; AUTHORITY SECTION:
foo.se.			86400	IN	NS	ns1.webb.se.
foo.se.			86400	IN	NS	ns2.webb.se.
foo.se.			7200	IN	NSEC	foobar.se. NS RRSIG NSEC
foo.se.			7200	IN	RRSIG	NSEC 5 2 7200 20080828055103 20080821141241 18048 se. ZlrpjdfZ5PfK26Uutc59Adl27W9MxRWtWFofMQGeTDcH79VWbCtAMOKQ 65Ciouu3wCL1D350mZPZ8/HfQWJCAWVh6ocQyEbRtqjJXsrdDUXg6t/z BTO4obAp1j20QPWGKLIjncPC3XHYZXsZSxmwJf6lrqSGuZqYMqUpwBF8 Ng4=

;; ADDITIONAL SECTION:
ns1.webb.se.		86400	IN	A	213.115.221.10
ns2.webb.se.		86400	IN	A	213.115.151.140

;; Query time: 368 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)
;; WHEN: Fri Aug 22 13:01:12 2008
;; MSG SIZE  rcvd: 301

	All NXDOMAIN responses will now fall into the 512-1200 band.
	This will result in TC for EDNS@512 clients.  You already
	handle TC for some PODS referrals today.

; <<>> DiG 9.3.4-P1 <<>> oewyouewy.se @a.ns.se +dnssec +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63605
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
se.			7200	IN	SOA	catcher-in-the-rye.nic.se. registry-default.nic.se. 2008082200 1800 1800 2419200 7200
se.			7200	IN	RRSIG	SOA 5 1 172800 20080828013700 20080822001240 18048 se. eqX68S5jhmWDTuddEE0ZuwFTSF5YZ14W06wztpKAQk3caqRdzouDYniA Z0XsZhRkQ+AejNxtWbTZ+E67QsuULW6yUjp2g5YAreytYgnYgVniv4xI HzUB2xjLnuD/3nF5YkDtVHAjysKxmnW2AfSlDASgujUSt5x0oQHM0EMW 3yE=
se.			7200	IN	NSEC	0-0.se. NS SOA TXT RRSIG NSEC DNSKEY
se.			7200	IN	RRSIG	NSEC 5 1 7200 20080826144950 20080820061240 18048 se. PfwyUPUmM4MWlMpau2TX+GGoc2YcSOEmA0G9q16o0c+8s7lpCAOHwciL CuD2GmOIFxWRItSxcanqT0klDp4DB/l4aRrHDSsir4CMAXS+Xao5mnfB KYfQ6EhOV0AK9ymBa3jtZkhadhevd94Eeqc40DFq0+tZZgJ4XwJQ0ff5 4Hg=
oewlite.se.		7200	IN	NSEC	oex.se. NS RRSIG NSEC
oewlite.se.		7200	IN	RRSIG	NSEC 5 2 7200 20080826012458 20080819141240 18048 se. YRXf9tX6PYQRKT2ldQ9U5afNIcqEl4qU2ZW+9h+IqOxAsllp2yT4hJBc ItDXIMGbOs/oeLpljscNIVaWMtTqo9aWyAOSQks4C6mQY1vpE+/ob+u2 F7LVHg/wrRJCx/KfESfH2cGmhjVsy4NpO38Tv5xiaZg6sD9qTGPdqjcK vUA=

;; Query time: 365 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)
;; WHEN: Fri Aug 22 12:48:01 2008
;; MSG SIZE  rcvd: 668

	Mark

> Regards,
> -drc
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

se setting DO is the default, the fact that  
> caching servers set DO says essentially nothing about the  
> infrastructure in which those machines reside.
> 
> While I might agree that it is unlikely that there will be major  
> issues if the root is signed, a lot depends on what you define as  
> 'major'. The impact if you are wrong can be ... substantial.  I  
> personally would prefer to have actual data rather than assertions of  
> confidence.

	Which is why I said look at SE and BR.  Their response
	profile to DO queries will be the same as the roots assuming
	you choose similar key sizes.

	Fragmentation shouldn't be a issue except for DNSKEY queries
	and only clients that are validating are likely to make
	such queries.

	You already have referrals falling into the 512-1200 band
	today, all COM referrals fall into this band.  The addition
	of a DS or NSEC and its signatures just going to change the
	percentage of referrals that fall into this band.  This
	band should not result in fragmentation under IPv4 or IPv6.
	No referrals will exceed 1200 bytes as long as you manage
	your zsk's so that only one signature is generated.

; <<>> DiG 9.3.4-P1 <<>> foo.se @a.ns.se +dnssec +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1651
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 3

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

;; AUTHORITY SECTION:
foo.se.			86400	IN	NS	ns1.webb.se.
foo.se.			86400	IN	NS	ns2.webb.se.
foo.se.			7200	IN	NSEC	foobar.se. NS RRSIG NSEC
foo.se.			7200	IN	RRSIG	NSEC 5 2 7200 20080828055103 20080821141241 18048 se. ZlrpjdfZ5PfK26Uutc59Adl27W9MxRWtWFofMQGeTDcH79VWbCtAMOKQ 65Ciouu3wCL1D350mZPZ8/HfQWJCAWVh6ocQyEbRtqjJXsrdDUXg6t/z BTO4obAp1j20QPWGKLIjncPC3XHYZXsZSxmwJf6lrqSGuZqYMqUpwBF8 Ng4=

;; ADDITIONAL SECTION:
ns1.webb.se.		86400	IN	A	213.115.221.10
ns2.webb.se.		86400	IN	A	213.115.151.140

;; Query time: 368 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)
;; WHEN: Fri Aug 22 13:01:12 2008
;; MSG SIZE  rcvd: 301

	All NXDOMAIN responses will now fall into the 512-1200 band.
	This will result in TC for EDNS@512 clients.  You already
	handle TC for some PODS referrals today.

; <<>> DiG 9.3.4-P1 <<>> oewyouewy.se @a.ns.se +dnssec +norec
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63605
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
se.			7200	IN	SOA	catcher-in-the-rye.nic.se. registry-default.nic.se. 2008082200 1800 1800 2419200 7200
se.			7200	IN	RRSIG	SOA 5 1 172800 20080828013700 20080822001240 18048 se. eqX68S5jhmWDTuddEE0ZuwFTSF5YZ14W06wztpKAQk3caqRdzouDYniA Z0XsZhRkQ+AejNxtWbTZ+E67QsuULW6yUjp2g5YAreytYgnYgVniv4xI HzUB2xjLnuD/3nF5YkDtVHAjysKxmnW2AfSlDASgujUSt5x0oQHM0EMW 3yE=
se.			7200	IN	NSEC	0-0.se. NS SOA TXT RRSIG NSEC DNSKEY
se.			7200	IN	RRSIG	NSEC 5 1 7200 20080826144950 20080820061240 18048 se. PfwyUPUmM4MWlMpau2TX+GGoc2YcSOEmA0G9q16o0c+8s7lpCAOHwciL CuD2GmOIFxWRItSxcanqT0klDp4DB/l4aRrHDSsir4CMAXS+Xao5mnfB KYfQ6EhOV0AK9ymBa3jtZkhadhevd94Eeqc40DFq0+tZZgJ4XwJQ0ff5 4Hg=
oewlite.se.		7200	IN	NSEC	oex.se. NS RRSIG NSEC
oewlite.se.		7200	IN	RRSIG	NSEC 5 2 7200 20080826012458 20080819141240 18048 se. YRXf9tX6PYQRKT2ldQ9U5afNIcqEl4qU2ZW+9h+IqOxAsllp2yT4hJBc ItDXIMGbOs/oeLpljscNIVaWMtTqo9aWyAOSQks4C6mQY1vpE+/ob+u2 F7LVHg/wrRJCx/KfESfH2cGmhjVsy4NpO38Tv5xiaZg6sD9qTGPdqjcK vUA=

;; Query time: 365 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)
;; WHEN: Fri Aug 22 12:48:01 2008
;; MSG SIZE  rcvd: 668

	Mark

> Regards,
> -drc
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 13:41:56 +1000

David do you have a nameserver we can bounce queries off
	which has the root zone signed as it would be in production?

	ns.iana.org doesn't count as the NS RRset is modified.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 13:41:56 +1000

Mark

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Aug 2008 20:57:34 -0700

> 	ns.iana.org doesn't count as the NS RRset is modified.

I'll see about getting that fixed.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Aug 2008 20:57:34 -0700

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Aug 2008 10:33:11 -0400

> 	you choose similar key sizes.

See, I think this premise is one for which we have very close to no
evidence right now.  But I know how we could get it.  If SE or BR (or
both) have traffic samples from before they signed, and from after,
then we (well, someone else -- I'm not volunteering.  But this seems
like a good OARC project) could compare the profiles of those data
sets to current root data sets.  Maybe we would learn what
differences, if any, there are.

Just asserting that the root traffic and some existing TLD's traffic
are the same does not make it so, and I can think of several reasons
why the analogy between SE or BR and . would fail.  It seems prudent
to me to try to understand what differences, if any, there are.  When
.org is signed, that will be another opportunity to compare things as
well, I guess.

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Aug 2008 10:33:11 -0400

A