Subject: [DNSOP] CloudFlare policy on ANY records changing

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 10 Mar 2015 22:19:55 +0000

On Mar 10, 2015, at 9:34 AM, Paul Hoffman <[email-masked]> wrote:

> On Mar 10, 2015, at 8:46 AM, David C Lawrence <[email-masked]> wrote:
>> 
>> Paul Hoffman writes:
>>> On Mar 10, 2015, at 6:25 AM, Yunhong Gu <[email-masked]> wrote:
>>>> So the problem is, why NOTIMP? REFUSED sounds like a better choice. 
>>> 
>>> +1. "REFUSED" exactly describes what is going on.
>> 
>> One down side there, however, is that REFUSED as understood by
>> resolvers commonly has the semantic currently that the name is not
>> hosted by the server at all.  What used to be root referrals for lame
>> delegations is now REFUSED to minimize response size.
> 
> If a resolver is sending an ANY before it sends its actual request, that could be a problem. However, they shouldn't be doing that.
> 
> It is likely that any response we think of (even no response at all) will cause some deployed resolvers to get the wrong idea. Having said that, it is perfectly reasonable for an operator to not want to reply to an ANY, given the unclarity of what it is expected to send back and the opportunity for malicious intelligence gathering. So us saying "if you want to do this, use that" at least will cause future versions of things that relied on ANY to know what they are getting.
> 
> Also: this should probably one of the three threads on [email-masked]...

As Paul suggests, I'll attempt to redirect the conversation to dnsop.

Does it make sense to define an Extended RCODE for additional signaling?
e.g.  "REFUSED_BECAUSE_QTYPE_ANY"

If you want to respond to ANY with NOTIMP/REFUSED, would you also
be willing to include an OPT RR in your response (when appropriate)?

DW

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Mar 2015 08:05:31 +0800

> Wessels, Duane <mailto:[email-masked]>
> Wednesday, March 11, 2015 6:19 AM
>
>

no, because the problem is with existing clients, who only look for
rcodes they understand.
> be willing to include an OPT RR in your response (when appropriate)?

as i wrote in
<http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/>...

> ... So I know that we send REFUSED in response to a query when we
> don't like the client's IP address --- DNS servers do not even look at
> the question before deciding whether to send REFUSED. On the client
> side, if we hear a REFUSED we give up on that server and move on to
> the next server --- which means we assume that it was the client's IP
> address that the server is refusing, not the question we happened to
> be asking at that moment. Microsoft Windows will actually
> "de-preference" a name server if they hear too many REFUSED messages
> from it --- so BIND is not the only DNS software that interprets
> REFUSED in this way. What this boils down to is that REFUSED is all
> about the relationship between the client and the server, and has
> nothing to do with the particular question being asked. If SOPA or
> PIPA becomes law with a requirement to signal REFUSED when someone
> looks up an infringing or pirate domain name, then in the language of
> DNS we will be saying "please stop asking this server any questions at
> all." There is no signal in DNS that means "that's a bad question but
> please feel free to ask other questions." 

we are, in this case, defining a protocol. our goal is to get the client
to stop asking the ANY question. if we send is a signal that sounds
right (REFUSED, for example) but merely has the effect of "go to next
server" then we're losing.

if we're serious about redefining ANY as a meta-query, then answering
with RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries
against an RA=1 server.)

but whatever we do, any new reaction to QTYPE=ANY has to ensure that the
client gives up, and stops asking.

-- 
Paul Vixie

---

From: Evan Hunt <[email-masked]>
Date: Wed, 11 Mar 2015 01:57:10 +0000

> with RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries

I'm concerned that a NOERROR/NODATA for qtype=ANY, once cached, would be
identical to the cache representation of an empty nonterminal node, and
that all subsequent queries for any other qtype would then be answered
with the cached NODATA.

> client gives up, and stops asking.

I liked the sound of REFUSED because it matches *XFR semantics, but if
you're right about how resolvers will react, then it's a bad idea.

I'm running on supposition here, and we need data. I wonder aloud if
CloudFlare or some other site would be open to trying a variety of
response semantics to find out which one pinches least.

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Mar 2015 12:13:42 +0000

> that all subsequent queries for any other qtype would then be answered

These are signed zones so the answer has to validate. Perhaps the answer
should be just the NSEC(3) and RRSIG(NSEC(3)) records matching the QNAME,
which is a plausible way to say, yes we have records here even though this
answer doesn't contain them.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Wight, Portland, Plymouth, Northwest Biscay: Southerly or southeasterly 4 or
5, occasionally 6. Slight or moderate, but rough at first in northwest Biscay.
Occasional rain. Good, occasionally poor.

---

From: Evan Hunt <[email-masked]>
Date: Wed, 11 Mar 2015 15:06:22 +0000

