I like it in principle, so I say adopt.
I already see a significant problem, though I expect we can fix it
somehow after adoption:
After sending out all requests for SVCB records [...]
My understanding of section 3 implies that an implementing resolver MUST
NOT ask any of the nameservers until *all* their SVCBs have been
attempted, in the most common case where no encryption is supported by
the nameserver-set. That would *not* scale at all. Even with 13 NSs
it's a rather bad amplification factor, and it reminds me of the recent
NXNS attack.
On the whole, if a NS set has (many?) names without encryption support,
I'm afraid the corresponding zones may have to do without a guarantee of
getting encryption, though glue might help.
On 26/05/2021 15.21, Stephen Farrell wrote:
SVCB in the parent zone will take years to happen
The SVCB glue is just a slight optimization. I don't think it can even
save latency, just a packet per NS (and only in cases where the SVCB
exists).
--Vladimir
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
