Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt

From: Paul Vixie <[email-masked]>
Date: Sat, 1 Oct 2011 04:58:26 +0000

Checking back in on this discussion after several days of watching it run.

On Friday, September 30, 2011 06:36:11 am Patrik Fältström wrote:
> On 30 sep 2011, at 00:21, Jakob Schlyter wrote:
> > I would prefer a RESTful API where the response data format is dependent
> > on the HTTP accept headers. Using such an API, one could receive various
> > formats, e.g., XML, JSON or plain old DNS wire format. A DNS client in
> > Javascript would probably like JSON, a libresolv-like DNS library would
> > like wire format and someone else (although I fail to see who) might
> > prefer XML.
> 
> My claim/feelings/religious view is that JSON is so much better than XML
> when coming to the kind of usage we talk about.
> 
> So if _one_ format is to be used, please choose JSON and not XML.

I like the binary format first proposed here by Edmonds.  I'm not as sure 
about Jakob's "use the accept headers to determine the format" idea since the 
only reason I wanted a printable format was so I could debug with "telnet".  
All clients, even those written in javascript, already know how to handle 
"plain old DNS wire format".  I truly do only expect this transport to be used 
when the normal UDP/53 and TCP/53 paths are middlebox-corrupted.

Assuming that Mohan agrees with me on "just use wire format" in the response, 
my observation is, we should not be using GET at all, nor should we be 
encoding the query into the URI.  We should use POST and our request body 
should be in DNS wire format.  This would defeat web caches but I think that's 
fine since I worry about web caches that don't understand DNS TTL and I worry 
even more about web caches that are intercepting rather than explicit.  POST 
is presumed by web caches to be unique data to which a unique response will be 
needed.

A side benefit of this is, the UPDATE opcode gets easy.

Feel free to respond 1x1, I would summarize.

Paul
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 1 Oct 2011 10:56:45 -0400

On Thu, Sep 29, 2011 at 4:55 PM, Robert Edmonds <[email-masked]> wrote:
> the actual HTTP response payload would simply be a binary wire-format
> DNS response message, possibly with a leading two byte length field like
> plain TCP DNS.

"Content-Length:"  or a chunked encoding should take care of this.

-- 
Colm

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 1 Oct 2011 08:01:33 -0700

> Feel free to respond 1x1, I would summarize.

Use GET, but if you want it to get through the most busted of web caches, do the following:

In the fetch, include cache-busters in the URL:  rather than things that translate to get http://dns_server/name/rtype use things like get http;//dns_server/name/rtype/NONCE

Web caches don't work.  In our experience, nearly 50% of those in Netalyzr tests cache things they shouldn't, so if the worry is cache-staleness, include a cache-buster. But you don't need to use POST to get through the bustedness if the URLs can have nonces in them.

And I'd have the return value be JSON rather than raw DNS on the wire.  Why?

Because since the point is validating DNSSEC, the HTTP-server should not just return the record asked for, but the whole signature chain that it has.  Since this is more information than a normal DNS reply, it might benefit from a new encoding.

And if you are going to do a new encording, JSON is the way to go:  it is FAR far easier to parse than any specialized format.

The other alternative is to say its "OK to put the whole signature chain in the additional field", in which case this would be DNS wire format, but that might be a good policy for ALL resolvers to support: why shouldn't a DNSSEC aware resolver provide the whole signature chain that it has in a reply?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 1 Oct 2011 11:03:33 -0400

> when the normal UDP/53 and TCP/53 paths are middlebox-corrupted.

Printable formats for DNS payloads are also lossy and sacrifice
monotonicity. If a binary response is turned into, say, json and then
back again - the original points of label compression may be not be
the same. Since not all implementations compress equivalently, it's a
minor loss of information - probably only relevant to fingerprinting,
but still a loss.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 1 Oct 2011 08:25:33 -0700

On Oct 1, 2011, at 8:01 AM, Nicholas Weaver wrote:

> Web caches don't work.  

+1.

> In our experience, nearly 50% of those in Netalyzr tests cache things they shouldn't, so if the worry is cache-staleness, include a cache-buster.

-.5. You are assuming that a bad HTTP cache will be bad in a predictable fashion. I'm not against using nonces to bust caches, but I don't think we should rely on it.

> But you don't need to use POST to get through the bustedness if the URLs can have nonces in them.

True, but is there really any disadvantage to using POST in the design?

My sense is that we will get less HTTP caching with POST than we would with GET-with-nonce, but I have no data to back that up.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sat, 1 Oct 2011 13:33:29 -0400 (EDT)

> when the normal UDP/53 and TCP/53 paths are middlebox-corrupted.

I am not sure people agree on the user cases for this.

If you truly think you are addressing the middlebox problem, most likely
you could just run the DNS over port 54 or 80/443.

