I’m not a fan of the new text in section 4.3: Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys or malformed SvcParamValues.
It is perfectly reasonable for a recursive resolver to reject any malformed DNS record. There’s a significant difference between “malformed” and “unknown”. A recursive resolver should definitely allow records with unknown SvcParamKeys, but if the format of a record is known, a resolver should be allowed (encouraged, in fact) to check that it conforms to that format. Brian On Apr 21, 2021, at 7:13 AM, Ben Schwartz <bemasc=40google....@dmarc.ietf.org<mailto:bemasc=40google....@dmarc.ietf.org>> wrote: Thanks for all the great input during WGLC. Here's the changelog for the latest draft: * Specify interaction with EDNS Client Subnet and Additional section caching * Rename "echconfig" to "ech" * Add a suite of test vectors (both valid and invalid) and more examples * Clarify requirements for resolvers' (non-)use of SvcParams * Clarify guidance regarding default ALPN values On Wed, Apr 21, 2021 at 9:51 AM <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) Authors : Ben Schwartz Mike Bishop Erik Nygren Filename : draft-ietf-dnsop-svcb-https-05.txt Pages : 56 Date : 2021-04-21 Abstract: This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org<mailto:DNSOP@ietf.org> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
