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

[Paul Vixie]

On Monday, 4 May 2020 17:36:00 UTC Paul Hoffman wrote:
> On May 4, 2020, at 9:01 AM, Fred Baker <fred at 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