Re: [dnsext] One other argument for local scope...
JINMEI Tatuya / 神明達哉
Nicholas Weaver <nwe...@ICSI.Berkeley.EDU> wrote:
>
> 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.
[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.
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
JINMEI Tatuya / 神明達哉
Nicholas Weaver <nwe...@ICSI.Berkeley.EDU> 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.
Matt Larson
> However, Ota also brings up an excellent point: DOES prevent me from
> saying to verisign:
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.
> www.mydomain.com NS ns1.google.com
> ns1.google.com A 66.6.66.6
>
> 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
JINMEI Tatuya / 神明達哉
"George Barwood" <george....@blueyonder.co.uk> wrote:
> << 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.
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
Internet Systems Consortium, Inc.
--