Subject: the RD bit is troubling me today

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Feb 2006 01:37:17 +0000

We've spent about half of the total DNSSEC development era to date (that is
around six years out of the twelve) going down ratholes due to
misunderstanding 1034/1035.  Sometimes we amend 1034/1035 to explain something
that didn't used to need to be explained; sometimes we amend 1034/1035 to
explain something that we thought had been explained that turned out to have
ambiguities... The result of DNSSEC is that we now understand far more about
the delegation model and wildcards (among other things) than we used to know.
Sort of like one of the great side-benefits of NASA's moon programme was the
ballpoint pen.

There's been some interest recently in the question "should a nameserver also
be recursive, if it's authoritative for any zones?"  The old, sad, answer has
been "don't do it, since BIND4 was terrible about mixing recursive and
authority data, and dual-purpose nameservers are a recipe for cache pollution"
but it turns out that since BIND8, BIND9, and all modern non-BIND servers can
safely mix authority and recursive data, folks are starting to do this again.
It's not that hard to run two nameservers on a host, and just use different
IP addresses for your resolv.conf file vs. your NS RR -> A/AAAA RR chain, but
even though it's not hard, it's not as easy as just using one nameserver.

While the RD bit in a query can disambiguate the case of a name-below-zonecut
such that if RD=0 a dual-use server will return a delegation whereas if RD=1
it will go fetch the data, I don't think this helps when the qname is equal to
a zonecut name.  An authority server should respond with a non-AA delegation
in that case, since the zone ends above the zonecut.  A recursive server
should respond with a non-AA answer in that case.  But the non-AA answer
should be first retrieved from the apex of the subzone, by following the
delegation, all without allowing an RD=1 query to affect subsequent RD=0
results.  A dual-use server would therefore have to maintain separate NS
RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers.

1034/1035 does not anywhere say this, but it's the implication of the other
"intent of the framers" clarifications we've made to 1034/1035 during the
DNSSEC development era.  But if we were going to write another clarification
document on this point, I'd rather we just said "nameservers that offer both
authority and recursive service are undefined, please just don't do it" than
to try to describe how many RD bits should be dancing on the head of this pin.

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Sun, 5 Feb 2006 09:02:31 +0100

On Feb 4, 2006, at 2:37 AM, Paul Vixie wrote:

> document on this point,

I read your mail as a request for such clarification document.

> I'd rather we just said "nameservers that offer both

I guess that once others agree you have to add boilerplate text to  
your mail and submit as an I-D.

Do others think this clarification is needed and useful and that the  
proposed "solution" is appropriate?

Without my hats I'd answer yes to both questions. Documentation and  
education on the cornercases will help developers and operators.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 06 Feb 2006 11:36:25 +0100

<AOL>
Me Too
</AOL>

	jaap

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 06 Feb 2006 14:13:12 +0100

> to try to describe how many RD bits should be dancing on the head of this pin.

This discussion is missing a crucial part: What happens when a
dual-server does not maintain a separate NS RRset for RD=0 and RD=1?

In other words, I'm looking for the failure mode caused by this
problem.  There are two cases two consider.  The first case is when
the dual-use server always send the RD=0 answer, and the second case
where it always send the RD=1 answer.

Forbidding dual-use servers seem like a slightly unrealistic solution
to me, given deployed use.  Without understanding what the actual
interoperability problems are (in contrast to implementation
problems), it seems that there is no justification for that solution.

Thanks,
Simon

---

From: Peter Koch <[email-masked]>
Date: Mon, 06 Feb 2006 18:28:51 +0100

> > RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers.

Algorithms 4.3.2 and 5.3.3 in RFC 1034 say that in the case RD=1 the query
will be answered by local data. So, if a server is authoritative for the
parent, but not for the child, a query would be satisfied from "local data",
i.e. the NS RRSet that's present in the parent. The response won't be
authoritative, but why should that matter? The problem seems to be that
you won't be able to receive a signed response this way. But then, why would
one ask for an NS RRSet in the first place (yeah, DynUpd, I know, but QTYPE
SOA is better here anyway)?

> problems), it seems that there is no justification for that solution.

Agreed. "Don't" won't work. "Education" (quoting Olaf) will need to explain
the (theoretical) problem and its practical relevance.

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Feb 2006 19:27:52 +0000

