North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Root Server Operators (Re: What *are* they smoking?)
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 <[email protected]> > > User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 > > To: Paul Vixie <[email protected]> > > Cc: [email protected] > > Subject: Re: Root Server Operators (Re: What *are* they smoking?) > > Sender: [email protected] > > > > > > 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 > > >
|