Subject: [dnsext] type=ANY

From: Edward Lewis <[email-masked]>
Date: Wed, 18 Feb 2009 14:24:38 -0500

Someone new to DNS asked me to explain the semantics of QTYPE=ANY in 
a caching/recursive server.

Stop me if you've heard this one before...

One thing I noticed is that the documentation covering QTYPE=* and 
QCLASS=* is asymmetric.  And, more to the point, the documents on 
QTYPE=* seem to be unclear.

When I try to explain the semantics of some DNS parameter, I start 
with the IANA registry page 
(http://www.iana.org/assignments/dns-parameters).  That page lists 
this:

(Cutting some things like the hexadecimal out for clarity)

# Registry Name: DNS CLASSes
# Registry:
# Decimal
# Hexadecimal    Name                            Reference
# -------------  ------------------------------  ---------
# 255            QCLASS * (ANY)                  [RFC1035]

# Registry Name: Resource Record (RR) TYPEs
# Reference: [RFC5395][RFC1035]
# Registry:
# TYPE         Value and meaning                              Reference
# -----------  ---------------------------------------------  ---------
# *            255 A request for all records                  [RFC1035]

Note that the (Q)TYPE "*" is defined as "all records" here, but in 
class "any" is used.

 From RFC 1035:

# 3.2.3. QTYPE values
# *               255 A request for all records

# 3.2.5. QCLASS values
# *               255 any class

My understanding is that QTYPE=*, aka, QTYPE=ANY, is not a request 
for all records, but whatever records a server has on hand.  Trying 
this out with popular implementations, that is what it appears to be.

If a server is authoritative, then any is all.  If a server is a 
cache, if it has anything cached for a name then the response has 
whatever it has, if there is nothing cached for the name, a recursive 
query is issued and that is used (essentially) for the response.

The first question - is there an update to these definitions that 
documents the behavior we experience today?  (I know we've talked 
this over on the list.)

Second question, should (specifically) the IANA registry "Value and 
Meaning" be altered to be more meaningful?

Why this matters - customer and customer support desks.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 18 Feb 2009 16:36:47 -0500

I believe you've captured the current state accurately: ANY for an
authoritative server means "all", while to a caching server it means
"whatever you have."  And if the caching server has nothing for the
given domain, it forwards the ANY query to its upstream server, which
may then load "all" of the records into the cache.  Otherwise, you might
have a few specifically-asked-for types (e.g., "A") for the domain lying
around in the caching server's cache.
 
I've used this semantics to obtain multiple types for a domain, but you
can't tell about the absence of a specific type of RR unless you either
ask for that specific type or ask the authoritative server.
 
        Craig

________________________________

	From: Edward Lewis [mailto:[email-masked]] 
	Sent: Wednesday, February 18, 2009 2:25 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: [dnsext] type=ANY

	Someone new to DNS asked me to explain the semantics of
QTYPE=ANY in a caching/recursive server.

	One thing I noticed is that the documentation covering QTYPE=*
and QCLASS=* is asymmetric.  And, more to the point, the documents on
QTYPE=* seem to be unclear.

	When I try to explain the semantics of some DNS parameter, I
start with the IANA registry page
(http://www.iana.org/assignments/dns-parameters).  That page lists this:

	# Registry Name: Resource Record (RR) TYPEs
	# Reference: [RFC5395][RFC1035]
	# Registry:
	# TYPE         Value and meaning
Reference
	# -----------  ---------------------------------------------
---------
	# *            255 A request for all records
[RFC1035]

	Note that the (Q)TYPE "*" is defined as "all records" here, but
in class "any" is used.

	From RFC 1035:

	# 3.2.3. QTYPE values
	
	# 3.2.5. QCLASS values
	# *               255 any class
	
	My understanding is that QTYPE=*, aka, QTYPE=ANY, is not a
request for all records, but whatever records a server has on hand.
Trying this out with popular implementations, that is what it appears to
be.

	The first question - is there an update to these definitions
that documents the behavior we experience today?  (I know we've talked
this over on the list.)

	Second question, should (specifically) the IANA registry "Value
and Meaning" be altered to be more meaningful?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-
	Edward Lewis             
	NeuStar                    You can leave a voice message at
+1-571-434-5468

---

From: bert hubert <[email-masked]>
Date: Wed, 18 Feb 2009 23:06:11 +0100

> a caching/recursive server.

It just keeps on coming back :-)
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00454.html
Chapter and verse can be found in the link above.

> this out with popular implementations, that is what it appears to be.

Indeed, and this is all one can count on. PowerDNS Recursor will go out to
the net for you if there is *nothing* in the cache, though. But only in that
case.

> Why this matters - customer and customer support desks.

I find that calls to support desks are rarely prevented by updating IANA
registries though :-)

But it might make sense to put the authoritative (haha) answer somewhere.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Feb 2009 08:45:43 +0200 (EET)

On Wed, 18 Feb 2009, Edward Lewis wrote:
> Someone new to DNS asked me to explain the semantics of QTYPE=ANY in a caching/recursive server.
> 

FWIW, I covered this e.g. in RFC 4472 Section 1.4.

I suppose the IANA values should change, but because the verbiage 
comes fom 1035, I doubt the explanation can be changed without an RFC 
reference requesting this.