On Wed, Mar 11, 2015 at 12:13:42PM +0000, Tony Finch wrote:
> These are signed zones so the answer has to validate.

... they are?  I thought the proposal was to restrict/deprecate
qtype=ANY for all zones, not just signed ones.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Mar 2015 16:39:19 +0000

> qtype=ANY for all zones, not just signed ones.

At least some of them are signed :-) But you are right it needs to work
for unsigned zones.

NOERROR/NODATA responses to ANY will not work well.

I did a quick test consisting of:

dig any non.terminal # initially empty
(echo 'update add non.terminal 3600 in txt "braaains"';
 echo send) | nsupdate -l
dig txt non.terminal

For both signed and unsigned zones, the first query make BIND create a
negtive cache entry which covers all types, so it doesn't recurse for the
second query.

This will make qmail fail deliveries with a permanent error.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire, Forties, Cromarty, Forth, Tyne, Dogger: Southerly or
southeasterly 6 to gale 8, occasionally severe gale 9 in Forties, Cromarty and
Forth, becoming variable 4 for a time. Moderate or rough, occasionally very
rough at first in Forties, Cromarty and Forth. Rain for a time. Good, becoming
moderate or poor for a time.

---

From: Evan Hunt <[email-masked]>
Date: Wed, 11 Mar 2015 17:15:35 +0000

> (echo 'update add non.terminal 3600 in txt "braaains"';

Thank you for being rigorous and running the test that I should've
before voicing my suspicion.

That suspicion being confirmed, I don't think NOERROR/NODATA is
going to be a good choice here. :/

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Mar 2015 17:27:14 +0000

> going to be a good choice here. :/

I also tried a stupid hack to send an ANY RR in the response. BIND's
resolver treats this as a FORMERR and returns SERVFAIL to the client.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest Fitzroy, Sole: Southwesterly, backing southeasterly for a time, 4 or
5 increasing 6 to gale 8. Moderate or rough, becoming very rough later in
west. Occasional rain, fog patches. Moderate or good, occasionally very poor.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 12 Mar 2015 07:35:10 +0800

> answer doesn't contain them.

i love this plan.

-- 
Paul Vixie

---

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

> On Mar 10, 2015, at 8:05 PM, Paul Vixie <[email-masked]> wrote:
> 
> we are, in this case, defining a protocol. our goal is to get the client to stop asking the ANY question. if we send is a signal that sounds right (REFUSED, for example) but merely has the effect of "go to next server" then we're losing.
> 
> if we're serious about redefining ANY as a meta-query, then answering with RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries against an RA=1 server.)
> 
> but whatever we do, any new reaction to QTYPE=ANY has to ensure that the client gives up, and stops asking.

I for one am concerned about doing away with QTYPE=ANY and would like to see something more along the lines of authorities returning results so dig +trace works for diagnosis.  Perhaps building better tools for this which might remove my concern around ANY, that way it can iterate through various QTYPEs for me.

- jared

---

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

> resolver treats this as a FORMERR and returns SERVFAIL to the client.

What about introducing a new non-meta RR type for this purpose?  It
would not increase the response size by much.

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Thu, 12 Mar 2015 23:38:04 +0000

So you're thinking it's more likely that we'll get folks to understand this new type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful way, than it is to convince them to stop making QTYPE=* queries in the first place?

Don't get me wrong -- I would actually *applaud* the definition of a new RR type (and possibly, a new meta-type to go along with it) that was designed to facilitate a controlled ability to fetch all RRsets for a given name, in a single query. That would be forward progress, in my opinion. But to create a new RR type solely for the purpose of making an RFC 1034/1035-defined feature of DNS less useful than it would otherwise be? I see that as going backwards, verging on Luddite. What's next? A new RR type to "gracefully" frustrate senders of MX queries, because we consider SRV a more general mechanism for accomplishing the same thing? That's a hell of a way to evolve a protocol, creating new RR types specifically to render old QTYPEs or RR types useless...

																- Kevin 

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Florian Weimer
Sent: Thursday, March 12, 2015 12:30 PM
To: Tony Finch
Cc: Evan Hunt; dnsop; Wessels, Duane; Paul Vixie
Subject: Re: [DNSOP] CloudFlare policy on ANY records changing

> resolver treats this as a FORMERR and returns SERVFAIL to the client.

What about introducing a new non-meta RR type for this purpose?  It would not increase the response size by much.

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

---

From: Evan Hunt <[email-masked]>
Date: Fri, 13 Mar 2015 00:30:03 +0000

On Thu, Mar 12, 2015 at 11:38:04PM +0000, Darcy Kevin (FCA) wrote:
> So you're thinking it's more likely that we'll get folks to understand
> this new type, that's designed to frustrate QTYPE=* queries in a
> more-or-less graceful way, than it is to convince them to stop making
> QTYPE=* queries in the first place?

They don't need to understand it, they just need to be able to receive
it without choking.

This could be a pretty brilliant solution, actually: If you're
authoritative for a signed zone and you receive a query of type ANY,
return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize
a response containing a single RR with a type from the "private use" range
(e.g. TYPE65531 or whatever), zero length rdata, and a long TTL.  The
resolver would get an answer, so it stops asking; it would *not* cache
the answer as an empty node, so subsequent queries for other qtypes can
still resolve.

I like this better than any of the prior suggestions.  (It doesn't
address qmail's problem, but that's a lost cause no matter which method
is chosen.)

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Mar 2015 11:10:18 +0000

> the answer as an empty node, so subsequent queries for other qtypes can

I tried this and it works OK. In the below, > is an nsupdate prompt and $
is a shell prompt in another window.

# set up fake ANY response
> add bar.mini.dotat.at 60 in type6666 \# 1 66
> send

# cache fake ANY response
$ dig +short bar.mini.dotat.at any
\# 1 66

# set up real response
> del bar.mini.dotat.at
> add bar.mini.dotat.at 60 in txt "booze"
> send

# name server fetches missing RRsets
$ dig +short bar.mini.dotat.at txt
"booze"

> address qmail's problem, but that's a lost cause no matter which method

This will work with qmail. Its query sequence is: ANY (for CNAME-based
rewriting and to prime the cache); MX (for delivery); fallback to A.

With this proposal, it will get a no-CNAME reply to ANY, so it will not
rewrite the address. Then it will get the same answers as before to its MX
etc. queries. The delivery will proceed OK.

Slightly interesting things occur if there is actually a CNAME at the
query name, but this is the same as what would happen if you are lucky
enough to make these queries while the QNAME changes from not-a-CNAME to
actually-a-CNAME. So it is OK to always give a fake reply to an ANY query.

If you are feeling generous when you implement this idea, you can add a
special case when the QNAME is a CNAME and return that, which will
preserve qmail's rewriting behaviour.

When you have cached non-CNAME data at a name and a subsequent query gets
a CNAME answer, the CNAME overrides the existing data at that name if you
make more not-ANY queries. But you can get some, um, interesting responses
to ANY queries.

; <<>> DiG 9.11.0pre-alpha <<>> bar.mini.dotat.at any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54981
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bar.mini.dotat.at.             IN      ANY

;; ANSWER SECTION:
bar.mini.dotat.at.      3596    IN      CNAME   localhost.
bar.mini.dotat.at.      3578    IN      TXT     "booze"

;; AUTHORITY SECTION:
mini.dotat.at.          86400   IN      NS      mini.dotat.at.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Mar 13 11:00:27 GMT 2015
;; MSG SIZE  rcvd: 101

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Southerly 6 to gale 8, decreasing 4 or 5. Rough or very
rough, becoming moderate or rough. Fair. Good.

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Mar 2015 17:10:43 +0000

> > (e.g. TYPE65531 or whatever), zero length rdata, and a long TTL.

Maybe this could be a use for the NULL RRtype? :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: Southerly 5 to 7, but variable 3 or 4 at first in east. Rough or very
rough, occasionally high later in north. Occasional rain, fair for a time.
Moderate or good.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 13 Mar 2015 17:27:49 +0000

> Maybe this could be a use for the NULL RRtype? :-)

