Subject: [DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 6 Mar 2015 12:33:52 -0500

As promised

Olafur

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Mar 6, 2015 at 12:27 PM
Subject: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt
To: Olafur Gudmundsson <[email-masked]>, Marek Majkowski <
[email-masked]>

A new version of I-D, draft-ogud-dnsop-any-notimp-00.txt
has been successfully submitted by Olafur Gudmundsson and posted to the
IETF repository.

Name:           draft-ogud-dnsop-any-notimp
Revision:       00
Title:          Standard way for Authoratitive DNS servers to refuse ANY
query
Document date:  2015-03-06
Group:          Individual Submission
Pages:          3
URL:
http://www.ietf.org/internet-drafts/draft-ogud-dnsop-any-notimp-00.txt
Status:
https://datatracker.ietf.org/doc/draft-ogud-dnsop-any-notimp/
Htmlized:       http://tools.ietf.org/html/draft-ogud-dnsop-any-notimp-00

Abstract:
   DNS ANY query is widely abused for reflection attacks.  This feature
   was designed to aid in debugging.  As there is no good reason for
   applications to ever issue an ANY query this document codifies how an
   authoritative server can reject such queries.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ralf Weber <[email-masked]>
Date: Fri, 6 Mar 2015 10:24:44 -0800

Moin!

> Title:          Standard way for Authoratitive DNS servers to refuse ANY
I do support this. But it will not stop reflection attacks. Also why have
you limited the this to authoritative servers?

Also if you are thinking about minimising vectors for amplification attacks
and complexity in the software implementation getting rid of RRSIG queries
might be also a good thing to consider.

So long
-Ralf

---

From: Tony Finch <[email-masked]>
Date: Fri, 6 Mar 2015 19:01:06 +0000

> you limited the this to authoritative servers?

Yes, to all these points. Since most of the confusing beviour of ANY
occurs on recursive servers it would make sense to deprecate it there
as well.

BTW, PHP's dns_get_record function defaults to ANY.
http://php.net/manual/en/function.dns-get-record.php

Slightly non-serious question: has anyone experimented with returning an
answer with TYPE=255 in response to an ANY query? If so, what broke?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth: Southwest 6 to gale 8, occasionally severe gale 9.
Rough or very rough. Occasional rain. Good, occasionally moderate.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Mar 2015 11:14:21 -0800

> Ralf Weber <mailto:[email-masked]>
> Friday, March 06, 2015 10:24 AM
> Moin!
> I do support this.

me too.

> But it will not stop reflection attacks.

very strong +1. such language must not be present in any form.

> Also why have

this raises the point: ANY deserves its own access control list, or
other non-BIND equivilent. because ANY is useful for diagnostics, local
sysadmins ought to be able to make such queries.
> might be also a good thing to consider.

this way lies madness. you can't know that a validator has no reasonable
intent behind an RRSIG query.

again, the "protects against amplification/reflection" meme must be
nipped in the bud here.

-- 
Paul Vixie

---

From: Ralf Weber <[email-masked]>
Date: Fri, 6 Mar 2015 13:38:56 -0800

Moin!

> sysadmins ought to be able to make such queries.
That depends. If you have other mechanisms than dig to get data out
of your cache you don't need it. I would like to see it deprecated to
the level that no one relies on the query being answered with a record.
So even the resolver can answer with NOTIMP. 

> intent behind an RRSIG query.
I can not see how there is a reason for a validator to issue an RRSIG
query, and I do not know of an validator that does this (there might
be). RRSIG is as complex as the ANY query as you have to look for all
resource record types and not just one. We don't need to include that
in this draft, but the complexity of the query is higher than a normal
query and the use of it is way lower (IMHO it is not needed).

Just two quick datapoints I got. On a recursive server farm that of a
medium ISP (that doesn't do validation, but has it server DNSSEC enabled)
out of a total of 15 billion queries a day there were 6 RRSIG queries 
and on an authoritative server for a DNSSEC secured domain that has 
around 2 million queries a day there were 7 RRSIG quries. So maybe we 
deprecate it before people use it more ;-).

So long
-Ralf

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Mar 2015 13:51:53 -0800

> Friday, March 06, 2015 1:38 PM
> Moin!
>
> of your cache you don't need it.

that's a big "if". here's another: if your diagnostic tools can use some
method other than "dig" to do your debugging for you, then, again, you
don't need ANY. those are two very big "if"'s.
>  I would like to see it deprecated to

me too. that's why i'm saying, ACL, default "nobody".

> So even the resolver can answer with NOTIMP. 

any RCODE other than 0 or 3 will cause spectacularly bad storms. i
prefer RCODE=0/ANCOUNT=0 to refuse "ANY".
> be).