> 
> One thing I noticed is that the documentation covering QTYPE=* and QCLASS=* is asymmetric.  And, more to the point, the documents on
> When I try to explain the semantics of some DNS parameter, I start with the IANA registry page
> Note that the (Q)TYPE "*" is defined as "all records" here, but in class "any" is used.
> 
> From RFC 1035:
> 
> # 3.2.3. QTYPE values
> My understanding is that QTYPE=*, aka, QTYPE=ANY, is not a request for all records, but whatever records a server has on hand.  Trying this
> out with popular implementations, that is what it appears to be.
> 
> If a server is authoritative, then any is all.  If a server is a cache, if it has anything cached for a name then the response has whatever
> it has, if there is nothing cached for the name, a recursive query is issued and that is used (essentially) for the response.
> 
> The first question - is there an update to these definitions that documents the behavior we experience today?  (I know we've talked this
> over on the list.)
> 
> Second question, should (specifically) the IANA registry "Value and Meaning" be altered to be more meaningful?
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Feb 2009 09:04:03 -0500

>FWIW, I covered this e.g. in RFC 4472 Section 1.4.

Thanks.  I promise to look at this in a little while.

>I suppose the IANA values should change, but because the verbiage comes fom
>1035, I doubt the explanation can be changed without an RFC reference
>requesting this.

Changing (as in text editing changes) an IANA registry doesn't need 
an RFC, just mail to them with the relevant info.  I've sent in 
updates before - mostly changes to the references.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Feb 2009 10:48:25 -0500

>FWIW, I covered this e.g. in RFC 4472 Section 1.4.

That text gives a good "informational" explanation of the situation. 
The one catch is that the text, as far as I can tell, introduces the 
use of the term "ANY" to apply to "QTYPE=*."  In RFC 1035 and the 
IANA registry, the word ANY (or any) is not currently used.

A question to the chairs (as agents of the I* complex): Would it take 
a standards track document to get IANA to alter what it calls QTYPE=*?

Before I said all it took to change text in IANA registries was an 
email, well, I kinda lied.  It can take a few emails over a few years 
to get it done. ;)  (Speaking of the experience in changing the 
reference for the ATMA resource record.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Feb 2009 10:50:53 -0500

>I find that calls to support desks are rarely prevented by updating IANA

My goal is to allow our support desk to answer a customer's call by 
pointing to the IANA registry.  For some reason, customers want to 
know why a service is not as they expected. ;)

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 19 Feb 2009 18:16:19 +0200

Edward Lewis wrote:
> use of the term "ANY" to apply to "QTYPE=*."

It goes back farther than that: RFC2136 also uses ANY instead of *,
for both classes and types.

> In RFC 1035 and the IANA registry, the word ANY (or any) is not
> currently used.

The IANA class registry already says "QCLASS * (ANY)".  I would be in
favor of updating the type registry to also say "* (ANY)".
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Feb 2009 11:21:05 -0500

>for both classes and types.

Oh, yes, I keep forgetting that Dynamic Update's document introduced 
a lot of terms "new to the spec but already in daily use" - like 
NXDOMAIN, etc.

>favor of updating the type registry to also say "* (ANY)".

Let's see if IANA will change based on mail list comments, or if 
they'll ask for a document...;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Chris Thompson <[email-masked]>
Date: 19 Feb 2009 17:16:36 +0000

>At 18:16 +0200 2/19/09, Andreas Gustafsson wrote:
[...]
>a lot of terms "new to the spec but already in daily use" - like 

NXDOMAIN is older than that, e.g. RFC 1536 (October 1993).

-- 
Chris Thompson
Email: [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 19 Feb 2009 17:17:42 -0500

Edward Lewis wrote:
> My understanding is that QTYPE=*, aka, QTYPE=ANY, is not a request for 
> all records, but whatever records a server has on hand.  Trying this 
> documents the behavior we experience today?  (I know we've talked this 
> over on the list.)
>
Personally, I think this should all be brought above-board. The original 
intent -- QTYPE=* as *all* records -- was, in retrospect of subsequent 
operational experience, naive, in the face of 
malicious/misconfigured/over-aggressive or just plain insane DNS clients 
hammering resolvers with the same queries continuously, combined with 
the inability to properly cache QTYPE=* answers with the current 
semantics. Thus QTYPE=* resolution was quietly "re-interpreted" into the 
"weak" form we see today as a self-protective measure.

But as long as the text of RFC 1034/1035 on this subject differs from 
what is actually in effect in the real world, there will continue to be 
a wellspring of confusion, for helpdesk customers and anyone else who 
encounters the subject matter. Changing the IANA description just puts 
an extra layer of gloss on the standard-versus-reality disparity; I 
would object to changing the IANA registry description without a 
standards action or at least a clarification. Let's fix it, once and for 
all, one way or another.

Some folks have waxed creative with the resolver-algorithm step that 
says (paraphrased) "if the answer is in cache, return it", as 
justification for the current QTYPE=* behavior being consistent with the 
standard. But it is rather vacuous to say that the resolver gets to 
decide what "the answer" is in any particular context, or to arbitrarily 
and undetectably lower its level of diligence such that a partial answer 
suddenly becomes "good enough" to serve as "the answer", even when a 
better answer is readily available through the regular 
recursive-resolver mechanisms.  "The answer" is what the requestor 
reasonably expects to receive, based on the description of the QTYPE 
and/or record type in the RFCs, and from the original description of 
QTYPE=* "the answer" is plainly "all" records at the QNAME node, not 
"whatever the ever-changing, unpredictable contents of your cache 
dictate".  (I'm assuming RD=1/RA=1 throughout; obviously in the case of 
RD=0 or RA=0, the resolver's level of diligence is intentionally or 
detectably lower and the requestor should not be surprised to find 
merely a partial answer in the response).

Rather than play semantic games with existing RFCs to justify current 
behavior, I'd prefer to see a formal clarification or update.

Either that, or we engineer some more advanced caching semantics so that 
QTYPE=* can work as originally intended. But that's a lot of work and, 
arguably, for very little benefit, since most apps and subsystems have 
long since given up on any QTYPE=* query methodology due to empirical 
evidence of its variability/unreliability.

                           - Kevin