Subject: [DNSOP] More work for DNSOP :-)

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Mar 2015 15:52:17 +0100

"Deprecating the DNS ANY meta-query type" (no Internet-Draft published)

https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/

"Today, we are announcing that we are deprecating the DNS ANY
meta-query. In a few weeks we'll be responding to those queries with
rcode 4 / Not Implemented."

---

From: Simon Perreault <[email-masked]>
Date: Fri, 06 Mar 2015 10:07:10 -0500

> rcode 4 / Not Implemented."

Good news!

The problem with ANY is that it appears to work just fine. If a 
significant chunk of DNS servers start breaking ANY then it might 
discourage naive developers from attempting to use it.

Simon

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Mar 2015 15:28:45 +0000

>rcode 4 / Not Implemented."

I'm happy to see an operator take this on.  I would prefer to see an
Internet Draft covered by the Note Well be used as the basis of the
discussion. ( poke - ;) )

A few years (3 maybe) back I (along with many others) abuse of the ANY
query while previously working with a DNS hosting operator.  For a while
we took a similar step (I forget the details now, think we chose REFUSED)
but reversed course when we received inquiries to our help desk.  At that
point I began to give a series of presentations related to this issue,
including this at DNS-OARC two years ago:

https://indico.dns-oarc.net/event/0/contribution/18/material/slides/0.pdf

(The presentation had a wider scope, but treating ANY queries was one of
the motivators.)

The query type ANY is not essential to the protocol architecture and it
certainly has become a problem for operators.  (Anyone wanting all records
at a node can just ask for each specific type.)  The only obstacle to
removing them is that they are expected to be available.

We (as in the royal we) know collectively that ANY queries to
non-authoritative servers are more headache than helpful.  We berate
implementations (like a recent browser that turned on ANY queries,
immediately causing a thread on non-IETF operations lists).  Use of ANY in
gathering research data is acceptable, without ANY, there are alternative
means to gather research data.

I don't know who should take this on, reacting to "More work for DNSOP".
I'd prefer this come from operators (of which I am not now) who can add
insight into why part of the protocol ought to be "removed."

---

From: Marcus Grando <[email-masked]>
Date: Fri, 6 Mar 2015 12:28:50 -0300

There's an thread about Firefox and ANY queries on dns-operations@ ML.

https://lists.dns-oarc.net/pipermail/dns-operations/2015-March/thread.html#12897

Best regards

--
Marcus Grando
marcus (at) sbh.eng.br
mnag (at) FreeBSD.org
@marcusgrando

On Fri, Mar 6, 2015 at 12:07 PM, Simon Perreault <[email-masked]>
wrote:

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Mar 2015 17:35:24 +0100

On Fri, Mar 06, 2015 at 03:28:45PM +0000,
 Edward Lewis <[email-masked]> wrote 
 a message of 159 lines which said:

>  I would prefer to see an Internet Draft covered by the Note Well be
> used as the basis of the discussion. ( poke - ;) )

Olafur Gudmundsson promised one on the dns-operations mailing list. In
the mean time, here is some prior art, which could be useful for the
future I-D:

https://github.com/moondawg/binddenyanybyview

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Mar 2015 10:59:25 -0800

> Simon Perreault <mailto:[email-masked]>
> Friday, March 06, 2015 7:07 AM
>
> ...
>

there's a much bigger problem with ANY, which is, its only valid use is
for diagnostics. like RD=0 sent to a recursive-only non-authoritative
name server, its intended purpose is helping other people learn things
about your name server state that you get no direct benefit from exposing.

mozilla's use of ANY is abusive. when sendmail used to send ANY queries,
we thought it could save round trips. we eventually learned that this
was crazy-talk. mozilla's abuse inevitably brings cloudflare's defense.

let's nip one meme in the bud, though: deprecating ANY will not change
the reflecting/amplifying landscape other than to obsolete some of the
existing low-end DDoS tools, which will quickly be changed to ask for
TXT or NS (or even better, DNSKEY).

-- 
Paul Vixie