This proposal does not at all address the problem where DNS is mangled due
to hotspot and captive portal scenarios. Once you work around that scenario,
for example like with the dnssec-trigger experiment that's still far from
workable to non-engineers, you usually get a clean connection with the
exception of port 53 mangling, which just moving to another port seems to
almost always fix it (with 80/443 having a slightly better chance then a
random port.

Doing DNS-over-HTTP is still going to get broken results in captive portals.

What dnssec-trigger is trying to do now is:
- selectable (but should be automatic) hot spot mode where you allow
   insecure dns only to go past captivity
- attempt to use DHCP assigned DNS servers as cache, validate locally
   - if broken, try and query auth servers directly
     - if broken, try an open resolver on port 80/443
       - if broken give user option for "insecure or cached only"

Aside from this, we have the new dnssec chains via alternative source,
both as a speedup and as a workaround using a leap of faith in TLS. this
is useful, though not a replacement for the above. It would also be nice
if any dnssec-chain extension would use some kind of standard so we can
feed it into a validating caching server.

Doing dns-over-http for broken middlewhere alone is going to be a partial
solution that is not going to be very useful on its own.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Sat, 1 Oct 2011 17:36:27 +0000

> Use GET, but if you want it to get through the most busted of web caches,

why "use GET"?  if POST allows us to send a dns message as post-body, which 
could either be a query or an update, then why would we prefer GET?

> Because since the point is validating DNSSEC, the HTTP-server should not
> just return the record asked for, but the whole signature chain that it
> has.  Since this is more information than a normal DNS reply, it might
> benefit from a new encoding.

i've got a draft in production that adds an EDNS option "send chain" where the 
option payload is any ancestor of the QNAME and indicates the requestor's 
deepest validated trusted domain name.  this will solicit a longer trust chain 
(all the RRSIG, DNSKEY, DS RRs) between this ancestor and the QNAME.  it is 
something i'd like for UDP/53 whenever ip fragmentation is working, and 
something i'd like for TCP/53 whenever that's not firewalled out.  it could 
also be used in DNS-over-HTTP, assuming that we allow transmission of full DNS 
messages in both directions (therefore, using POST).

in other words i don't see this as HTTP-specific which is why it's not in this 
draft.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Sat, 1 Oct 2011 17:43:03 +0000

> you could just run the DNS over port 54 or 80/443.

no, because all-that-is-not-allowed-is-denied for most firewalls.  random udp 
ports especially low numbered ones just don't work in a lot of places.  it's 
not that UDP/53 is special by being middleboxed, it's that UDP/53 is special 
by being allowed to work at all (where "work" and "middlebox" are at odds.)

> ... (with 80/443 having a slightly better chance then a random port.

indeed, 80 and 443 are often cleaner.  especially 443 with private keys (no 
CA).  especially if the request is a POST.

> Doing DNS-over-HTTP is still going to get broken results in captive

alas, you are right, there is no universal way to get our packets through, 
since just about everybody between the dns requestor and the dns responder 
wants a piece of the action these days, or thinks they know better, or both.  
however, TCP/80 and TCP/443 are "the RS232 of the new millenium" and i expect 
good results on average from making these available as a fallback to the long 
corrupted UDP/53 and TCP/53.

> solution that is not going to be very useful on its own.

right, agreed, but the things it will work better alongside are also useful in 
their own right, like "send me the trust chain from the QNAME back to the 
deepest trust anchor i've currently validated".  therefore that proposal is 
going to come separately.

paul

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 1 Oct 2011 11:25:22 -0700

> -.5. You are assuming that a bad HTTP cache will be bad in a predictable fashion. I'm not against using nonces to bust caches, but I don't think we should rely on it.

No, what I'm assuming is SOME minimal-level of nonborkenness.

IF a cache takes url 

http://www.example.com/url_a

and instead returns

http://www.example.com/url_b

Its going to be so b0rken for everything that HTTP will be nonusable.

Thus making the URLs like

http://www.dnsresolver.com/name/rtype/NONCEA.json

will be noncached, because if it instead returns the results of a previous fetch

http://www.dnsresolver.com/name/rtype/NONCEB.json

the cache will be not subtly broken, but so broken-as-to-uselessness.

THats the other reason for json:  If the middlebox is content aware, JSON is one thing that will be let through because block application/json these days you might as well block the web altogether.

So encoded as JSON, transfered as mimetype application/json, is most likely to get through.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 01 Oct 2011 22:02:58 +0100

--On 1 October 2011 11:25:22 -0700 Nicholas Weaver 
<[email-masked]> wrote:

>> -.5. You are assuming that a bad HTTP cache will be bad in a predictable
>> fashion. I'm not against using nonces to bust caches, but I don't think
>> we should rely on it.
>

This is true, but the GET/POST question is half orthogonal (so that would 
be 45 degrees?) to the nonce question. IE you could use a POST plus a nonce 
if you wanted. IIRC POST /should/ do enough alone to avoid the need for a 
nonce though, as I can't see how any web cache would cache POSTs.

-- 
Alex Bligh

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 1 Oct 2011 14:08:20 -0700

On Oct 1, 2011, at 2:02 PM, Alex Bligh wrote:
> This is true, but the GET/POST question is half orthogonal (so that would be 45 degrees?) to the nonce question. IE you could use a POST plus a nonce if you wanted. IIRC POST /should/ do enough alone to avoid the need for a nonce though, as I can't see how any web cache would cache POSTs.

Yeah, but if we're assuming maximum borkennes, I could see truly borken proxies failing to properly return data in the reply of a POST.

Thus if the goal of using POST instead of GET is cache-busting, GET with NONCE should work unless the case is "Broken to the point of uselessness HTTP proxy".

Oh, one BIG warning that might sabotage this that I just realized:  I've seen proxies, eg the Bluecoat proxy, which will intercept all traffic until the BROWSER is logged into the proxy and has a cookie set, so there isn't HTTP access unless through a browser that's already gone through the login process.  :(

Since thats likely to the the same sort of network where you can't bypass the DNS borkenness by TCP or UDP port 53, this could be a problem.

---

From: David Conrad <[email-masked]>
Date: Sat, 1 Oct 2011 11:26:51 -1000

> Since thats likely to the the same sort of network where you can't bypass the DNS borkenness by TCP or UDP port 53, this could be a problem.

This succinctly captures my ill-ease about this proposal.

Pretending (in effect) HTTP{,S} is IPv7 will work until the network administrators/middlebox vendors decide they want to block/intercept that traffic. Then what?  How many levels of turtles are we willing to go down?

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 02 Oct 2011 08:33:37 +0900

I'm not sure about the environment to use this proposal.

Perhaps, DHCP is not expected to work and the raw addresses
of http servers are written in /etc/resolv.conf.

But, how can a client get secure time?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 02 Oct 2011 09:01:12 +0900

Paul Vixie wrote:

> I truly do only expect this transport to be used

And only for SDNS.

Maybe, google is considering to always use this transport with
hardwired addresses of 8.8.8.8 and 8.8.4.4 even for plain DNS
to get privacy information of clients from HTTP headers.

							Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Sat, 1 Oct 2011 17:09:37 -0700

> to get privacy information of clients from HTTP headers.

For google, the information they get from Public DNS is a poor source of data by Google's standards.

a)  Google's privacy policy is clear on what data they keep and discard from Public DNS.  http://code.google.com/speed/public-dns/privacy.html

Full IP logs are kept for 24-48 hours, after that, IP addresses are replaced with a network & city level GeoIP localization, which means it is very poor for user tracking.  Which is excellent for tracking aggregate information but fails completely for user tracking.

b)  Google +1 and Analytics capture much much much more information about what users are reading on the web.  The rumors (threats?) about +1 being used by the pagerank algorithm are particularly disturbing.

