[Dnssec-deployment] dealing with broken TLD name servers

Francisco Arias francisco at arias.com.mx
Wed Jun 30 18:27:13 EDT 2010

At least for new gTLDs there is something that can be done right now.
Currently there is a public comment period about, among other things,
Specification 6 of the Draft Registry Agreement for new gTLDs.

Specification 6 covers most of the technical standards that a new gTLD
has to comply. It lists the RFCs and includes a Service Level
Agreement with its respective real time monitoring system, that would
have caught the issue that started this thread. Suggestions on how to
improve it are more than welcomed.

Draft Registry Agreement can be found at:


Anyone can submit comments, before 21 July 2010, by email to
<4gtld-base at icann.org>. The full list of comments already submitted
can be seen at:


If anyone would like more information, please contact me off-list in
"francisco.arias at icann.org"



On 30 June 2010 08:15, Paul Vixie <vixie at isc.org> wrote:
>> From: David Conrad <drc at virtualized.org>
>> Date: Tue, 29 Jun 2010 21:59:23 -0700
>> http://www.iana.org/procedures/nameserver-requirements.html
>> These requirements were subject to an extended public review and comment
>> period.  If it is felt that these requirements are insufficient or should
>> be modified, there are policy definition processes in the GNSO and ccNSO
>> that are appropriate for those discussions.
> it's definitely missing a section, "No lossage from EDNS and IP
> Fragmentation" and if you'll say a little more about the GNSO/CCNSO PDP
> i'll get out of your hair here and instead go bother somebody else.
>> > > ICANN should also periodically retest, and should have the
>> > > contractual right to warn privately, warn publically, and then remove
>> > > after 24 hours any such NS RR, without reference to the national
>> > > sovereignty of the CCTLD.
> since this sovereignty thing is drawing fire, let me suggest that this
> process would not permit removal of all NS RRs, and that a minimum of two
> NS RRs would be left even if both of them were "broken" in terms of
> EDNS0. we must not make a CCTLD completely unreachable or nonexistent,
> which would be an even worse public health hazard than a non-clearpath
> EDNS0 server. but if there are seven servers and one of them is misbehaving
> in this way and neither private or public warnings are effective, then
> ICANN in its technical coordination function should be able to act
> unilaterally on a public health basis.
>> > IANA does check changes to TLD delegations.
>> Yes.  However, if a ccTLD operator insists on making a change that is
>> known to be broken, ICANN will make the change.
> that's a structural defect in "internet governance". how can we address it?

More information about the Dnssec-deployment mailing list