Subject: [DNSOP] Again about refuse ANY and HINFO

From: Edward Lewis <[email-masked]>
Date: Thu, 7 Apr 2016 13:32:36 +0000

I've shuffled my feet before (the "Again" in the subject) to express my
dislike of the HINFO technique.  This time I dove a little deeper into why
I dislike the approach, motivated by something quickly said in the DNSOP
meeting yesterday.

If nothing else, I suggest that this not be standards track due to
interoperability concerns with private key sharing.

(The draft :- 
https://www.ietf.org/archive/id/draft-dnsop-refuse-any-00.txt)

The draft says "the operator of an authoritative DNS server might choose"
and proceeds to propose solutions that involve what belongs to the zone
administrator.  Architecturally, this bugs me.

The draft proposes that a server (and I'll hand wave over details that are
in the draft for the sake of brevity in email) respond with "some other
record" at the QNAME or, if it chooses, a synthesized HINFO record.  With
DNSSEC, one would need to sign the synthesized record.

Notably missing is - what if the QNAME does not exist ("Role of Wildcards
in the DNS" section 2.2)?
(An open question...)

If the server chooses to answer with "just some record" (the first
option), how would a querier know that this means ANY is not honored?
Personally, I don't think that a protocol should have a state in which the
situation is ambiguous.  (There are many examples of protocols that do and
many examples of ambiguity, but that doesn't make it a good thing.)  I
can't quantify why this approach seems to lacking something
(architecturally).  Perhaps, if you mean "no" say "no."  Or maybe passive
aggressive is not a good personality trait for a protocol.  I don't know.

If the server chooses to answer with a synthesized HINFO and has to sign
it for DNSSEC, there's a line being crossed.  The server answering has to
have the zone's key to make the signature.  DNSSEC was not designed for
that although it is easily demonstrated that on-line signing can be done.
The reason I raise this is, what about interoperability?  ("What about the
children?" as per https://en.wikipedia.org/wiki/Think_of_the_children)

The draft doesn't address how one operator can opt out of ANY answers if
the zone administrator does not share the keys with the operator.  In
examples existing today, so far as I know and I could be wrong, the live
implementation is an "owner/operator", that is an organization that plays
the role of zone administrator (on behalf of others) and the exclusive DNS
operator for those zones.

There is nothing wrong with that set up, I'm just being specific about
"why it works" in the field yet I see an architectural challenge.

I am not criticizing the desire to opt out of ANY queries.  I have been in
position where I wanted to do the same thing.  My discomfort lies in using
the "data plane" to signal though.

I agree this is an server operator thing, not a zone admin thing.  The
data in the DNS is managed by a zone admin, not the server operator.  (See
how the root zone responsibilities are divided for an example.)

If nothing else, this perhaps should not be standards track.  Experimental
or informational perhaps.  This approach is implementable, it is what an
operator does today.  It addresses a need.

But I see interoperability holes in the approach.

I do know of another operator that has turned off ANY queries.  They did
it by sending nothing back.  The name exists, the authoritative server
sends back RCODE=refused.  As far as I know, that operator has not made
public statements about this, I discovered it in some code I run.  Because
of the way it answered, it was obvious that I needed to stop sending ANY
queries to get the data I sought.  Hard fail can be good.

The draft does address this:

"Alternative proposals for dealing with ANY queries have been discussed.
One approach proposed using a new RCODE ... resolvers receiving an unknown
RCODE caused them to re-send the same query to all available authoritative
servers, rather than suppress future such ANY queries
   for the same QNAME."

I see this as a tradeoff.  Extra queries versus having to reply on
distributing a DNSSEC private key to Internet-exposed servers.  To me, in
my opinion, for the sake of interoperability the option costing extra
queries seems more desirable than having to figure out how to allow server
operators share a zone admin's private key.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2016 10:55:04 -0300

One point about repeated queries is that on the list of problems we have in
the DNS, this probably isn't high.   What would the packet rate be for such
queries as opposed to the other problem queries we see?   (I tend to agree
with your take on this generally, Ed.)

On Thu, Apr 7, 2016 at 10:32 AM, Edward Lewis <[email-masked]>
wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Apr 2016 15:26:44 +0100

Edward Lewis <[email-masked]> wrote:

> dislike of the HINFO technique.

I have implemented (and deployed into production) the pick-one option
not the HINFO option.

> Notably missing is - what if the QNAME does not exist ("Role of
> Wildcards in the DNS" section 2.2)? (An open question...)

You should either get a negative response or a wildcard-synthesized
positive answer. And for refuse-any the positive answer will be
substituted by HINFO or pick-one - the negative answer remains negative.

> (architecturally).

There are three kinds of clients we care about: real software (such as
qmail) making legitimate (but misguided) queries; manual debugging
queries; and abusive queries.

Clients making legit queries don't (can't) care whether ANY is answered in
full or not, because they have to deal with partial ANY responses because
caches can expire different RRsets at different times. So a partial answer
will work OK even if the software has to make follow-up queries to fill in
the missing RRsets.

Humans doing manual debugging should have enough clue to be able to work
it out. A synthesized HINFO helps to provide the clue, but if the server
can't synthesize, the human will have to enjoy a slightly more challenging
learning experience.

Abusive queries frequently get relayed by otherwise-legitimate recursive
servers or proxies. You want to minimise the abuse traffic, so you have to
avoid making these co-opted intermediaries retry, so you have to give them
a positive answer. Anything will do, but a small answer minimises the
traffic both at the authority server and at the relays and/or caches that
are being more directly attacked.

> Perhaps, if you mean "no" say "no."

That isn't an option because it breaks things.

> The reason I raise this is, what about interoperability?

Online synthesis falls into the same bucket as all the existing CDN DNS
shenanigans. Domain owners either buy in to one implementation for all
their name servers, or they abstain from clever tricks. There is no
interoperability. Shrug. Not much point complaining about proprietary
extensions.

> data in the DNS is managed by a zone admin, not the server operator.

That is not right - it can be either depending on which option you choose.

The pick-one option can be a server operator thing. For example, my
authoritative servers for cam.ac.uk provide minimal ANY responses, but
most of my secondaries do not. (And my servers also do minimal ANY
responses for signed zones which we secondary in the traditional manner,
such as srcf.net and ic.ac.uk.)

However the synthetic HINFO option assumes (and requires that) the server
operator is also acting as zone admin and keyholder etc.

> sends back RCODE=refused.

That is not a good idea because it leads to retry amplification and it
will probably upset qmail.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
German Bight, Humber: Southwest 5 to 7, veering west 4 or 5. Moderate or
rough, becoming slight or moderate. Showers. Good.

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Apr 2016 15:43:27 +0100

Ted Lemon <[email-masked]> wrote:

> queries as opposed to the other problem queries we see?

I didn't record numbers when I saw this attack, I'm afraid.

One of our authoritative servers was getting a lot of queries from a very
large number of different recursive servers. It looked like the attackers
were probably using home gateways as amplifiers, and the gateways were
getting the records from their recursive servers which were getting the
records from us.

In this situation, I could massively reduce the amount of attack traffic
by getting small positive cache entries into the recursive servers (and
maybe also the gateways, if they have caches).

If you don't give a positive answer then the traffic at the authority will
probably increase by multiple decimal orders of magnitude - each query
will be retried bu the recursive servers, and the answers won't be cached
so every query will hit the authorities.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Northwest Fitzroy, Sole: Northwesterly backing southwesterly for a time later,
5 to 7, decreasing 4 for a time. Rough or very rough. Showers, rain later.
Good, occasionally poor later.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2016 12:03:07 -0300

On Thu, Apr 7, 2016 at 11:43 AM, Tony Finch <[email-masked]> wrote:

> so every query will hit the authorities

Right, I remember this discussion now.   Sorry for the repeat.