Mark.. can you amplify a bit on: >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.
Because somewhere north of 10% of the world now validates.. On Wed, Jan 14, 2015 at 10:09 AM, Mark Andrews <[email protected]> wrote: > > 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 >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
