Re: HTTPSSVC record draft

On Wed, Jul 03, 2019 at 02:45:47PM -0400, Erik Nygren wrote:
> Ben, Mike, and I have submitted the first version of a proposal for an
> "HTTPSSVC" DNS record.
> 
> TL;DR:  This attempts to address a number of problems (ESNI, QUIC
> bootstrapping, HTTP-to-HTTPS redirection via DNS, SRV-equivalent for HTTP,
> etc) in a holistic manner through a new extensible DNS record, rather than
> in a piecemeal fashion.  It is based on some previous proposals such as
> "Alt-Svc in the DNS" and "Service Bindings" but takes into account feedback
> received in DNSOP and elsewhere.
> 
> Feedback is most welcome and we're looking forward to discussing with
> people in Montreal.
> 
> Draft link:
> 
>       https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01

Some quick comments:

- What if SvcDomainName has length different from its length field?
  DNS wire-form names are self-delimiting (DNS message parsing relies
  on this).
- What does it mean for SvcDomainName to be absent in alternative
  service form? I would guess it means "same as RRNAME".
- Why there is length field for SvcFieldValue? Why not let it run to
  the end of record?
- 2 byte length field can encode values up to 65535, not 65536. 
  And the length of SvcFieldValue can not be that big, because
  RRDATA and DNS message length limits (both 65535) would be hit.
- Why 302 redirects instead of 307? 302 is frequently buggy.
- I-D.ietf-tls-tls13 -> RFC8446.
- Is there any envisioned use for chained HTTPSSVC records, except
  for type 0 record pointing to type 1 record?
- The MUST requirement to have only one type 0 record and then
  SHOULD behave non-deterministically if this is violated is pretty
  odd.


-Ilari

Received on Wednesday, 3 July 2019 19:55:27 UTC