Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

[Warren Kumari <[e-mail]>]

On Tue, Jan 13, 2015 at 9:13 AM, Paul Wouters <[e-mail]> wrote:
> On Tue, 13 Jan 2015, Davey Song (宋林健) wrote:
>
>> As to the draft itself, there are two questions:
>>
>> First, for a same transaction, the cost from using TCP may be more than
>> the
>> gain from the queries you save, which may ultimately let the performance
>> become even worse. Do you have any consideration on this?
>
>
> And also, if already doing tcp the the auth server, why not just ask the
> 4 questions asynchronously over the TCP channel, instead of waiting to
> see if the server will give you a freebie, where you might have to send
> another query (After the RTT) for the data?

Because you don't *know* all of the questions you need to ask until you get:
A: some of the answers and / or
B: some of the resources at the answers.

If I want to send you mail at nohats.ca I do an MX for nohats.ca.
This gives me back the inventively names mx.nohats.ca:

wkumari-macbookpro1:tmp wkumari$ dig +short mx nohats.ca
10 mx.nohats.ca.

Only *after* I get that back do I know that I need resolve
mx.nohats.ca into an address. Similar issues happen with CNAME chains,
etc. Before getting back some answers I don't know that I'll need the
others.

I also hit www.nohats.ca in a webbrowser while running 'tcpdump port
53' and got:
12:16:29.846791 IP 10.2.3.97.31679 >
google-public-dns-a.google.com.domain: 49210+ A? www.nohats.ca. (31)
12:16:30.640061 IP 10.2.3.97.36067 >
google-public-dns-a.google.com.domain: 22581+ A? nohats.ca. (27)
12:16:31.953095 IP 10.2.3.97.32374 >
google-public-dns-a.google.com.domain: 55912+ A? www.paypal.com. (32)
12:16:31.953447 IP 10.2.3.97.39594 >
google-public-dns-a.google.com.domain: 52512+ A? api.flattr.com. (32)
12:16:32.063993 IP 10.2.3.97.57364 >
google-public-dns-a.google.com.domain: 28378+ A?
blog.intelligistgroup.com. (43)
12:16:32.064204 IP 10.2.3.97.22750 >
google-public-dns-a.google.com.domain: 14230+ A? libreswan.org. (31)
12:16:32.064404 IP 10.2.3.97.43119 >
google-public-dns-a.google.com.domain: 42571+ A? heml.is. (25)
12:16:32.265799 IP 10.2.3.97.22719 >
google-public-dns-a.google.com.domain: 60101+ A? www.paypal.com. (32)
12:16:32.825883 IP 10.2.3.97.15536 >
google-public-dns-a.google.com.domain: 65455+ A? flattr.com. (28)
12:16:32.826109 IP 10.2.3.97.36181 >
google-public-dns-a.google.com.domain: 64959+ A? static1.flattr.net.
(36)
12:16:32.826273 IP 10.2.3.97.12831 >
google-public-dns-a.google.com.domain: 1690+ A? static2.flattr.net.
(36)
12:16:32.831187 IP 10.2.3.97.23825 >
google-public-dns-a.google.com.domain: 11673+ A? static3.flattr.net.
(36)
12:16:32.832103 IP 10.2.3.97.32762 >
google-public-dns-a.google.com.domain: 63752+ A? static4.flattr.net.
(36)
12:16:32.897722 IP 10.2.3.97.27532 >
google-public-dns-a.google.com.domain: 18520+ A? 2.bp.blogspot.com.
(35)
12:16:32.930835 IP 10.2.3.97.43140 >
google-public-dns-a.google.com.domain: 57738+ A?
sharoncol.balkowitsch.com. (43)
12:16:32.986412 IP 10.2.3.97.51562 >
google-public-dns-a.google.com.domain: 52486+ A? images.nap.edu. (32)

This involved doing 6 separate queries to ns[12].flattr.net - if these
servers implemented this new thingie, when I did the first lookup
(api.flattr.com) it could have given me the answers for flattr.com,
static1.flattr.net., static2.flattr.net., static3.flattr.net.,
static4.flattr.net.
Until I've spoken to api.flattr.com and done some stuff (~800ms) I
have no idea that need to get static[1-4].flattr.com.


>
>> Second, the purpose of using TCP is to mitigate amplify attack as you
>> describe in the draft. I notice that there is a draft using DNS cookie to
>> counter that problem. But it lacks incentive to deploy. For my concern,
>> you
>> can consider to combine the two ideas to achieve better result.
>
>
> The cookies wouldn't help much because it per definition introduced
> another round trip.
>
> Also, why hardcode the records on the auth server. I think it is much
> better to leave the auth servers as is, and have resolvers figure out
> dynamically what is often asked in bundles and see if it can stuff
> in an additional record there.

hmmm.. that's an interesting idea. This requires changing the stub as
well, which feels like lots of work :-P


>
> While I see a great use of a long term TCP connection between stubs and
> resolvers, I am not sure I'm much in favour or doing lots of TCP between
> resolver and auth server.
>
> Paul



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf