Subject: I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-09.txt

From: [email-masked]
Date: Thu, 7 Feb 2008 14:37:02 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Update to DNAME Redirection in the DNS
	Author(s)	: S. Rose, W. Wijngaards
	Filename	: draft-ietf-dnsext-rfc2672bis-dname-09.txt
	Pages		: 16
	Date		: 2008-2-7
	
The DNAME record provides redirection for a sub-tree of the domain
name tree in the DNS system.  That is, all names that end with a
particular suffix are redirected to another part of the DNS.  This is
an update to the original specification in RFC 2672, also aligning
RFC 3363 and RFC 4294 with this revision.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dnsext-rfc2672bis-dname-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2008 11:19:58 +1100

Section 2.4 and 5.2 are contradictory.

	The 2nd and 3rd paragraphs of 5.2 should be deleted. 

	It is legal to add/delete records below a NS (and should
	be for DNAME) they just won't be visible until the DNAME
	or NS RRsets are remove.  In the NS case A and AAAA are
	visible as glue.

	You have to allow obscured records to be loaded.  2.4
	currently prevents this.

	Mark

2.4.  Names Next to and Below a DNAME Record

   Other resource records MUST NOT exist at a domain name subordinate to
   the owner of a DNAME RR.  To get the contents for names subordinate
   to that owner, the DNAME redirection must be invoked and the
   resulting target queried.  A server SHOULD refuse to load a zone that
   has data at a domain name subordinate to a domain name owning a DNAME
   RR.  Also a server SHOULD refuse to load a zone subordinate to the
   owner of a DNAME record in the ancestor zone.  See Section 5.2 for
   further restrictions related to dynamic update.

5.2.  Dynamic Update and DNAME

   Dynamic update for DNAME records works similar to dynamic update for
   delegating NS records.  For example, adding a DNAME obscures names in
   the zone.  DNAME records can be added, changed and removed.

   Zones containing a DNAME RR MUST NOT accept a dynamic update message
   that would add a record or delegation with a name existing under a
   DNAME.

   A server MUST return an error message with RCODE=YXDOMAIN [RFC2136]
   in response to a dynamic update message that would add a resource
   record under a DNAME in the zone.  This is similar to a dynamic
   update request to add a resource record under a delegation NS in a
   zone.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Edward Lewis <[email-masked]>
Date: Thu, 7 Feb 2008 22:03:39 -0500

>	Section 2.4 and 5.2 are contradictory.

I'm going to disagree. I see what you are tripping over though.

Dynamic update for NS records are quite different from DNAME. For 
instance, it is fine to add and delete NS records so long as the set 
is neither brought into existence or deleted altogether.  DNAME is a 
singleton type (i.e., RR set is limited to 1 record).

RFC2136, rule 7.6 says "it is not possible to create a zone using 
this protocol" and rule 7.13 adds "if deleting RRsets, it is not 
possible to delete either SOA or NS RRsets at the top of a zone." 
And then there's the sticky case of glue.

I was going to argue that similar != the same, but the fact is that 
DNAME dynamic update is quite different from NS dynamic update.

>	The 2nd and 3rd paragraphs of 5.2 should be deleted.

I think the problem is the wording of the first sentence of 5.2, not 
the latter two paragraphs.

>	You have to allow obscured records to be loaded.  2.4

I don't agree that we have to allow obscured records to be loaded. 
Why do we "have to"?  Why "(and should be for DNAME)?"

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Mail archives, backups.  Sometimes I think the true beneficiaries of
standards work are the suppliers of disk drives.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2008 14:26:29 +1100

> singleton type (i.e., RR set is limited to 1 record).

	At the apex.  It's perfect fine to add and delete NS RRsets
	at the bottom of zone.  DNAME is always at bottom of zone
	even when it is at the apex.
 
> Why do we "have to"?  Why "(and should be for DNAME)?"

	Because you can't ADD a DNAME which obscures some record
	then STOP and RESTART the server.

	Mark

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 08 Feb 2008 09:09:19 +0100