---

From: Simon Perreault <[email-masked]>
Date: Fri, 06 Mar 2015 14:15:31 -0500

Le 2015-03-06 13:59, Paul Vixie a écrit :
> for diagnostics.

Private email, and this public one, made me realize that what I wrote 
wasn't clear: discouraging naive developers from attempting to use ANY 
is a *good thing*. Breaking ANY is a *good thing*. Let's do this.

> like RD=0 sent to a recursive-only non-authoritative

Full agreement.

All of that would not be so bad if ANY did not appear to work. Mozilla, 
and others, would not have used ANY if it had not appeared to work. 
That's why ANY is so subversive.

Let's break it significantly so it doesn't appear to work anymore.

Simon

---

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

> Friday, March 06, 2015 11:15 AM
> All of that would not be so bad if ANY did not appear to work.
> Mozilla, and others, would not have used ANY if it had not appeared to
> work. That's why ANY is so subversive.
>

i now realize that the draft should cover "meta queries" in general,
including RD=0 to a recursive server, AXFR and IXFR, and ANY of course,
and whatever else we can come up with. and the recommendation should be
to place these query types behind some access control mechanism, to
prevent them from being used in normal DNS operations, but to support
their use for diagnostic or other close-relationship activities (zone
transfers).

-- 
Paul Vixie

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Mar 2015 19:29:43 +0000

>there's a much bigger problem with ANY, which is, its only valid use is

And it's not even necessary for that.  One can easily enumerate through
all interesting types.

---

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

> And it's not even necessary for that.  One can easily enumerate through

so, i disagree, but it doesn't matter.

i disagree, because the existence of a non-predicted type can have
extreme significance.

it doesn't matter, because this is a meta-query example, and all
meta-queries should remain available under ACL (see my other message on
this thread about RD=0 to recursive-only servers, and zone transfer
query types.)

-- 
Paul Vixie

---

From: Bob Harold <[email-masked]>
Date: Fri, 6 Mar 2015 14:37:00 -0500

I would be concerned about blocking RD=0 (non-recursive).  That would
prevent me from check to be sure an entry was NOT in the cache, in some DNS
server my clients are using. That would make troubleshooting more
difficult.  Let's not automatically include that in some group to get
easily blocked.  A separate command to block RD=0 is fine, if someone
chooses to use it, to make life difficult for others, that is their choice,
but don't recommend it or make it part of a group.

-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
[email-masked]
734-647-6524 desk

On Fri, Mar 6, 2015 at 2:20 PM, Paul Vixie <[email-masked]> wrote:

>
>
>   Simon Perreault <[email-masked]>
> and others, would not have used ANY if it had not appeared to work. That's
> why ANY is so subversive.
>
> including RD=0 to a recursive server, AXFR and IXFR, and ANY of course, and
> whatever else we can come up with. and the recommendation should be to
> place these query types behind some access control mechanism, to prevent
> them from being used in normal DNS operations, but to support their use for
> diagnostic or other close-relationship activities (zone transfers).
>
> --
> Paul Vixie
>

---

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

> Bob Harold <mailto:[email-masked]>
> Friday, March 06, 2015 11:37 AM
> prevent me from check to be sure an entry was NOT in the cache, in
> some DNS server my clients are using. That would make troubleshooting
> more difficult.  Let's not automatically include that in some group to
> get easily blocked.  A separate command to block RD=0 is fine, if
> someone chooses to use it, to make life difficult for others, that is
> their choice, but don't recommend it or make it part of a group.

i feel, and share, the pain you're describing. however, we're in a
post-snowden era, and any information leaks (such as RD=0 queries to
recursive-only servers) have to be reconsidered on the new risk:benefit
model. i find that giving every one of my users and customers the
ability to find out the presence and if present the TTL of anything in
my cache is something more likely to be used against me than to be used
for me. the fact that this will make reasonable things like what you're
describing also broadly impossible is no different from all the
reasonable things that ubiquitous perfect forward secrecy will also make
impossible.

