Re: [RSSAC Caucus] [Ext] TCP and TC (was Updating the RSSAC FAQ)
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.
On 04/05/2020 17:01, Fred Baker wrote:
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?
Yes, absolutely. See RFC 7766 (which strictly refers specifically to implementation) and draft-ietf-dnsop-dns-tcp-requirements (which relates to operationand configuration). Ray
On Mon, May 04, 2020 at 09:01:47AM -0700, Fred Baker wrote:
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.
There was some previous treatment in RFC 1123 (section 6.1.3.2):
DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries. Specifically, a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first. If the Answer section of the response is truncated and if the requester supports TCP, it SHOULD try the query again using TCP.
DNS servers MUST be able to service UDP queries and SHOULD be able to service TCP queries. A name server MAY limit the resources it devotes to TCP queries, but it SHOULD NOT refuse to service a TCP query just because it would have succeeded with UDP.
Truncated responses MUST NOT be saved (cached) and later used in such a way that the fact that they are truncated is lost.
As Ray has said, RFC 7766 made TCP a requirement. Mukund
On May 4, 2020, at 9:01 AM, Fred Baker <fred@isc.org> wrote:
Does this become a requirement for resolvers using the RSS?
We currently don't have any requirements on how anyone uses the RSS, and setting up requirements at this point might be considered a major issue. It is not clear how such a requirement would be enforced, nor why all of a sudden there are requirements when there have not been any in the past three decades. We certainly have expectations, but those are not requirements. Ray pointed out two relevant documents: RFC 7766 and draft-ietf-dnsop-dns-tcp-requirements. The former has requirements on implementations, and the latter has requirements on the expected operation of the DNS. Neither of those are requirements on resolvers (or any hosts) using a service, particularly not the RSS. --Paul Hoffman
On Monday, 4 May 2020 17:36:00 UTC Paul Hoffman wrote:
On May 4, 2020, at 9:01 AM, Fred Baker <fred@isc.org> wrote:
Does this become a requirement for resolvers using the RSS?
We currently don't have any requirements on how anyone uses the RSS, ...
i think there may be some misunderstanding. RSS has an inferior relationship to almost everything. we don't make or change protocols, we don't approve RZ changes. the only intgov decision we ever made was in 1998 when postel died, we had to meet for the first time to discuss whether to recognize ICANN as new IANA operator. we do not place requirements on how ths RSS is used; IETF does that. most rootops also participate in IETF and ICANN but we have no special voice there. whatever the community decides, is what we'll do.
We certainly have expectations, but those are not requirements. Ray pointed out two relevant documents: RFC 7766 and draft-ietf-dnsop-dns-tcp-requirements. The former has requirements on implementations, and the latter has requirements on the expected operation of the DNS. Neither of those are requirements on resolvers (or any hosts) using a service, particularly not the RSS.
we expect, which is different from we require, that most full resolvers who send queries to the RSS will follow the DNS protocol as defined by IETF. since that now includes TCP fallback as mandatory, we are within our rights to make dependent design decisions, such as clamping our returned EDNS message size to a size smaller than what the initiator offered. this wasn't possible before TCP fallback was made mandatory, because this would have meant any black hole was due to RSS overreach. now, it's RSS operating within the community's stated constraints, and any black hole shows up on some ledger other than ours. we need to know our constraints so that we can operate within them. so, to the question i think fred meant to ask, TCP fallback is an expectation we can have, and it's full-resolver behaviour that we can rely on, even if some full resolvers don't support TCP fallback and rely on UDP fragmentation. -- Paul
On May 4, 2020, at 11:34 AM, Paul Vixie <paul@redbarn.org> wrote:
so, to the question i think fred meant to ask, TCP fallback is an expectation we can have, and it's full-resolver behaviour that we can rely on, even if some full resolvers don't support TCP fallback and rely on UDP fragmentation.
In my mind, it is fine to say that RSSAC (or some other RSS-y body) expects resolvers to be able to do TCP fallback. That is, some or all of the RSS will act based on that expectation being fulfilled. --Paul Hoffman
On 04. 05. 20 20:52, Paul Hoffman wrote:
On May 4, 2020, at 11:34 AM, Paul Vixie <paul@redbarn.org> wrote:
so, to the question i think fred meant to ask, TCP fallback is an expectation we can have, and it's full-resolver behaviour that we can rely on, even if some full resolvers don't support TCP fallback and rely on UDP fragmentation.
In my mind, it is fine to say that RSSAC (or some other RSS-y body) expects resolvers to be able to do TCP fallback. That is, some or all of the RSS will act based on that expectation being fulfilled.
To me this is no-brainer. DNS clients need to follow the DNS protocol to be interoperable with DNS servers, RSS included. To emphasise this I propose to extend the last FAQ paragraph to read like this: For full interoperability DNS-over-TCP is nowadays mandatory to implement. For additional information please refer to RFC 7766. -- Petr Špaček @ CZ.NIC
participants (6)
-
Fred Baker -
Mukund Sivaraman -
Paul Hoffman -
Paul Vixie -
Petr Špaček -
Ray Bellis