Subject: Re: draft-stjohns-secure-notify-00.txt

From: Mike StJohns <[email-masked]>
Date: Mon, 30 Jun 2003 17:03:01 -0400

At 16:39 6/30/2003, Andreas Gustafsson wrote:
>In draft-stjohns-secure-notify-00.txt, M. StJohns writes:
> >   In fact, best practice requires that a zone be served by at least one
> >   server that can be referenced by a name not within that zone.
>
>My interpretation of RFC2182 is that a zone should have at least one
>server on a geographically and topologically distinct network, but I
>see no requirement that it be referenced by a name in a different
>zone.

yeah - I can actually read 2182 either way - specifically section 6 
discussion of the selection of secondaries.  I'd be interested in 
understanding what others think is best practice here.  The reason I like 
the name diversity constraint is because it provides one more resolution 
path to the delegated zone, even if the glue records in the parent are 
messed up or more probably, missing.

> >   The parent zone MUST verify the names pointed to by the NS are
> >   resolvable, that at least one name points to a server not named in
> >   the child zone, and that it has glue A records for any server named
> >   in the child zone. [Q:  Does this make sense, or is it better to just
> >   trust the child?] If these conditions are not satisfied, the parent
> >   server MUST NOT install the new records, and MUST log the problem
>
>I don't think this makes sense.  Whether the best practice is to have
>a server in a different zone or just on a different network, it is
>just an operational recommendation and not something that should be
>enforced as part of the protocol.

To be clear, your issue is with "that at least one name points to a server 
not named in the child zone" and not with the rest of it as above?  Yeah - 
this might either be a) removed, b) turned into a policy configuration item 
(e.g. something the parent zone wants to enforce on the child - in which 
case this section become MAY) or c) left as a MUST.  My guess is that 
either a or b is probably appropriate given our off line discussion.

>--
>Andreas Gustafsson, [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: [email-masked] (Andreas Gustafsson)
Date: Mon, 30 Jun 2003 17:53:14 -0700 (PDT)

Mike StJohns writes:
> not named in the child zone" and not with the rest of it as above?

That was the specific issue I wanted to address, but since you ask, I
don't think the rest of the paragraph is a good idea, either.  It
seems to me that the parent refusing the update would leave an NS
and/or DS inconsistency that in itself is more harmful than the glue
inconsistency the parent is reacting to.
-- 
Andreas Gustafsson, [email-masked]

---

From: Mike StJohns <[email-masked]>
Date: Mon, 30 Jun 2003 21:15:43 -0400

>inconsistency the parent is reacting to.

Yeah -- the right answer might be to conditionally accept the update, but 
wait for approval from a human.

On the other hand, there are some meta protocol things that should take 
place.  For example, if you're deleting a server, you need to update the NS 
records to delete the server, then confirm they've been updated before 
taking the server out of service.  Operationally, there should never be 
wholesale changes - the adds/deletes/changes are generally 3 phase 
commits.  I've got a set of slides on how to do DS updates that I can 
provide - pdf format that describes some of the broader process issues.

There will be some inconsistency, but that can be managed somewhat 
automatically with the server flagging the exception points.

Actually, now that I've thought about it, rejecting records where the 
servers aren't routable/reachable, where the extra-zone names can't 
resolve, and where the glue records aren't correct is probably more correct 
than accepting them.  As long as the check can be done as part of the 
notify transaction and the child is given the rejection then, there 
shouldn't be any consistency issue (or rather no issue worse than what 
happens currently?).