[dns-operations] Google Chrome Pre-Caching

[Stephane Bortzmeyer]

On Wed, Sep 03, 2008 at 10:41:04PM +0000,
 Paul Vixie <vixie at isc.org> wrote 
 a message of 14 lines which said:

> >    https://wiki.mozilla.org/Gecko:Effective_TLD_List
...
> and what a terrible, miserable, horrible idea that all is.

We probably agree on this point but, to be sure, here is a PROPOSED
statement I wrote some time ago (nothing official, mostly personal
ideas), on a related issue:


**************** DRAFT DRAFT DRAFT DRAFT **************

Some Web browsers (at least Mozilla Firefox and Konqueror but it may
also happen in non-free browsers for which there is no source code
available to check) ship with an hardcoded list of TLDs (Top-Level
Domains). This is typically done to work around security issues in the
HTTP cookie specification (RFC 2965, see
<http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt> and
<http://www.acrossecurity.com/papers.htm>). Some applications do not
use cookies in a secure way and, as a result, Web browsers' authors
are sometimes pushed to add their own filtering rules against
cross-domain cookies.

These lists in the browsers typically indicate which TLDs register
domains at the second-level (like ".de" or ".org") or at the
third-level (like ".za", ".uk" or ".jp"). Some lists are not subtle
enough to handle TLDs which use both levels (such as ".fr", ".dz" or
".af") <http://bugs.kde.org/show_bug.cgi?id=163774>. There is no
standard language to express these policies, nor even a common
ontology (and there is no evidence that such ontology is possible).

The first big issue with these hardcoded lists is the fact that there
is no obvious way to be sure they are updated. Not all users upgrade
their Web browsers every week, even when there is a seamless mechanism
to do so (and mechanisms like firewalls may prevent the users from
upgrading). As a result, the list will be outdated soon. It is a very
common problem in the Internet. For instance, many applications still
cannot handle TLDs with more than three letters, many years after
".info" and ".museum" were introduced. Therefore, shipping a product
with a hardcoded list of domains or IP addresses is almost always an
inappropriate idea.

This first issue could be mitigated by a dynamic mechanism to
distribute the list, for instance using the DNS in RBL-style. It is
not clear whether this mechanism could be sufficiently available for
every user (non-DNS techniques such as IRIS would certainly have
reachability problems).

But the second issue is the maintenance of this list. Even if it is
distributed automatically, it will have to be kept up-to-date, which
is one more task for the authors and one more thing that can become
stale.

A maintenance organized along the existing DNS tree, with registries
taking care of their own policies and publishing them, would improve
things but this raises other problems. As noted before, it is not
obvious that a standard language is possible. And it is questionable
to force the registries into maintaining one more thing, just to
implement controversial security workarounds.

Also, "registry" is a complicated notion. Some registrants of domain
names delegate further away in the tree, for instance "eu.org" or
allow users to create domain names such as "free.fr". What is the
point of publishing ".org" policies if the problem occurs at a lower
level?

This leads us to the crux of the matter. Today, registries delegate
according to policies developed with the relevant community, according
to a well-defined process, and often backed by the local law. This
means that, for a registrant, once a domain is registered according to
the registration rules, it can be used freely and safely. If programs
start to have their rules of "good" and "bad" things in the DNS, the
registrant will no longer be sure that his domain works. As we have
seen from the IDN issues in a well-known browser (which deliberatley
punishes the user by showing the Punycode encoding if the brower's
author disagrees with the registry IDN policies), the registrant will
now need, not only to comply with the registration rules of the parent
domain, but also with the policies of remote Web browsers.