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"

[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

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

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

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

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

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

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

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

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.

[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

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

[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. >

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

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

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

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

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

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

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

[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

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

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

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

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.finch

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

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