peter wrote:

# Algorithms 4.3.2 and 5.3.3 in RFC 1034 say that in the case RD=1 the query
# will be answered by local data.  So, if a server is authoritative for the
# parent, but not for the child, a query would be satisfied from "local data",
# i.e. the NS RRSet that's present in the parent.

that's an odd "i.e.", one i consider nonsequitur.  1034/1035 are at best
unclear and at worst inconsistent and at least guideance-free on this point,
as they were on some other dnssec-relevant definitions like ownership of data
at delegation points, and the real meaning of wildcards.

# The response won't be authoritative, but why should that matter? The problem
# seems to be that you won't be able to receive a signed response this
# way. But then, why would one ask for an NS RRSet in the first place (yeah,
# DynUpd, I know, but QTYPE SOA is better here anyway)?

what i want to know is, what's the right answer.  the rest of 1034/1035, and
common programmer-in-the-street intepretation, is that a non-empty response to
an RD=1 query will contain data that came from the authority zone.  we know
(because dnssec required that we learn) that an authority-only server should
not respond to queries for its out-of-zone glue.  we know (again, from dnssec)
that zone-bottom NS RRs are only authoritative in the child zone (where they
would be apex NS RRs) and that an authority server should return delegations
rather than answers when queried about them.  what we don't know, and what i
really do want to know now, is what the right answer is to an RD=1 query that
matches a zone-bottom NS RRset.  the answer to this will bear on how we handle
future debates on the merits of wildcard NS RRsets, among other things.

simon wrote:

# This discussion is missing a crucial part: What happens when a
# dual-server does not maintain a separate NS RRset for RD=0 and RD=1?

that leads to the fallacy of the argument from utility.  i didn't want to
go there but see below.

# In other words, I'm looking for the failure mode caused by this
# problem.  There are two cases two consider.  The first case is when
# the dual-use server always send the RD=0 answer, and the second case
# where it always send the RD=1 answer.

there are more than two cases.  it can answer with one type of answer unless
it has ever answered with the other type of answer; it can return SERVFAIL or
an upward delegation; it can return inconsistent answers across a loadbalance
set if some loadbalance members are also configured for recursion and others
not.  there are all kinds of undefined things that can happen -- that's why
i called them "undefined" in my previous mail on this topic.

# Forbidding dual-use servers seem like a slightly unrealistic solution
# to me, given deployed use.  Without understanding what the actual
# interoperability problems are (in contrast to implementation
# problems), it seems that there is no justification for that solution.

rfc's have no power to forbid.  however, they are looked at by folks who want
to hold eachother to a standard when negotiating a contract, and they are even
sometimes looked at by people who are wondering what the right thing to do
would be, either out of curiousity or because they want to do the right thing.

peter added:

# Agreed. "Don't" won't work. "Education" (quoting Olaf) will need to explain
# the (theoretical) problem and its practical relevance.

i'm not really as interested in practical relevance as i am in nailing down
the definition of the protocol so that we know what "the right answer" is, and
under what conditions, and so on.

but consider the case where the parent's zone-bottom delegation is wrong or
out of date -- a VERY common case, as most of you know first hand.  (and it's
likely to remain the common case until the DNS protocol or a new protocol
adds the ability for parent-zone delegation glue to be updated by child zone
servers or child zone operators, and yes, i know this is being discussed in
conjunction with the key rollover feature set, but that's not relevant here.)

if the parent zone-bottom NS RRset and the child zone-apex NS RRset differ,
then by definition, the parent is wrong.  we know this because the parent's
zozne-bottom NS RRset is called glue and is not authoritative for dnssec
purposes; we know because other recursive/caching DNS protocol agents will
prefer to cache the authority data from the child zone as "more credible",
and we know it because it's the least-strenuous interpretation of 1034/1035's
words on the topic.

if the parent's zone-bottom NS RRset happens to be wrong, or for that matter,
can be wrong or is known to be sometimes or often wrong, then we ought to be
limiting the use of that data.  it ought to be used not only as seldom as
possible, but also, for as few purposes as possible.  there is only one real
purpose for it, and that's delegation.  if it's so wrong that delegation won't
work, then we're done, because the child's apex NS RRset will never be seen.
if it's only partly wrong, such that some of the nameservers designated by the
parent's zone-bottom NS RRset exist, some don't, some have had their names
changed, and so on... but there is some "data path" through the bad data that
does in fact lead to the right and proper and intended child zone, then we're
not done, and we have to ask, what NS RRset should a dual-purpose server give
out if asked for an NS RRset at its zone-bottom?

the rule of least astonishment demands, in my interpretation, that if RD=1 and
a response's answer section will be nonempty (that is, it's not a referral),
the answer section contain only data that came, originally, from the authority
zone.  that would require the dual-purpose server recurse for names equalling
a delegation point, just as they do for names below a delegation point.  but
such recursion should not change the content of referrals, or else an authority
server will respond with a different below-zonecut referral after an equal-to-
zonecut referral, than it did before the equal-to-zonecut referral.  that way
lies madness, from a conformance testing and interoperability testing and
operational debugging standpoint.  also it would still be inconsistent, even
if no longer undefined.

