> 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, because 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 [EMAIL PROTECTED] 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 PROTECTED]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