i heard several people enumerate the TCP initiators they could think of,
when arguing about whether to change the client's behaviour to
"keepopen". as i said there-- our ability to enumerate means precisely
nothing: if someone somewhere coded a reasonable expectation based on
RFC text and tested to work, then we have to act as if there are an
unknown, and treat as unknowable, but real and relevant set of users of
that encoding.

>  RRSIG is as complex as the ANY query as you have to look for all

if you want to change how DNSSEC works, i'll listen. but there's no
reasonable interpretation of past or current specifications by which
QTYPE=RRSIG can be categorized a "meta-query". (unlike
QTYPE=ANY/IXFR/AXFR, or RD=0 when speaking to a recursive-only server.)

> deprecate it before people use it more ;-).

you could multiply all those numbers by six trillion, and they would
still not be relevant to the standard of care by which the DNS
specification must evolve.

-- 
Paul Vixie

---

From: Ralf Weber <[email-masked]>
Date: Fri, 6 Mar 2015 14:33:36 -0800

Moin!

> don't need ANY. those are two very big "if"'s.
I can answer them with yes, so I think I'm good. I do need dig for lots
of stuff, but not to find out what records at a give node my resolver
has.

> me too. that's why i'm saying, ACL, default "nobody".
ACL is something application specific. There may be applications that
may want to have a default behavior, thus we should not put ACL in the
draft. The only thing to define in the draft is to what a requester
can expect when issuing a ANY query.
 
> prefer RCODE=0/ANCOUNT=0 to refuse "ANY".
That would look confusing to me as it looks like an valid answer.
NOTIMP looks clearer to me. What do you think this will cause given 
that we want to get people of off it?

> unknown, and treat as unknowable, but real and relevant set of users of
I really could not parse or understand this. After reading it a couple of
times I think that I say:
     There is no reason to use RRSIG queries in a validator
and you say:
     It is not forbidden to use RRSIG queries in a validator
both are true. We can't stop people from doing unreasonable things.

> QTYPE=ANY/IXFR/AXFR, or RD=0 when speaking to a recursive-only server.)
I never said that RRSIG is a meta query. I said that implementing RRSIG
is as hard as implementing ANY with regard to the aspect that you have
to use/look for more than one query type, which is different from
all other query types.

> specification must evolve.
Yeah I noticed over the years that people were very concerned on even
minor changes. Yet when I look at all the things that implementations
of DNS servers did that were against the specs and others had to work
around, maybe sometimes a disruptive change is good. One of the point
of the numbers was to show that so far people have been reasonable 
about RRSIG.

So long
-Ralf

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Mar 2015 14:53:34 -0800

> Friday, March 06, 2015 2:33 PM
> Moin!
>

my point being, "deprecate it because i have alternatives i can use"
does not meet the use case of "many other people may be using dig-based
diagnostics and we should try not to completely invalidate their
approach if there's a low-hanging alternative."
> ACL is something application specific.

no. for example, see RFC 2136:

8 - Security Considerations

   8.1. In the absence of [RFC2137] or equivilent technology, the
   protocol described by this document makes it possible for anyone who
   can reach an authoritative name server to alter the contents of any
   zones on that server.  This is a serious increase in vulnerability
   from the current technology.  Therefore it is very strongly
   recommended that the protocols described in this document not be used
   without [RFC2137] or other equivalently strong security measures,
   e.g. IPsec.

