Subject: Resolution of the DNAME via dynamic update issue

From: "Scott Rose" <[email-masked]>
Date: Wed, 13 Feb 2008 10:31:40 -0500

Resolution of DNAME in dynamic update issue

Issue:  What should happen when attempting to add a DNAME RR via dynamic
update?

Possible resolution 1:  Return error code.  Either overload YXDOMAIN or
allocate a new error code for this case (or this and NS case):  OBSURENAME
error (or something else):  meaning that if the RR is added; it will cause
one or more other RRs at that name or below that name to become obscured.

From Paul Vixies original comment:
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00046.html

http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00283.html

Then expanded after discussion that YXDOMAIN is not the correct error code
on Monday Feb 11:

http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00321.html

Possible resolution 2:  Accept and obscure names.  From Mark Andrews post:
http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00247.html

Allow dynamic updates of DNAME to obscure names below the added name.  Those
obscured names are transferred in AXFR/IXFR operations but are not used in
the resolution process.   A dynamic update message adding a DNAME RR at a
name that already has RR’s of some other type would still generate an error
(must be delete/add operation).

In addition, zone files with names below a DNAME still load successfully but
a server MAY wish to log an error to log files to alert administrators.

Please indicate which you prefer (or give an alternate).

--
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: Paul Vixie <[email-masked]>
Date: Wed, 13 Feb 2008 17:02:20 +0000

> Possible resolution 1:  Return error code.  Either overload YXDOMAIN or ...

marka pointed out to me that YXDOMAIN is a response to a prerequisite not
an update action, and we have no way to express "name must have no children
and no records" in the current prerequisite encodings.  thus, this idea will
not work unless we add another prerequisite encoding, which i think is the
wrong approach.

> Possible resolution 2:  Accept and obscure names.  ...
> 

of the two possible resolutions given, i prefer #2.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 13 Feb 2008 14:04:44 -0500

At 10:31 13/02/2008, Scott Rose wrote:
>name that already has RR's of some other type would still generate an error

<no-hat>

For completeness
Possible resolution 3: Accept and delete zone contents below the DNAME/NS added

This one has been mentioned.

Side effect of #2
         can name/RRset below DNAME be deleted ?

         can name/RRset below DNAME be modified ?

         can name/RRset below DNAME be added  ?

Special case of #2
zone example.com.
         SOA .....
         NS foo.example.com.
         NS bar.some-other-zone.tld.
foo     A a.b.c.d

Attempting to add "example.com. DNAME example.org."
This obscures foo.example.com.
Should this update be allowed or rejected as foo.example.com will
never be visible ?

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Feb 2008 19:42:52 +0000

> This one has been mentioned.

i think #3 is a really and terribly bad idea.

>          can name/RRset below DNAME be added  ?

yes.

> Should this update be allowed or rejected as foo.example.com will

i think this level of semantic control is unrealistic.  it begs questions
about DNAMEs to parents, DNAME loops, CNAME loops, and similar.  proposal
#2 says UPDATE shouldn't enforce these limitations.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Feb 2008 15:10:16 -0500

The reason I prefer #1 is that #2 and #3 have a shared feature of 
"unintended consequences."

Okay, let's now drop #3 from consideration.

The problem with #2 is that it means possibly many names are impacted 
as a side effect without notice.  The very error that is easily 
recoverd from (being able to undo the obscuring) is the error enabled 
by #2.  (It only saves itself from itself.)

I'd prefer to allocate a new error code.  Yes, this means more work 
for the implementations, but protocols are supposed to be all about 
communications, the clearer the better optimized for performance. 
(Oh, and I'm against overloading the YXDOMAIN because that wouldn't 
be clear.)

I favored obscuring until I realized that it was an unintended consequence.

I do have a question for the group.  When we say NS records obscure 
names below them in the same zone, where is that planted in the 
specs?  Was it something that was coded and we just stuck with it?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: [email-masked] (Andreas Gustafsson)
Date: Wed, 13 Feb 2008 22:55:07 +0200

> Issue:  What should happen when attempting to add a DNAME RR via dynamic

I prefer resolution 2, "Accept and obscure names", as it is consistent
with the existing dynamic update behavior with regards to NS records
(RFC2136 section 7.18).  And to be fully consistent, perhaps we should
use the same terminology as that section and say "occlude" rather than
"obscure".

> A dynamic update message adding a DNAME RR at a

