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.
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.
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
