On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <tpa...@apple.com> wrote:
> I wanted to chime in on this discussion as a client-side implementor who > has already widely deployed support for SVCB/HTTPS. > > The current format, where the parameters are structured as a list within a > single RR, is certainly simpler and less error prone for processing. Much > of the information contained as parameters within the SVCB RR are useful > for higher-level “application” logic. Within our deployment, the DNS stub > resolver daemon receives the RR and does the parsing, and passes up the > parameters bundle as a blob that is more or less opaque, to the layer that > handles actual connection processing (doing happy eyeballs, protocol > selection). > > Processing the content of SVCB parameters must be handled atomically: the > ALPN, ECH config, and any other information must be handled clearly as a > unit and not have any chance of being broken up. Lots of code is already > based on processing RRs as chunks of data, and requiring anyone looking at > the information to stitch the parameter list back together based on > multiple RRs that must be in a particular order adds complexity and invites > in bugs and errors. > > I’d strongly encourage sticking with the wire image we’ve already been > using and deploying. > Would it be accurate to say that as long as the wire format of both SVCB and HTTPS do not change, your client implementation(s) would not be impacted by any changes to zone file format? I.e. you don't implement any server code, so what the zone format is does not affect you, and how the wire format gets produced from the zone format is not relevant to you? Thank you for the details on how your client uses the wire format and the way those impact the end client systems. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
