where and how to submit DNSSEC DS record for a IDN ccTLD

Question

I got the opportunity to configure an IDN ccTLD. I have already configured the DNS server and it is working properly. Now I have a challenge to secure the dns service by DNSSEC. I configured DNSSECC by self-signing. But Now I can't understand where and how I should entry the DS record.

Answer 1

The DS record lives in the delegating zone, which if you actually are configuring a ccTLD is the root zone. So talk to your contact at ICANN about how to get the necessary information to them.

Answer 2

While Calle Dybedahl answered "where", I'd like to offer some pointers about "how" you should enable DNSSEC for your ccTLD (IDN or otherwise).

Viktor Dukhovni's "Common Mistakes" page deals with a lot of things specific to DANE (the use of DNSSEC as an anchor for certificates, particularly for SMTP), but his first two points (and the next to last one) are valid for any operator implementing DNSSEC, especially a TLD of any sort.

In particular, the first point, abridged below, is vital:

Publishing DNSSEC DS records ... as a fashion statement

Keeping these correct requires operational discipline. Administrators who expect "fire and forget" should not publish DNSSEC signed zones... Or they can pay others to host their zones... Operating poorly maintained DNSSEC zones ... creates problems not only for the domain in question, but also for all the domains trying to communicate with such a domain. Everyone is better off if DNSSEC ... [is] taken seriously.

There are a number of ccTLDs whose records in terms of maintaining their DNSSEC-signed zones in proper operation is far from stellar; there is a "hall of shame"—just look for the TLDs that appear more than once on the IANIX outages list.

Since your IDN ccTLD is a new TLD, DNSSEC is mandatory, so even if you were to swallow the red pill that IANIX offers you and renounce DNSSEC, you would still have no choice but to implement it. You should make all efforts to treat your DNSSEC deployment as a charge of the utmost gravity, since as a TLD, it directly affects the operation and security not only of your domain, but of any and all domains registered with it.

Furthermore, as difficult and problematic as DNSSEC is, it is unlikely to go away, and the number of clients that validate DNSSEC themselves (or rely solely on DNSSEC-validation resolution services like Google Public DNS, Comcast ISP, or Verisign Public DNS) is significant, exceeding 15% of all clients worldwide and significantly more in many countries that are likely candidates for an IDN ccTLD (see regional and per-country drill-downs at the previous link for examples like Kenya where 40% of clients rely on DNSSEC validation, and the .KE TLD had a significant DNSSEC outage last month).

There are good resources at ISOC, and a best practices PDF to help you manage DNSSEC if you want to "do it yourself" and roll your own DNSSEC zone signing. But it is very easy to get this wrong, and without regular monitoring and on-call response, your DNSSEC signatures can expire and render your entire domain unreachable to millions. Worse, if the private keys used for DNSSEC signing are compromised, the security of any domains depending on DNSSEC may be placed in jeopardy.

You may want to seriously consider whether it might not be easier and cheaper in the long run to host the zones for your IDN ccTLD with a commercial DNS provider that can provide managed DNSSEC (while you operate the registry side of the TLD and update the zones from your registry implementation using a DNS management API).

One final piece of advice; unless you are delegating millions of domains that have no DS records in your ccTLD and need NSEC3 opt-out, or you are operating in Europe where data privacy laws[1][2] may require that you use NSEC3, you should probably use old-style NSEC for now, as it allows Google Public DNS (and other implementations of aggressive NSEC caching) to absorb NXDOMAIN Denial of Service attacks and junk queries without forwarding them to your authoritative servers. If NSEC3 actually offered significant protection against zone enumeration it might be worth using, but it is not hard to break it if you have a decent GPU and the protection against NXDOMAIN attacks (in 2016–2017 only possible with NSEC) is more useful.