or, earlier in that same document:

   3.3 - Check Requestor's Permissions

   3.3.1. Next, the requestor's permission to update the RRs named in
   the Update Section may be tested in an implementation dependent
   fashion or using mechanisms specified in a subsequent Secure DNS
   Update protocol.  If the requestor does not have permission to
   perform these updates, the server may write a warning message in its
   operations log, and may either signal REFUSED to the requestor, or
   ignore the permission problem and proceed with the update.

   3.3.2. While the exact processing is implementation defined, if these
   verification activities are to be performed, this is the point in the
   server's processing where such performance should take place, since
   if a REFUSED condition is encountered after an update has been
   partially applied, it will be necessary to undo the partial update
   and restore the zone to its original state before answering the
   requestor.

   3.3.3 - Pseudocode for Permission Checking

      if (security policy exists)
           if (this update is not permitted)
                if (local option)
                     log a message about permission problem
                if (local option)
                     return (REFUSED)

i'd appreciate not having to argue about whether the term "ACL" is one
of art or one of practice. let's talk about what we're trying to
accomplish in terms of protocol revision, rather than talking about what
specific application-specific words we shouldn't use when describing
those accomplishments.

obviously ACL is a BIND term, but unbound and nsd (and ans and cns) have
equivilents, and i don't expect any implementer to say "i don't call it
an ACL, therefore any discussion about the protocol change must not use
the term ACL." that would be a huge waste of time, similar to the time
i'm wasting writing this paragraph.

>  There may be applications that
> draft.

i don't understand this statement. make the default "nobody". i thought
you were disagreeing?

>  The only thing to define in the draft is to what a requester

the draft should define what a requester will hear if they ask an ANY
question when not explicitly permitted to do so using server-specific
local policy to override that default. are we still disagreeing?
> That would look confusing to me as it looks like an valid answer.

when someone is asking you something in DNS that you don't want to
answer, you have to answer them in a way that causes them to stop asking
you that question. NOTIMP and REFUSED do not have that property.

i'm fine with giving them an empty answer to a question they should not
be asking.
> that we want to get people of off it?

i think it will cause re-try storms, just like it always does.

see also this text:

http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/
> both are true.

yes, sure, but...

> We can't stop people from doing unreasonable things.

...that is a complete nonsequitur, since you have not established that
QTYPE=RRSIG is unreasonable, whereas i think olafur and others have
amply demonstrated that QTYPE=ANY is unreasonable.

> to use/look for more than one query type, which is different from

i see. so, are you proposing to change the way DNSSEC works, or not?
> of the numbers was to show that so far people have been reasonable 

you're putting highly controversial and unsupported statements behind
the cover of the word "maybe." let me answer you with something less
controversial, more supported, and unmitigated:

> Complexity
>
> From this overview, it is possible to conclude that DNS is a poorly
> specified protocol, but that would be unfair and untrue. DNS was
> specified loosely, on purpose. This protocol design is a fine example
> of what M.A. Padlipsky meant by "descriptive rather than prescriptive"
> in his 1984 thriller, The Elements of Networking Style (Prentice
> Hall). Functional interoperability and ease of implementation were the
> goals of the DNS protocol specification, and from the relative ease
> with which DNS has grown from its petri dish into a world-devouring
> monster, it's clear to me that those goals were met. A stronger
> document set would have eliminated some of the "gotchas" that DNS
> implementers face, but the essential and intentional looseness of the
> specification has to be seen as a strength rather than a weakness.
>
> That having been said, a stronger document set written today would not
> be able to put all of the DNS genies back into their bottles. Too many
> implementations have guessed differently when presented with a loose
> specification, and interoperability today is a moving, organic target.
> When I periodically itch to rewrite the specification from scratch, I
> know there are too many things that must be said that also cannot be
> said. It's as though, in a discussion of the meaning of some bit
> pattern, a modern description of the protocol---written with full
> perspective on all that has been done in the DNS field---would have to
> say, "It could mean x but some implementations will think it means y
> so you must be cautious."
>
> If the objective meaning of a set of potential states and conditions
> and patterns has a complexity index that is a function, somehow, of
> the combinations and permutations of those states, conditions, and
> patterns, as well as the multiple interpretations and deliberate
> uncertainties, then DNS is a very complex system, even though its
> rules are simple and few, and even though a new DNS protocol agent can
> be constructed using only a few thousand lines of software code.

