In message <[email protected]>, Paul Wouters wr
ites:
> 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?
>
> > 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.
Nameserver vendors will just turn this on by default, that is ISC's
intention with named once the option is finalized. Theoretically
it should be ignored if not understood and if not it can be disabled
of a per server basis.
>From BIND 9.10 (configure --enable-sit).
server 2001:428::7 { request-sit no; };
http://users.isc.org/~marka/ts/gov.optfail.html
http://users.isc.org/~marka/ts/au.optfail.html
http://users.isc.org/~marka/ts/tld.optfail.html
http://users.isc.org/~marka/ts/bottom.optfail.html
http://users.isc.org/~marka/ts/alexa.optfail.html
FORMERR will just cause the nameserver to think that EDNS is not
supported. This is not a issue unless there are signed zones and
the resolver is validating.
BADVERS is identifiable in the response and you use it as a heuristic
to disable sending the option.
Echoing of the option is not a issue for cookies.
Timeout will be treated like EDNS is not supported.
NXDOMAIN can sometimes be returned by badly configured load balancers.
Adobe's load balance is a example of this. They just need CNAME's
added to the backend nameserver but Adobe doesn't seem to understand
this. They also don't respond correctly to CNAME queries despite
returning CNAME to A/AAAA queries.
> The cookies wouldn't help much because it per definition introduced
> another round trip.
Cookies don't "require" another round trip. Authoritative servers
can still adjust the responses they send depending upon whether
there is as valid server cookie or not.
Additionally I don't see nameservers leaving idle TCP connections
around for hours / days.
> 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.
>
> 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
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
