Subject: Re: [DNSOP] Services and top-level DNS names

From: Brian Dickson <[email-masked]>
Date: Fri, 04 Jul 2008 19:26:31 -0400

(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 againsFrom [email-masked]  Fri Jul  4 16:26:41 2008
Date: Fri, 04 Jul 2008 19:26:31 -0400
From: Brian Dickson <[email-masked]>
To: Mark Andrews <[email-masked]>
Cc: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] Services and top-level DNS names
Sender: [email-masked]

(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 agait 
"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-masked]
https://www.ietf.org/mailman/listinfo/dnsop

nst 
"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-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Sat, 05 Jul 2008 14:09:20 +1000

> 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.
 
> entry ofFrom [email-masked]  Fri Jul  4 21:09:26 2008
To: Brian Dickson <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Sat, 05 Jul 2008 14:09:20 +1000
Cc: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] Services and top-level DNS names
Sender: [email-masked]

> 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.
 
> entry of ".". The semantics are: first a search is done against 

	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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

 ".". The semantics are: first a search is done against 
>           o This protects the user from gonzo admins having search lists

	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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Brian Dickson <[email-masked]>
Date: Sat, 05 Jul 2008 01:11:36 -0400

> 	unless you never use a partial name which matches a tld.

Exactly!

The problem is a "who choses last" problem.

Anyone who is using a partial name, which *then* becomes a new TLD, gets 
the surprise results.

And, as the new rules are likely to result in TLDs with more 
semantically meaningful values, there is greater
likelihood that such problems will appear.

Especially for TLDs with geographic significance. ".asia" was bad 
enough, but what if the various FAA airport codes
get used by the respective airport authorities as new TLDs?

How many operators have infrastructure naming schemes based on FAA 
codes? How much chaos might occur if new
TLDs like "CHI", "NYY", "LAX", "SEA", or "YYZ" come into existence? 
(Shudder).

That's precisely why it makes sense to think about the partial name 
problem, before big problems happen for lots of ISPs.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sat, 05 Jul 2008 01:11:36 -0400

Exactly!

Brian

---

From: Andras Salamon <[email-masked]>
Date: Mon, 7 Jul 2008 02:00:14 +0100

> problem, before big problems happen for lots of ISPs.

My feeling is that search lists for DNS are a bad optimization that
should never have happened.  After publication of RFC 1535, they
should have been removed altogether, instead of being half-patched.
    ftp://ftp.rfc-editor.org/in-notes/rfc1535.txt

I routinely dot-terminate domain names and disable search lists,
and I believe software should treat any given domain name as it is
presented, without trying to second-guess the intent.  Software should
not try to guess intent when the syntax is unambiguous.

It is way too late to catch this particular horse, but removing bad
optimizations from current software releases would still be a useful
step to take.  It would certainly be better than continuing to keep
them around due to some notion that inertia is invincible.

-- Andras Salamon                   [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andras Salamon <[email-masked]>
Date: Mon, 7 Jul 2008 02:00:14 +0100

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jul 2008 11:38:24 +1000

> not try to guess intent when the syntax is unambiguous.

	no dots == local (search)
	dots == global unique

	It's only when you start treating one as the other that you
	get into problems.  This can be enforced in the getaddrinfo()
	and friends by not looking up single label tokens against
	".".  "localhost" is solvable before anyone complains about it.

> them around due to some notion that inertia is invincible.

	To get rid of searching you also need to get rid of alternate
	name spaces (NIS, /etc/hosts).

	We really need to provide / encourage mechanisms for home
	networks to get domains for $0 additional cost.  With IPv6
	we will be connecting networks, not machines.  ISP's need
	to come up with schemes which can be used to plug home
	networks into the global DNS.  ISP's are going to have to
	support reverse IPv6 zones (delegate/serve).  It's only a
	small additional step to support the forward zones in
	addition to reverse zone.

	e.g.
		<identifer>.<isp>.net -> <machine>.<identifer>.<isp>.net
	or
		<identifer>.home.<isp>.net ->
			 <machine>.<identifer>.home.<isp>.net

	Where <identifer>.<isp>.net or <identifer>.home.<isp>.net
	is a dynamic zone.  <identifer> may or may not be the account
	identifier.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jul 2008 11:38:24 +1000

e.g.

	Mark

---

From: Florian Weimer <[email-masked]>
Date: Mon, 07 Jul 2008 04:11:07 +0200

>    ftp://ftp.rfc-editor.org/in-notes/rfc1535.txt

Have you noticed that this document calls for the implementation of a
public suffix lis? 8-)

> I routinely dot-terminate domain names and disable search lists,

This doesn't work reliably with HTTP as deployed, by the way.

I don't see the problem with a static, non-devolving search list which
is always tried first.  Sure, there is a collision if certain TLDs are
introduced, but at least it's backwards-compatible.  But it's
unreasonable to assume that just because you paid ICANN a certain amount
of money, your shiny new TLD is globally usable--single root or not.  It
doesn't work that way with IP addresses, where considerably less
politics are involved, so I don't see why DNS should be any better.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Florian Weimer <[email-masked]>
Date: Mon, 07 Jul 2008 04:11:07 +0200