therefore let me repeat my previous observation.  a dual-purpose server would
have to maintain discrete NS RRset data for all zonecut nodes ("delegation
points") in order to satisfy the other protocol invariants we know about.  we
all believe that this is overly burdensome.  we can therefore recommend that
no server be configured for both authority and recursive service.  although
i guess we can also define the proper behaviour so that those implementors
who don't find it burdensome can just operate in the "right" way.

let me show my colours for a moment.  BIND4 taught me to hate dual-purpose
servers, and there is no nameserver within reach of my keyboard that is
configured that way, or is allowed to be configured that way.  i find the
whole idea of dual-purpose servers disturbing and repellent.  this knowledge
may help some of you to decide to ignore my tirade on the topic, but in the
spirit of full disclosure, now you know where i'm coming from.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Feb 2006 19:42:22 +0000

i was curious so i googled.

# that leads to the fallacy of the argument from utility.  [...]

<http://www.law.upenn.edu/conlaw/issues/vol2/num3/king/node10_ct.html> has a
writeup "COMPETING PRINCIPLES AND THE ARGUMENT FROM UTILITY" which talks
about laws, constitutions, majorities, and supermajorities.  highly apropos
to our discussion about what the spec means vs. how it's been implemented.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Feb 2006 17:21:58 -0500

I think that...

A DNS server is always supposed to answer a query with the best 
available data, with best being defined as most trustworthy.  (I have 
been using "credible" for a while by mistake, I should have been 
saying "trustworthy.")  BTW, It sounds like there is a small problem 
with RFC 2181, 5.4.1.  Where "glue" is mentioned, it should be "glue 
and zone cut [NS Set]" data.

What this means is that no matter what the setting of the RD is the 
server ought to answer with the learned NS set over the authoritative 
NS set when the learned set is more trustworthy.  (Applying to the 
case where the QNAME is a zone cut, etc.)

It's tempting to make (a) DNS (server) be able to answer with the 
authoritative data when RD=0 and the learned data when RD=1, but I'd 
say this is a "siren's call."

1) Wanting to know the authoritative data in this case is something 
only a maintainer or reverse engineer would want to do.  (I.e., it's 
unusual.)

2) It's more work that just meeting the mission of a simple lookup 
service.  I.e., Complicates the code (to achieve the unusual case).

3) Let's keep the design such that servers are as aggressive as 
possible in returning the final result quickly.  (No one likes a slow 
librarian.)

As far as clarification ... to me this is pretty clear.  However, I 
won't say "don't clarify this" because clarity is in the eye of the 
beholder and clarity doesn't mean "right."  (Ignorance is bliss and 
all that.)

I'm no longer against mixing caching and authoritative servers.  I 
think that the reasons once used to justify separating the two have 
largely vanished.  I think that there are now valid reasons to 
combine them into one (at times).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Paul Vixie <[email-masked]>
Date: Wed, 08 Feb 2006 03:33:38 +0000

# ...
# What this means is that no matter what the setting of the RD is the server
# ought to answer with the learned NS set over the authoritative NS set when
# the learned set is more trustworthy.  (Applying to the case where the QNAME
# is a zone cut, etc.)

i disagree with this interpretation in two ways.

first, an authority server doesn't send answers when asked for non-apex NS,
it sends a referral.  that is, if you ask the COM-zone servers for VIX.COM NS,
you should get back a response with an empty answer section and a non-empty
authority section.