Rather, it appears Google Public DNS is about having a public DNS service where an NXDOMAIN remains an NXDOMAIN, since half of those NXDOMAINs from the browser result in a Google search anyway (the other half go to Bing), so there is little point in monetizing NXDOMAINs for Google.

---

From: Brian Dickson <[email-masked]>
Date: Sat, 1 Oct 2011 21:04:09 -0400

> Pretending (in effect) HTTP{,S} is IPv7 will work until the network administrators/middlebox vendors decide they want to block/intercept that traffic. Then what?  How many levels of turtles are we…

Including this, depending on how you count, one, or two if you treat
http and https in this proposal as two turtles instead of one.

Here's why:

Intercept precludes https (since the "s" means end-to-end TLS).
And blocking https requires some way of determining what to block, on
a destination basis alone, for the same reason. The http component is
opaque in an https connection, protected by the TLS connection.

So, in the case of the middlebox vendors or network administrators not
reacting to the use of DNS over HTTP(S), problem solved. Otherwise, it
then becomes baby+bathwater for those trying to block this, based only
on IP addresses. Name-based HTTP servers that support this (on 80 or
443) on shared infrastructure (web hosting etc.), plus popularity of
use (large numbers of sites and/or well known large sites), including
phone-home use with client-authentication by HTTPS servers, means
there will be significant benefit to this, and significant pressure to
not try to break it (at least in the HTTPS case).

Where practical to do so, eg for business enterprise employees away
from the office, having server running on both 80 and 443 is ideal. If
80 works, there is low cost for doing this. If 80 does not (ie blocked
or mangled), 443 should. Blocking 443 on a given IP is particularly
ill-advised for hot-spot operators and hotels.

As for encoding, I definitely support wire-format over XML.

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 02 Oct 2011 14:44:02 +0900

Nicholas Weaver wrote:

> a)  Google's privacy policy is clear on what data they
> keep and discard from Public DNS.

That's not the point. See client subnet thread.

						Masataka Ohta

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 2 Oct 2011 04:42:39 -0700

> That's not the point. See client subnet thread.

Oh, THAT particular weird meme, which makes no sense either since:

a)  Client subnet doesn't send IP, only subnet

b)  It sends this information to the DNS authority representing the domain the user is going to contact anyway.

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 2 Oct 2011 04:48:18 -0700

> not try to break it (at least in the HTTPS case).

There is actually two cases that this seems to want to address:

a)  The amazingly borken middlebox at a consumer/hotspot.  In this case, DNS over TCP is likely to work (they don't get it), and DNS over TCP on a high port is really likely to work.  

The network is probably not trying to restrict DNS AFTER login anyway.

b)  A corporate network with a vicious firewall.  In this case, well, its less clear that THIS proposal would work if the network administrator doesn't want it to work.  These networks sometimes do proxy HTTPS as well as HTTP, by having an additional certificate installed in the client.

EG, I've seen Netalyzr runs from corporate networks that block EVERYTHING out (and I mean EVERYTHING), routing ALL traffic through HTTP/HTTPS proxies and blocking everything else.

