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
pgpKn1hE3txf2.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