as you say, fine grained acl's should be the recommendation. but the
default ACL for all meta types should be recommended as "nobody". this
is further evidence that abuse breeds overcompensation, like with ANY
itself. (if mozilla hadn't abused ANY, we would not be having this
conversation.)

-- 
Paul Vixie

---

From: Dan York <[email-masked]>
Date: Fri, 6 Mar 2015 20:13:09 +0000

On Mar 6, 2015, at 1:20 PM, Paul Vixie <[email-masked]<mailto:[email-masked]>> wrote:

i now realize that the draft should cover "meta queries" in general, including RD=0 to a recursive server, AXFR and IXFR, and ANY of course, and whatever else we can come up with. and the recommendation should be to place these query types behind some access control mechanism, to prevent them from being used in normal DNS operations, but to support their use for diagnostic or other close-relationship activities (zone transfers).

While I agree with this idea, I wonder if from a clarity of deployment point of view, as well as a speed point of view, it would be easier to divide this into two different documents:

1.  Deprecate the ANY query

2. “Meta queries” should be behind some access control mechanism

Is there anyone arguing that the ANY query should still be around?  Or can we agree that ANY is now a query that has outlived its usefulness and needs to fade away?

I say that because I think if we agree ANY should go, we should be extremely clear about that and, as Simon said, break ANY significantly so that people stop relying on it and stop supporting it in DNS clients and applications.  Get rid of it.

And provide that guidance in an extremely simple and clear manner.    (Realizing, of course, that all we can do is make the recommendation and encourage operators and app developers to follow that recommendation.)

Separately, we can also provide guidance that other meta queries should be put behind some kind of access control mechanism.   My worry about grouping ANY with the other meta queries is that it may indicate to people that it is still okay to implement the ANY query.

My 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Evan Hunt <[email-masked]>
Date: Fri, 6 Mar 2015 20:59:20 +0000

On Fri, Mar 06, 2015 at 08:13:09PM +0000, Dan York wrote:
> While I agree with this idea, I wonder if from a clarity of deployment
> point of view, as well as a speed point of view, it would be easier to
> divide this into two different documents:
> 
> Is there anyone arguing that the ANY query should still be around?  Or can
> we agree that ANY is now a query that has outlived its usefulness and
> needs to fade away?

I use QTYPE=ANY for testing and troubleshooting quite frequently, and would
prefer to see it hidden behind an access control mechanism rather than
disabled completely.

(As an aside: I've often wondered why the DNS doesn't have *more* meta-query
types, less extensive than ANY, such as a single type covering A and AAAA.
Or, an EDNS OPT mechanism to request a list of desired types in addition to
QTYPE to be returned in the additional section (subject to packet size, rate
limiting, DNS cookie authentication, whatever).  I would guess the absence
of such conveniences to be the reason Mozilla decided to take their
regrettable shortcut.  It seems like such an obvious optimization, I'm
guessing it was talked to death before I ever started working with the DNS
and there were good reasons not to do it, but I don't actually know what
they were.)

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

---

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

> Dan York <mailto:[email-masked]>
> Friday, March 06, 2015 12:13 PM
>
>

i don't want to see ANY deprecated. there are valid diagnostic uses for
it. the definition of this protocol verb should remain. the only change
we should make is that it be ACL'd to "nobody" by default.
> 2. “Meta queries” should be behind some access control mechanism

that's new work, new protocols, new implementations. while i'd like to
see that work progress, it's a large work-item and would result in a DNS
Maintainance and Diagnostic protocol, probably REST/JSON, and would drag
in DNS Provisioning, for adding slave zones or whatever. by the time we
get done accepting all the help from all the innovators who would have
strong contributions to that, we're talking a period of five to ten years.

> Separately, we can also provide guidance that other meta queries
> should be put behind some kind of access control mechanism.   My worry
> about grouping ANY with the other meta queries is that it may indicate
> to people that it is still okay to implement the ANY query.