I'd completely forgotten its existence.  But yes, that
makes plenty of sense.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 14 Mar 2015 20:57:00 +0100

>> QTYPE=* queries in the first place?

Yes, I do.

> They don't need to understand it, they just need to be able to receive

Correct, or not too much choking.  Entering a fallback path is
acceptable and the desired behavior (if you can speak of such in this
context).

---

From: Florian Weimer <[email-masked]>
Date: Sat, 14 Mar 2015 20:58:59 +0100

* Evan Hunt:

> (It doesn't address qmail's problem, but that's a lost cause no
> matter which method is chosen.)

I think it does.  qmail already copes correctly with a partially
cached ANY response (due to TTL mismatch between RRset), does it?
The new behavior just looks like a partially cached response
all the time.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 14 Mar 2015 21:10:03 +0100

> Maybe this could be a use for the NULL RRtype? :-)

We'd have to be reasonably sure that no resolver treats is as a
meta-type and turns the upstream response into a FORMERR upon seeing
it in the answer section.  “NULLs are used as placeholders in some
experimental extensions of the DNS.” is not confidence-inspiring in
this regard.

---

From: Evan Hunt <[email-masked]>
Date: Sat, 14 Mar 2015 20:52:19 +0000

> experimental extensions of the DNS.” is not confidence-inspiring in

On the other hand, it saves us the grief of allocating a code point, and
it has an intuitive name: if I saw a NULL RR in a cache dump I'd
immediately guess it was a placeholder.  Your point is well taken,
but if that hypothetical resolver behavior turns out not to commonplace,
then I say let's run with it.