Re: Root Server Operators (Re: What *are* they smoking?)
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
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
Paul Vixie wrote:
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.
Paul, I would argue as seen in some of my other posts, that the wildcard feature of .museum is not always wanted either. Would it not be wise to push forward into the future with support for software to request if it wants a wildcard or not? While a wildcard bit is ideal, there are methods of determining wildcard programatically. Being able to cache and handle such information is important as different applications have different requirements. After all, is this the Internet or just the World Wide Web? wildcards at the roots are catering solely to the web and disrupting other protocols which require NXDOMAIN. -Jack
* jbates@brightok.net (Jack Bates) [Thu 18 Sep 2003, 16:41 CEST]:
After all, is this the Internet or just the World Wide Web? wildcards at the roots are catering solely to the web and disrupting other protocols which require NXDOMAIN.
Wildcards anywhere are problematic. I've yet to encounter a situation where they didn't cause extreme operational brokenness. -- Niels.
participants (4)
-
bmanning＠karoshi.com -
Jack Bates -
Niels Bakker -
Paul Vixie