Mark Andrews wrote:
|> I don't agree that we have to allow obscured records to be loaded.
|> Why do we "have to"?  Why "(and should be for DNAME)?"
|
| 	Because you can't ADD a DNAME which obscures some record
| 	then STOP and RESTART the server.
|
| 	Mark

Hi Mark,

Why do we need obscured records?

Can't we rule that an added DNAME removes (not obscures) everything
below it. And nothing can be added below a DNAME.
That would make the draft consistent (but have to say that dynamic
update for DNAME is different from NS).

What is the current practice for DNAME and dynamic update in existing
implementations? How do they handle this - that is what I as an editor
want to know before introducing another implementation change :-)

Is it handled exactly like NS records now? In that case - can you
describe (in text) how that can be put in the draft?

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2008 19:18:39 +1100

> Why do we need obscured records?

	* So that you can easily correct mistakes.
	* So you can build namespace before you remove a DNAME.

> want to know before introducing another implementation change :-)

	We obscure as that matched NS and preserved the DNAME semantics.
 
> describe (in text) how that can be put in the draft?

	You basically look for a DNAME the same way as you look for
	a NS record as you traverse down through a zone.
 
> Best regards,
> ~   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFHrA4vkDLqNwOhpPgRAj9bAJ4oAdG82P5PVNRK8XXvA1s13W5WAgCfd558
> cbMONewtfJI61tDCyhRFSSk=
> =fwIp
> -----END PGP SIGNATURE-----

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Feb 2008 15:00:58 +0000

> below it. And nothing can be added below a DNAME.

if the unix "mv" or "cp" command could ever behave like "rm -rf" then the
natural error rate would be high enough, at scale, that a whole lot of
data would get implicitly destroyed, and the behaviour would be changed.

> update for DNAME is different from NS).

we just can't have UPDATE doing implicit "rm -rf".  anyone who wants that
behaviour should code it as successive, explicit UPDATE operations.

> describe (in text) how that can be put in the draft?

