(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".
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
* 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
