Re: DNS Speculation

[natron <shiftnato () gmail com>]

In your scenario, the root servers would have more control over the
*.google.com domain than google.com would, correct?  You are proposing
that the client/resolving DNS server cache the root server's response
and not let ns.google.com overwrite the entry.  As a general
discussion of trust, it shouldn't be a problem trusting either the
root server or ns.google.com to deliver info on google.com.

Assuming for a moment that one can place whatever additional records
in the additional section they choose, I would posit that they didn't
patch it because they don't care about that behaviour.  If
ns.google.com is an authority for google.com, you should be able to
trust whatever responses it receives, right?  In addition, if you can
take control of where ns.google.com points to, it's kind of irrelevant
that you can also change the cache for www.google.com.  Gaining
ns.google.com grants the ability to change the rest of them at your
discretion.

The issue the patch fixed was one of psuedo-authentication.  Random
ports helps ensure that the packets you're receiving came from where
they say they did, the root cause of the problem.

N

On Tue, Jul 22, 2008 at 11:51 AM, Alexander Sotirov <alex () sotirov net> wrote:

    On Tue, Jul 22, 2008 at 11:38:59AM -0500, natron wrote:
    > The AUTHORITY SECTION in a response tells you that ns2.example.com is
    > where you should look for www.example.com, but how do you know where
    > ns2.example.com is located?  The ADDITIONAL SECTION is the part that
    > tells you.  If you were to not include it, you would start the process
    > over for ns2.example.com -- but would get stuck in a loop where the
    > root server was telling you to go to ns2.example.com to find
    > ns2.example.com's IP address.

    Yes, the response in step 5 in my email has an authority record for
    ns.google.com and an A record giving its IP address. However, after you do a
    single query for any *.google.com domain, the DNS resolver should cache the
    authority record and not accept any updates to it that are not
coming from the
    .com nameserver. Since the .com nameserver is queried very rarely (only when
    the google.com authority record expires), the chance of an attacker spoofing
    one of its replies is much lower.

    If the attacker is spoofing replies from ns.google.com, they
should not be able
    to update the cached authority record for the google.com domain.
Perhaps this
    is not how resolvers work, but the question is why couldn't we patch them to
    work like this instead of (or in addition to) adding random source ports?

    > I can't think of any reasons why this would be used by anything other
    > than looking up domain servers, but I would assume you can stick in a
    > www. in that section and probably have it cached.  (Haven't tested.)

    I can't think of any reason for this either, but there must be one since the
    DNS patches added source port randomness instead of fixing this behavior (if
    that's what the real problem is).

    Alex
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave