Subject: Re: Resolution of the DNAME via dynamic update issue

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

> 
> > At 9:51 +1100 2/14/08, Mark Andrews wrote:
> > 
> > >>>	NXDOMAIN is a fatal error for mail, etc.
> > >>
> > >>  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
> > 
> > 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?
> 
> 	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

	without

> 	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.
> 
> > -- 
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > 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.
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
-- 
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: Wouter Wijngaards <[email-masked]>
Date: Fri, 15 Feb 2008 11:39:26 +0100

Mark Andrews wrote:
|>> 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?
|> 	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
|
| 	without
|
|> 	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.

So, I understand the argument is that the obscure option provides a
feature that the error-code option does not provide. The obscure option
provides a way for zone operators to leverage a DNAME to make large
changes to the zone, atomically, using dynamic update.

The error code option argument is that it doesn't have obscuring, which
is then an unwanted feature. A clean way to do this is to have a good
precondition, or proper errorcode to return.

~From the discussion I gather that NS records can also be leveraged to
make large atomic changes using dynamic update.

Leverage procedure:
1) copy current zone contents to a remote server or zone
2) set a NS or DNAME to point to that server or zone. Users get same
content but via an indirection
3) build up large change using dynamic update requests to obscured records.
4) remove NS or DNAME, exposing the covered data atomically.

To be honest, I never heard of this feature before. I can imagine it
being useful. I hope I rendered the procedure correctly here.

The fact remains that non dynamic update servers do not expect obscured
data in zone transfers or zone files. There is no RFC telling them about
it. That would mean that obscured data requires all servers that support
AXFR/IXFR to start supporting dynamic update features to implement
covered data features. I highly doubt that existing AXFR/IXFR but not
dynamic update servers do so.

Best regards,
~   Wouter

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Feb 2008 16:21:44 +0000

> feature that the error-code option does not provide.

that's not my argument.  my argument is, there is no way to get that
error code at the moment.  we would have to define a new kind of UPDATE
prerequisite, to which a possible response would be YXDOMAIN.  i think
we should avoid defining a new kind of prerequisite to handle DNAME,
and that's my argument for why the obscure option is better.

---

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Andrews wrote:

	That assumes you *have* another server.  It can't
	be the existing server or the zone will be found via
	normal delegation.

> 4) remove NS or DNAME, exposing the covered data atomically.

	Say you have SOA + NS + DNAME and you want to remove the
	DNAME and have a complete zone.  You can't replace the
	DNAME with a NS RRset.
 
> it.

	There will be if we tell them in this document.

> That would mean that obscured data requires all servers that support

	And no one has complained in the last 8 years about BIND 9
	doing it.  It is a rarely used option at this point.

	When we look at RFC's for reveiw, we are supposed to look at
	what we got wrong and repair it.
 
> Best regards,
> ~   Wouter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> 
> iD8DBQFHtWvdkDLqNwOhpPgRAnKYAKCTyazoO3SaSIMZs2czb6aRNirTHACgrnVp
> mRZvXzGfcy/txlFT178aIWE=
> =ZTB4
> -----END PGP SIGNATURE-----