i think that any recommendation we make that says "ANY is a meta-query"
should also state that like AXFR/IXFR and like RD=0 for recursive-only
servers, ANY should not be available to untrusted or unidentified
initiators. that would address the "is it still OK to implement?"
question in the best possible way.

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Mar 2015 16:10:59 -0500 (EST)

On Fri, 6 Mar 2015, Evan Hunt wrote:

> limiting, DNS cookie authentication, whatever).

It's been tried, for instance to get a lot of crypto records along with
the address records. People don't seem to like it at all. It might be
harder now too when needing to include a bunch of NSEC(3) proofs.

Paul

---

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

>> types, less extensive than ANY, such as a single type covering A and

nothing prevents a server from answering A with AAAA as additional data,
or answering AAAA with A as additional data. there can be no delegation
point between rrtypes at a single node, so poisoning isn't to be feared.
the RRSIGs for additional data can be included just as when A/AAAA
additional data is included with MX, SRV, or NS.

i'd like to see this done. it would not require an internet-draft, or if
one existed, it would be an FYI nor STD.

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Fri, 6 Mar 2015 19:37:02 -0500 (EST)

On Fri, 6 Mar 2015, Paul Vixie wrote:

> nothing prevents a server from answering A with AAAA as additional data, or answering AAAA with A as
> additional data. there can be no delegation point between rrtypes at a single node, so poisoning isn't to
> be feared. the RRSIGs for additional data can be included just as when A/AAAA additional data is included
> with MX, SRV, or NS.
> 
> i'd like to see this done. it would not require an internet-draft, or if one existed, it would be an FYI
> nor STD.

At the time, I was more thinking of an EDNS option with a nsec3-style
bitmap to specify which RRTYPE's you are interested in. Those would
have to include the proof that something does not exist. It gets
trickier if you want to support asking for "IPSECKEY and TLSA record for
www.nohats.ca" and map that to the proper _443._tcp.www.nohats.ca. for
TLSA and its NSEC3 records.

People were pretty fast to say "just send multiple queries at once". And
that is kind of true, and exactly what is now done with A / AAAA. But it
would be better to get one query reply so you can make an informed
decision instead of either waiting for the 2nd query or doing v4 when
you could have done v6 if you had waited on the second query reply.

The problem with specifying this without a new EDNS option is that you
don't know the differenec between old software or a missing A/AAAA
record - you just know it was not in the reply. So software will still
use two queries. It's fixable, but the migration path will take years
while we don't have a good dns library to do this work in that everyone
will then use.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Mar 2015 19:47:31 -0500

On Fri, Mar 06, 2015 at 01:37:17PM -0800, Paul Vixie wrote:
> or answering AAAA with A as additional data.

I seem to recall having this discussed at length more than once in
DNSEXT, and the conclusion was always that the additional complication
wasn't worth the effort.  If a cache had an A but not AAAA or
conversely (a situation likely to happen), then there'd be no win
because you'd have to ask again anyway.  Moreover, you couldn't even
tell whether you didn't get the thing you wanted because it wasn't in
cache or because it didn't exist, so you'd end up asking more often
than you wanted.  And because application developers would need to
handle all these cases anyway, the workflow would be more complicated.
(Simplification of the workflow seemed to be the main driver in the
past.  Maybe latency would now trump that, but I actually am not
convinced this would lower latency as opposed to popping off queries
in parallel anyway.)

So it didn't seem to be worth it, at least the last time.  I'm not
able to put my hands on those discussions at the moment, which makes
me think it probably happened on namedroppers@ and not on dnsext@.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Mar 2015 17:25:23 -0800

Paul Wouters wrote:
>> i'd like to see this done. it would not require an internet-draft, ...
>

we don't need new signaling. additional data rules already permit what
i'm proposing here.

> you could have done v6 if you had waited on the second query reply.

