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

[bmanning () karoshi com]

amen.  of course the security problems are inherent in the use of wildcards
at all, not just at delegations at/near the root.  One would hope that the 
folks who use wildcards or are IMPACTED by wildcards would review the current 
IETF ID on wildcard clarification that is approching last-call. 


> 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 () brightok net>
> > User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624
> > To: Paul Vixie <paul () vix com>
> > Cc: nanog () merit edu
> > Subject: Re: Root Server Operators (Re: What *are* they smoking?)
> > Sender: owner-nanog () 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