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

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 30 Sep 2015 16:20:25 -0700

FYI,
this is latest incarnation of of how to give out minimal answer to ANY
query without breaking anything and being friendly to resolvers.
Comments,

Olafur

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Sep 30, 2015 at 12:04 PM
Subject: New Version Notification for draft-jabley-dnsop-refuse-any-00.txt

A new version of I-D, draft-jabley-dnsop-refuse-any-00.txt
has been successfully submitted by Joe Abley and posted to the
IETF repository.

Name:           draft-jabley-dnsop-refuse-any
Revision:       00
Title:          Providing Minimal-Sized Responses to DNS Queries with
QTYPE=ANY
Document date:  2015-09-30
Group:          Individual Submission
Pages:          16
URL:
https://www.ietf.org/internet-drafts/draft-jabley-dnsop-refuse-any-00.txt
Status:
https://datatracker.ietf.org/doc/draft-jabley-dnsop-refuse-any/
Htmlized:       https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00

Abstract:
   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification does not include specific guidance for the
   behaviour of DNS servers or clients in this situation.  This document
   aims to provide such guidance.

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: Evan Hunt <[email-masked]>
Date: Thu, 1 Oct 2015 02:58:33 +0000

> query without breaking anything and being friendly to resolvers. 

This was discussed at some length back around the Toronto IETF
and I made a suggestion that seemed to garner fairly wide support,
i.e., selecting a single RRset from the ANY response and returning
only that.  See:

  https://www.ietf.org/mail-archive/web/dnsop/current/msg13945.html

...and its followups. Is there a reason you decided not to go in
that direction?  (I'd be happy to contribute text if you like.)

The new proposal to return an empty HINFO record has the advantage of
a smaller response, but will be inconvenient for DNSSEC-signed zones,
unless the server has access to the signing key and can generate a
covering RRSIG. This should be mentioned in security considerations.

The pick-one-RRset mechanism doesn't have this problem, because
the covering RRSIG will already exist for whichever RRset is
returned.

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 30 Sep 2015 23:28:45 -0400

> covering RRSIG. This should be mentioned in security considerations.

There are two options for a signed zone that we mentioned in the text:

1. Return an unsigned response. This will be marked as bogus, and 
trigger a QTYPE=HINFO re-query that will either return an actual signed 
HINFO from the zone or a signed proof of non-existence. We think. I 
haven't actually tested that a re-query will happen, but Olafur is 
confident. :-)

2. Sign the HINFO RR as it is synthesised (or pre-sign one, to avoid the 
edge authority servers needing access to a signing key).

> the covering RRSIG will already exist for whichever RRset is

That is true. However, one of the use-cases for this approach is a 
nameserver for which a search for records present at a particular owner 
name (as would normally be performed when responding to an ANY query) is 
expensive. A synthesised HINFO is cheaper, even if it's a child only a 
mother could love.

Joe

---

From: Evan Hunt <[email-masked]>
Date: Thu, 1 Oct 2015 05:08:50 +0000

> haven't actually tested that a re-query will happen, but Olafur is 

I haven't tested it either, but that is not what I would expect.

If the resolver gets a bogus response to a query of type ANY, I
would expect it to try the same query at another name server,
until it had exhausted all authoritative name servers, and then
reply with SERVFAIL.

> edge authority servers needing access to a signing key).

Pre-signing essentially reduces to adding an empty HINFO to every node in
every zone, then using the pick-one-RRset method, but ensuring that HINFO
is always selected first.

> expensive.

It's not at all obvious to me that this is cheaper.

With either method, you have to search down through the zone to find out
whether the node exists (otherwise you'd be returning NXDOMAIN, rather than
a minimized response).  Since you're doing that search anyway, choosing an
RRset to return is pretty cheap.  And actually, you really *should* also
look through the RRsets at the node to make sure there isn't a non-empty
HINFO record before you synthesize an empty one, and if you're doing *that*
anyway, choosing an RRset wouldn't cost any more and could well cost less.

Assuming we aren't considering the possibility of native HINFO records,
I agree that synthesizing an unsigned HINFO would be little quicker
than pulling an RRset out of the node, but not *so* much quicker as
to seem obviously worthwhile.

And for signed zones, synthesizing a signed HINFO would almost
certainly be slower, while returning a pre-signed HINFO would be
no faster than choosing an RRset.

The disadvantages of pick-one-RRset that I can see are 1) more
information leaked (but nothing that couldn't be obtained by sending
queries for individual qtypes anyway), and 2) modestly larger response
size (but still a lot better than unminimized ANY responses).

Perhaps both approaches should be described in the draft.

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 01 Oct 2015 02:25:49 -0400

> Perhaps both approaches should be described in the draft.

I think I've run out of reasons why the HINFO approach is better than 
your pick-one idea, which mainly leaves us with the HINFO approach 
feeling a lot like a dirty hack that makes me want to shower, while 
yours gets the job done without needing updates to 1035, assuming we 
feel comfortable with the assertion that ANY doesn't have to mean ALL in 
the context of an authority server. I like it quite a lot. Sorry again 
to have missed it when you first brought it up.

Olafur had a particular code-base in mind as motivation for documenting 
this, and he may have some perspectives that I have missed. On that 
note, I will take a few steps away from the microphone.

Joe