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

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Jul 2003 02:55:11 -0000

Mike StJohns writes:
> 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.

You have the situation backwards. Forcing the resolution process to go
through extra servers doesn't help reliability; it hurts reliability.
Gluelessness is the single most common source of DNS lookup failures.
(If you don't have enough DNS experience to realize this, why are you
writing DNS documents?)

Best practice is to have completely glued names everywhere. VeriSign's
software used to have trouble with this practice, but they recognized
their mistake and fixed it.

This has nothing to do with the physical location of servers. Sites
should, of course, have their DNS servers spread just as widely as their
HTTP servers, SMTP servers, etc.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
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: Robert Elz <[email-masked]>
Date: Tue, 01 Jul 2003 17:51:35 +0700

Date:        Mon, 30 Jun 2003 17:03:01 -0400
    From:        Mike StJohns <[email-masked]>
    Message-ID:  <5.2.1.1.2.20030630165223.026f4008@localhost>

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

For what it is worth, and this might almost be a first time in history,
I agree with djb's comments on this.   I won't repeat those, but I would
add that if you can't trust the parent zone to have your delegation
configured correctly, you may as well give up and go someplace else
completely - adding a server that has a name somewhere else isn't very
likely to help (sure, you can craft a case where it actually solves an
imagined potential problem, but in reality...)

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

Here, I agree with your and not Andreas - parent zone admins should do
their utmost to ensure that the child zone is correctly configured before
updating delegations - it is the only tool that exists to cause people
managing the delegated domains to get things right.

But this only extends to the technical requirements, "good policy" can't
be enforced (shouldn't be anyway), so even if it were reaosnable to attempt
to discover the attachment points of different servers, that wouldn't
be reasonable for the parent to do.   Checking that the servers are
properly configured and answering correctly however it can easily, and
should always, do.

kre

---

From: Mohsen Souissi <[email-masked]>
Date: Thu, 10 Jul 2003 16:26:10 +0200

Hi Mike,

Please find my comments below.

On 30 Jun, Mike StJohns wrote:
| 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.

==> I believe that updating Parent DS Record and updating Parent NS
Records for a given child are completely different. Using the same
NOTIFY to either update DS and/or NS records at the Parent zone adds
much more complexity on the Parent side.

It is not necessarily the role of the Parent master server to check
whether the new NS's are resolvable or not. As mentioned Jim Reid,
some TLDs check zone configuration on authoritative nameservers for
the child zone before creating/modifying the child NS
delegation. Checking DNS configuration is for some TLDs far more than
just checking whether the NS names are resolvable or not. Just have a
look at http://www.zonecheck.fr and you see the numerous
mandatory/optional tests one can enable for checking a DNS zone. Once
again, I agree with Jim when he says that how NS's are updated at the
Parent is rather related to the Parent's policy.

My humble suggestion is to deal with only one feature at a time if we
want to add some extra semantics to the NOTIFY message. I think that
the DS update should be simpler.

Regards,

Mohsen.