This change seems reasonable, and makes “.” still more useful for the generic SVCB case.
Thanks, Tommy > On Oct 6, 2020, at 4:51 PM, Ben Schwartz <[email protected]> > wrote: > > Hi DNSOP, > > There was recently an interesting proposal [1] for a change to the SVCB draft > that seems to merit input from the working group. > > Background: > When using SVCB, clients append an underscore prefix ("Attrleaf") to the > name, containing the "scheme". When there is an actual URI involved this > will literally be the URI scheme, e.g. _ftp.ftp.example.net > <http://ftp.ftp.example.net/>. Schemes can prepend additional > underscore-prefix labels to encode scheme-specific service identifiers; the > only anticipated use for this is a port number (e.g. > _8080._https.www.example.com <http://https.www.example.com/>). > > SVCB also contains a small optimization: In ServiceMode, if the TargetName is > ".", this means "use the address records for the owner name". This reduces > packet size (since name compression is not possible in new RR types), but > more importantly, it makes zone file editing easier and guides zone owners > toward the "happy path", where there is no latency penalty because the > resolver has already requested the corresponding address records. > > This construction works well for HTTPS on port 443, and for any lookup > following an AliasMode record, because in those cases the SVCB/HTTPS, A, and > AAAA queries all share the same QNAME. However, it does not work when the > initial query has underscore labels and returns a ServiceMode record, because > the ServiceMode record's name is not the hostname (due to the underscore > labels). > > Proposal: > The proposal would change the meaning of "." from "Use the SVCB record's > owner name" to "Use the SVCB record's owner name *minus any leading > underscore labels*". > > Pro: TargetName = "." would now coincide with the "happy path" in all > ordinary cases. > * Simpler guidance to zone owners (always prefer ".") > * Clearer design rationale ("." is where the address queries already went) > * Shorter RDATA in the "happy path" case (for some non-HTTPS uses) > > Con: > * Servers (recursive and authoritative) that perform Additional Section > processing would have to implement this underscore-label stripping procedure. > This would be a rare violation of DNS's usual abstraction barrier (servers > don't normally discriminate based on the format of labels). > * There could be a change of operational control (e.g. zone cut or CNAME) > between _port._scheme.$HOSTNAME and $HOSTNAME, in which case the ServiceMode > record might actually prefer to use address records at its own name, despite > the latency cost. > * This gets very tricky if an AliasMode or CNAME target contains underscore > prefixes. It may be impossible to stay on the "happy path" in all these > cases. > > [1] https://github.com/MikeBishop/dns-alt-svc/issues/252 > <https://github.com/MikeBishop/dns-alt-svc/issues/252> > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