(from http://queue.acm.org/detail.cfm?id=1242499)

in summary, we've successfully rebuilt the DNS airplane in flight, not
just once but continuously, and we did it by never believing for an
instant that there was any possibility what you said: "maybe sometimes a
disruptive change is good". i'll stand behind the results, and the
approach taken to get those results.

-- 
Paul Vixie

---

From: Ralf Weber <[email-masked]>
Date: Fri, 6 Mar 2015 15:33:12 -0800

Moin!

> specific application-specific words we shouldn't use when describing
And I wasn't talking about that. My point was and still is that we
should make the ACL or hell what you call it not a requirement in
the draft, at least not one that is mandatory.

> i don't understand this statement. make the default "nobody". i thought
See above. I am fine with a draft that says one can implement an ACL to
allow requests. Lets try with some text for the section 3 of the draft:

A Recursive Resolver can answer with RCODE=0/ANCOUNT=0 to an ANY query
rather than the current content of it's cache. A recursive resolver can
implement a mechanism to allow certain hosts access to the cache content
with an ANY query.

is that what you want? I would be fine with that. I just don't want a
MUST on the ACL thing.

So long
-Ralf

---

From: Tony Finch <[email-masked]>
Date: Sat, 7 Mar 2015 21:04:14 +0000

> On 6 Mar 2015, at 22:53, Paul Vixie <[email-masked]> wrote:
> 

I think Ralf is right that QTYPE=RRSIG is weird just like ANY, in that it is asking for (part of) all? any? RRsets at a given owner name. I wonder how caches handle it...

Since DNSSEC does not use or need QTYPE=RRSIG, I do not see how deprecating it would require any changes to DNSSEC.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Tony Finch <[email-masked]>
Date: Sat, 7 Mar 2015 21:19:09 +0000

> On 7 Mar 2015, at 21:04, Tony Finch <[email-masked]> wrote:
> 

OK, that's fun, a test demonstrated that BIND treats RRSIG queries like ANY, i.e. you get whatever happens to be in the cache.

Tony (ssh and dig is a bit fiddly on a phone).
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Tony Finch <[email-masked]>
Date: Sat, 7 Mar 2015 22:01:36 +0000

Another thought: responses to RRSIG queries cannot be validated. I hope resolvers don't cache them, or at least treat them with great suspicion.

Tony.

> On 7 Mar 2015, at 21:19, Tony Finch <[email-masked]> wrote:
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Sun, 08 Mar 2015 12:26:31 +1100

Personally RRSIG is worse for a implementer than ANY.

I remember a time when there was a hope that you could do DNSSEC
through a non DNSSEC aware server.  RRSIG queries come from such a
time.  I would be happy to ban RRSIG queries.

That said banning RRSIG or ANY queries won't help with amplification
issues.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sun, 08 Mar 2015 05:46:01 -0700

Tony Finch wrote:
>>>> if you want to change how DNSSEC works, i'll listen. ...
>>> ... implementing RRSIG
> I think Ralf is right that QTYPE=RRSIG is weird just like ANY, in that
it is asking for (part of) all? any? RRsets at a given owner name. I
wonder how caches handle it...
> Since DNSSEC does not use or need QTYPE=RRSIG, I do not see how
deprecating it would require any changes to DNSSEC.

ok, i'm convinced. (olafur, please note?)

-- 
Paul Vixie

---

From: Florian Weimer <[email-masked]>
Date: Thu, 12 Mar 2015 17:27:01 +0100

> Title:          Standard way for Authoratitive DNS servers to refuse ANY

NOTIMP doesn't do that, it tells resolvers to query another name
server for the zone.  The authoriative server part of this proposal
increases the number of upstream ANY queries instead of reducing them.

I don't know if REFUSED is any better in this regard, probably not.