This is a multi-part message in MIME format...

------------=_1139379267-41854-97
Received: (from namedroppers@localhost)
by mail.ogud.com (8.13.1/8.13.1/Submit) id k186ENKt044391
for namedroppers@ops.ietf.org; Wed, 8 Feb 2006 01:14:23 -0500 (EST)
(envelope-from namedroppers)
Approved: bert
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level: *
X-Spam-Status: No, score=1.4 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24,
DNS_FROM_RFC_WHOIS,HTML_10_20,HTML_MESSAGE,SPF_PAS S autolearn=no
version=3.1.0
Received: from [81.200.64.181] (helo=shell-ng.nominum.com)
by psg.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.60 (FreeBSD))
(envelope-from )
id 1F6hKA-000Pmm-5Q
for namedroppers@ops.ietf.org; Wed, 08 Feb 2006 04:53:02 +0000
Received: from Pivo.nominum.com (shell-ng.nominum.com [81.200.64.181])
by shell-ng.nominum.com (Postfix) with ESMTP id 98631568E3;
Tue, 7 Feb 2006 20:52:58 -0800 (PST)
(envelope-from pvm@nominum.com)
Message-Id: <6.0.3.0.0.20060207055855.084c3d60@127.0.0.1>
X-Sender: pvm@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Tue, 07 Feb 2006 06:24:57 -0800
To: Paul Vixie , namedroppers@ops.ietf.org
From: "Paul V. Mockapetris"
Subject: Re: the RD bit is troubling me today
In-Reply-To: <20060204013717.6BD8111427@sa.vix.com>
References: <20060204013717.6BD8111427@sa.vix.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_37909500==.ALT"

[ Moderators note: Post was moderated, either because it was posted by
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]

--=====================_37909500==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Disposition: inline

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
>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.

>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.


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.

bind wasn't alone in exploring that space>

>--
>to unsubscribe send a message to namedroppers-request@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive:


--=====================_37909500==.ALT
Content-Type: text/html; charset="us-ascii"
Content-Disposition: inline



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

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.


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.


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>


--

to unsubscribe send a message to namedroppers-request@ops.ietf.org
with

the word 'unsubscribe' in a single line as the message text body.

archive:
<http://ops.ietf.org/lists/namedroppers/>



--=====================_37909500==.ALT--



------------=_1139379267-41854-97
Content-Type: text/plain; name="SpamAssassinReport.txt"
Content-Disposition: inline; filename="SpamAssassinReport.txt"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.418 (Entity 5.418)

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



------------=_1139379267-41854-97--

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: