Dailydave mailing list archives
Re: DNS Speculation
From: natron <shiftnato () gmail com>
Date: Tue, 22 Jul 2008 12:27:09 -0500
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
Current thread:
- Re: DNS Speculation, (continued)
- Re: DNS Speculation Tyler Krpata (Jul 22)
- Re: DNS Speculation Cedric Blancher (Jul 23)
- Re: DNS Speculation ninjaboy (Jul 23)
- Re: DNS Speculation Cedric Blancher (Jul 24)
- Re: DNS Speculation marc_bevand (Jul 25)
- Re: DNS Speculation Bryan Burns (Jul 25)
- Message not available
- Re: DNS Speculation marc_bevand (Jul 28)
- Re: DNS Speculation Macvarish, Richard C (Jul 24)
- Re: DNS Speculation natron (Jul 22)
- Re: DNS Speculation Dominique Brezinski (Jul 23)
- Message not available
- Re: DNS Speculation Joseph Patterson (Jul 25)