Davey,

Thanks! Some expanded comments from me, inline below...
At 2016-03-21 18:43:02 +0800
Davey Song <songlinj...@gmail.com> wrote:

> We have updated the draft as follows:
> 
> * fixed typos
> * made "transport:" always required

We had it implicitly optional if a client was using the protocol
directly (rather than converting a stub resolver DNS packet). However
this was quite correctly pointed out to be silly, so now we are always
explicit about it.

> * mentioned the possibility to use DNS over HTTP in a browser, if you
> really want to

It really doesn't make sense to use this technology in a browser, but I
grudgingly admit that it is *possible*, for someone very determined.

> * made the language stronger when talking about the 2-byte length label in
> TCP

I've tried 2x to make this clearer now. If this one is still confusing
then I either need to ask someone else to write this or I'll delete
this completely, do some tequila shots, and then try from scratch in a
new state of mind. ;)

> * expanded the security considerations. We go through RFC 3552, but do not
> find it applies much since we're basically just layering on HTTP.

If anyone has recommendations for a document that we can refer to which
covers security problems with DNS, HTTP, or TLS, that would be great.
Right now I resorted to saying "yeah, any problems in DNS, HTTP, or TLS
can be a problem here too" without references, because they do not
appear to exist.

> * give a explanation why using POST and try to answer the questions from
> the mailing list.
> * call for a Well-Know URI like /.well-known/dns-over-http. But I think It
> is still open for future edition.

Yes, I was unsure whether this makes sense. To be clear, I am not
opposed to the "/.well-known" approach, I'm just curious if it is
actually widely used.

> * add a co-author who contributed the first implementation and details of
> this protocol.

An international man of mystery. ;)
 
> Thanks to Bob Harold and Paul Hoffman for review. 

Yes, thank you!

I also note that someone pointed out that DNS over HTTP requires more
data, which can be a problem on slow links. I honestly hadn't really
considered this because the main concern when we were testing this was
extra RTT and the related latency. I admit this could be an issue for
some use cases. Is this important enough to merit some discussion in
the document?

Cheers,

--
Shane

Attachment: pgpKn1hE3txf2.pgp
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to