Subject: [dnsext] One other argument for local scope...

From: Nicholas Weaver <[email-masked]>
Date: Mon, 6 Oct 2008 09:09:48 -0700

I've made the argument that there should be a separate notion of local  
scope (data which is only valid for resolving an individual  
outstanding query) and global scope (the cache), because of the  
ability to prevent race-until-win attacks by limiting what gets  
included into the global scope.

One other advantage, it makes the following case always resolve  
correctly:

example.com NS ns.example2.org
	ns.example2.org A 12.34.56.78

example2.org NS ns.example.com
	ns.example.com A 90.12.34.56

This will resolve both correctly AND safely:  A query to .com for www.example.com 
  will get:

example.com NS ns.example2.org
	ns.example2.org A 12.34.56.78

Since it is safe to use the value for ns.example2.org's A record  
within the local scope (after all, you trust that example.com's NS is  
ns.example2.org, so you can trust that A record solely for the purpose  
of this lookup), the recursive resolver will contact ns.example2.org  
and get the proper value.

Yet because it is not within the global scope, the out-of-bailywick A  
record can't affect any other query, making it safe.

Yet if you have only a global scope (only a cache), you can NEVER  
accept the A record for ns.example2.org if you want safety, instead  
you'd try to query .org for ns.example2.org, which points you to .com,  
which will fail (Open the box with the crowbar inside the box).

Yet if you want resolution to work with only global scope, you are  
unsafe, as an attacker could use this to at least temporarily bind an  
arbitrary name to his value (old school cache poisoning).

Thoughts?  Comments?

One other question:  Is there any document explicitly forbidding or  
recommending against the case in question?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Oct 2008 16:22:20 +0000

> Thoughts?  Comments?

i am becoming very comfortable with the idea of local scope.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 10 Oct 2008 11:45:14 -0700

At Mon, 6 Oct 2008 09:09:48 -0700,
> included into the global scope.

[snip]

> Thoughts?  Comments?

The idea seems to be very similar to, if not same as, what Ohta-san
has been proposing, see, e.g.:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01212.html

I think this type of defense is generally a good idea.  It may not be
easy or trivial to actually implement it for existing caching server
code, though.  At least it won't be easy to implement it for BIND9.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 13 Oct 2008 10:38:49 -0700

At Fri, 10 Oct 2008 12:00:12 -0700,
Nicholas Weaver <[email-masked]> wrote:

> However, Ota also brings up an excellent point: DOES prevent me from  
> saying to verisign:
> 
> www.mydomain.com NS ns1.google.com
> 	ns1.google.com A 66.6.66.6
> 
> and then tricking a victim into visiting mydomain.com?
> 
> A lot of my experimenting suggests that the resolvers I've testing  
> (I'm building a Java test applet) will accept and follow such records,  
> at least in the second level domain (I haven't tried attacking .com  
> however).

Please actually try attacking .com, then:-)

Seriously, I'm very much interested in whether .com or any other major
top level domains would blindly accept such a bogus glue address
record.  If they do, it would create even much stronger motivation to
implement and deploy additional defense.

---
JINMEI, Tatuya

---

From: "Matthew Dempsky" <[email-masked]>
Date: Mon, 13 Oct 2008 11:21:30 -0700

>     ns.example2.org A 12.34.56.78

Where do the com servers get the ns.example2.org A record from?  Does
it resolve it like a normal cache by asking the org and example2.org
name servers or does the user have to specify it?

Also, rather than changing DNS clients to support the above glue, why
not instead use records like

    example.com NS ns.example2.org._local-glue.example.com
    ns.example2.org._local-glue.example.com A 12.34.56.78

and work with existing DNS caches?

---

From: "George Barwood" <[email-masked]>
Date: Mon, 13 Oct 2008 20:30:25 +0100

RFC 1034, section 4.2.1 states:

<<  In particular, if the name of the name server is itself in the subzone, 
we could be faced with the situation where the NS RRs tell us that in order 
to learn a name server's address, we should contact the server using the 
address we wish to learn.  To fix this problem, a zone contains "glue" RRs 
which are not part of the authoritative data, and are address RRs for the 
servers.These RRs are only necessary if the name server's name is "below" 
the cut, and are only used as part of a referral response. >>

"Only necessary" implies that resolution will occur using only this specific 
type of glue, where the name of the name server is in the subzone.

That specifically rules out cases where other kinds of glue are required, 
hence the example is outside the standard, and also I would suggest common 
sense.

---

From: Matt Larson <[email-masked]>
Date: Mon, 13 Oct 2008 16:14:30 -0400

> However, Ota also brings up an excellent point: DOES prevent me from  

An important and relevant point here is that you don't communicate
directly with VeriSign to make changes in the .com registry; rather,
you use an ICANN-accredited registrar.  The .com registry is "thin":
it contains no registrant-specific information.  The registry only
knows which registrar owns the domain.

> and then tricking a victim into visiting mydomain.com?

There are two main kinds of objects in the .com registry, domains and
name servers.

Only the registrar that owns mydomain.com can make any changes to it.

If the name server ns1.google.com already exists, any registrar can
associate that name server with any of its domains.  (This isn't a
cache-poisoning attack vector: at worst, it sends unwanted traffic to
authoritative name server.)  However, only the registrar that owns
google.com can make changes to ns1.google.com.

If the same registrar owns both mydomain.com and google.com, then that
registrar could make the changes described above.  However, one hopes
that the registrar's systems--which unlike the .com registry, do have
knowledge of which specific users own which domains--would prevent the
owner of mydomain.com from changing one of google.com's name servers
(or creating a new name server under google.com).

Matt

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 14 Oct 2008 15:49:47 -0700

At Mon, 13 Oct 2008 20:30:25 +0100,

> hence the example is outside the standard, and also I would suggest common 

I'm afraid we're talking about different things.  My specific
comment/question in the previous response was about domain
registration phase, where the name resolution rules defined in RFC1034
don't matter.

---
JINMEI, Tatuya