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 go
+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 exp
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 sec
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/1
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,
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 java
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
> figur
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
poi
>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
>> 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.
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 s
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-ord
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 in
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 performanc
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
>>> o
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 heade
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
> > DNSO
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, si
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
abo
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 r
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 nega
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
DN
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 whet
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
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/ -
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 w
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
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
28 matches
Mail list logo