So for a:  (which is mostly ignorant network), having a few global recursive resolvers with high ports is probably sufficient.

For b:  (which is the deliberate corporate network), I don't think this proposal is guarenteed to work.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 02 Oct 2011 21:53:16 +0900

> b)  It sends this information to the DNS authority representing the domain the user is going to contact anyway.

You completely miss the point.

I acknowledge you don't understand the problem of implied business
model.

					Masataka Ohta

---

From: Tony Finch <[email-masked]>
Date: Mon, 3 Oct 2011 15:26:36 +0100

Paul Vixie <[email-masked]> wrote:
> (all the RRSIG, DNSKEY, DS RRs) between this ancestor and the QNAME.

What about support for lookaside trust anchors?

> [...] i don't see this as HTTP-specific which is why it's not in this draft.

Sensible.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Southerly veering southwesterly 6 to gale 8,
occasionally severe gale 9 at first in northwest Viking. Moderate or rough
becoming very rough or high. Rain then squally showers. Moderate or good,
occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Mon, 3 Oct 2011 15:49:02 +0000

On Mon, 3 Oct 2011 15:26:36 +0100
Tony Finch <[email-masked]> wrote:

> > i've got a draft in production that adds an EDNS option "send
> > chain" where the option payload is any ancestor of the QNAME and
> > indicates the requestor's deepest validated trusted domain name.
> > this will solicit a longer trust chain (all the RRSIG, DNSKEY, DS
> > RRs) between this ancestor and the QNAME.
> 

i don't think we should enshrine lookaside in dnssec validation, so i
was not planning to incorporate that in a "send chain" edns option
proposal.

complete support for lookaside would include support for ISP-layer data
replacement (perhaps under government mandate), as well as enterprise
(private keys), and the quasi-public deployment aid represented by DLV.

none of these things have a place in my long term vision for ubiquitous
DNSSEC, though i have championed DLV as an early deployment aid.
-- 
Paul Vixie
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 3 Oct 2011 08:54:24 -0700

On Sep 30, 2011, at 9:58 PM, Paul Vixie wrote:

> I like the binary format first proposed here by Edmonds.

I also like that format. 

> encoding the query into the URI.  We should use POST and our request body 

I have a slight preference for GET over POST.  I find GET simpler to
implement (maybe code size isn't a concern) and probably more likely
to get through.  OTOH I also like that POST has the content-length
header.

DW

---

From: Paul Vixie <[email-masked]>
Date: Mon, 3 Oct 2011 17:13:19 +0000

> to get through.  OTOH I also like that POST has the content-length

what's your view of the need to someday express UPDATE, and to include future 
extensions to QUERY (like more stuff in the additional section)?  if those 
seem like worthwhile goals, then we really need to put the request into the 
body rather than into the URI or into the http headers.  that calls for POST.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 3 Oct 2011 10:21:19 -0700

> body rather than into the URI or into the http headers.  that calls for POST.

+1. The slight increase in programming difficulty of using POST vs. GET buys you a huge amount of flexibility in queries. It's not just about cache-prevention.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Oct 2011 10:32:47 -0700

On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <[email-masked]> wrote:

>
> +1. The slight increase in programming difficulty of using POST vs. GET
> buys you a huge amount of flexibility in queries. It's not just about
> cache-prevention.
>
>
All silver linings have their clouds...  The only unfortunate thing about
POST, in my view, is that the flexibility can trend you away from
interoperability as people add and change things at  different  speeds at
different hosts.  If you want standard behavior the descending list goes:
New Method, GET, POST, at least in my view.

Since new methods are notoriously hard to get deployed, POST seems like the
best choice if you want something that can handle any DNS operation.  If it
is meant to be only retrieval, then I would personally say that keeping it
within GET is the best choice.

I'm also increasingly of the opinion that this should have the validation
bits sets by default.  Allowing a web site to update the local DNS cache for
a client system by including a reference and a DNS result for the reference
causes my paranoia to ratchet up a few notches.  The only other defense
against it I see is using Web results only in same-origin web contexts, and
that's going to be very hard to make work.

Ted

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 3 Oct 2011 10:34:48 -0700

> body rather than into the URI or into the http headers.  that calls for POST.

Robert's idea was to take a (binary) UDP message, express it in hex, and it
becomes the URL-pathname.  I don't see why you can't also do that with UPDATE.

(I'd add a message TCP-like length prefix, as you suggested, so the receiver
knows it got the whole thing).

Maybe your point is that URL length becomes a problem?  We've all seen
very long URLs I'm sure.  

Anyway, my preference for GET over POST is not that strong.

DW

---

From: Paul Vixie <[email-masked]>
Date: Mon, 3 Oct 2011 18:16:32 +0000

> becomes the URL-pathname.  I don't see why you can't also do that with

theoretically we could, yes.

> (I'd add a message TCP-like length prefix, as you suggested, so the
> receiver knows it got the whole thing).
> 

i'm not sure i've seen 64KB URL's.  i have seen 64KB UPDATE's.  but it's not 
the size that concerns me, rather the content-aware routers out there who may 
or may not respect our http cacheability headers.  we have no need of another 
layer of caching at the transport layer, especially if it means we have to 
translate our DNS TTL's into http expiration times.  and i don't know how to 
reliably avoid that caching on this data path if we use GET.

> Anyway, my preference for GET over POST is not that strong.

does anyone here have anecdotal evidence of POST being intercepted by a 
content aware router, or otherwise painfully middleboxed the way GET so often 
is?  at the moment i've got three weak reasons for preferring POST, but if any 
of the three is silly, they would not add up to a strong preference as they do 
(for me) at the moment.

paul

---

From: Alex Bligh <[email-masked]>
Date: Mon, 03 Oct 2011 19:31:52 +0100

--On 3 October 2011 18:16:32 +0000 Paul Vixie <[email-masked]> wrote:

> i'm not sure i've seen 64KB URL's.  i have seen 64KB UPDATE's.  but it's
> not  the size that concerns me, rather the content-aware routers out
> there who may  or may not respect our http cacheability headers.

I would also bet money that application layer interceptors of http
traffic are more likely to fail on 64KB GET URLs than 64KB POST.

I presume we could base64 encode POST data if we couldn't send it
binary, whereas IIRC we couldn't do much more than hex encode GET URLs.

So +1 for POST here, with body content as close to UDP message format
as possible, save that we should surely be able to junk a pile of UDP
restrictions (e.g. we can surely mandate EDNS, assume 'packet' size
can 2^32 bytes, etc.). I presume we also don't need UDP headers etc.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 3 Oct 2011 18:41:41 +0000

> binary, whereas IIRC we couldn't do much more than hex encode GET URLs.

the ability to base64-encode POST data is part of the HTTP spec, so yes.  the 
response could also come back encoded that way.  this is supposed to be "just 
web traffic."

> can 2^32 bytes, etc.). I presume we also don't need UDP headers etc.

