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

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

At 17:25 6/30/2003, Loomis, Rip wrote:

> > > >   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
>My interpretation of it, upon re-reading, still matches Andreas.
>
> > I'd be interested in understanding what others think is best practice
> > here.
>I think that the "name diversity constraint" (as you refer to it) is
>a great idea to suggest, but not something that even rates a SHOULD
>in terms of an IETF document.  It's not realistic for many folks...
>anyone who happens to have umptyscrumpty.com should now also have
>a nameserver for that zone living under .net or another TLD???
>Please demonstrate the clear overall benefit...

Nope - if I'm running zone foo.com, what I mean to say is that I'll need to 
have a NS record pointing to a host that does not end in foo.com - that's 
all.

Benefit?  Let's assume for foo.com at master.foo.com, secondaries at 
secondary.foo.com and foreignsecondary.bar.com.  There will be NS records 
for master.foo.com, secondary.foo.com and foreignsecondary.bar.com and 
hopefully glue records for the first two.  In the event that the glue 
records get screwed up, there's still the possibility of completing the 
resolution by following the delegation chain for bar.com which has its own 
glue records.

Think of it as one further way of reducing fate sharing.

> > > >   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, [...]
>
>I recommend (a), removing that requirement.  I don't think that the
>wording makes sense (a server not named in the child zone?  Do you
>really mean a server that is not "under" the child zone, or one that
>is not the RHS of an NS RR in the child zone, or what?) but I think
>that you're trying to spell out a MUST based on the item above which
>I don't think even rates a SHOULD.

Actually, I did mean "a server not named in the child zone".  For a 
delegation for "foo.com"  "secondary.foo.com" "another.level.foo.com" are 
all named in the child zone "foo.com".  "myhost.bar.com" is not.

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