One of the things we found out with CAA is that this extremely optimistic view of the support for unknown RR types by large hosting providers is not accurate.
-Tim > -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, July 2, 2018 11:53 PM > To: tls@ietf.org > Subject: Re: [TLS] DNS-based Encrypted SNI > > On Mon, 2 Jul 2018, Eric Rescorla wrote: > > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > > > This is at a pretty early stage, so comments, questions, defect > > reports welcome. > > > This structure is placed in the RRData section of a TXT record as a > base64-encoded string. If this encoding exceeds the 255 octet limit > of TXT strings, it must be split across multiple concatenated strings > as per Section 3.1.3 of [RFC4408]. > > It is strongly recommended not to use TXT records. Why not use a new > RRTYPE? Everything these days knows how to serve unknown record types (see > RFC 3597). The only possibly exception is provisioning tools of small > players, > but this document starts of saying you basically need to be on a bulk > hosting > provider anyway. They can properly provision. > > I need to think more about the document to see if there is really not > something > simpler or better possible. > > Paul > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