second, an authority server should not, in general, fetch any glue or
otherwise send any packets to anybody, and especially, it should never answer
differently unless its own authority zone data has been made different.

# It's tempting to make (a) DNS (server) be able to answer with the
# authoritative data when RD=0 and the learned data when RD=1, but I'd say
# this is a "siren's call."

i'm not tempted by any sirens here.  i just want to know what the right thing
is, so that i can do it, and complain if/when others don't, and test for it in
conformance suites, and so on.  none of that is possible while this case
remains undefined.

# I'm no longer against mixing caching and authoritative servers.  I think
# that the reasons once used to justify separating the two have largely
# vanished.  I think that there are now valid reasons to combine them into
# one (at times).

i think i've pointed out a case where a server's answer not defined by the
spec, where authority and recursion are done on the same IP/UDP listener
address.  since undefined is not what we usually want in a spec, and isn't
what folks think this spec offers, i'm calling that a problem.

we can decide that it's not really undefined, or that it's always been
undefined and everybody knew it but me and i'm chasing parked cars again, or
that it's not defined but the operational cost is low so we'll just document
it as undefined, or we can say that it's undefined and should become defined,
or we can say that it's undefined and therefore not a recommended practice.

our chairs will have to take the lead on determining which way we want to go.

---

From: "Paul V. Mockapetris" <[email-masked]>
Date: Tue, 07 Feb 2006 06:24:57 -0800

>RRsets (and associated A/AAAA glue) for RD=0 vs RD=1 answers.

I'm assuming we are operating in the RA=1 world.  That is the server is 
willing to honor the request for recursive service.

The intent of the framer was that authoritative data would always take 
precedence over cached data and that hints were even lower in priority.  A 
common metaphor for this was that the authoritative data in zones were like 
windows on a screen and the cache was the background.  At a zone cut, the 
parent was definitive with regard to controlling whether a child zone was 
recognized as a legitimate descendant, but the child, once recognized by 
the parent, was authoritative for the contents of that zone, including the 
top node.  Thus the NS records marking a zone cut in the parent, as well as 
glue data, were part of the zone, but not part of the zone's authoritative 
data.

>to try to describe how many RD bits should be dancing on the head of this pin.

Well, this intent again was that a recursive name server was just a name 
server that executed the resolver logic to fetch data if necessary, and 
that having access to authoritative data as well as a cache was possible.

--

Anyway, if RD=0, I'd argue that the authority section of the response 
should contain a delegation and the answer section cached data if available.

If RD=1, the answer section has the answer, with aa set if the answer came 
from a zone's authoritative data, 0 otherwise.

--

I can imagine lots of reasons where I might want to have a server 
configured to be authoritative only or caching only, but I don't think the 
one can credibly argue that the behaviour is "undefined" for a mixed server.

<And yes, there are lots of ways to implement mixed mode incorrectly, and 
bind wasn't alone in exploring that space>

Spam detection software, running on the system "hlid.ogud.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  At 05:37 PM 2/3/2006, Paul Vixie wrote: >We've spent
  about half of the total DNSSEC development era to date (that is >around
  six years out of the twelve) going down ratholes due to
  >misunderstanding 1034/1035. Sometimes we amend 1034/1035 to explain
  something >that didn't used to need to be explained; sometimes we amend
  1034/1035 to >explain something that we thought had been explained that
  turned out to have >ambiguities... The result of DNSSEC is that we now
  understand far more about >the delegation model and wildcards (among
  other things) than we used to know. >Sort of like one of the great
  side-benefits of NASA's moon programme was the >ballpoint pen. >
  >There's been some interest recently in the question "should a
  nameserver also >be recursive, if it's authoritative for any zones?" The
  old, sad, answer has >been "don't do it, since BIND4 was terrible about
  mixing recursive and >authority data, and dual-purpose nameservers are a
  recipe for cache pollution" >but it turns out that since BIND8, BIND9,
  and all modern non-BIND servers can >safely mix authority and recursive
  data, folks are starting to do this again. >It's not that hard to run
  two nameservers on a host, and just use different >IP addresses for your
  resolv.conf file vs. your NS RR -> A/AAAA RR chain, but >even though
  it's not hard, it's not as easy as just using one nameserver. > >While
  the RD bit in a query can disambiguate the case of a name-below-zonecut
  >such that if RD=0 a dual-use server will return a delegation whereas if
  RD=1 >it will go fetch the data, I don't think this helps when the qname
  is equal to >a zonecut name. An authority server should respond with a
  non-AA delegation >in that case, since the zone ends above the zonecut.
  A recursive server >should respond with a non-AA answer in that case.
  But the non-AA answer >should be first retrieved from the apex of the
  subzone, by following the >delegation, all without allowing an RD=1
  query to affect subsequent RD=0 >results. A dual-use server would
  therefore have to maintain separate NS > [...] 

