> On 6 Nov 2018, at 5:27 am, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> > wrote: > > On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren <erik+i...@nygren.org> wrote: > How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it > more DNS-aligned (e.g. the name as a separate field in the record) not help > here? > > Thanks for mentioning DNS-Alt-Svc, Erik. > > Compared to URI or the proposed HTTP record, one thing that's different about > DNS-Alt-Svc is that Alt-Svc is always optional, as currently defined, and > DNS-Alt-Svc inherits those semantics. That means servers have to be prepared > for some users to ignore the ALTSVC record, so the apex would still need AAAA > records.
The publishing or the lookup? > Being optional may seem like a deficiency for this application, but I now > think it's actually the best we can do as a first step. If we start with an > optional record type that offers added value (e.g. performance, privacy, or > security), then both client vendors and server operators have a reason to > invest in deployment. Once it's widely deployed, then we can imagine > simplified architectures that rely on the new record type, starting with > servers that don't need to support legacy clients. > > I think it's reasonable to have a roadmap to a full transformation of the DNS > architecture for HTTP, but every step along the roadmap ought to have clear > net benefit to each participating party. This seems to require a design more > or less like DNS Alt-Svc, where the additional indirection is coupled to > other improvements for HTTP. > > It comes from the HTTP world and is aligned with the existing AltSvc > feature and thus is useful in other ways (such as perhaps solving the DNS > deployabilty issues for encrypted SNI): > > https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02 What are the rules for populating the additional section of a response? It looks like nameservers will have to split the rdata up on commas the look for protocol-id=value pair at the start of comma separated field. Then look for the :port and remove it from value. then look to see if there was a host specified and if so lookup up that name. Wouldn’t be better to pre-parse the fields in the record? [<len><id-len><id><host><port>[<name-len><name><value-len><value]*]{1+} where host is in DNS wire format and . (00) is used for a empty host field in the alt-srv record? Libraries can reconvert this to textual format if that makes it easier for a browser though you may as well use it in structured format. > - Erik > > > > On Sun, Sep 23, 2018, 10:41 AM Ray Bellis <r...@bellis.me.uk wrote: > On 21/09/2018 19:11, JW wrote: > > > I also feel from this discussion, we are all roughly on the same page. > > We want SRV as the long term solution ... > > except that we heard at the side meeting in Montreal (albeit from > browser people rather than content people) that they *don't* want SRV, > because it has fields that are not compatible with the web security model. > > I still want to define a new RR that does have mutually agreed semantics > that's specifically for use by HTTP(s), but so far no takers. > > Ray > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