This error case is analogous to the existing error case of adding a
CNAME to a name having other data, and for consistency, it should be
dealt with in the same way, by ignoring the update RR.
-- 
Andreas Gustafsson, [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Feb 2008 08:24:12 +1100

> I favored obscuring until I realized that it was an unintended consequence.

	Any change can have unintend consecquences.  Your wanting
	to make the zone contents disappear before the update has
	unintended consequnences.  There *will* be a window where
	names that used to exist won't and then will exist once the
	DNAME is added.

	There will also be a window between when a DNAME is removed
	and the namespace restored.

	NXDOMAIN is a fatal error for mail, etc.

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Feb 2008 16:43:07 -0500

>	names that used to exist won't and then will exist once the

What I meant by unintended consequences is that when occluding the 
names, the status of names are changing without an explicitly 
communication.  If the introduction of a DNAME is prevented because 
there are names in place and must be explicitly removed first, then 
all the changes are explicitly communicated.

>	and the namespace restored.

How common is the use case of a DNAME being introduced and then 
withdrawn on top of an otherwise stable tree structure?  I don't see 
what this is "solving for."

>	NXDOMAIN is a fatal error for mail, etc.

I don't understand why this is mentioned.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Feb 2008 09:34:53 +1100

>          can name/RRset below DNAME be deleted ?

	yes.  can update delete a name/RRset below a delegating NS?  yes.
 
>          can name/RRset below DNAME be modified ?

	yes.  can update modify a name/RRset below a delegating NS? yes.
 
>          can name/RRset below DNAME be added  ?

	yes.  can update add a name/RRset below a delegating NS? yes.

> Should this update be allowed or rejected as foo.example.com will

	allowed and will be visible if DNAME is removed.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Feb 2008 09:51:21 +1100

> I don't understand why this is mentioned.

	Because the only other choice is to make names DISAPPEAR
	then REAPPEAR as you DESTROY/REBUILD the namespace below
	the DNAME.

	zone with lots of content beneath new DNAME location
		|
	 *** LOTS OF NXDOMAINS ***
	     DESTROY
		V
	zone with not content beneath new DNAME location
		|
	 *** LOTS OF NXDOMAINS ***
		V
	zone with DNAME

	or

	zone with DNAME
		|
		V
	zone with not content beneath old DNAME location
		|
	 *** LOTS OF NXDOMAINS ***
	     REBUILD
		V
	zone with lots of content beneath old DNAME location
	
	Mark

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Feb 2008 22:01:46 -0500

>	zone with lots of content beneath old DNAME location

Still not getting the point.  How often is this a concern?  How often 
would a zone be run this way?  I understand the scenario, the 
question is, when in operations would this be a concern?

And what does that have to do with mail?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Feb 2008 14:14:49 +1100

> question is, when in operations would this be a concern?

	Does it really matter how often?  All we need to realise
	as engineers is that it happens with zone which are being
	managed via dynamic update.  Such changes should happen
	with having to shut the server down, manually edit the zone
	and then reload it.  Often the people that are managing the
	zone don't have access to do this.  Pick any of the dynamic
	dns service providers for examples of where manual changes
	are not available.  You can create the zone, delete the zone
	and the rest is done via update.
 
> And what does that have to do with mail?

	You can have mail lost in the intermediate stages.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Feb 2008 14:29:17 +1100

> all the changes are explicitly communicated.

	Pre-requisites are what prevent unintended consequences
	in UPDATE.  If we don't have a appropriate pre-requisite
	we need to invent one.

	Mark

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 15 Feb 2008 12:58:01 +0000

> dealt with in the same way, by ignoring the update RR.

	Since when is a DNAME not allowed _at_ a name that already
	has RR's of some other type (except CNAME, of course)?

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 15 Feb 2008 15:21:03 +0200

> 	has RR's of some other type (except CNAME, of course)?

Sorry, I responded to Mark's comment without checking his assertions.
You're right, DNAME is allowed at a name that has other RRs (except
CNAME or another DNAME).

What I should have said was that cases that actually _are_ errors,
such as attempts to add a DNAME to a name already having a CNAME or
another DNAME, should be dealt with by ignoring the update RR, since
that is how RFC2136 generally deals with errors (as opposed to
unsatisfied prerequisites, which cause error responses to be sent).
-- 
Andreas Gustafsson, [email-masked]

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 15 Feb 2008 15:07:55 +0000

> Sorry, I responded to Mark's comment without checking his assertions.

	Sorry, I responded to yours without looking back along
	the thread.

> unsatisfied prerequisites, which cause error responses to be sent).

	Makes sense.

	Best regards,

	Niall O'Reilly