On May 22, 2019, at 7:01 PM, Erik Nygren <erik+i...@nygren.org> wrote: > > Some comments: > > * We should define what TLS SNI value gets sent. Perhaps the first value of > "domain-to-match" when present, but preferably the hostname of the URL when > it's not an IP?
The "domain-to-match" values are not known until after the query has been responded to. Thus, it seems like the only likely SNI value would be the domain name of the resolver, if the application knows that. We can include that in a future draft. > * Should clients consider the templates list to be ordered or unordered? We > may wish to define the behavior for handling multiple entries. (A common > case might be both an IPv6 and IPv4 address. Some clients might only have > only one of those, so would need to filter appropriately, and operators may > wish to specify an ordering preference such as IPv6-preferred.) Our first guess was "unordered". The draft says: If the "template" array has more than one string, a client can consider them all to be of equal value when finding a DoH server associated with the resolver. My personal view is that suggesting order always complicates processing for very little actual gain. Assume that clients are smart if they want to be smart. > * It would be worth a conversation with the people working on PvD in IntArea > to see if there is some alignment (eg, in-terms of JSON practices, and > perhaps even with PvDs being able to include or reference a > resolver-information block). There might be a path here that could also help > with the split-horizon case. The PvD folks are free to do their JSON however they want. It may be premature to try to add DoH information to their document. > * With the draft-sah-resolver-information framework, we may wish to also have > an attribute or draft for specifying the DNS64 prefix to allow client-side > DNS64 synthesis. (On the other hand, there are also drafts to send this via > an RA option as well as some other paths in-addition to other mechanisms. So > perhaps another mechanism isn't needed.) draft-sah-resolver-information framework makes it easy for anyone to suggest new additions to the information. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
