Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)
Hi Wes, Thanks for responding. I'll trim to only the the remaining items needing a response, and express my appreciation at the clarified items. On 9/07/2016, 9:53 AM, "iesg on behalf of Wes Hardaker" wrote: >"Terry Manderson" writes: > > >> s1.2 is https://github.com/ogud/DNSSEC_ALG_Check going to be a fully >> stable URL? > >Per discussion in another thread: probably. Olafur certainly won't >delete it as the owner, and I doubt github will die anytime soon. > >The only other choice is to remove the helpful reference. Thanks. > >I've changed it to "validating resolver daemon" instead. Make more sense? It does. > >> s3.1.1, please use the example domain for such examples, ie example.com, >> and once you have used it do you really need to repeat it for each >> 'existing' text until you get to the non-existent tests and so on up to >> 3.1.14. > >Well, here's the deal: example.com won't work and the domain in question >actually does work. Some of them can probably be replaced with the root >server, but many others require somewhat specialized tests pointing to a >special domain. That one is known to be the only one that likely will >work for some tests at this point. The question is, what to do about >that? Can we list a known one? Must we list a useless one instead? >Should we pre-declare the problem? I've been waiting for this to come >up :-) Personally, my advice would be to pre-decalre the issue, and why it's an issue and why some special domain is needed and describe the semantics of the FQDNs needed for the appropriate tests (including an appendix zone file?), and then use example.com as the label which needs to be substituted by the person constructing the tests/zone. The benefit here is that some folks might like to replicate such a construct in their own infrastructure, and this document might give them that guidance. Does that make sense? Thanks Terry smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] 答复: Call for Adoption: draft-song-dns-wireformat-http
+1, there is enough room for us to improve. When I first drafted some idea, I was told that the IETF work is driven by the community. It's good. As one of the co-authors, I'm fairly open for suggestions. But for experimental draft, I'm not sure whether we should stick to the scope of original experiment we have done (hiding the DNS traffic in web traffic ), or expand it for potential usage. I will ask and handle it to the WG people if it is adopted by the WG. As to the question of performance, we once had done some simple test (http://www.dnsv6lab.net ) . It is not so scary and almost equal to DNS/TCP. I'm glad to see more comprehensive test result if some guys are interested on that. Davey -邮件原件- 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Paul Hoffman 发送时间: 2016年7月13日 3:22 收件人: dnsop 主题: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http Folks, this is a call for WG adoption, not a design exercise. If the WG adopts the document, we will have plenty of opportunity to fine-tune or make major changes. Such as: On 12 Jul 2016, at 11:51, Shane Kerr wrote: > I recognize that HTTP/2 is definitely a better option because of > out-of-order replies, but I worry about requiring it. It's still quite > new and language support may be spotty. But I guess given it's > popularity this shouldn't be a huge problem, so maybe that is a > reasonable recommendation. If this WG adopts the document and then says "but we want to use an older version of the HTTP protocol", we should expect a fair amount of push-back during IETF Last Call. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)
There is nothing that stops someone from writing malware that uses a custom-built JavaScript DNS server (or takes advantage of DNS capabilities built into node.js) today. The difference is that even a custom built DNS server still relies on port 53 for DNS queries, which means that existing DNS security safeguards (if they exist in a network) are still able to detect it. A piece of malware that uses DNS over TLS is going to operate outside of those existing bounds and be more difficult to detect and is not something that exists today (yes, a malware developer could tunnel DNS traffic over a JavaScript TLS connection, but that would be cumbersome and unreliable. I am not disagreeing with you, my point is that I can see a lot of bad things that can be done with this capability and I don't really see a lot of benefit. allan On 7/12/2016 at 6:48 PM, "Ted Lemon" wrote:What's to stop someone from writing that malware today? Keeping the net safe by reducing the expressiveness of what is carried over HTTP is already a lost cause, and would have been a slender reed to rely on for security in any case. On Tue, Jul 12, 2016 at 4:33 PM, Allan Liska wrote: On 7/12/2016 at 4:10 PM, "Shane Kerr" wrote:John, At 2016-07-11 23:50:05 - "John Levine" wrote: > I'd also want to change some of the motivation text. To me, by far > the most likely scenario here is javascript applications that want to > do DNS queries, e.g. for SRV, but can't because javascript doesn't let > you do that. Now the server that provided the javascript blob can > also be the DNS proxy. The javascript can't query random other DNS > proxies due to cross-site scripting rules. As I think that I mentioned before, the current draft of DNS-over-HTTP is poorly suited for JavaScript. Building and parsing DNS binary messages in JavaScript seems like a really hard way to get at the few tidbits of information that you actually want. OTOH, I am (obviously) not a web developer, so perhaps I overestimate the difficulty in working with DNS binary-format. Maybe it's a relatively compact set of JavaScript functions that can be used? Maybe I just found a project for the IETF Hackathon? Hm... :) My first thought (and maybe this says more about me than the project) is that this seems like the perfect way to make a fully self-contained piece of malware. Ransom32 already proved that you can create ransomware developed entirely in JavaScript, imagine if you combined a JavaScript DNS library with a JavaScript TLS library (https://github.com/digitalbazaar/forge) you could create a piece of malware that is significantly harder to detect because all of the network indicators would be encrypted or not in places that security tools normally look. Now, it would also be somewhat easy to detect because there are very few legitimate reasons for someone to be emailing you 25+ Meg .js file. I am not saying something shouldn't be done simply because bad guys might abuse it, otherwise we should have gotten rid of email a long time ago. What I am asking is are there more legitimate uses for DNS over JavaScript than there are illegitimate? I don't know the answer, but I don't know if the "cool" factor outweighs the potential security risk. allan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)
What's to stop someone from writing that malware today? Keeping the net safe by reducing the expressiveness of what is carried over HTTP is already a lost cause, and would have been a slender reed to rely on for security in any case. On Tue, Jul 12, 2016 at 4:33 PM, Allan Liska wrote: > On 7/12/2016 at 4:10 PM, "Shane Kerr" wrote: > > John, > > At 2016-07-11 23:50:05 - > "John Levine" wrote: > > I'd also want to change some of the motivation text. To me, by far > > the most likely scenario here is javascript applications that want to > > do DNS queries, e.g. for SRV, but can't because javascript doesn't let > > you do that. Now the server that provided the javascript blob can > > also be the DNS proxy. The javascript can't query random other DNS > > proxies due to cross-site scripting rules. > > As I think that I mentioned before, the current draft of DNS-over-HTTP > is poorly suited for JavaScript. Building and parsing DNS binary > messages in JavaScript seems like a really hard way to get at the few > tidbits of information that you actually want. > > OTOH, I am (obviously) not a web developer, so perhaps I overestimate > the difficulty in working with DNS binary-format. Maybe it's a > relatively compact set of JavaScript functions that can be used? > > Maybe I just found a project for the IETF Hackathon? Hm... :) > > > My first thought (and maybe this says more about me than the project) is > that this seems like the perfect way to make a fully self-contained piece > of malware. Ransom32 already proved that you can create ransomware > developed entirely in JavaScript, imagine if you combined a JavaScript DNS > library with a JavaScript TLS library ( > https://github.com/digitalbazaar/forge) you could create a piece of > malware that is significantly harder to detect because all of the network > indicators would be encrypted or not in places that security tools normally > look. Now, it would also be somewhat easy to detect because there are very > few legitimate reasons for someone to be emailing you 25+ Meg .js file. > > I am not saying something shouldn't be done simply because bad guys might > abuse it, otherwise we should have gotten rid of email a long time ago. > What I am asking is are there more legitimate uses for DNS over JavaScript > than there are illegitimate? I don't know the answer, but I don't know if > the "cool" factor outweighs the potential security risk. > > > > allan > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what isn't the DNS, was New Version Notification for draft-shane-dns-manifesto-00.txt
A while back I wrote a draft that put a B-tree in the DNS, for fairly efficient prefix matches for lookups, with the intended application being IPv6 DNSBLs. Last year I wrote a draft that put a state machine for a DFA for regular expressions in the DNS, to do more general string pattern matching, with the intended application being e-mail address local parts. Or look at the DBOUND drafts that Casey Deccio and I wrote, that use wildcards in parallel subdomains to publish boundary info sort of like the PSL. Hm... interesting. For me the question is, do these ideas affect the fundamental architecture? If I understand them, they are transformations that take place on queries at specific labels, right? The hierarchical nature of the DNS remains, right? In the first two of those applications, I was just using the DNS as a flat key store. For the B-trees, the labels were just block numbers, e.g. 48933.blacklist.example. For the DFA, the labels were state numbers and tokens, e.g. if you were in state 123 and your next character was an A, the node name would be 41.123.somenames.example (41 is the hex ASCII for A.) In that latter case I made the character leaf node so I could use *.123.somenames.example for the common case where there's a default rule for all the letters that don't have explicit rules. For the PSLish stuff, I used wildcards and the closest encloser rule so if you wanted to find the boundary for, say, www.bigbank.co.uk, you'd look up www.bigbank.co._ob.uk (_ob is organizational boundary) and that would be matched by *.co._ob.uk since co.uk is a boundary. I'm not sure how helpful this is, but do keep in mind that just because you don't use some feature of the DNS, it doesn't mean other people don't use it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)
On 7/12/2016 at 4:10 PM, "Shane Kerr" wrote:John, At 2016-07-11 23:50:05 - "John Levine" wrote: > I'd also want to change some of the motivation text. To me, by far > the most likely scenario here is javascript applications that want to > do DNS queries, e.g. for SRV, but can't because javascript doesn't let > you do that. Now the server that provided the javascript blob can > also be the DNS proxy. The javascript can't query random other DNS > proxies due to cross-site scripting rules. As I think that I mentioned before, the current draft of DNS-over-HTTP is poorly suited for JavaScript. Building and parsing DNS binary messages in JavaScript seems like a really hard way to get at the few tidbits of information that you actually want. OTOH, I am (obviously) not a web developer, so perhaps I overestimate the difficulty in working with DNS binary-format. Maybe it's a relatively compact set of JavaScript functions that can be used? Maybe I just found a project for the IETF Hackathon? Hm... :) My first thought (and maybe this says more about me than the project) is that this seems like the perfect way to make a fully self-contained piece of malware. Ransom32 already proved that you can create ransomware developed entirely in JavaScript, imagine if you combined a JavaScript DNS library with a JavaScript TLS library (https://github.com/digitalbazaar/forge) you could create a piece of malware that is significantly harder to detect because all of the network indicators would be encrypted or not in places that security tools normally look. Now, it would also be somewhat easy to detect because there are very few legitimate reasons for someone to be emailing you 25+ Meg .js file. I am not saying something shouldn't be done simply because bad guys might abuse it, otherwise we should have gotten rid of email a long time ago. What I am asking is are there more legitimate uses for DNS over JavaScript than there are illegitimate? I don't know the answer, but I don't know if the "cool" factor outweighs the potential security risk. allan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt
John, At 2016-07-11 01:02:19 -0400 "John R Levine" wrote: > I agree that a protocol that had versioning and signalling and negotiation > and other stuff would be cool, but it wouldn't be DNS. With respect to > the stuff in the manifesto, I think it needs to take another step back and > figure out what problem(s) the DNS is supposed to solve, which affects > questions like whether wildcards are a good idea. I'm happy to call it anything other than DNS. ;) But I take your point, that we should definitely make sure that we solve the right problems. I guess thinking about what DNS gets right doesn't really address *why* people use DNS in the first place. > A while back I wrote a draft that put a B-tree in the DNS, for fairly > efficient prefix matches for lookups, with the intended application being > IPv6 DNSBLs. Last year I wrote a draft that put a state machine for a DFA > for regular expressions in the DNS, to do more general string pattern > matching, with the intended application being e-mail address local parts. > Or look at the DBOUND drafts that Casey Deccio and I wrote, that use > wildcards in parallel subdomains to publish boundary info sort of like the > PSL. Hm... interesting. For me the question is, do these ideas affect the fundamental architecture? If I understand them, they are transformations that take place on queries at specific labels, right? The hierarchical nature of the DNS remains, right? > Even if the main application is still finding addresses for host names, > I'd want to push what SRV does into the protocol so I can say I want to > find the web server or the mail server for foo.example, and it'd tell me > the IP addresses and the ports and some hints about what sort of > connection to make, TLS over TCP or whatever. Yes, that sounds good. Perhaps another way to say it is that the main application would actually be finding how to connect to a specific service rather than finding addresses for hosts? > We already have a draft for DNS over HTTP. Perhaps we can bootstrap from > there once we understand what we're trying to do. I'm not sure I see the relationship, but I won't rule it out. :) Cheers, -- Shane pgp0fIdKa45uU.pgp Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt
George, I *do* want people to consider radical positions - although I feel very strongly that we should focus on an evolutionary path for the technology. What I mean is that we should not feel constrained by the DNS as it is today when thinking of ideal solutions, *but* that we should at some point ensure that we have a backward-compatible path to get there. (I'm hoping for something more like the 4-byte ASN roll-out and less like the IPv6 roll-out.) I deliberately avoided putting possible solutions in this document because I'd like it to be something like a problem statement, rather than hinting too much at solutions. Having said that, I do think that we already have some hints as to what we can do to improve the situation. If we look at how DNSSEC uses the DO bit and RRSIG+DS records, we can see that it is possible for a resolver to signal to an authority server that it supports a specific feature and for the authority server to respond differently based on that. While imperfect (because a single bit doesn't tell us which algorithms are supported on the client, or what the trust anchors are, and probably a whole bunch of other stuff that might be useful if we ever considered the possibility), it is basically successful and shows at least one way to perform capability negotiation that is backward-compatible. Imagine if instead of just adding a couple of RR to the response that the master actually sent clients to different servers (or different ports on the same servers) if they understood FancyPantsDNS instead of just DNS. I think versioning is important because it gives us a way to more easily add (and remove!) stuff from the protocol - something we really don't have today. :) Cheers, -- Shane At 2016-07-11 14:10:55 +1000 George Michaelson wrote: > I think you missed the point John. Its a manifesto, and it can take > radical positions. If you read Shanes markup its clear a lot of things > which are implicit in 'UDP/EDNS0' are up for grabs. > > I for one, would welcome versioning models closer to HTTP. I'd also > welcome client-capability signalling and negotiation, another thing > which won't happen in my lifetime on port 53. > > -G > > On Mon, Jul 11, 2016 at 2:04 PM, John Levine wrote: > > In article <037201d1db19$78c3ac90$6a4b05b0$@cn> you write: > >>When I first looked into DNS, I was recommended with a complex figure of DNS > >>protocol family describing the dependency and activeness of many RFC > >>documents. I'm wondering if it is possible to attach versions to DNS > >>protocol similar like IPv4 and IPv6, http/1.1 and HTTP/2 which can give > >>clear path of DNS evolution and help to keep protocol conformance. > > > > In a word, no. EDNS0 is the closest thing we have to versioning, and > > even though it's designed to be as backwards compatible as possible, > > things still break. > > > > The main problem is that there's a lot of dusty old firewalls and the > > like that have dusty old software with a rigid and obsolete idea of > > what DNS packets to allow through. We all would like people to get > > with the program and use less cruddy and obsolete software, but good > > luck with that. pgpiqYuMQFUhM.pgp Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)
>As I think that I mentioned before, the current draft of DNS-over-HTTP >is poorly suited for JavaScript. Building and parsing DNS binary >messages in JavaScript seems like a really hard way to get at the few >tidbits of information that you actually want. Having written DNS servers and proxies in perl (using the low level socket library, not Net::DNS), I think you underestimate the gross stuff that people do in scripting languages. Sure, you could try to write something that sugared up the queries that you thought people would use, but I can promise that before the toner is dry you'll get complaints from people who want use some arcana you never thought anyone was interested in. Just give us the bits; we can deal with them. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The case for the UDP flag on DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)
>> My main suggestion is to lose the Proxy-DNS-Transport header and >> always have the request and response in TCP format. ... >Remember, we want DNS-over-HTTP to be able to handle existing DNS stub >resolvers. The motivation for UDP is to keep the client side of the DNS >over HTTP proxy simple. Oh, OK, but that gets us back to the question of what the real purpose of this thing is. If it's to let javascript apps do DNS requests, who cares, it's all going to be in js libraries anyway. If it's to tunnel through hostile firewalls for general DNS service, then your model makes sense, but I have to ask how likely it is that many people will really use it that way. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] JavaScript use case for DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)
John, At 2016-07-11 23:50:05 - "John Levine" wrote: > I'd also want to change some of the motivation text. To me, by far > the most likely scenario here is javascript applications that want to > do DNS queries, e.g. for SRV, but can't because javascript doesn't let > you do that. Now the server that provided the javascript blob can > also be the DNS proxy. The javascript can't query random other DNS > proxies due to cross-site scripting rules. As I think that I mentioned before, the current draft of DNS-over-HTTP is poorly suited for JavaScript. Building and parsing DNS binary messages in JavaScript seems like a really hard way to get at the few tidbits of information that you actually want. OTOH, I am (obviously) not a web developer, so perhaps I overestimate the difficulty in working with DNS binary-format. Maybe it's a relatively compact set of JavaScript functions that can be used? Maybe I just found a project for the IETF Hackathon? Hm... :) Cheers, -- Shane pgpmNMlAd8erb.pgp Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
Folks, this is a call for WG adoption, not a design exercise. If the WG adopts the document, we will have plenty of opportunity to fine-tune or make major changes. Such as: On 12 Jul 2016, at 11:51, Shane Kerr wrote: I recognize that HTTP/2 is definitely a better option because of out-of-order replies, but I worry about requiring it. It's still quite new and language support may be spotty. But I guess given it's popularity this shouldn't be a huge problem, so maybe that is a reasonable recommendation. If this WG adopts the document and then says "but we want to use an older version of the HTTP protocol", we should expect a fair amount of push-back during IETF Last Call. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The case for the UDP flag on DNS-over-HTTP (was Call for Adoption: draft-song-dns-wireformat-http)
John, At 2016-07-11 23:50:05 - "John Levine" wrote: > >Please review this draft to see if you think it is suitable for adoption > >by DNSOP, and comments to the list, clearly stating your view. > > Yes, we should adopt it. It needs some work, but what draft doesn't. > > >Please also indicate if you are willing to contribute text, review, etc. > > Yes. > > My main suggestion is to lose the Proxy-DNS-Transport header and > always have the request and response in TCP format. If the server > doing the http-to-DNS proxy wants to microoptimize and try the query > as UDP and see if it works, that's fine, but I'm guessing that the > proxy will usually be close to the cache it's using so the penalty for > TCP will be low. Remember, we want DNS-over-HTTP to be able to handle existing DNS stub resolvers. The motivation for UDP is to keep the client side of the DNS over HTTP proxy simple. If you always send TCP, then the client side may receive a response which will not fit into either the 512 byte or EDNS buffer size. The client side then has to remove RRset from the response to try to get it to fit into the right size, possibly setting the truncation bit (TC=1). This requires that the client side actually know quite a bit about DNS, and be able to process DNS packets. You cannot do this on the server side of the DNS-over-HTTP because the server would not have any way to distinguish between a UDP packet without a EDNS buffer size and a TCP message. So it would not know if it had to assume a 512 byte maximum or a 65535 byte maximum. Even if it could, it would still have to have all of the same logic needed to reduce DNS message size by removing RRset. If we can instead pass the stub DNS packet through exactly as it came to the client DNS-over-HTTP proxy then the DNS server will be able to remove RRset to make sure the response is small enough. The DNS server already has to be able to do this, so no additional code is needed. Neither the DNS-over-HTTP client or server has to actually understand DNS messages. :) Cheers, -- Shane pgp5ef1eNsmi8.pgp Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
Marek, At 2016-07-11 22:26:00 -0500 Marek Vavruša wrote: > > You get queueing for free, but not pipelining and out-of-order > responses, that has to be defined. > The draft mentions this, but I think at this point it should just > depend on HTTP/2, > as it's the only way to get decent performance from resolvers but high > variance in response time, > and request semantics in both is different and needs to be defined, > i.e. what happens when client cancels > in-flight query, what happens when server resolver pushes response. There is another option, which is what HTTP developers have done for years, which is keep multiple HTTP connections open. Not ideal, but better than blocking all lookups on a slow resolution. :) I recognize that HTTP/2 is definitely a better option because of out-of-order replies, but I worry about requiring it. It's still quite new and language support may be spotty. But I guess given it's popularity this shouldn't be a huge problem, so maybe that is a reasonable recommendation. I'm also not sure if we need to define all of the semantics in full. Rather, I am worried about over-specifying semantics. Perhaps we can do that as "suggested semantics"? Cheers, -- Shane pgpWh3QIOWW0T.pgp Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
On Tue, Jul 12, 2016 at 11:03 AM, John R Levine wrote: >>> The reason to use TCP framing is so that you can send multiple DNS >>> requests >>> in a single http request and get back multiple answers. Recent messages >>> here suggest that's of considerable interest, and if you're only sending >>> one >>> request, the two bytes of TCP length are tiny compared to the http >>> headers. > > >> Maybe I'm still missing something - so you pack multiple DNS requests in >> single HTTP request, answer#1 takes 5s, answer#2 timeouts, the rest is >> answered from cache. How do you send back the fast answers first without >> blocking when you have just a single HTTP request outstanding? > > > The obvious way would be to send chunked http responses as the answers come > back. See section 4 of RFC 7230. The DNS responses don't have to be in > order. Great, so you get a couple of queries from DNS/TCP stream and batch them into HTTP request, now you get additional query but your HTTP connection is already blocked and you have to start a new one or wait. After all this is just an optimisation game, perhaps I'm foolish to pursue it, but (for me) it's important to define the requirements before we end up with a long tail of weak implementations. > I don't think anyone sees DNS over http as a general replacement for > ordinary DNS. I see two plausible scenarios: > > * The most likely is javascript apps that want to look up SRV or NAPTR or > something, but can only make http/s requests back to the place the js files > came from. > > * The other is an application that wants to make it hord to observce its DNS > queries, so it uses https to a trusted proxy. > > This should be fine for both of those. > > R's, > John I hope these would be the cases, I thought about search engine results page pushing resolved addresses (secured) for search results ahead of time, but using packed DNS wire format for this is not terribly great. It looks like the motivation is to get around DNS firewalls and filters, which implies deploying a scattered set of "open" resolvers similar to dnscrypt to get around IP blocking. Performance should matter in this case. Marek ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
The reason to use TCP framing is so that you can send multiple DNS requests in a single http request and get back multiple answers. Recent messages here suggest that's of considerable interest, and if you're only sending one request, the two bytes of TCP length are tiny compared to the http headers. Maybe I'm still missing something - so you pack multiple DNS requests in single HTTP request, answer#1 takes 5s, answer#2 timeouts, the rest is answered from cache. How do you send back the fast answers first without blocking when you have just a single HTTP request outstanding? The obvious way would be to send chunked http responses as the answers come back. See section 4 of RFC 7230. The DNS responses don't have to be in order. I don't think anyone sees DNS over http as a general replacement for ordinary DNS. I see two plausible scenarios: * The most likely is javascript apps that want to look up SRV or NAPTR or something, but can only make http/s requests back to the place the js files came from. * The other is an application that wants to make it hord to observce its DNS queries, so it uses https to a trusted proxy. This should be fine for both of those. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
Paul, At 2016-07-12 07:00:17 -0400 Paul Wouters wrote: > On Mon, 11 Jul 2016, Tim Wicinski wrote: > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ > > > > Please review this draft to see if you think it is suitable for adoption by > > DNSOP, and comments to the list, clearly stating your view. > > I am very hesitant to accept any protocol-over-http wrapper, as it just > moves the problem around and generate a new set of middleware boxes that > mess with the data. > > I think RFC 7858 is fine for mistakenly broken networks. The only > advantage of this method is to work around administrative blocks. And > that's a rat-race with middle boxes. This is indeed the main use case of the draft - getting around administrative blocks. Widespread adoption would indeed result in a sort of arm's race with developers adding blocks, although the main advantage of DNS over HTTP is that HTTP is difficult to block in general, whereas DNS is easy to block in general. One can of course use RFC 7858 over port 443. My guess is that traffic analysis will quickly reveal this to be DNS traffic (although EDNS0 padding may combat this). The advantage of DNS over HTTP beyond this is that you can run DNS over HTTP on an HTTP server which is serving other HTTP content. (The DNS over HTTP draft mentions this, IIRC.) This makes DNS over HTTP indistinguishable from "normal" HTTP traffic, because it is running on the same server as "normal" HTTP traffic. > There is also a bootstrap issue. if you can use the local DNS to get to > the webserver for DNS-over-HTTP then the local DNS can prevent you from > resolving it. If you hardcode the IP they can blacklist known servers. > And they can transparent proxy your requests to prevent you from using > it anyway. So it's not even that good to work around administrative > blocks. There is indeed a bootstrap issue. In our code you can either use the IP directly or use another resolver (like the normal DHCP-supplied resolver) to lookup the IP of the HTTP over DNS server. Perhaps we should address this in the draft? The impact of blocking on this will vary depending on the scenario. Yes, China will surely maintain a blacklist, just like they do for VPN. Hopefully this will be mitigated a little bit by sharing the DNS over HTTP with web pages, but maybe not. It's still useful for people who are stuck behind less comprehensive blocks. > So I am not convinced of the use case compared to RFC 7858. That's fine. One thing that I have mentioned several times in the past is that the IETF has a culture of stopping things because people don't like proposals for various reasons. This is especially true in the DNS community, for some reason. I'm hoping even though you and Ray and surely others don't find this a useful technique, that the document can proceed anyway. You don't have to use it, and can discourage use by others. But maybe having an extra potential tool is okay. Cheers, -- Shane pgpnSwQBChn7x.pgp Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
On Tue, Jul 12, 2016 at 8:45 AM, John R Levine wrote: >>> My main suggestion is to lose the Proxy-DNS-Transport header and >>> always have the request and response in TCP format. >> >> >> The HTTP payload should always be unframed (like DNS over UDP) regardless >> of the upstream DNS transport, since HTTP already provides content-length >> framing so there's no need to repeat the message length. Like TCP, the >> EDNS0 UDP buffer size is irrelevant for HTTP. > > > The reason to use TCP framing is so that you can send multiple DNS requests > in a single http request and get back multiple answers. Recent messages > here suggest that's of considerable interest, and if you're only sending one > request, the two bytes of TCP length are tiny compared to the http headers. Maybe I'm still missing something - so you pack multiple DNS requests in single HTTP request, answer#1 takes 5s, answer#2 timeouts, the rest is answered from cache. How do you send back the fast answers first without blocking when you have just a single HTTP request outstanding? > It occurs to me that this crock is not inherently much slower than regular > TCP over DNS. In both cases the client opens a connection and sends out the > request, and the server sends back the answer. In both DNS and most > versions of http you can leave the connection open and reuse it, probably > more important in http since you're likely reusing the TLS negotiation too. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
RFC 7766 is about DNS/TCP not about DNS/HTTP, the order of processing has to be determined by the wrapping protocol. You would get it for free if this draft was about TCP over HTTP or HTTP over DNS/TCP, but it's not. It's hard to believe we're reading the same draft. The one I'm reading is about wrapping DNS wire format requests in http, with a header saying whether it's wrapping UDP format or TCP format. (My preference is to lose the UDP and only wrap TCP, but that's a nit.) So it's DNS in TCP in http. Since DNS in TCP handles multiple requests and out of order responses, so does this. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
My main suggestion is to lose the Proxy-DNS-Transport header and always have the request and response in TCP format. The HTTP payload should always be unframed (like DNS over UDP) regardless of the upstream DNS transport, since HTTP already provides content-length framing so there's no need to repeat the message length. Like TCP, the EDNS0 UDP buffer size is irrelevant for HTTP. The reason to use TCP framing is so that you can send multiple DNS requests in a single http request and get back multiple answers. Recent messages here suggest that's of considerable interest, and if you're only sending one request, the two bytes of TCP length are tiny compared to the http headers. It occurs to me that this crock is not inherently much slower than regular TCP over DNS. In both cases the client opens a connection and sends out the request, and the server sends back the answer. In both DNS and most versions of http you can leave the connection open and reuse it, probably more important in http since you're likely reusing the TLS negotiation too. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-02
Hi, I think that a bit more should be said on the problem statement in the introduction. I might have missed it, but what entity originates the query? Stub or resolver? You say that “ A caching recursive server receiving a Multiple QTYPE Option SHOULD attempt to fill its positive and negative caches with all of the specified RR types before returning its response to the client.” won’t this run the risk of delaying a response to the client? You say a server can “omit some (or all) of the records for the additional RR types” in the case of truncation. Given the previous quote, how should a caching recursive server behave in this case? Query again for the missing QTYPES or switch to TCP? I am also wondering how this interacts with https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-03? regards John John Dickinson http://sinodun.com Sinodun Internet Technologies Ltd. Magdalen Centre Oxford Science Park Robert Robinson Avenue Oxford OX4 4GA U.K. signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
On 12/07/2016 12:00, Paul Wouters wrote: > > I am very hesitant to accept any protocol-over-http wrapper, as it just > moves the problem around and generate a new set of middleware boxes that > mess with the data. +lots Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
Warren Kumari wrote: > > Yup - it could be used to instruct a (non-validating) resolver to > please go off and start fetching this list of other records... but, > seeing as everyone already validates (right?!) we don't suggest this. :-D > > However I don't know how an authority would decide whether > > to fill in the additional data or the EXTRA RRs... > > Hmm. It seems that we have done a poor job of wording this bit. We > meant to say that this information is always placed in the additional > section (assuming that support is signalled). The only exception to > this is if someone queries for the EXTRA record explicitly. > > But, Wes, Yan and I (and anyone else interested. Tony?) will discuss > the best way to encode this in the zone file in Berlin, and also > better explain the "always stuff this in additional (because, well, it > is additional), but people can ask if they really want to..." bit Sorry, I was being too terse. I was thinking that in some cases (lack of DNSSEC) the resolver might want to receive the EXTRA RRset itself rather than the other records that it lists, so the resolver can go and fetch the other records. But on second thoughts this is silly, because the resolver can use the other records as a fetch hint just as well as it could use an EXTRA RRset as a fetch hint. (I'm afraid I won't be in Berlin.) Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Fair Isle: Northwest 5 or 6, decreasing 4 at times. Moderate. Rain or showers, fog patches in north. Moderate or good, occasionally very poor in north. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
On Mon, 11 Jul 2016, Tim Wicinski wrote: The draft is available here: https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. I am very hesitant to accept any protocol-over-http wrapper, as it just moves the problem around and generate a new set of middleware boxes that mess with the data. I think RFC 7858 is fine for mistakenly broken networks. The only advantage of this method is to work around administrative blocks. And that's a rat-race with middle boxes. There is also a bootstrap issue. if you can use the local DNS to get to the webserver for DNS-over-HTTP then the local DNS can prevent you from resolving it. If you hardcode the IP they can blacklist known servers. And they can transparent proxy your requests to prevent you from using it anyway. So it's not even that good to work around administrative blocks. So I am not convinced of the use case compared to RFC 7858. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
Adrien de Croy wrote: > > I guess presuming that the back end will use TCP for DNS you could do this, > but I would imagine that's not always the case? In a good implementation the back-end DNS framing should be independent of the HTTP framing. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode South Fitzroy: Northerly 4 or 5, increasing 6 or 7 in east. Moderate, occasionally rough later in southeast. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
Adrien de Croy wrote: > > So I suggest some thought should be given to reducing round-trips by allowing > for multiple DNS request payloads in a single HTTP request message, and > multiple DNS response payloads in an HTTP response message. Why not just specify that pipelined HTTP should be used where possible? Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Fair Isle: Northwest 5 or 6, decreasing 4 at times. Moderate. Rain or showers, fog patches in north. Moderate or good, occasionally very poor in north. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
John Levine wrote: > > My main suggestion is to lose the Proxy-DNS-Transport header and > always have the request and response in TCP format. The HTTP payload should always be unframed (like DNS over UDP) regardless of the upstream DNS transport, since HTTP already provides content-length framing so there's no need to repeat the message length. Like TCP, the EDNS0 UDP buffer size is irrelevant for HTTP. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Northeast Viking, North Utsire: Westerly veering northerly later, 3 or 4, occasionally 5 in south. Slight or moderate. Occasional rain, fog patches. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt
On 11/07/2016 22:55, George Michaelson wrote: > UDP+cookies could work for you? Yes, it possibly could, but it's still "to be determined". Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
