Re: DNS Speculation

[natron <shiftnato () gmail com>]

Additionally, there's no A record in the invalid response, but there
are A records if it's a valid response.  Consider the output from
www.google.com:

;; AUTHORITY SECTION:
l.google.com.           56129   IN      NS      e.l.google.com.
l.google.com.           56129   IN      NS      h.l.google.com.
l.google.com.           56129   IN      NS      f.l.google.com.
l.google.com.           56129   IN      NS      b.l.google.com.
l.google.com.           56129   IN      NS      a.l.google.com.
l.google.com.           56129   IN      NS      d.l.google.com.
l.google.com.           56129   IN      NS      c.l.google.com.
l.google.com.           56129   IN      NS      g.l.google.com.

;; ADDITIONAL SECTION:
d.l.google.com.         54223   IN      A       66.249.93.9
h.l.google.com.         53843   IN      A       74.125.45.9
c.l.google.com.         54003   IN      A       64.233.161.9
g.l.google.com.         53704   IN      A       64.233.167.9
b.l.google.com.         53919   IN      A       64.233.179.9
e.l.google.com.         53943   IN      A       209.85.137.9
f.l.google.com.         53784   IN      A       72.14.235.9
a.l.google.com.         53878   IN      A       209.85.139.9

I assume that mucking with ns.google.com's ability to update
*.google.com records on the fly would probably negatively impact large
organizations current DNS architectures, where they probably rely on
this for redundancy and load balancing.

Nathan

On Tue, Jul 22, 2008 at 12:18 PM, natron <shiftnato () gmail com> wrote:
> 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