Hi Pieter,
On 10 May 2021, at 11:23, Pieter Lexis <pieter.le...@powerdns.com> wrote:
> You then invite the following issues:
>
> Clients need to match the tuple (ownername + prio + target) and get all
> data from all matched rrsets, whereas now you get all that data in one
> piece of rdata.
Inviting that issue is also a potential benefit, but I agree that the
implication exists. For example, the ability to publish sets of SvcParams with
long TTLs ought to increase the probability of cache hits for that data and
reduce SVCB response sizes.
> A client also can't figure out (if not doing DNSSEC valdiation
> themselves) if you have received all the SVC data for a certain name.
A client can't figure out without DNSSEC whether anything they have received is
correct in, in general. So setting aside that more general authentication
problem, I don't think it's correct to say that a client cannot tell whether
they have received a complete RRSet in the answer section of a response. It's
either there and complete or it's absent (and perhaps TC=1 if the reason for
its absence is message truncation).
There should be no response possible in an implementation that adheres to the
protocol in which a truncated RRSet appears in the answer section. If we're
widening the net to implementations that don't follow the rules then I agree
anything is possible.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
