Stability, Security, and Resilience of the DNS Review Team
Hello NARALOers, There is currently an open vote for ALAC members on whether to endorse the current statement on the SSR-Team. https://community.icann.org/display/alacdocs/ALAC+Statement+on+the+Stability... As there was recently some discussion of this on the na-discuss list, I would like to find out whether the current version incorporates the views that were expressed. I note that this statement calls for the new gTLD program to make DNSSEC optional rather than mandatory. (There are specific kinds of TLDs for which DNSSEC should be mandatory IMO, but that's outside the scope of this document) I will need to vote soon and would like to know if there are any substantial problems with the document in its current form according to NARALO members. Thanks, - Evan
We believe that DNSSEC should be mandatory for all from day one. If not, the same problem that .fr had (as it was mentioned in the statement) might happen with these in the future. Better to verify the system on day one than later when the effect of a software bug can be felt by many. Eduardo ISOC-PR On Thu, Apr 7, 2011 at 11:00 AM, Evan Leibovitch <evan@telly.org> wrote:
Hello NARALOers,
There is currently an open vote for ALAC members on whether to endorse the current statement on the SSR-Team.
https://community.icann.org/display/alacdocs/ALAC+Statement+on+the+Stability...
As there was recently some discussion of this on the na-discuss list, I would like to find out whether the current version incorporates the views that were expressed.
I note that this statement calls for the new gTLD program to make DNSSEC optional rather than mandatory. (There are specific kinds of TLDs for which DNSSEC should be mandatory IMO, but that's outside the scope of this document)
I will need to vote soon and would like to know if there are any substantial problems with the document in its current form according to NARALO members.
Thanks,
- Evan ------ NA-Discuss mailing list NA-Discuss@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/na-discuss
Visit the NARALO online at http://www.naralo.org ------
-- NOTICE: The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication by error, please notify us immediately by e-mail, and delete the original message.
I note that this statement calls for the new gTLD program to make DNSSEC optional rather than mandatory. (There are specific kinds of TLDs for which DNSSEC should be mandatory IMO, but that's outside the scope of this document)
Realistically, a handful of registry operators will provide the back ends for all of the new TLDs, and they all can do DNSSEC, so there's litle practical reason not to require it. End to end DNSSEC is not ready for prime time, but the structure of a TLD is simple enough (just delegations and glue records) that there's little technical risk. Personally, I would like to require that registrars and registrants also do full DNSSEC signing, since that will bring registrations in these useless domains to a screeching halt. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
The main counterpoint to this was raised, IIRC, by Eric. He may offer a better take on this than I, but here's how I recall the point. For those community-based TLD proposals from poorer economies -- the ones for whom the JAS group has been formed to try to lower costs -- the use of one of the big registry operators is *not* a given, and in these cases the cost of implementing DNSSEC could be significant. Not all TLD proposals exist just for the money. There are a number of well meaning proposals that seek to duplicate the success of .cat to use a TLD as a focal point for a cultural, ethnic or linguistic community. Some of these may envision using other registry operations that may not assume DNSSEC -- in these cases, mandatory DNSSEC for all is part of a barrier to entry. - Evan On 7 April 2011 11:44, John R. Levine <johnl@iecc.com> wrote:
I note that this statement calls for the new gTLD program to make DNSSEC
optional rather than mandatory. (There are specific kinds of TLDs for which DNSSEC should be mandatory IMO, but that's outside the scope of this document)
Realistically, a handful of registry operators will provide the back ends for all of the new TLDs, and they all can do DNSSEC, so there's litle practical reason not to require it. End to end DNSSEC is not ready for prime time, but the structure of a TLD is simple enough (just delegations and glue records) that there's little technical risk.
Personally, I would like to require that registrars and registrants also do full DNSSEC signing, since that will bring registrations in these useless domains to a screeching halt.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
-- Evan Leibovitch, Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56
For those community-based TLD proposals from poorer economies -- the ones for whom the JAS group has been formed to try to lower costs -- the use of one of the big registry operators is *not* a given, and in these cases the cost of implementing DNSSEC could be significant.
I see your point, but I don't think it's a problem. If you have a small zone, you can do everything with BIND or NSD or unbound. You need competent staff to manage it, but it's all industry standard free software, most likely the same software you'd be using anyway. If .MUSEUM can sign and publish, which it does using that freeware, I think it's fair to expect other small TLDs to do the same thing. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
On 7 April 2011 16:45, John R. Levine <johnl@iecc.com> wrote:
For those community-based TLD proposals from poorer economies -- the ones
for whom the JAS group has been formed to try to lower costs -- the use of one of the big registry operators is *not* a given, and in these cases the cost of implementing DNSSEC could be significant.
I see your point, but I don't think it's a problem. If you have a small zone, you can do everything with BIND or NSD or unbound. You need competent staff to manage it, but it's all industry standard free software, most likely the same software you'd be using anyway. If .MUSEUM can sign and publish, which it does using that freeware, I think it's fair to expect other small TLDs to do the same thing.
Just to be clear... you're saying the benefits of universal DNSSEC outweigh the costs, even for smaller (and less financially capable) TLDs. (And there will certainly be costs to implement, even if the software itself is free...) This, combined with Eduardo's agreement that DNSSEC should be mandatory everywhere, seems to indicate a lack of agreement with an ALAC statement that suggests otherwise. What do other think? If there is even partial agreement with the stances taken by Eduardo and John, I can't really vote in favour of the statement. - Evan
Just to be clear... you're saying the benefits of universal DNSSEC outweigh the costs, even for smaller (and less financially capable) TLDs. (And there will certainly be costs to implement, even if the software itself is free...)
If you'd asked me a year or two ago, I would have said no, but now I think it does. It requires some expertise, but at this point, anyone who can't figure out DNSSEC has no business running a TLD. "Less financially capable" doesn't mean less smart, just perhaps less trained which is straightforward to fix. Also, some of the DNS attacks which seemed hypothetical have now turned out to be more practical than we thought, and there are some useful things you can do with domain names with DNSSEC -- a name with a DNSSEC chain back to the root is as secure as an SSL certificate, at typically much lower cost. That might well turn out to be attractive for people with less money. And finally, if you think that everyone will eventually need DNSSEC, which I do, it is vastly easier to design it into your systems from the beginning than to try to retrofit it to something that's already running. So new registries should just do it. It's not that hard, and the potential benefits are significant. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
participants (3)
-
Eduardo Diaz -
Evan Leibovitch -
John R. Levine