i don't think we should overly constrain the message (like mandating EDNS) 
since this adds test cases to compliance suites and precludes future DNS 
protocol extensions that could be better than EDNS.

we would only include the DNS message, which UDP thinks of as a "payload";
not the transport or network headers.  also note, this isn't necessarily a 
tunneling protocol -- if it's used by a stub then there is no underlying UDP 
packet to pull anything from.  and where it is used as a tunneling protocol, 
the underlying DNS message could have arrived via TCP/53 or even HTTP.

paul

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 3 Oct 2011 12:22:44 -0700

> that's going to be very hard to make work.

I am not sure I understand this concern fully. I guess you mean that
you want to use this only with CD =1 which also implies that you want
to use only with DNSSEC . Though this is the primary use case that
this draft is trying to address, should we restrict it ? Previously,
your concern was cache poisoning of the HTTP proxies having an impact
on DNS. If we require HTTPS and POST, is this still a concern ?

-mohan

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Oct 2011 13:25:27 -0700

> on DNS. If we require HTTPS and POST, is this still a concern ?
Well, I don't think you can functionally say that it can only be used with
DNSSEC at the protocol level; there's always the risk that you want to use
it for some zone that hasn't been signed.  But I think we're going to have
to strongly suggest that it should be used when DNSSEC validation can be
done and, if it has not been, how to handle the results with respect to the
local cache.

If I am a helpful web site with the ability to do this DNS return, I could
theoretically get slightly higher speed for web page loads by providing the
DNS data for the component loads along with the initial return.  If those
can be trusted because of DNSSEC validation, using the data and storing it
in the local cache for use by other applications (subject to TTL expiry
etc.) should be fine.  But if I cannot validate it, then I have to have some
other trust model for the data.  One potential model is to use (but likely
not store) data with the same origin as the web server from which I got it.
So if I land at financial.example.com, I use the data it gives me for
nasdaq.financial.example.com and sp500.financial.example.com, but not for
ftse.example.co.uk or, even worse, for social.network.com of
deposit.bank.com.

It's still a cache poisoning problem, but it is the local cache that might
be poisoned in this worry.

In the case where you are getting this from a 3rd party DNS provider which
supports HTTPS transport, the trust is presumably between you and that
provider.  That may be the initial use case.  But I'm guessing that once
this is available, other uses, included blended content/DNS returns will
occur.

regards,

Ted

-mohan

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 04 Oct 2011 06:59:31 +0900

Mohan Parthasarathy wrote:

> Though this is the primary use case that
> this draft is trying to address,

The primary use case is not clear.

How can a client know an address of an HTTP server?

How can a client know secure time?

Both are important information of a use case.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Oct 2011 11:15:47 +1100

In message <[email-masked]>, Mohan Parthasarathy writes:
> > On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <[email-masked]> wro=
> te:
> >>
> > All silver linings have their clouds...=A0 The only unfortunate thing abo=
> ut
> > interoperability as people add and change things at=A0 different=A0 speed=
> s at
> > different hosts.=A0 If you want standard behavior the descending list goe=
> s:
> > Since new methods are notoriously hard to get deployed, POST seems like t=
> he
> > best choice if you want something that can handle any DNS operation.=A0 I=
> f it
> > bits sets by default.=A0 Allowing a web site to update the local DNS cach=
> e for
> > a client system by including a reference and a DNS result for the referen=
> ce
> > causes my paranoia to ratchet up a few notches.=A0 The only other defense
> > against it I see is using Web results only in same-origin web contexts, a=
> nd
> you want to use this only with CD =3D1 which also implies that you want