certainly, sending multiple queries in parallel means more processing
for everybody including the intervening routers, and unless you have a
tcp session open, means you have a smaller chance of success (meaning,
that nothing you want back will face loss or congestion.) if you need to
know whether AAAA exists before you will fall back to IPv4, then you
have to wait for both responses before you can make your next move.
also, if AAAA would satisfy you, then you'll end up hearing an "A"
response that you don't care about, probably after you've made your next
move (initiated a IPv6 TCP session). i don't see how we can build the
star-trek like future that many of us would like to live in, starting
from awful design-by-organic-side-effect like this.

> while we don't have a good dns library to do this work in that everyone

my proposal is just send the additional data. granted, many RDNS clients
("stub resolvers") wouldn't cache the additional data, but newer ones
like http://getdnsapi.net/ that we hope the world will switch to, can.
and, if ADNS servers did this, then it would prepopulate the RDNS cache,
thus speeding up the non-parallel queries that folks are making today.
(this is the big win from MX, SRV, and NS additional data processing.)

so, no new signaling is needed. this can be done, opportunistically,
now, by anybody and everybody.

-- 
Paul Vixie

---

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

> Andrew Sullivan <mailto:[email-masked]>
> Friday, March 06, 2015 4:47 PM
>
> wasn't worth the effort.

i remember that position being advanced, but i do not think it was ever
a consensus, other than leading into consensus-by-exhaustion, where the
consensus was not "this is a bad idea" but rather "the status quo will
have to serve, since we can't agree on changing it."

> If a cache had an A but not AAAA or
> than you wanted.

perhaps there's been a misunderstanding. this is never imperative,
always opportunistic. what additional data does is increase the
likelihood of related data of being found in caches, whether that cache
is inside the stub or inside the RDNS.

> And because application developers would need to

i'm alarmed that you're not convinced. is your position falsifiable --
can you describe any conditions under which you might become convinced?
(i'm willing to try, but not if there's no hope, not even a theoretical
if-pigs-had-wings situation, under which you could find merit in this
approach.)
> me think it probably happened on namedroppers@ and not on dnsext@.

alas, we don't write RFC's about roads not taken, so, many negative
conclusions remain undocumented even after well rounded debates that
followed good rules and visited all corner cases.

what's supposed to happen under my "just include the other kind of
address as additional data" proposal is that existing clients are more
likely to find the other kind of address in a nearby cache, and
opportunistic clients can add nearby caches to take advantage of this
increase in likelihood. there's no new signaling, no change to any
specification, no requirement to change any code except on servers, who
can send more additional data in certain cases, if they want the
statistical benefit of receiving fewer followup queries.

very few changes to the internet architecture are interest-aligned for
all parties, entirely opportunistic, and entirely uncontroversial.

perhaps our friends in the CDN world could make this change to some high
volume authority servers and let us know if it decreased their overall
DNS query rate.

-- 
Paul Vixie

---

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

> On 6 Mar 2015, at 19:37, Bob Harold <[email-masked]> wrote:
> 
> I would be concerned about blocking RD=0 (non-recursive).  That would prevent me from check to be sure an entry was NOT in the cache, in some DNS server my clients are using. 

I thought cache probing was considered an unfortunate information leak :-)

You can block rd=0 in BIND using a view with a match-recursive-only directive. So I think the only missing ACL is for ANY (and the similar RRSIG).

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 8 Mar 2015 21:23:34 -0400

There is a new version in the works, expect it late tomorrow (monday) 

It does not outlaw ANY per say, just says limit it  to trusted parties. 
I tries to define that resolver treat NOTIMP as long term signal that resolver should keep track of and not retry. 
It says ignore RD=1 on meta queries. 
It says do not upstream Meta queries 

It applies to all meta types, including RRSIG. 

	Olafur

> On Mar 7, 2015, at 4:36 PM, Tony Finch <[email-masked]> wrote:
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Mar 2015 18:48:05 -0700

> It applies to all meta types, including RRSIG. 

Hopefully you meant "all meta types, and RRSIG as well". RRSIG is not a metatype.

--Paul Hoffman

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 9 Mar 2015 10:38:06 +0200

Olafur Gudmundsson wrote:
> [...]
> I tries to define that resolver treat NOTIMP as long term signal
> that resolver should keep track of and not retry.

