On Wed, May 12, 2021 at 3:32 PM Eric Orth <ericorth= 40google....@dmarc.ietf.org> wrote:
> > > On Wed, May 12, 2021 at 6:21 PM John Levine <jo...@taugh.com> wrote: > >> It appears that Joe Abley <jab...@hopcount.ca> said: >> >> Agreed that there is no such issue with either wire format if all >> parties in the ecosystem are bug-free and RFC-compliant. >> > >> >Do you know of an example of a DNS authoritative or recursive server >> that does return truncated RRSets in the ANSWER section? >> > > Honestly, those aren't the caches I'm worried about. What worries me the > most is the caching layers between the recursive and the client (e.g. > forwarders and various libraries on the enduser machine, including caching > in various clients themselves). While I don't have any examples in mind > specifically of these layers messing up RRSet cohesion, there are many > examples of various bugs in these layers (e.g. see all the recent > "name:wreck" fun), and there are a million implementations (hyperbolic) to > worry about. > > And given that these layers are typically past the last DNSSEC validation, > there is not a lot here to historically depend on fully correct behavior. > Who would have noticed if some bug in a client means that every once in a > while it's only attempting connections on 4 out of the 5 addresses it's > supposed to have received? > > My overall point is that I'm strongly in favor of the wire format with > less potential points of failure in correctly transmitting and stitching > together the individual components of endpoint information that really need > to stay cohesive. > Unless you have a guarantee that the client can always obtain the full and complete RRset from the resolver in non-attack situations, you already have a major problem (i.e. even assuming each SVCB plus SvcParameters is a single RR, but where more than one SVCB are published in an RRset). There are multiple problems, if you cannot guarantee the RRset being delivered to the client: 1. If an RRset contains both an AliasMode and a ServiceMode record, the client MUST ignore all ServiceMode records (per 2.4.1 of the draft). If the complete RRset is not returned, the client cannot be guaranteed to pick the right record. 2. If an RRset contains multiple ServiceMode records, the client SHOULD start making connection attempts with the highest priority record. If the complete RRset is not returned, the client cannot be guaranteed to pick the right record(s) in the right order. Note that if the client API to DNS only returns a single RR from an RRset, this will not in any way depend on the SvcPriority value, as that is an opaque value within the randomly-ordered RRset. So, either the client is guaranteed to get all the RRset members (and the draft is a viable approach to the intended goal), or it isn't (and it isn't). If the guarantee is present and applicable to the existing parts of the draft, it also absolutely guarantees the necessary preconditions for combining the key/value elements if they are split into different RRs in the RRset (rather than one combined entity). The entire path from resolver to client has to work for the existing draft to function as intended. And if it does, it is mathematically impossible for the split key/value mechanism to not also work. It is demonstrably more likely that a complex parser will have problems, than something that combines data from simple RRs in simple RRsets will have problems. (The history of SMTP is, I think, a good poster child for this, with MX, A, AAAA, plus DNSSEC and TLSA support in the clients, which are email transport things, not merely DNS things.) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