DO=1 implies DNSSEC.  Stubs/forwarders SHOULD NOT set CD=1.  The
upstream validator needs to filter out the spoofed responses
on behalf of the stub/forwarder.

Also it is just a "DNS message".  UDP/TCP/HTTP/HTTPS is just the
transport for the DNS message.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 3 Oct 2011 19:35:56 -0700

> transport for the DNS message.

If a validating stub resolver can set CD = 1 for UDP/TCP why not for
HTTP or HTTPS ?

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Oct 2011 13:55:02 +1100

In message <CACU5sD=[email-masked]>
, Mohan Parthasarathy writes:
> > In message <[email-masked]=
> l.com>, Mohan Parthasarathy writes:
> >> > On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <[email-masked]> =
> wro=3D
> >> te:
> >> >>
> >> >> +1. The slight increase in programming difficulty of using POST vs. G=
> ET
> >> > All silver linings have their clouds...=3DA0 The only unfortunate thin=
> g abo=3D
> >> ut
> >> > interoperability as people add and change things at=3DA0 different=3DA=
> 0 speed=3D
> >> s at
> >> > different hosts.=3DA0 If you want standard behavior the descending lis=
> t goe=3D
> >> s:
> >> > Since new methods are notoriously hard to get deployed, POST seems lik=
> e t=3D
> >> he
> >> > best choice if you want something that can handle any DNS operation.=
> =3DA0 I=3D
> >> f it
> >> > is meant to be only retrieval, then I would personally say that keepin=
> g it
> >> > I'm also increasingly of the opinion that this should have the validat=
> ion
> >> > bits sets by default.=3DA0 Allowing a web site to update the local DNS=
>  cach=3D
> >> e for
> >> > a client system by including a reference and a DNS result for the refe=
> ren=3D
> >> ce
> >> > causes my paranoia to ratchet up a few notches.=3DA0 The only other de=
> fense
> >> > against it I see is using Web results only in same-origin web contexts=
> , a=3D
> >> nd
> >> you want to use this only with CD =3D3D1 which also implies that you wan=
> t
> > DO=3D1 implies DNSSEC. =A0Stubs/forwarders SHOULD NOT set CD=3D1. =A0The
> > Also it is just a "DNS message". =A0UDP/TCP/HTTP/HTTPS is just the
> If a validating stub resolver can set CD =3D 1 for UDP/TCP why not for
> HTTP or HTTPS ?

A validating stub resolver really doesn't want to set CD=1, by
default.  If it gets SERVFAIL back to a CD=0 query then resending
with CD=1, may help if the SERVFAIL was a validation failure caused
by a bad clock on the recursive server / out of date trust anchors.
A stub resolver *needs* the upstream server to weed out the bogus
responses due to spoofing or, more likely, operational stuff ups
and only pass through those that pass validation.  Remember a stub
resolver does not have access to multiple authoritative sources,
only the recursive server does.  If you are willing to bet that
every response you get back is good then always set CD=1 otherwise
CD=1 should only be set if the CD=0 lookup fails.

> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org
> >

---

From: Mohan <[email-masked]>
Date: Mon, 3 Oct 2011 20:17:48 -0700

> and only pass through those that pass validation.  Remember a stub

Why does a validating stub resolver care ? If there was spoofing or other problems, it can find out itself. It is much easier to set CD=1 always. 

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Oct 2011 15:02:59 +1100

In message <[email-masked]>, Mohan writes:
> > In message <CACU5sD=[email-masked]=
> il.com>
> >>> In message <[email-masked]=
> i=
> >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie <[email-masked]> wrote:=
> 
> 3D=
> >> wro=
> =
> >>>>>> buys you a huge amount of flexibility in queries. It's not just about=
> 
> >>>>>> cache-prevention.
> >>>>>> 
> >>>>> 
> >>>>> All silver linings have their clouds...  The only unfortunate th=
> in=
> >> g abo=
> >>>> ut
> >>>>> interoperability as people add and change things at  different=
> =
> 3DA=
> >> 0 speed=
> >>>> s at
> >>>>> different hosts.  If you want standard behavior the descending l=
> is=
> >> t goe=
> >>>> s:
> =
> >> e t=
> =
> >>   I=
> =
> =
> >>>>> bits sets by default.  Allowing a web site to update the local D=
> NS=
> >> cach=
> >>>> e for
> =
> >> ren=
> >>>>> causes my paranoia to ratchet up a few notches.  The only other d
> =
> e=
> >> fense
> =
> >> , a=
> >>>> you want to use this only with CD =1 which also implies that you w
> =
> an=
> >> t
> >>> DO=1 implies DNSSEC.  Stubs/forwarders SHOULD NOT set CD=1. =
> 3D=
> A0The
> Why does a validating stub resolver care?

Say example.com is served by a DNSSEC aware authoritative server
(D) and a DNSSEC unaware authoritative server (P).  The stub resolver
asks for www.example.com/DO=1/CD=1.  The validating recurive server
get a answer from P (without DNSSEC records) and passes it on.
Validation fails.  The stub resolver asks for www.example.com/DO=1/CD=1
again and it gets the same answer (from thout DNSSEC records) the
CD=1 cache and again fails.  Rince, lather, repeat.

