Root Server Operators (Re: What are they smoking?)

Thu Sep 18 01:11:56 UTC 2003

actually, i had it convincingly argued to me today that wildcards in root
or top level domains were likely to be security problems, and that domains
like .museum were the exception rather than the rule, and that bind's
configuration should permit a knob like "don't accept anything but delegations
unless it's .museum or a non-root non-tld".  i guess the ietf has a lot to
think about now.

re:

> Date: Wed, 17 Sep 2003 09:58:40 -0500
> From: Jack Bates <jbates at brightok.net>
> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624
> To: Paul Vixie <paul at vix.com>
> Cc: nanog at merit.edu
> Subject: Re: Root Server Operators (Re: What *are* they smoking?)
> Sender: owner-nanog at merit.edu
> 
> 
> Paul Vixie wrote:
> > no.  not just because that's not how our internal hashing works, but
> > because "hosted" tld's like .museum have had wildcards from day 1 and
> > the registrants there are perfectly comfortable with them.  there's
> > no one-policy-fits-all when it comes to tld's, so we would not want
> > to offer a knob that tried to follow a single policy for all tld's.
> 
> I agree Paul. This is a policy issue and not a technical issue. TLDs that
> are sponsored or setup with a specific design sometimes do and should be
> allowed to use the wildcard for the tld. The issue has become that net and
> com are public trusts and changes were made to them without authorization
> by the public and damage was caused as a result.
> 
> Just as root server operators are subject to operating as IANA dictates, so
> should Verisign be subject to operating as IAB and ICANN dictate. The
> Internet as a whole depends on the predictability of TLDs. It is impossible
> to maintain a security policy based on unpredictable information.
> 
> I would recommend that the TLDs which do utilize wildcards setup or
> restrict such use in a predictable manner. While historically it has not
> been an issue, such as nonexistant .museum domains being forged in email
> envelopes, such practices could be exploited at a later time. The ability
> to recognize that a domain is not registered and should not be used is
> paramount in basic forgery detection.
> 
> One method that might be considered for recursive servers as well as
> resolvers, is the ability to specify if a wildcard entry will be accepted
> or not, perhaps at any level or just at the 2nd level. Cached records which
> are wildcards could be marked as such so that subsequent queries could
> specify desire of accepting or not accepting the wildcard entry. A web
> browser, for example, which supports its own redirections for NXDOMAIN,
> might wish to ignore the wildcard records, as would smtp servers.
> 
> While I believe that net and com should never have wildcards, the ability
> to detect, cache, and override wildcards for tld's such as museum when the
> application requires it is paramount. I realize that the client software
> can perform the queries and detection itself, but in many cases, there
> wouldn't be an effecient way to cache the information without the resolver
> and recursive cache being aware of the process and performing such
> detection would require two queries versus one.
> 
> 
> -Jack
> 