DNS Security

DNSSEC Deployment at the Root

The DNSSEC is a security protocol for providing cryptographic assurance (i.e. using the public key cryptography digital signature technology) to the data retrieved from the DNS distributed database (RFC4033). DNSSEC deployment at the root is said to be subject to politics, but there is seldom detailed discussion about this "DNS root signing" politics. Actually, DNSSEC deployment requires more than signing the DNS root zone data; it also involves secure delegations from the root to the TLDs, and DNSSEC deployment by TLD administrations (I omit other participants involvement as my focus is policy around the DNS root). There is a dose of naivety in the idea of detailing the political aspects of the DNS root, but I volunteer! My perspective is an interested observer.

Cricket Liu Interviewed: DNS and BIND, 5th Edition

In follow-up to recent announcement on the release of the latest edition of the very popular DNS and BIND book -- often referred to as the bible of DNS -- CircleID has caught up with Cricket Liu, co-author and a world renowned authority on the Domain Name System. In this interview, Cricket Liu talks about emerging issues around DNS such as security and IPv6 support, and important new features such as internationalized domain names, ENUM (electronic numbering), and SPF (the Sender Policy Framework). "Cricket Liu: We're now seeing more frequent attacks against DNS infrastructure. ...Turns out that name servers are terrific amplifiers -- you can get an amplification factor of nearly 100x. These attacks have raised awareness of the vulnerability of Internet name servers, which is possibly the only positive result..."

ICANN Gets the Root Zone, Too

A small but intriguing paragraph in the VeriSign settlement says that ICANN gets to maintain the root zone. I thought they did now, but I guess VRSN does, following advice from ICANN. This has two and a half effects. The most obvious is political -- if ICANN rather than VRSN is distributing the root zone, it removes the symbolic significance of VeriSign's A root server. The second is DNSSEC key management. Until now, the contents of the root zone have been pretty boring, a list of names and IP addresses of name servers. If DNSSEC is deployed in the root, which is not unlikely in the next few months, ICANN rather than VeriSign will hold the crypto keys used to sign the root zone. If a tug of war develops, whoever holds the keys wins, since without the keys, you can't publish a new version of the root with changed or added records unless you publish your own competing set of keys and can persuade people to use them.

About Those Root Servers

There is an interesting note on the ITU Strategy and Policy Unit Newslog about Root Servers, Anycast, DNSSEC, WGIG and WSIS about a presentation to ICANN's GAC. (The GAC website appears to be offline or inaccessible today.) The interesting sentence is this: Lack of formal relationship with root server operators is a public policy issue relevant to Internet governance. It is stated that this is "wrong" and "not a way to solve the issues about who edits the [root] zone file." Let's look at that lack of a formal relationship...

The US Department of Commerce, the DNS Root, and ICANN

The recent announcement in eWeek titled "Feds Won't Let Go of Internet DNS" (slashdotted here) has some major internet policy implications. The short, careful wording appears to be more of a threat to ICANN than a power grab. In short, the US Department of Commerce's (DOC) National Telecommunications and Information Administration (NTIA) announced that it was not going to stop overseeing ICANN's changes to the DNS root. ...Of course, they have done next to nothing to support DNSSEC or other proposal for securing the DNS, but it sounds reassuring. The last sentence shows that the Bush administration shares the Clinton administration's lack of understanding of how the internet should evolve...

Preventing Future Attacks: Alternatives In DNS Security Management - Part II

In Part I of this article I set the stage for our discussion and overviewed the October 21st DDoS attacks on the Internet's 13 root name servers. In particular, I highlighted that the attacks were different this time, both in size and scope, because the root servers were attacked at the same time. I also highlighted some of the problems associated with the Domain Name System and the vulnerabilities inherent in BIND. Part II of this article takes our discussion to another level by critically looking at alternatives and best practices that can help solve the security problems we've raised.