Snapshot of original Etherpad minutes.
doh agenda
Notes: Aaron Falk
* Hackathon Experiences (S. Bortzmeyer)
Slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-doh-hackathon-feedback-01
Paul: doc authors learned a lot from the implementations via the Hackathon
Mark: why were people using options?
Tom: see github project ref on list, certain MIME types don't get a response; seems like a javascript in a browser problem.
Patrick: doc goal was to be able to allow browser apps to participate in DOH within origin's security policies.
Tom: agreed, browsers are doing the right thing. however, browsers need to be able to handle the option to respond to this type of request. Doc should address.
Tony: there's been some dicussion of correctness with response & status codes but should extend to options as well
* draft-ietf-doh-dns-over-https (P. Hoffman, P. McManus)
- https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/
- Update on changes, one more rev, and possible move to last call.
slides: https://datatracker.ietf.org/meeting/101/materials/slides-101-doh-draft-status-01
Issue #82:
Mark: choose 1 or MTI for both methods; prefer GET only but realistically MTI for both for servers; no opinion for clients, can use either
Martin: if you don't provide both on the server, things will break; client gets to choose. implication that client gets to choose which is cacheable and that kind of sucks
DKG: both make sense for server & client; if server redirects a POST to a GET, a client that only implements POST will break so clients need to do both if server can do either. You need this if DOH is going to be primary or sufficient DNS mechanism. by redirect, I mean 302 found. It's not desireable but possible.
Mark: <sarcasm> alt-service</> There's no standard behavior for caching POST. This will make CDN behavior unpredictable.
Martin: clients will blindly follow redirects, not a DOH-specific behavior
Patrick: addressing this in the doc
Tale: looks like we are reaching consensus in the room: GET/POST will be MTI on server and clients can implement either. will validate on list.
Issue #48:
Stuart: I would prefer to see this, b/c as the DNS continues to evolve with new extensions, it may or may not be work; if you make it look like UDP, you get any new formats for free
Ray: 'yes', should call it 'wire format' not 'UDP wire format' (or 'TCP wire format' which has framing you don't need).
Martin: 'yes', don't see any other rational approach to teh problem
Andrew: I'm with Ray about not referring to 1035 on this. (Paul throws shade on UDP encoding.) Should we say that MTI is for the server? Client will never get one if it doesn't ask for it. (uncertain grumbling in room)
Patrick: server can throw error or respond; client should be able to read this so MTI covers client
Olafur: wire format should be MTI. Another JSON format that is all-ecompassing would be good but will take a few yeears.
Martin: I submitted an issue earlier today (#107): there's a proposal to make upgradeing request to another content type easier. Suggestion was to overload the name of the query parameter block.
Patrick: this adds more complexity. Not sure about the value.
Ben: be sure to consider different query parameters
Kirsty Paine: enterprises will lose control over what DNS lookups & associated DNS-related protectsions; there's a detection issue here
DKG: security consideration addresses this point
DKG: Correction - this is actually in the operational considerations
* Charter discussion (B. Schwartz)
- Close the WG following RFC publication, or recharter for more work?
via jabber: would the JSON media type for DNS be within the current charter?
- Tale: one chair's opinion: that would not require a recharter
- Adam (AD): that surprises me, we need to talk
- Tale: my response was based on the charter text "wg is chartered to standardsize codings for responses"
erik: would end user subnet cachability be in scope? anyone interested in working on this? not a straightforward way to do that within HTTP semantics.
- Ben: would depend on contents of the proposal
patrick (as HTTPbis cochair): EDNS0 caching would not be in HTTPbis
olafur: would like to see JSON media formats within charter; recommend don't cache EDNS0
- Tale: DNSOPS discussed stress on the DNS system
ben: issues around discovery (boostrapping a connection to a DOH server) using only domain name needs authors for a draft, considered within scope
- Ben: won't close wg before current draft is complete
- Paul: thinking about writing a draft
- DKG: if a DOH server is defined by a URI, a mapping shouldn't be that hard
- Ben: there's a lot of history and past controversial proposals here
- Tale: our point is that it's now or never to do this work within this wg
* Opportunistic DNS (D. K. Gillmor)
Same slides as at HotRFC
https://datatracker.ietf.org/meeting/101/materials/slides-101-doh-opportunistic-dns-00
??: what if I only trust responses from certain sources? Can't we leave it to the user?
- DKG: leaving it to the user is problematic bc they don't make good choices. not encouraging promiscuous use of opportunistic dns.
Dan: could you give some examples you want to see it used?
- DKG: web browser, example.com links to a resource on example.net, doesn't require a DNS lookup
Andrew: this is an incredibly good Back to the Future moment. The DNS used to just do this for you. We learned this was called poison. If you want to do this, what you are talking about now is a new naming protocol that has the properties necessary to do this. E.g., How do you handle signed records? Maybe we should look at a brand new protocol.
- DKG: I don't think we need any additional machinery. You can use a specified DNS chain query.
Patrick: I'm calling this "Out of Band DNS". HTTP has a few mechanism that do request routing, restricted to the origins that you are talking to. HTTPbis should look at this use case. 2 major technical topics: 1. how do I know its safe to use this address, ie, some kind of a signature; 2. how do I know this is the endpoint that this name would have wanted me to use if I had looked it up on the authoritative server
David: This is cool. benefit would be for a social media site. See real value there from preloading the DNS. negative point: lots of folks use DNS for load balancing to the right data center. How about you use this without signatures? But that requires DNSSSEC support everywhere including in cliends. Happy eyeballs would work without DNSSEC. Feed addresses into an API. If origin requires TLS, you don't care whether the IP address is valid.
Shane: I think we need DNSSEC. Timing attachs are possible. Andrew is probably (on the edge of) correct. We might have hit the limitations of DNS.
Brian: I see a lot of cause for useing this data for your current request. Not sure it's somehting you want to cache. Contains the impact of any poison.
Mike: Thats not entirely true. Othre requests for that object will share the results. Could use alt-service to also notify clients of the avilability of QUIC.
Warren: I think this is a grand idea. Wrote a doc in DNSOP. Worth getting input from DNSOP.
Jim: Have you thought about DOS attacks using this mechanism?
- DKG: good point. need to think about applying client rate limiting to reduce work server can casue.
??: Have you thought about the costs associated with implementing this to balance against the benefits?
- DKG: the more significant costs are not around implementation.
Erik: between DOH, DNSOP, HTTPbis there are a lot of complexity, the camel is standing on it's own back.... are the working group boundaries becoming a restriction here?
Jabber: I haven't looked into this for a while.Would this use NS records to provide the IP address of the http server being used ?
Olafur: something seomething Poisoned Happy Eyeballs (of the Camel)
Suz: maybe we shouldn't call this DNS
- DKG: but there's lots of good stuff in DNS
Mark: maybe a barbof in Montreal
Paul: disagree with Suz, not uncomfortable with using DNS. Maybe this will be done over DOH and stuff it into a local DNS cache in the web.
David: name suggestion: Out of Band Names (NOOB)
- DKG: this is really in-band
Mark: can DOH populate the DNS cache?
- Paul: not out of scope or in scope; DOH doesn't say what you can do with the response to a query.
- Mark: small difference between I want to use DOH for my web browser and a random piece of software pupoulates my DNS cache.
- DKG: you would lose app context if you did that