> (Thread originated on main IETF mailing list...)
>
> In a discussion concerning new TLD names and namespace collisions that
> might (and to
> some extent, are likely to) occur, Mark Andrews wrote:
> >> So the "problem" isn't whether some string not listed in 2606
> >> can be allocated, it is how it is used after it is allocated.
> >> And _that_ situation has a lot more to do about "buyer beware"
> >> and understanding of conflicting expectations about use than it
> >> does about ownership.
> >>
> > This is a security problem, not a buyer beware problem.
> >
> > This is a namespace clash and namespace clashes are bad for
> > many reasons.
> >
> > Now as far as I can see there are two solutions which attack
> > the problem from different ends.
> >
> > 2. rewrite resolvers to not lookup single labels against the
> > root
>
> It occurs to me that there may need to be some thought given to the
> issue, in terms of writing up
> the set of "good practices" vs "danger, danger" things lurking in the
> use of search lists, and in
> names which do not terminate in "." (and in some cases, which might not
> permit such name termination).
>
> Consider the label "foo.bar", a stub resolver, a recursive resolver, new
> TLD "bar", and existing SLD "example.com".
Partially qualified domains and search lists are always dangerous
unless you never use a partial name which matches a tld.
> It may become appropriate, sometime in the near future, to have explicit
> search lists with *no* implicit entries.
>
> For instance, currently a search list might be "example.com" (or
> ".example.com", or ".example.com."), with an implicit
> entry of ".". The semantics are: first a search is done against
> "foo.bar.example.com"; and then against "foo.bar".
>
> With the implicit entry of "." in the search list, any failure of child
> zone "bar" might result in an entirely unintended search
> result, "foo.bar". It is entirely possible that the administrator(s) for
> "example.com" don't want this possibility, and would
> prefer that they have the choice of either including an *explicit* entry
> of ".", or by excluding ".", making the failure of
> the "bar" child zone result in NXDOMAIN on queries for "foo.bar" (using
> their own resolver).
>
> What I'm basically saying is, the semantics of "search lists" may need
> to be adjusted so that new TLDs don't cause scary
> surprises (or even worse, vectors for bad actors to achieve results).
>
> Here are some examples of combinations that I think make sense:
>
> * No relationship between stub resolver (user/admin) and recursive
> resolver (admin), e.g. DSL ISP:
> o stub resolver always adds "." to queries, to preclude use of
> searching
> o This protects the user from gonzo admins having search lists
> that include naked TLDs
ISPs shouldn't be setting search lists. I always override
the ISP's search list. Mind you I had to add a CNAME to a
local zone as one of their html pages used a unqualified
hostname.
> * Relationship between stub resolver and recursive resolver (admin),
> e.g. corporate stuff
> o stub resolver does not add anything
> o recursive resolver includes local domain (and as
> appropriate, subdomains) in the search list
> o recursive resolver is also secondary authority server for
> local domain and subdomains, so resolution shares fate with
> authority server
> * In short, search domains and global namespace searching are
> mutually exclusive, and "." normally should not be included with
> anything else in a search list
>
> I'm not sure I have thought of all the cases and failure modes, and
> certainly don't claim to be an expert in this (yet), but I think it's
> something we should start thinking about sooner, so as to avert
> forseeable problems.
>
> What do others think?
>
> Brian Dickson
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
