At Tue, 8 Dec 2015 14:11:16 +0100,
Shane Kerr <[email protected]> wrote:
> As I mentioned a while ago, we have been working on a document to
> describe the various ways of (ab)using HTTP to transmit DNS traffic. We
> have finished a -00 draft, and I would appreciate it if you had a look
> and see if it makes sense.
I've read the draft. I think it contains some useful information, but
I don't have a particular opinion on whether this should be adopted as
a dnsop wg document - I'm not sure if it fits the charter of the wg.
Some comments on the draft (mostly editorial):
- Section 1
o Case 2: Clients may want to chose a resolver other than the one
locally available.
This doesn't necessarily seem to lead to DNS/HTTP; unless packets
using port 53 are blocked, clients can freely use other resolvers.
So isn't it essentially the same as case 1?
- Section 2.1
[...] The
difference between port 80 and 443 is that the traffic of port 80 is
usually intercepted as HTTP traffic while the traffic of port 443 is
usually considered to be encrypted, [...]
I first thought 'intercepted' should probably be 'interpreted'. On
reading toward the end of the doc I now see that is actually the
intent, but to avoid such confusion it might help if you say, e.g.
'usually intercepted as HTTP traffic for purposes as deeper
inspection'
- Section 2.2 s/coming/becoming/ ?
[...] Second, it
prevents resolvers from coming amplifier of reflection attack.
- Section 2.4 s/cause/because/ ?
[...] The support of DNSSEC might also be a
problem cause the response usually do not contain RR records with the
answer, making it impossible for a client to validate the reply.
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
