October 22, 2016

ICANN Working Group Issues Domain Hijacking Recommendations

ICANN (Internet Corporation For Assigned Names and Numbers) has been working on a new set of recommendations related to the issues around domain hijacking, the urgent return of an inappropriately transferred name and a domain’s “lock status”.

The wonderfully named “GNSO Inter-Registrar Transfer Policy (IRTP) Part B Policy Development Process Working Group” (don’t you just love bureaucrats) has come up with nine recommendations to address the problem of domain hijacking.

Some of the language of the recommendations seems a bit fuzzy and at times bureaucratic… Recommendation #1 starts with “is considering recommending”. Or in other words we are thinking about making a recommendation which could then be ignored, but we won’t commit either way… But at least they are thinking… we hope…

So here are some of the recommendations in simple English.

  • Requiring registrars to provide an Emergency Action Channel when a domain is hijacked.
  • Proactive measures to prevent hijacking including measures to protect domain registrar accounts against compromise and misuse.
  • Creation of a ‘thick’ WHOIS that stores the complete WHOIS information from all the registrars. Currently there is no standard means for the secure exchange of registrant details in the current ‘thin’ registry.
  • Require that the Registrar of Record/Losing Registrar notify the Registered Name Holder/Registrant of a transfer.
  • Standardizing and clarifying WHOIS status messages regarding Registrar Lock status. The goal of these changes is to clarify why the Lock has been applied and how it can be changed.

New Protection From Internet Routing Hijacking and Incorrect Addressing

The beginning of January saw the start of a new era for Internet routing. Well, it almost did. Four of the five Regional Internet Registries (RIRs) have deployed the Resource Public Key Infrastructure (RPKI), a robust security framework for verifying the association between resource holders and their Internet resources.

RIPE Network Coordination CentreThe RIRs, like the RIPE Network Coordination Centre (which is responsible for the European part of the Internet), provide Internet resource allocations, registration services and co-ordination activities. RPKI allows ISPs and network operators to verify the accuracy of routes on the Internet and to prevent fraudulent or erroneous misdirection of Internet traffic. A famous example of erroneous routing happened in 2008 when the YouTube web site was unavailable in several different parts of the world because Pakistan Telecom incorrectly co-opted YouTube’s IP address range as its own.

The only RIR not to implement RPKI yet is the American Registry for Internet Numbers (ARIN). According to their website their deployment has been delayed until “very early in the second quarter of 2011”.

Once AIRN is up and running the use of Resource Certificates will mean that worldwide each resource holder will own a certificate which lists the Internet resources (IPv4 addresses, IPv6 addresses, and Autonomous System Numbers) that are owned by the certificate holder (e.g. an ISP). The certificate are of course encrypted and by using the public keys associated with the certificate owner the list of Internet resources can be easily verified.

Internet Infrastructure Supports DNSSEC Now

DNSSEC is now up and running in all of the internet root servers. Rod Beckstrom, president and CEO of ICANN, the governing body for Internet domains, at Black Hat 2010 conference made this announcement. Nine top-level Internet domains have also now been signed with DNSSEC, including in .uk, .org, and others.

“We expect another dozen or so to take this step over the coming weeks,” Beckstrom said. He says others should be DNSSEC-signed in the next 12 months.

What is DNSSEC?

The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS cache poisoning. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a worldwide public key infrastructure for email.

DNSSEC records:

  • DS
  • NSEC

How it works?

DNSSEC works by digitally signing these records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone which is the trusted third party.

Please visit http://en.wikipedia.org/wiki/DNSSec for more information. This page has been used as a reference for this article.

[ad code=2 align=center]