Content analysis details:   (5.1 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.2 HEADER_SPAM            Bulk email fingerprint (header-based) found
 1.0 DATE_IN_PAST_12_24     Date: is 12 to 24 hours before Received: date
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.9 HTML_10_20             BODY: Message is 10% to 20% HTML

---

From: Paul Vixie <[email-masked]>
Date: Wed, 08 Feb 2006 08:06:51 +0000

# --
# 
# Anyway, if RD=0, I'd argue that the authority section of the response
# should contain a delegation and the answer section cached data if available.
# 
# If RD=1, the answer section has the answer, with aa set if the answer came
# from a zone's authoritative data, 0 otherwise.

I am pleasantly surprised by your RD=0 clarification, but the RD=1 baffles me.

For the RD=0 case, no existing server of which I'm aware works this way, and
noone I've spoken to about this who has read 1034 and 1035 interpreted it this
way.  However, I can see the consistency in it and I can live with the ruling.

In the RD=1 case, you'd have a dual-purpose server respond with data that did
not come about by recursion, and is in practical terms "less credible than"
what would result from querying the child zone's authority servers for it.

To help understand my bafflement, consider that regeneration is all the rage,
and AA=1 never occurs after recursion in BIND9.  In BIND4 and early BIND8, we
passed through the initial AA=1 from the authority server but gave back AA=0
on subsequent queries for the same data.  For a BIND9 recursive server, AA=0
on all responses.  I regard the current BIND9 behaviour as "more correct."

# --
# 
# I can imagine lots of reasons where I might want to have a server configured
# to be authoritative only or caching only, but I don't think the one can
# credibly argue that the behaviour is "undefined" for a mixed server.

I hope you're right, but I'd like to understand more about your reasoning in
the RD=1 case.  I really think that if a requestor wants recursion, that the
data they should be given should be the result of recursion.  If any other
RA=1 server were to respond with parent-zone-glue rather than child-zone-data
in this case, we would call that server "defective".

---

There's another, more extreme problem with dual-purpose servers, and that's
security.  Recursive nameservers which are open to the internet are, because
of the widespread ridicule heaped upon RFC2827/BCP38 and SAC004, "dangerous".
(I am aware of a multi-gigabit attack occuring against a neighbor, even as I
type this, involving a few thousand open-to-recursion nameservers, 4K TXT RRs,
a low-intensity spoofed source query stream from a botnet, and EDNS0.)  Since
it's operationally difficult to use different ACLs for recursion vs authority,
most people just don't do it.  So most dual-purpose nameservers are fully open
and thus "dangerous".  So if we do manage to nail down a practical
interpretation of dual-purpose, I'll want the resulting clarification document
to sing most expansively the damnation against open recursive servers, and if
I am an author of such a document, it will advise "just don't do it" as the
safest course of action.

---

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Feb 2006 12:27:50 -0500

>differently unless its own authority zone data has been made different.

I think what you said agrees with my interpretation. ;)

In my text I refer to "learned NS set" - which may be a null set, 
which is what a nominal authority server would have.  (I.e., 
authority only means not learning.)  Looking at the COM-zone servers 
you do see what I call hybrid responses (sorry, in my text, where I 
said answer, I should have said response) that have the NS records in 
the answer section.  In this instance, "learned" is not from caching 
but from being fed by the registry behind the servers.

No non-recursive server ought to do more than the priming queries for 
the root zone.  That's clear.  To underscore this, when I say 
"learned" I am assuming "passively learned" in this case - the result 
of the server learning for another reason.

>conformance suites, and so on.  none of that is possible while this case

