Sending again using the right email address.
On May 4, 2020, at 9:01 AM, Fred Baker <fredbakersba@gmail.com> wrote:
Stepping aside a bit from the question of the FAQ... Yes, this is a change of subject, which is why I changed the subject line.
Does this become a requirement for resolvers using the RSS? RFCs 1034/1035 only hint at it (they define the bit without defining its use case). If, however, I look at RFC 2181, it says
Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies.
In the absence of any other alternative that reliably works (Geoff will argue from his data that IP fragmentation and reassembly is not a mechanism that works reliably to transport larger replies, and protocols like SCTP and QUIC are not generally used to communicate with the RSS), that reads to me as "responding with TC set means 'please ask again using TCP'".
The interface between a host and its resolver is another question; I would argue wants gets the same answer, but that's perhaps secondary to a conversation about the RSS.
So, is it reasonable to say that the ability to pose a DNS request and receive a response using TCP, and using TCP as the fallback transport when TC is invoked, is a requirement of a modern resolver?
On May 4, 2020, at 1:44 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
On May 1, 2020, at 22:22, Geoff Huston <gih@apnic.net> wrote:
On 2 May 2020, at 1:25 am, Dave Lawrence <tale@dd.org> wrote: Geoff Huston writes:
"Finally, many more resolvers today are capable of falling back to TCP when they receive a truncated response over UDP”
really? Where is the study that publishes this finding?
It could use clarification, certainly, beyond just the fuzziness of "many more". There are several metrics which could all claim to be relevant. A few of them seem like they are probably true in raw numbers if only because of overall growth over the past couple of decades (and yes, good measurement would confirm that). Like:
* Total number of implementations * Total number of running servers * Total number of people served (not strictly a resolver, but still relevant)
But, maybe that picture changes when you ask about the percent of the whole, and then "many more" might not apply.
Measurement rules, for sure. I also don't think it is entirely out of place to make a qualified claim based on our cumulative anecdotal experience that overall the TCP fallback scenario is improved now vs the past, as long as it clear that it is supposition rather than data.
My measurements of TCP use from time to time report that the relative number of users that sit behind recursive resolvers that cannot perform TCP appear to be unchanged for the 6 years that I’ve looked (from time tim time). Now there are many ways of reporting DNS (resolvers, users, queries, … as well as absolute numbers or relative numbers).
Therefore I don't understand the basis of the TCP claim in that report - it seems apocryphal to me
I’ve deleted that sentence from the answer to question 1. The answer no longer makes any statements regarding how many resolvers can fallback to TCP if UDP comes back truncated.
—Andrew
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.