On Wed, Mar 18, 2020 at 10:34 PM Daniel Migault <[email protected]> wrote:
> Thanks for the response. I apology for the late response. Please see > inline some comments/responses. I will review 02 later. > Thanks in advance. Note I am interested in SVC RRsets as I am using them to discover DNS > resolvers [1] - using non http or https scheme. Comments or > suggestion regarding the use SVCB would be highly appreciated. > I'll be happy to advise on that topic. I would start by looking at the adaptive DNS draft, which is pursuing similar idea: https://tfpauly.github.io/draft-pauly-adaptive-dns-privacy/draft-pauly-adaptive-dns-privacy.html#rfc.section.3.1 unless I am missing something. I do not see the use of two RRsets doubling > the load. The mechanism coudl be similar as the Alias Form specifying the > next RRtype. > Clients would have to perform queries for both types separately (double the queries to the recursive). A recursive resolver processing a query for the "service form" type would have to query the authoritative for both the service form and the alias form, at every step of the alias chain (double the queries to the authoritative). .... This section is the first time HTTPSSVC is mentionned. My interpretation of >>> HTTPSSVC is that HTTPS is mentiond in the RRtype because that >>> information is >>> not contained into the QNAME. My understanding is that using RRTypes was >>> discouraged though I might misinterpret 8556. >>> >> >> I wasn't able to find this reference. >> >> <mglt> > here is the text I was referring. > https://tools.ietf.org/html/rfc8552#section-1.2 > </mglt> > I think the draft follows that recommendation, by splitting each protocol into its own RRSet to avoid sending the client irrelevant information. .... > With DNSSEC and parameters that includes keys, it might happen that >>> response >>> may be large and that the server may select some responses to put in the >>> additional data. Some selection algorithms could be provided and DNSSEC >>> protected RRsets should be given a preference - though this won't be the >>> only >>> criteria. >>> >> >> The situation where a single ServiceForm RRSet refers to domains of which >> some are signed and some are not seems pathological, so I'm not inclined to >> propose an optimization for it. If the zone owner wants to prefer the >> signed zones, they can give them higher SvcFieldPriority. >> > <mglt> > I was suggesting the client prefers DNSSEC signed RRsets. Since a > delegation can occur to multiple cloud providers, I envisioned that some > may support DNSSEC other do not or are under NTA for example. > </mglt> > Sure, but the domain owner also knows which of its cloud providers support DNSSEC. The domain owner is free to increase the priority of those that use DNSSEC.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
