[RSSAC Caucus] [Ext] TCP and TC (was Updating the RSSAC FAQ)

[Fred Baker]

Sending again using the right email address.

> On May 4, 2020, at 9:01 AM, Fred Baker <fredbakersba at 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 at icann.org> wrote:
>>> On May 1, 2020, at 22:22, Geoff Huston <gih at apnic.net> wrote:
>>>> On 2 May 2020, at 1:25 am, Dave Lawrence <tale at 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 at 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.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200504/959d28b6/signature.asc>