That's a bad idea, IMO.  When the resolver gets a NOTIMP response, it
has no way of knowing if it means "meta-type not implemented", "class
not implemented", "opcode not implemented", or any number of other
"not implemented" conditions.

There have been many operational problems caused by resolvers applying
cached SERVFAILs or cached indications of non-responsiveness to entire
servers, entire names, or excessive periods of time in violation of
RFC2308 sections 7.1 and 7.2.  We are now at risk of repeating all
those mistakes with the caching of NOTIMPs.

If we really do want NOTIMP caching in spite of those risks, it should
be specified in a separate draft updating RFC2308.  Discussing it in
the context of ANY will only make things worse by biasing the reader
towards assuming that NOTIMP responses are ANY related.

Also, ANY queries are relatively rare, and with this draft, should
because even rarer, and cheaper for the authoritative server to
respond to.  Keeping state in the resolver is expensive, and the
memory would probably be better spend on other things such as a
larger cache.
-- 
Andreas Gustafsson, [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 Mar 2015 10:26:24 +0000

> It applies to all meta types, including RRSIG.

I think you should suggest that implementations should have reasonably
fine-grained ACLs, e.g. we currently have an ACL for AXFR+IXFR; this draft
essentially proposes another ACL for RRSIG+ANY.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Southwesterly backing easterly 5 to 7, then backing
northwesterly 6 to gale 8 later. Very rough or high. Rain or wintry showers.
Good, occasionally poor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Mar 2015 15:21:20 +0100

On Fri, Mar 06, 2015 at 11:42:08AM -0800,
 Paul Vixie <[email-masked]> wrote 
 a message of 155 lines which said:

> we're in a post-snowden era, and any information leaks (such as RD=0
> queries to recursive-only servers) have to be reconsidered on the
> new risk:benefit model.

Yes. This is mentioned in "DNS privacy considerations"
<https://tools.ietf.org/html/draft-ietf-dprive-problem-statement-02#section-2.3>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 9 Mar 2015 15:28:44 +0100

On Fri, Mar 06, 2015 at 08:59:20PM +0000,
 Evan Hunt <[email-masked]> wrote 
 a message of 28 lines which said:

> (As an aside: I've often wondered why the DNS doesn't have *more*
> meta-query types, less extensive than ANY, such as a single type
> covering A and AAAA.

Probably for the same reason that makes QTYPE=ANY queries very
difficult to understand for the beginner and counter-intuitive:
because it is hard to specify the semantics. Imagine there is an ADDR
meta-query covering A and AAAA. You send QTYPE=ADDR and you get only A
record(s). Can you be *sure* (and can you validate with DNSSEC) that
there was no AAAA? Think of the various cases, RD=0, RD=1, caches,
forwarders, etc.

Same question if IETF invents IPv12 and we have AAAAAAAA records. At
first, some servers will ignore them. What is the meaning of ADDR if
you do not know if the servers handle AAAAAAAA?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Mar 2015 08:51:49 -0700

> There is a new version in the works, expect it late tomorrow (monday) 

There are questions about whether NOTIMP is the correct response. Given that, please consider starting a new -00 without "notimp" in the filename. That will help make it clear that you are open to the various changes that might come in the WG. Proposal: draft-whoever-metarr-acl-00.

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Mon, 9 Mar 2015 16:05:29 +0000

> On 9 Mar 2015, at 14:28, Stephane Bortzmeyer <[email-masked]> wrote:
> 

I wrote this a few years ago:

http://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-01

The primary stumbling block was the possibility (given DNSSEC) for multiple different RCODEs for the different QTYPEs being requested.

I couldn't think of any failure modes in the non-DNSSEC case, but with signed data it's theoretically possible to have valid signatures for the owner name on one QTYPE and invalid signatures on another.

Ray

---

From: "Olafur Gudmundsson" <[email-masked]>
Date: Mon, 9 Mar 2015 12:30:59 -0400 (EDT)

Happy to pick a less offensive file name :-) will discuss with co-editors (Joe Abley is also helping)
 
