Re: [Resolverless-dns] Paper on Resolver-less DNS

[Erik Sy <[e-mail]>]

Hi Paul,

On 8/16/19 21:50, Paul Vixie wrote:
> On Friday, 16 August 2019 18:40:43 UTC Erik Sy wrote:
>> ...
>>
>> Beyond this, I describe in Section 3.2.2 of the paper restrictions for
>> DNS records retrieved via resolver-less DNS. Here, it is recommended
>> that user agents restrict the use of unvalidated DNS records retrieved
>> via resolver-less DNS within the context of the same website or possibly
>> the same browser tab. This measure prevents the described leaks beyond
>> the applied context of a website or browser tab. Thus, I do not agree
>> that resolver-less DNS contributes to the described increase in the
>> attack surface.
>>
>> Erik
> does this mean an fbcdn.net link occuring inside a facebook.com object would 
> require a real DNS lookup, and that any fbcdn.net DNS data included in the 
> facebook.com link would be ignored by a correctly implemented browser?

Let's assume, the user visits the website facebook.com. This website
requires the resource https://fbcdn.net/file1. Furthermore, the
connection with facebook.com pushes a DNS record for fbcdn.net to the
client. Now, the client can use the provided DNS record to retrieve
https://fbcdn.net/file1. However, if the server authentication with
fbcdn.net fails, this requires the client to evaluate a fallback DNS lookup.

Expanding this scenario, we can assume file1 requires to retrieve
https://a.com/file2 and the connection with fbcdn.net also pushes the
corresponding DNS record for a.com. Now, the browser can use the DNS
record for a.com to retrieve file2 because these connection occur within
the context of the same website assuming a successful server authentication.

Erik

> i ask, because of this:
>
>> ;; ANSWER SECTION:
>> www.microsoft.com.  CNAME  www.microsoft.com-c-3.edgekey.net.
>> www.microsoft.com-c-3.edgekey.net. CNAME www.microsoft.com-
> c-3.edgekey.net.globalredir.akadns.net.
>> www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net. CNAME 
> e13678.dspb.akamaiedge.net.
>> e13678.dspb.akamaiedge.net. A 23.197.97.139
> my stub resolvers trust this from their recursive servers. but such CNAME 
> chains are ignored by recursive servers, since the authority can only speak 
> for one zone at a time. i'd like to be sure that i understand the rules you 
> are proposing for the web equivalent of all this.
>