Now if the stub asks for www.example.com/DO=1/CD=0 the validating
resolver will reject any answers from P and only pass on answers
from D (with DNSSEC record) which should then validate.

Now if the recursive server doesn't validate or it validates as
insecure you are left with first senario hoping that you are getting
answers from the DNSSEC aware authoritative server.

What would help would be a EDNS option to send to the recursive
server the closest trust anchor(s) and current time so that it can
validate responses in a consistant manner to the stub resolver.

Mark

> If there was spoofing or other problems, it can find out itself.
> It is much easier to set CD=1 always.
>
> -mohan

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 3 Oct 2011 21:43:53 -0700

> (D) and a DNSSEC unaware authoritative server (P).  The stub resolver

Isn't this a broken configuration ? Why do we end up with this configuration ?

> from D (with DNSSEC record) which should then validate.
So, this is a validating resolver, sets CD=0 (ignoring what is said in
RFC 4035), gets the "proper" responses, ignores the AD bit,
validates the responses. Is this discussed in any document ?

> validate responses in a consistant manner to the stub resolver.

This seems complex to me. Perhaps, the operational document should say
that a dnssec signed zone should be served only by dnssec aware
authoritative servers. If there is still an operational error, the
validating resolver should just give up. For example, if i set
DO=1/CD=1 and there are no RRSIGS, then abort and declare insecure.

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Tue, 04 Oct 2011 16:24:09 +1100

In message <CACU5sDnCB62cbBYW_E26fcmGuKU0+V_-BSeF=[email-masked]>, Mohan Parthasarathy writes:
> > In message <[email-masked]>, Mohan writes=
> :
> >>
> >>
> >> > In message <CACU5sD=2HSCi4VKT235APU7aS7bqk_Czzf_CmdN9fXpEF61s0A@mail=
> .gma=
> >> il.com>
> >> >>> In message <CACU5sDmurSriLgrD9Pn_xAarfBxrjY0x9sRdJPrdkvJiJ6FJZQ@mail=
> .gma=
> >> i=
> >> >>>> On Mon, Oct 3, 2011 at 10:32 AM, Ted Hardie <[email-masked]> wr=
> ote:=
> >>
> >> >>>>> On Mon, Oct 3, 2011 at 10:21 AM, Paul Hoffman <[email-masked]=
> rg> =
> >> 3D=
> >>
> >> >> wro=
> >> >>>> te:
> >> >>>>>>
> >> >>>>>> +1. The slight increase in programming difficulty of using POST v=
> s. G=
> >> =
> >> >> ET
> >> >>>>>> buys you a huge amount of flexibility in queries. It's not just a=
> bout=
> >>
> >> >>>>>> cache-prevention.
> >> >>>>>>
> >> >>>>>
> >> >>>>> Since new methods are notoriously hard to get deployed, POST seems=
>  lik=
> >> =
> >> >> e t=
> >> >>>> he
> >> >>>>> best choice if you want something that can handle any DNS operatio=
> n.=
> >> =
> >>
> >> >>   I=
> >> >>>> f it
> >> >>>>> is meant to be only retrieval, then I would personally say that ke=
> epin=
> >> =
> >> >> g it
> >> >>>>> I'm also increasingly of the opinion that this should have the val=
> idat=
> >> =
> >> >> ion
> >> >>>>> a client system by including a reference and a DNS result for the =
> refe=
> >> =
> >> >> ren=
> >> >>>> ce
> >> >>>>> causes my paranoia to ratchet up a few notches.  The only other =
> d
> >> =
> >> e=
> >> >> fense
> >> >>>>> against it I see is using Web results only in same-origin web cont=
> exts=
> >> =
> >> >> , a=
> >> >>>> nd
> >> >>>> I am not sure I understand this concern fully. I guess you mean tha=
> t
> >> >>>> you want to use this only with CD =1 which also implies that you =
> w
> >> =
> >> an=
> >> >> t
> >> >>>> this draft is trying to address, should we restrict it ? Previously=
> ,
> >> >>>> your concern was cache poisoning of the HTTP proxies having an impa=
> ct
> >> >> If a validating stub resolver can set CD = 1 for UDP/TCP why not fo=
> r
> >> >> HTTP or HTTPS ?
> >> >
> Isn't this a broken configuration ? Why do we end up with this configuratio=
> n ?

Because people make mistakes.  I've definitely seen this sort of
configuration error. Remember this misconfiguration is indistigishable
from a spoof attack.  Validators are expected to cope with spoof
attacks.  They are not expected to cope with MITM attacks other
than to reject the bogus answers.

> > Validation fails.  The stub resolver asks for www.example.com/DO=1/CD=
> =1

No, its not ignoring what is said in RFC 4035, CD=1 is a SHOULD
(4.9.2).  In this case I'm recommending that defaulting to CD=0 as
the default is what should be done and falling back to CD=1 in
SERVFAIL is what should be done.  AD should be ignored by a validating
stub resolver.  It's for stubs that trust the resolver, not stubs
that validate.

As for whether this is documented anywhere, apart from the archive
of this list and dns/dnssec lists I doubt it.  I've definitely
mentioned this before.  Mike St John's discussion of CD/DO setting
is similar in nature if I'm remembering it correctly.

