On Mon, 8 Mar 2021, Eric Rescorla wrote:
- Ignoring this issue, if the resolver were to accept the SVCB record
in glue from the parent zone, the information to be saved per zone ->
name server mapping will go up significantly since there is now an
SVCB record in addition to the NS record. If the SVCB information is
tied to the nameserver name, then it needs to be saved only once per
name server or name server set.
Yes, I would it expect it to use it for this request but not cache it.
I already brought up the fact that SVCB records cannot be served by
parents because the EPP infrastructure and software updates just aren't
there for such a change and won't magically appear in the next several
years to decade. It is really a non-starter.
But adding rules to resolves to treat some resolving paths different
from other paths is not a good design and hard to implement. It also
goes against various RFCs regarding using TTLs etc.
Clarification question for Eric: You have mentioned elsewhere in this
thread that you expect the protocol will allow both/either DNSSEC and
WebPKI to be used by an operator. Is the expectation that recursive
resolvers will support *both* mechanisms early on? Otherwise if a
resolver supported DNSSEC authentication only while the nameserver for
a zone supported WebPKI only, the two won't be able to communicate
securely.
I think we'd need to sort this out. The minimum requirement, I think,
is to allow the SVCB record to indicate what the authoritative supports,
so you don't get downgrade. If you have that, then both sides can
vote with their feet and we can see what is most deployable.
That's the core problem yes. And the ideas that have come up boil down to:
- Convey via DNSKEY / DS records - but this requires DNSSEC
- Convey via special named NS record (just signal and/or with pubkey/hash)
(dangerous because the glue isn't signed/authenticated)
- New RRtype about child zone published at parent (non-starter)
- Via TLSA/SVCB at the nameserver name (not child zone name) (and give up
on protecting zones containing their own nameservers in bailiwick)
- Try opportunisticly and do negative/positive caching of nameserver results
(with or without tls-dnssec extension)
The key questions are:
- Is encrypted DNS a property of the _zone_ or a property of the _nameserver_ ?
- Can the indicator for encrypted DNS for a _zone_ live in the parent zone ?
- Can the indicator for encrypted DNS for a _zone_ live in the child zone ?
- Can the indicator for encrypted DNS for a _nameserver live in the child zone ?
- Are zone indicators flags or pins ?
- Are nameserver indicators flags or pins ?
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
