paulehoffman / draft-hoffman-dispatch-dns-over-https Goto Github PK

From mnot:

The media type is "application/dns-udpwireformat"

That's needlessly long; suggest "application/dns-uwf".

According to RFC 2616 POST requests to server forces server to invalidate an entity.

Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are:

• PUT
• DELETE
• POST

In case when we use DNS over HTTP for user-resolver connection, POST requests will cause the server to perform a full lookup of the name again regardless TTL, thus making resolver useless.

From mnot:

I think it's a mistake to bifurcate the request style so fundamentally; it's HTTP tunnelling at its worst.

The GET-style request in your example (which I think is pretty representative) uses 44 octets to encode the body; the POST serialisation is 33 octets. However, with HPACK's huffman encoding (remember, you're requiring HTTP/2), that goes down to 34 bytes.

Are we really that sensitive to on-the-wire size? To me, the cache efficiency gains as well as simplicity more than make up for a 3% difference. The statement that "POST-ed requests are smaller" isn't going to be true, in pathological cases.

1. allowing the UPDATE opcode (or anything else that affects state) in GET requests is wrong, but the draft could get away with just saying that.
2. one could argue that allowing UPDATE, by default, is a security problem in (bad) network setups that currently do not ACL updates and get away with this because they trust their users - but they may not trust random sites on the Internet. When I discussed this with Paul his stance appeared to be that these people should be ACLing then.
3. We cannot be exhaustive about what opcodes affect things, so when writing words on this, be clear about the incompleteness.

CORS is defined by https://fetch.spec.whatwg.org/. The TR/cors/ copy is misleading and doesn't reflect what's implemented.

If HTTPs acts as a transport for DNS even with dns-udpwireformat MIME type, it should not be treated as a datagram encapsulted in a HTTPs header but a new byte stream over HTTPs(similar with DNS TCP). No truncation loop is needed. It is different from DNS wire-format over HTTP.

I'm wondering is it worthwhile differenciating the term "DNS HTTPs" with "DNS over HTTP(s)", in which the former means HTTPs transport usage, the later means DNS in a HTTP(s) tunnel.

Davey