Olafur
-----Original Message-----
From: "Paul Hoffman" <[email-masked]>
Sent: Monday, 9 March, 2015 11:51
To: "Olafur Gudmundsson" <[email-masked]>
Cc: "IETF DNSOP WG" <[email-masked]>
Subject: Re: [DNSOP] More work for DNSOP :-)

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Mon, 9 Mar 2015 13:17:10 -0400

On Mon, Mar 9, 2015 at 12:05 PM, Ray Bellis <[email-masked]>
wrote:

> The primary stumbling block was the possibility (given DNSSEC) for
> multiple different RCODEs for the different QTYPEs being requested.
>
> I couldn't think of any failure modes in the non-DNSSEC case, but with
> signed data it's theoretically possible to have valid signatures for the
> owner name on one QTYPE and invalid signatures on another.
>
> Ray
>

Interesting idea. I think it's worth discussing these kinds of proposals in
more depth. To account for the multiple distinct response codes case, one
possibility is to carry an extended "response code array" in an EDNS
option. Clients already have to sometimes parse EDNS to get extended
response codes today, so we have one foot in that direction already. And
this could also support the more general case of multiple distinct query
names (not just multiple query types for the same name). There might be a
usecase for this in some application communities (like web browser vendors)
that are highly resistant to performing additional DNS queries for
additional latency reasons (eg. execute in one query: A/AAAA +
corresponding TLSA record which sits at a different qname).

PS. regarding Paul Vixie's recent suggestion of adding an AAAA or A record
set in the additional section for a corresponding A or AAAA query, I just
learned today that Unbound already does this. Not sure if there are any DNS
client APIs that can successfully make use of this info yet.

Shumon Huque.

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 9 Mar 2015 14:45:07 -0400

> client APIs that can successfully make use of this info yet.

Hi, Shumon:

Do you mean that Unbound will accept such answers from servers, or that
it will send such answers to clients, or both?

I just tried querying an Unbound 1.5.2 server for a cached, signed pair
of A/AAAA records and I don't believe Unbound sends such answers to
clients, at least not by default.

-- 
Robert Edmonds

---

From: Shumon Huque <[email-masked]>
Date: Mon, 9 Mar 2015 14:55:53 -0400

> it will send such answers to clients, or both?

This was from a transcript of a 'dig' session to an unbound resolver - so
this is unbound sending responses back to clients. I'm not sure if it
accepts such answers from queries to authority servers, nor do I know if
there are any authority servers that return such responses.

> clients, at least not by default.

Hmm, let me double check the details of the configuration and get back to
you. From the discussion with the colleagues that are running this server,
it sounded like it was the default, but perhaps some configuration knob
needs to be tweaked.

Shumon Huque.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 9 Mar 2015 16:17:53 -0400

> it sounded like it was the default, but perhaps some configuration knob

Upon closer inspection, it looks like I was mistaken. I was misled by the
following output which coincidentally looks like gratuitous AAAA in the
additional section:

$ dig @N.N.N.N getdnsapi.net A +ignore
+sit='b1c18d3e4328485cfe63a64b54fdf6a106f0e2e550919fa3'

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52975
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; SIT: b1c18d3e4328485c43b55e7954fdfd02f2cd44ce05415c15 (good)
;; QUESTION SECTION:
;getdnsapi.net.            IN    A

;; ANSWER SECTION:
getdnsapi.net.        450    IN    A    185.49.141.37

;; AUTHORITY SECTION:
getdnsapi.net.        450    IN    NS    getdnsapi.net.
getdnsapi.net.        450    IN    NS    mcvax.nlnet.nl.
getdnsapi.net.        450    IN    NS    dicht.nlnetlabs.nl.

;; ADDITIONAL SECTION:
getdnsapi.net.        450    IN    AAAA    2a04:b900:0:100::37

When in fact it's probably just unbound helpfully adding an AAAA
corresponding to one of the NS names in the authority section. The resolver
(actually identity masked) is at NLNetlabs (the unbound folks), so I was
thinking this might possibly be some special code or configuration in one
of their servers, but the actual explanation seems to be more benign.

