Snapshot of original Etherpad minutes.

doh agenda

Notes: Aaron Falk

* Hackathon Experiences (S. Bortzmeyer)


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)
  - Update on changes, one more rev, and possible move to last call.


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?

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.

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

ben: issues around discovery (boostrapping a connection to a DOH server) using only domain name needs authors for a draft, considered within scope

* Opportunistic DNS (D. K. Gillmor)

Same slides as at HotRFC

??: what if I only trust responses from certain sources? Can't we leave it to the user?

Dan: could you give some examples you want to see it used?

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.

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?

??: Have you thought about the costs associated with implementing this to balance against the benefits?
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
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)
Mark: can DOH populate the DNS cache?
JavaScript license information