Subject: [DNSOP] Another suggestion for "any"

From: Brian Dickson <[email-masked]>
Date: Tue, 10 Mar 2015 20:13:04 -0700

On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson <[email-masked]
> wrote:

> Hey, everyone,
[snip]

> "dig"-friendly.

Okay, thinking about this a bit more...
Recursive vs authoritative, RD=0 vs RD=1.

In all combinations of the above, do the "new thing", except for one corner
case:
if(RD==1 && I_AM_AUTHORITY) then
  do_ANY

(Which happens to be the default if someone uses "dig" against an auth
server).

I'm pretty sure this qualifies as "leaks nothing".

This stops clients asking recursives for ANY, and stops recursives asking
authorities for ANY (with RD=0).

And, FWIW, I like the noerror/nodata answer.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Mar 2015 17:00:51 +0800

> Brian Dickson <mailto:[email-masked]>
> Wednesday, March 11, 2015 11:13 AM
> On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hey, everyone,
>
> [snip] 
>
>     "dig"-friendly.
>
>
> In all combinations of the above, do the "new thing", except for one
> corner case:

djb doesn't want QTYPE=ANY deprecated in any form.

olafur doesn't want to "do_ANY", under any conditions.

so i'm baffled by why you're offering this alternative?

-- 
Paul Vixie

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Mar 2015 07:12:55 -0700

> so i'm baffled by why you're offering this alternative?

Neither djb nor Olafur are automatically the consensus of this WG. None of us are.

--Paul Hoffman

---

From: Jared Mauch <[email-masked]>
Date: Wed, 11 Mar 2015 12:22:20 -0400

> Neither djb nor Olafur are automatically the consensus of this WG. None of us are.

<mostly-ot>
	I've had trouble emailing djb about this and received bounces
from his mailer, so feel trustrated trying to have a conversation that includes
him at least.
</mostly-ot>

	This does seem to fall into the whole "undefined" category just
like many people feel that TCP is optional where my reading of 1035
4.2.2 defines how queries over TCP should be performed.

	At the most recent NANOG John Kristoff presented on the
TCP part: 

https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-dnstcp.pdf

	There is a gap, neither positive or negative in the behavior of
these things, which I'm sure will rage along for a bit re: ANY, TCP, etc...

	I'm working on a project right now that should collect some data
and help better study the behavior of systems.  once it's ready, I will share
more data.  If you are a researcher or PHD candidate interested in DNS,
please contact me off-list.

	- jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Mar 2015 09:32:26 -0700

tl;dr:
I am thinking of the "principle of least surprise", for the use case of
interactive "dig" users.

Here's why:
Asking ANY to a recursive resolver, the expected behavior is "whatever is
in the cache" (which could be a subset of the real RRsets, and possibly
empty even though RRs exist on corresponding auth servers). No-error,
no-data in this circumstance would not be unexpected, and would not be a
cause for concern.

Asking ANY to an auth server, the expected behavior is "everything at this
node".

At 3am, when investigating a problem with a domain, if I unwittingly type
"ANY" as the type, I don't want to have to think about or remember that the
behavior changed, and that the "no-error, no-data" answer really means
"deprecated".

I would be happy if the differential behavior were "refused" or "notimpl",
in this specific corner case (RD=1, to an auth server).

Maybe that compromise is sufficient? It would still accomplish Olafur's
goal.

Brian

On Wed, Mar 11, 2015 at 2:00 AM, Paul Vixie <[email-masked]> wrote:

>
>
>   Brian Dickson <[email-masked]>
> On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson <
> [email-masked]> wrote:
>
>> Hey, everyone,
>>
> [snip]
>
>> "dig"-friendly.
>>
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Mar 2015 12:48:00 -0400

> (Which happens to be the default if someone uses "dig" against an auth

Which means that authoritative servers who were _already_ seeing abuse
with RD=1 and ANY would be told they have to reply to them; but some
operators of authoritative servers have been dropping those on the
floor for some time on the principle that you shouldn't be asking an
authoritative server with the RD bit set.

Either ANY is something we think needs support or it is not.  If we
think it's really not something that needs support, then we should say
so and be done with it.

In any case, I don't like all this conditional logic around ANY.  It
seems to me likely to make code bases brittle and hard to change, new
implementations to be hard to get right, and to make operations
troubleshooting much harder because you have to cover more cases.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Mar 2015 10:23:38 +1100

> 4.2.2 defines how queries over TCP should be performed.

RFC 1123, Section 6.1.3.2 Transport Protocols, introduced the SHOULD with
the current well known description.

         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

If you read that along with Section 6.1.3.2 I don't see how any
vendor could ship a recursive DNS server that doesn't support TCP.
I can understand how you could ship a authoritative server where
you have full control over the data you are sending.

Mark

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