Shumon Huque

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 10 Mar 2015 12:37:51 +0100

Hi Shumon,

On 09/03/15 21:17, Shumon Huque wrote:
> On Mon, Mar 9, 2015 at 2:55 PM, Shumon Huque <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Shumon Huque wrote:
>> PS. regarding Paul Vixie's recent suggestion of adding an AAAA or
>> A record set in the additional section for a corresponding A or
>> AAAA query, I just learned today that Unbound already does this.
>> Not sure if there are any DNS client APIs that can successfully
>> make use of this info yet.
> 
> Hi, Shumon:
> 
> Do you mean that Unbound will accept such answers from servers, or
> that it will send such answers to clients, or both?
> 
> 
> This was from a transcript of a 'dig' session to an unbound
> resolver - so this is unbound sending responses back to clients.
> I'm not sure if it accepts such answers from queries to authority
> servers, nor do I know if there are any authority servers that
> return such responses.
> 
> 
> I just tried querying an Unbound 1.5.2 server for a cached, signed
> pair of A/AAAA records and I don't believe Unbound sends such
> answers to clients, at least not by default.
> 
> 
> Hmm, let me double check the details of the configuration and get 
> back to you. From the discussion with the colleagues that are 
> running this server, it sounded like it was the default, but
> perhaps some configuration knob needs to be tweaked.
> 
> 
> Upon closer inspection, it looks like I was mistaken. I was misled
> by the following output which coincidentally looks like gratuitous
> AAAA in the additional section:
> 
> $ dig @N.N.N.N getdnsapi.net <http://getdnsapi.net> A +ignore 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52975 ;; flags:
> qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
> 
> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; SIT:
> b1c18d3e4328485c43b55e7954fdfd02f2cd44ce05415c15 (good) ;; QUESTION
> SECTION: ;getdnsapi.net <http://getdnsapi.net>.            IN    A
> 
> ;; ANSWER SECTION: getdnsapi.net <http://getdnsapi.net>.        450
> IN    A    185.49.141.37
> 
> ;; AUTHORITY SECTION: getdnsapi.net <http://getdnsapi.net>.
> 450    IN    NS getdnsapi.net <http://getdnsapi.net>. getdnsapi.net
> <http://getdnsapi.net>.        450    IN    NS mcvax.nlnet.nl
> <http://mcvax.nlnet.nl>. getdnsapi.net <http://getdnsapi.net>.
> 450    IN    NS dicht.nlnetlabs.nl <http://dicht.nlnetlabs.nl>.
> 
> ;; ADDITIONAL SECTION: getdnsapi.net <http://getdnsapi.net>.
> 450    IN    AAAA 2a04:b900:0:100::37
> 
> corresponding to one of the NS names in the authority section. The 
> resolver (actually identity masked) is at NLNetlabs (the unbound
> folks), so I was thinking this might possibly be some special code
> or configuration in one of their servers, but the actual
> explanation seems to be more benign.

Unbound varies its answers depending on what the authority server is
doing.  If the authority server inserts such an A or AAAA record in
the additional section, unbound has code for this case (an AAAA
inserted for an A query, or an A inserted for an AAAA query).

Only for the name that is queried, this to stop poisoning, and this is
why the code is there (it is a (happy?) side-effect of anti-poison code).

Best regards,
   Wouter

---

From: Shumon Huque <[email-masked]>
Date: Tue, 10 Mar 2015 09:24:47 -0400

> inserted for an A query, or an A inserted for an AAAA query).

Ah, that's good to know. The code for this case is "insertion into the
resolver's cache" I presume.

What about the side facing the clients? Will unbound insert the gratuitous
A/AAAA in responses to them if they exist in cache? Quick tests I did
suggest not (yet).

> why the code is there (it is a (happy?) side-effect of anti-poison code).
Yup, that makes perfect sense. Thanks for the details Wouter!

Shumon Huque.