Mark Andrews wrote:
if the stub who asked the SRV question does not receive the
addresses it needs in additional data, it will query for them. that
will put those addresses in cache, so that on subsequent same-SRV
questions, it will be present.

And that requires 2 RTT’s from the client which, despite being only a
few ms normally, has been enough for the HTTP folks to refuses to
deploy anything other than CNAME for ~2 decades now.

i don't think we've made it clear to them that this only happens once.

if the SRV is never fetched again, then there's no win to be had.

The win is loosing the extra RTT from the stub to the recursive

i know that. but the second RTT stub-rdns only happens once per unique SRV or AAAA/A. after they are both cached, they are returned in a single RTT.

And then we get back to the complaints from the HTTP side saying the
SRV takes longer than CNAME, which is valid for the first lookup if
you don’t fetch the additional records before returning.

i don't think they are objecting to something that only happens on the first time a unique SRV or AAAA/A is needed. someone should explain to them that we built this with the expectation that popular data would be fast, and unpopular data wouldn't make a difference in the long run.

P Vixie

DNSOP mailing list

Reply via email to