right now there are no special rules for UPDATE on DNAME RRs.  unlike
NS RR it is possible to delete the last DNAME at a zone apex, for example.
(not that this matters, i'm just using it as an example.)  so what we get
at the moment is, if you add a DNAME then the zone beneath that point is
unreachable by the authority server's search algo, and names/records below
that point which have been cached, are still returnable from recursive
servers, who aren't aware of the DNAME.

if you're going to update the DNAME++ spec on this point, i'd say, adding a
DNAME to an existing name (which has either records or children) is not
permitted, and YXDOMAIN should be returned in this case.  i thought that we
had covered this adequately in an earlier thread here.  see attached.

Subject: Re: updated dname draft-08
From: Paul Vixie <[email-masked]>
To: Scott Rose <[email-masked]>
Cc: Wouter Wijngaards <[email-masked]>, Namedroppers <[email-masked]>
Date: Mon, 14 Jan 2008 18:20:45 +0000

> Basically yes, but the changes are:

thanks very much for this, and for wouter's answer to the same lazy question
from me.

> Server side
> Old:
> server generated CNAME RRs have TTL=0
> Always generated CNAMEs in response containing DNAME
> 
> New:
> server generated CNAME RRs have TTL = DNAME TTL (some implementations
> already do this)
> 
> Only generate CNAME RRs if the Understand DNAME (UD) bit is NOT set (EDNS0
> flags field - 2nd highest bit requested)

so far so good.

> Server MUST return RCODE=REFUSED to a dynamic update message that would add
> any RR with a domain name under a DNAME RR's ownername.
> 
> Server handles adding DNAME RRs much like adding a NS to a zone (removes
> any domain names that would be under the DNAME ownername).

these are both controversial.  see below.

> Client side
> New:
> If resolver understands DNAME RRs in a response (i.e. follow them without
> the need of a CNAME) set the UD bit in the EDNS0 flags section.

and presumably ignore any presented CNAMEs whose owner matches a presented
DNAME (since not all servers will notice the UD).  but since EDNS is hop/hop
i'm going to ask whether recursive servers are allowed to synthesize CNAME
if there is a cached DNAME and UD=0?  (i don't need to know, it's fine with
me either way, i just hope the draft covers this.)

> If generated CNAMEs present, expect TTL = DNAME TTL or TTL = 0

how does an initiator know whether the presented CNAMEs are synthetic?

> Caches:
> Discussion only
> 
> The rest of the draft is a discussion of DNAME including clarification and
> pulling in sections of other drafts that discuss DNAME RRs.
> 
> I think that's all.  Would it help if this was expanded and included as an
> appendix to the draft?

yes, very much.

---

now for the two controversial UPDATE issues

first, RCODE=REFUSED is defined by RFC 2136 as follows:

              REFUSED     5       The name server refuses to perform the
                                  specified operation for policy or
                                  security reasons.

every RCODE related to UPDATE failure that is dependent on pre-existing zone
content is something other than REFUSED.  by "policy" in the above text, we
really meant something that had a configuration knob, where the knob was in
the "wrong" or incompatible position.  to use RCODE=REFUSED as a data-present
zone content incompatibility would be, in my opinion, the wrong thing to do.

i propose that RCODE=YXDOMAIN be used instead:

              YXDOMAIN    6       Some name that ought not to exist,
                                  does exist.

here, we deliberately did not say that the name which does exist is, or is
not, the same as a name being updated.  it covers perfectly well the case you
said: "would add any RR with a domain name under a DNAME RR's ownername."  if
this isn't reasonable, then i propose we allocate a new RCODE for this case,
but that no matter what we do, we must not use RCODE=REFUSED.

second, automatic removal of removal of domains below a DNAME.  RFC 2136 does
not, as far as i can tell by searching it, ask an UPDATE responder to delete
names when an NS RR is added.  in fact, this issue came up during the DNSIND
discussions and we determined that since the zone searching algorythm used by
QUERY would stop when searching downward from the apex upon encounter with an
NS RRset, then it was theoretically possible to add an NS RR which would hide
all data beneath its owner name, and then later delete that NS RRset causing
all the previously hidden data to become visible.  since DNAME has the same
effect on QUERY's downward search as NS has (that is, the search stops), i
think there is no reason to require any automatic deletion of data when a 
DNAME is added.

sorry to be so late with this.  i don't keep up with drafts like i used to.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 11:23:43 -0500

>	even when it is at the apex.

Ergo, NS processing is not "similar" to DNAME, right?  DNAME can be 
at the apex or not, there's no difference.

>	then STOP and RESTART the server.

I don't know how to read that.  By the rules of DNAME, it isn't 
allowed to "obscure" domain names.  So, no, you can't do that.

Should we want to?

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 11:41:25 -0500

>	* So that you can easily correct mistakes.

You can cover that via clever scripting.  Once I added 100's of names 
incorrectly.  I just modified the "add" to "delete" in the script and 
took them out.

But granted, easy to fix would be nice.  I question it is necessary.

>	* So you can build namespace before you remove a DNAME.

But, atomicity of dynamic updates can solve that.  "delete DNAME, add 
these" can be in one step.

>	We obscure as that matched NS and preserved the DNAME semantics.

So you are saying that you implemented DNAME much like (similar?) NS?

---

From: Scott Rose <[email-masked]>
Date: Fri, 08 Feb 2008 14:28:36 -0500

Edward Lewis wrote:
> I don't know how to read that.  By the rules of DNAME, it isn't allowed 
> to "obscure" domain names.  So, no, you can't do that.
> 
> Should we want to?

So when it comes to names under a DNAME - obscure/delete/remove all 
basically mean the same thing (in the protocol) and the only difference 
is in bookkeeping on the server side as to what to do with the actual 
RRs.  Is that the point?

In which case the first paragraph of Section 5.2 can be changed to read:

   DNAME resource records can be added, changed and removed.
   Adding a DNAME RR removes all domain names that would appear
   under the newly added DNAME RR.  The zone data that is
   removed MAY still exist on the local server in some form
   but MUST NOT be used as zone data when responding to queries
   and MUST NOT be included in zone transfer operations.

Then the following two paragraphs of Section 5.2.  Removed can be 
interpreted as obscured, deleted, copied to another file, or some other 
operation - it is up to the implementation.

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 15:14:57 -0500

At 14:28 -0500 2/8/08, Scott Rose wrote:
>basically mean the same thing (in the protocol) and the only 
>difference is in bookkeeping on the server side as to what to do 
>with the actual RRs.  Is that the point?

Not quite.

If you choose the semantics of obscuring...

When a DNAME is put "above" an (explicitly) existing name, subsequent 
searches will cross the DNAME (as if it were an NS - cut point) and 
be processed there.  The obscured name is "dormant." If subsequently 
the DNAME is "removed" then the name in question returns to "live" 
action when it comes to query processing.

If you prohibit the addition of DNAME above an existing name...

You are "forcing" a delete of the below names before the DNAME can be 
added.  Consequently, when ever the DNAME is removed, the old names 
are still gone.

If you make the addition of a DNAME cause an implicit deletion of 
names below...

You effectively create the same as the previous case, but without an 
error condition to check for.  (Like "rm -f" vs. "rm")

>   and MUST NOT be included in zone transfer operations.

Whether to remove or obscure, I am currently neutral.

Obscure is the de jure method for NS changes.  I don't know if it is 
in a specification, I know it is the way it has been implemented. 
I'm going to throw out a faded memory here, the reason for the choice 
was an implementation detail to handle the speed in which memory 
could be jostled when there were changes to zones (not a zone's data) 
on a server.  I think it just worked it's way into being a "given."

Although I have questioned Mark's statements about "we should 
obscure" I mean that to challenge the rationale and not the decision. 
Perhaps it is the right thing to do, but we shouldn't "have to do" it 
just because any one implementation (in this case BIND) has been 
doing it that way.  If there's a reason why we should choose 
removing, we can.

My objection to Mark's message was that the DNAMEbis document is 
consistent (minus the reference to NS processing being 'similar') 
with itself but is not consistent with the NS record semantics.  And 
that's okay I think, unless there's a stronger reason to use the same 
semantics (obscure) for DNAME.

>Then the following two paragraphs of Section 5.2.  Removed can be interpreted
>as obscured, deleted, copied to another file, or some other operation - it is
>up to the implementation.

Well, I don't think it's that simple.  One reason this is not just an 
implementation issue is, what if, an operator has a BIND and a NSD 
server as master and slave.  If one obscures and the other removes as 
a result of a dynamic update add of a DNAME, the two will fall out of 
sync if the DNAME is deleted (even under the same serial number).

I encourage the editors and chair to take the suggestion to open up a 
debate on obscure vs. remove semantics and see what the group thinks.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Feb 2008 20:26:36 +0000

> operation - it is up to the implementation.

i really think this is the wrong approach.  if you try to add a DNAME to
a name that has records or children, you should get a YXDOMAIN error.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 12:50:35 +1100

> these" can be in one step.

	Try changing > 64K of zone data atomically.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 12:54:50 +1100

> at the apex or not, there's no difference.

	There are NS records at the apex.  There are NS records
	that delegate.  The NS records that delegate are the one
	that obscure zone content.  These NS RRsets behave similarly
	to DNAME.  They are the only NS records which obscure data.
 
> allowed to "obscure" domain names.  So, no, you can't do that.

	Yes.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 13:00:23 +1100

> But granted, easy to fix would be nice.  I question it is necessary.

	That's the whole point of obsuring the names and not deleting
	them.  You can turn a add into a delete and restore the zone
	state.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 21:00:48 -0500

>	Try changing > 64K of zone data atomically.

Yeah, it's a lot of work.  But computers are big these days and 
pretty good a tedious tasks.

In contexts that matter, resource limits are not tested.  What we're 
talking about is an extreme situation, a corner case.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Vixie <[email-masked]>
Date: Sat, 09 Feb 2008 02:03:58 +0000

> ... if you try to add a DNAME to a name that has records or children, you
> should get a YXDOMAIN error.

likewise, if you try to load a zone that has any other records at a name
when there is a CNAME or DNAME at that name, or has any children under a
name that has a DNAME or NS, the zone should be rejected.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 21:05:36 -0500

>	Yes.

Why?

What's missing from your answer is a justification.

As it stands now, the WG document says "can't be done."  If you want 
to get consensus for what you want, you need to do some explaining.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Feb 2008 21:08:55 -0500

>At 12:54 +1100 2/9/08, Mark Andrews wrote:

Okay, in our passing messages it struck me that the reason is for 
"recovering from mistakes."

Is that all?

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 13:44:58 +1100

>    but MUST NOT be used as zone data when responding to queries

	Yes

>    and MUST NOT be included in zone transfer operations.

	No.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 09 Feb 2008 14:57:32 +1100

> "recovering from mistakes."

	Errors. Consistancy.  Atomic change.

---

From: Edward Lewis <[email-masked]>
Date: Sat, 9 Feb 2008 09:58:31 -0500

>	Errors. Consistancy.  Atomic change.

Up until last night I was inclined to prefer "obscuring" to "preventing."

By obscuring, I mean the addition of the DNAME hides the other names 
but they stay in the zone's memory.

By preventing, I mean that the attempt to add the DNAME is rebuffed 
if there are names that would be obscured.

The reason is that 'obscuring' is an implicit, unstated action taken 
as the result of another.  Just like the third semantic possible here 
(the addition causes the implicit loss of the would be obscured 
names), there is an unintended consequence.

The "error" we are talking about here is merely the mistaken addition 
of a DNAME at the wrong owner name or mistaken in the sense that the 
operator forget there was a name somewhere.  In this case, obscuring 
is better than removing.

But prevention is even better.  If the operator tries to add the 
record and gets an error, the mistake is caught in live time, 
obvious, concrete.

(Note that the writing sounds like dynamic update, but this goes for 
zone load too.)

When it comes to to consistency, again I think that obscuring is the 
wrong choice, as in the question in a previous message.  Are the 
obscured in the zone transfer?  If they are, it's pretty much a 
waste, isn't it?  I really think we want to avoid allowing for (more) 
obscured elements in the DNS.

Atomic change.  I don't understand how that relates.  I'd guess 
though that any action that has an intentional unintended side effect 
would be detrimental to atomicity because of the potential shear 
volume of actions that might ensue.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Sun, 10 Feb 2008 09:56:17 +1100

> obscured elements in the DNS.

	No they are NOT obscured in zone transfer.  Records obscured
	by NS cuts are NOT obscured by a zone transfer either.

	NS and DNAME records are both forms of delegation.  NS to
	a different zone, DNAME to a different namespace.  NS and
	DNAME will both obscure and reveal record by there addition
	/ removal.  The obscured records are both transmitted in 
	AXFR / IXFR.

	Mark

---

From: Wouter Wijngaards <[email-masked]>
Date: Mon, 11 Feb 2008 17:09:14 +0100

Edward Lewis wrote:
| At 14:57 +1100 2/9/08, Mark Andrews wrote:
|
|>     Errors. Consistancy.  Atomic change.
|

| But prevention is even better.  If the operator tries to add the record
| and gets an error, the mistake is caught in live time, obvious, concrete.

I think preventing, as in return rcode YXDOMAIN(or another one) when
trying to add a DNAME that obscures/stands over lower domain names is
better. These are no unintended consequences to the operator's actions.
It is a simple concept, and (I believe) implementation as well.

I do not know how it stands to current implementations (well, BIND seems
to do obscuring).

NSD, refuses to load *files* with DNAMEs that obscure content.
But accepts zone *transfers*, and could possibly act pretty strange with
such a transfer (answering queries for obscured data, but using the
DNAME to synthesize for nxdomains; and after a restart refusing to
reload the zone file).

The problem of trying to DNAME a huge zone, I think is something where
you need to use an AXFR or IXFR for that update. Any very large update
for a very large zone will be > 64 kb in any case.

Best regards,
~   Wouter

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Feb 2008 08:47:22 +1100

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Edward Lewis wrote:

	YXDOMAIN becomes overloaded.   Is it the prerequisite or
	is it the update section that failed?  YXDOMAIN is not
	an appropriate rcode.
 
	Mark

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Feb 2008 22:54:26 +0000

> 	is it the update section that failed?  YXDOMAIN is not

damn.  that's right.  the update section succeeds or fails silently -- all
zone content related errors have to be the result of failed prerequisites.
adding a DNAME to an existing name (one which has children or records) would
fail silently under this proposal.

so, we'd have to express this as a "name does not exist" assertion, which
would only hold true if the prospective DNAME owner has no children and no
records.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Feb 2008 10:16:19 +1100

No.

That would change it from "DNAME does not exist" to "DNAME could
exist".  Also is that before or after the UPDATE section is processed?
Delete all at node, add DNAME at node.

Do you want to change "NS does not exist" to "NS could exist"?  The
later would require walking the sub tree looking for non-glue.

DNAME has basically the same probles as NS when it comes to adding
one to a zone.  The same solutions are equally applicable.

Consistancy is important.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Feb 2008 23:47:23 +0000

> > would only hold true if the prospective DNAME owner has no children and no

well, you're right, but not for the reason you gave.

> That would change it from "DNAME does not exist" to "DNAME could exist".

that's not the problem.  the problem is that there is no assertion that does
what we want.  RFC2136 2.4.5 says:

   2.4.5 - Name Is Not In Use

   Name is not in use.  No RR of any type is owned by a specified NAME.
   Note that this prerequisite IS satisfied by empty nonterminals.

   For this prerequisite, a requestor adds to the section a single RR
   whose NAME is equal to that of the name whose nonownership of any RRs
   is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
   must be specified as NONE.  TYPE must be specified as ANY.  TTL must
   be specified as zero (0).

the "is satisfied by empty nonterminals" mystifies me, but it means this
is not the same as "DNAME can be added".  

> Also is that before or after the UPDATE section is processed?

in [ibid] we see:

   2.4 - Prerequisite Section

   This section contains a set of RRset prerequisites which must be
   satisfied at the time the UPDATE packet is received by the primary
   master server.   [...]

> Delete all at node, add DNAME at node.

that won't do.  a DNAME can't be meaningfully added if there are children,
so, the empty nonterminal case has to be sorted.

> later would require walking the sub tree looking for non-glue.

yes, i want that also.  but we're talking about DNAME at the moment.

> Consistancy is important.

in that case we should fix the NS case also.  a new UPDATE prerequisite
that said "no records no children" would do it.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Feb 2008 11:23:12 +1100

>    satisfied at the time the UPDATE packet is received by the primary

	I know when the prerequite have to be tested.  All the other
	UPDATE changes are tested as the UPDATE record is processed.

	What do we do if the pre-requisite succeeds.  A record is
	added below then a DNAME is added?  What do we do if the
	DNAME is then removed in the same update?
 
> so, the empty nonterminal case has to be sorted.

	I got the example wrong.  The point is however by the time
	the DNAME addition is processed the condition have potentially
	changed.
 
> that said "no records no children" would do it.

	You need three tests.

	No children. DNAME
	No children but glue. NS
	No child records at node. NS

	If you are converting a zone from a copy to a DNAME you
	want the DNAME to go in first then the records that are
	obscured to be deleted.  This removes the NXDOMAIN race.
	Note you can't always delete all the obscured records in a
	single update.

	There are lots of place where the DNS RFC's assume that
	large changes can happen atomically *and* in small amounts
	of time.

	e.g.
	     Converting a unsigned zone to a signed zone and still
	being able to processes multiple updates per minute.

	UPDATE just can't deliver "large and atomic".  At some point
	changes need to be made so that it can.  Obscuring/revealing
	the content on DNAME allows for "large and atomic" in both
	directions.

	Mark