July 9, 2008, Washington, D.C.: The Domain Name System (DNS) is responsible for translating host names to IP addresses (and vice versa) and is critical for the normal operation of internet-connected systems. DNS cache poisoning (sometimes referred to as cache pollution) is an attack technique that allows an attacker to introduce forged DNS information into the cache of a caching nameserver. DNS cache poisoning is not a new concept; in fact, there are published articles that describe a number of inherent deficiencies in the DNS protocol and defects in common DNS implementations that facilitate DNS cache poisoning.

The following are examples of these deficiencies and defects: * Insufficient transaction ID space The DNS protocol specification includes a transaction ID field of 16 bits. If the specification is correctly implemented and the transaction ID is randomly selected with a strong random number generator, an attacker will require, on average, 32,768 attempts to successfully predict the ID. Some flawed implementations may use a smaller number of bits for this transaction ID, meaning that fewer attempts will be needed. Furthermore, there are known errors with the randomness of transaction IDs that are generated by a number of implementations. Amit Klein researched several affected implementations in 2007. These vulnerabilities are described in the following vulnerability notes: o VU#484649 - Microsoft Windows DNS Server vulnerable to cache poisoning o VU#252735 - ISC BIND generates cryptographically weak DNS query IDs o VU#927905 - BIND version 8 generates cryptographically weak DNS query identifiers The Mozilla Foundation announced today that future releases of their web browsers will incorporate new technology that uses the Public Suffix list.

Gervase Markham a senior programmer for the Mozilla Foundation said today "The technology in question, including a version of the list, is about to ship in Firefox 3". In order to ensure the list is up to date Markham has asked that technical contacts for existing Top-Level Domains help "verify and improve the quality of the underlying data" in the Public Suffix list.

The Public Suffix List is a cross-vendor initiative of the Mozilla Foundation, to provide an accurate list of domain name suffixes. It is available for use in any software, but was originally created to meet the needs of browser manufacturers. It allows browsers to, for example:

- Avoid privacy-damaging "supercookies" being set for high-level domain name suffixes
- Highlight the most important part of a domain name in the user interface
- Accurately sort history entries by site

It is in the interest of Internet registries to see that their section of the list is up to date. If it is not, their customers may have trouble setting cookies, or data about their sites may display sub-optimally. Top-Level Domain operators are encouraged to maintain their section of the list by submitting amendments.

Members of the Public Root who require technical assistance in submitting their TLD information to be added to the Public Suffix list should contact the public root at info@publicroot.org.

A copy of the email sent to the technical community by the Mozilla Project follows.

Dear Technical Contact,

The Mozilla Project (http://www.mozilla.org/), responsible for the
Firefox web browser, requests your help.

We are maintaining a list of all "Public Suffixes". A Public Suffix is a
domain label under which internet users can directly register domains.
Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".
In other words, the list is an encoding of the "structure" of each
top-level domain, so a TLD may contain many Public Suffixes. This
information is used by web browsers for several purposes - for example,
to make sure they have secure cookie-setting policies. For more details,
see http://publicsuffix.org/learn/.

We would like your help to make sure, now and in the future, that the
entries for your TLD(s) are correct. It is in your interest as a
registry to make sure that this is so. Any errors may either cause your
customers (domain owners in your TLD) to not be able to set cookies when
they should, or cause cookie information to be leaked between two
domains without a trust relationship. Neither of these things is desirable.

Therefore, we are writing to ask your technical team to view the current
list and, if it is incorrect, to submit updated data. A description of
the format of the list, and details for sending updates is at:

http://publicsuffix.org/submit/

We also ask you to send updated information whenever you change your
registration policies in a way which affects the list.

Thanking you in advance,
Gervase Markham

Contact: Gervase Markham
The Mozilla Project
E-Mail: gerv@mozilla.org

References: draft-pettersen-subtld-structure-03.txt