I understand.  Nevertheless I think that if we open up the protocol 
to say "RD=0" means that a server expose data that would otherwise be 
obscured by what's learned passively relative to the query at hand 
then we are reacting to a siren's call.  (I.e., undesirable feature 
creep in the protocol.)

>or we can say that it's undefined and therefore not a recommended practice.

I don't like to say that "because X is undefined, don't do it."  If X 
solves a need, do it and clarify it.  Don't let the specification 
lead the code, don't let the code lead the service, don't let the 
service lead the demand.  As engineers, we have to remain ready to 
answer the needs of the populace, not the other way around.

I say this in support of defining what needs defining in this case 
and not because I saw you falling behind in a race with a parked car.

>our chairs will have to take the lead on determining which way we want to go.

The only thing I disagree with is that the chairs don't need to lead, 
we need to have the WG talk about this.  The chairs only need to 
detect when we've gotten to tired to fight and they declare 
"consensus."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Feb 2006 13:31:29 -0500

>I am an author of such a document, it will advise "just don't do it" as the

When you say "security" you mean potential for abuse on the public 
Internet, not security as in the safety of what you learn, right?

Just because "most dual-purpose nameservers are fully open" doesn't 
mean that dual-purpose shouldn't be clarified if the specs are 
unclear.  What needs to be made more clear is that open recursers are 
a problem - regardless if whether they are also dual-pupose.

Perhaps default settings of nameserver implementations ought to limit 
recursion to the loopback address, forcing a conscious decision on 
the deployer of the server to know what they are driving on the 
street.

For me, my most common use of dual-purpose has been with BIND views, 
defining one view that has no recursion and answers to the outside 
world and another view that has my split-brained zones and recursion 
allowed for internal machines.  This is my "most common"...I will say 
that when I dual-purpose a server it usually is done with BIND's 
views whether or not split-brain is involved.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Feb 2006 13:24:29 -0500

I've been trying to understand why mixing authority data and cached 
data is confusing or ill-defined.  Perhaps there are two angles.

1) CNAME?DNAME that "crosses" from authority to cache or vice versa.
2) At a delegation point, when considering the algorithm in 1034/4.3.2.

(I.e., the RD bit is the tip of the iceberg.)

># should contain a delegation and the answer section cached data if available.

This sounds like what the COM-zone servers appear to do today, if you 
interpret "cached data" as "otherwise learned data."

>what would result from querying the child zone's authority servers for it.

I don't see a problem here.  If I ask a server for data, I may assume 
some context like "I'm asking the tld server and expect to get back a 
referral to the next-level server."  The server doesn't have the 
context and would say "I'm being asked about this Q-tuple, let me 
find the most specific answer I can."  The disconnect we often make 
(and this came up repeatedly when developing the DS record years 
back) is that we forget the context assumed by the client is not the 
same context assumed by the server.

Ergo - the client shouldn't be surprised to find data it would label 
less credible/trustworthy from a server because it thought the server 
wouldn't answer from cached data.  The client should always expect 
the most trustworthy data it can get.

>on all responses.  I regard the current BIND9 behaviour as "more correct."

I think that BIND9 is "more correct."  But I don't see why 
regeneration is baffling in this case.  (Unless it has to do with 
4.3.2.)  If any part of the answer section comes from learned data 
(passively or actively cached), then the AA is off.  Otherwise it is 
on.  When I say "part" I am thinking of CNAME situations, in 
particular.

If a wild card domain name is in the cache, that is not a source of 
synthesis.  One more thing to keep in mind.

>in this case, we would call that server "defective".

I disagree with "if a requestor wants recursion, that the data they 
should be given should be the result of recursion."  Maybe this is 
where some confusion lies.

I see that the RD bit is a direction from the client to the server on 
how to handle the query.  Ordinarily the RD=1 only from stub to 
recursive cache, RD=0 for all full resolvers.  Exceptions to this are 
not a problem though, I would think.  If an implementation of a full 
resolver wanted to send RD=1 all the time to off-load it's work.

I don't think the server ought to determine what the resolver is 
asking for based on the header bits.  Yes, RD=0 says give me what you 
have but don't go looking elsewhere.  To me that's query management, 
not data lookup management.  That's my interpretation though, not 
based on any portion of a spec.

>I am an author of such a document, it will advise "just don't do it" as the

I think that deserves another Subj:
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar