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