Remember when RFC 4035 was written there was very little experience
with validating stub resolvers.  There still isn't much but defaulting
to CD=1 is clearly wrong.  Making stub validating resolvers work
well may still require more work or what we have may be "good
enough".

> DO=1/CD=1 and there are no RRSIGS, then abort and declare insecure.

Except you can't do that most of the time because there could be a
zone cut that makes that name insecure.

Mark

> > PHONE: +61 2 9871 4742   =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org
> >

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Oct 2011 12:04:42 +0100

> binary, whereas IIRC we couldn't do much more than hex encode GET URLs.

You can send it in binary, otherwise multipart/form-data file uploads
would not work.

> as possible,

Yes.

> save that we should surely be able to junk a pile of UDP restrictions
> (e.g. we can surely mandate EDNS, assume 'packet' size can 2^32 bytes,
> etc.).

You can't increase the DNS message size beyond 64KB.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: Southwest 4 or 5, increasing 6 at times. Moderate,
occasionally rough later in Plymouth. Occasional drizzle, fog patches for a
time. Moderate or good, occasionally very poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Alex Bligh <[email-masked]>
Date: Tue, 04 Oct 2011 12:40:50 +0100

> You can't increase the DNS message size beyond 64KB.

I was under the (mis) apprehension that was a UDP limitation, and that
large AFXRs could exceed 64KB. Live and learn.

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Oct 2011 12:49:55 +0100

> large AFXRs could exceed 64KB. Live and learn.

DNS over TCP has the same limit. If we want to maximise compatibility with
existing DNS code we shouldn't change it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin: Southwesterly 5 to 7, occasionally gale 8. Very rough or high.
Squally showers, rain later. Moderate or poor, occasionally good.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 4 Oct 2011 14:55:24 +0200

> large AFXRs could exceed 64KB. Live and learn.

I've done AXFRen of 1/2 GB zones. Not practical, but doable. The 64K
limit does not apply to AXFR, but, then again, AXFR is not like the
other children...

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Is it NOUVELLE CUISINE when 3 olives are struggling with a scallop in a
plate of SAUCE MORNAY?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Oct 2011 01:09:48 +1100

In message <[email-masked]>, =?utf-8?B?TcOlbnM=?= Nils
son writes:
> Subject: Re: [dnsext] draft-mohan-dns-query-xml-00.txt Date: Tue, Oct 04, 2=
> 011 at 12:40:50PM +0100 Quoting Alex Bligh ([email-masked]):
> >=20
> >=20
> >=20
> >=20
> --=20
> M=C3=A5ns Nilsson     primary/secondary/besserwisser/machina

If we ever want to go greater than 64 K, tcp length limits 0..11
make good escape sequences, just encode the number of length bytes
with EDNS signaling to say we handle the longer length encodings.

00 03 XX XX XX
00 04 XX XX XX XX
00 05 XX XX XX XX XX
00 06 XX XX XX XX XX XX
00 07 XX XX XX XX XX XX XX
00 08 XX XX XX XX XX XX XX XX

Mark

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Oct 2011 16:09:02 +0100

> with EDNS signaling to say we handle the longer length encodings.

That's OK for large responses but not large UPDATE requests.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth: Southwest 4 or 5, increasing 6 at times. Moderate,
occasionally rough later. Occasional drizzle, fog patches for a time. Moderate
or good, occasionally very poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 4 Oct 2011 12:50:04 -0700

<snip>
> well may still require more work or what we have may be "good
Why can't the recursive server fetch the "proper" response when it
sees DOK=1/CD=1 ? It knows that a validating resolver is asking for
DNSSEC records to validate itself. If it does not get from the first
server, it can ask the next server and get it. Why should the behavior
be different for CD=0/1 ? As long as DOK=1, it should do it.

> zone cut that makes that name insecure.
You should get a NSEC/NSEC3 in that case, right ?

-mohan

---

From: Paul Vixie <[email-masked]>
Date: Tue, 4 Oct 2011 22:33:42 +0000

> limit does not apply to AXFR, but, then again, AXFR is not like the

an AXFR can have many messages, each will be 64KB or smaller, and no RRset is 
allowed to span a message.  this means among other things that no RRset can be 
larger than ~64KB.  the fact that RRsets larger than 64KB could also not be 
carried in a query (whether by TCP/53 or UDP/53) also enforces this 
constraint.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Wed, 05 Oct 2011 11:48:31 +1100

In message <[email-masked]>, Paul Vixie writes:
> On Tuesday, October 04, 2011 12:55:24 M=E5ns Nilsson wrote:
> 
> an AXFR can have many messages, each will be 64KB or smaller, and no RRset =
> is =
> 
> allowed to span a message.  this means among other things that no RRset can=
>  be =
> 
> larger than ~64KB.  the fact that RRsets larger than 64KB could also not be =
> 
> carried in a query (whether by TCP/53 or UDP/53) also enforces this =
> 
> constraint.

RRsets are allowed to span messages in AXFR/IXFR.  BIND 4 used to
send one RR per message.  That said the current practical limit is
slightly less than 64K for a RRset without protocol extensions.

Mark