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

From: Jim Reid <[email-masked]>
Date: Tue, 01 Jul 2003 09:50:06 -0700

>>>>> "kre" == Robert Elz <[email-masked]> writes:

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

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

Agreed. But even this is not enough. Even in the TLDs that do have
these checks, entropy takes over eventually. ISTR Patrik Faltstrom's
survey of .se which showed 20-25% of the .se delegations were broken
even although they were checked and found to be correct at the time
the delegations were made. So the question becomes one of policy. Who
will be the DNS delegation checking police? What do they check? And
how do they deal with offenders?

--
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: Mike StJohns <[email-masked]>
Date: Tue, 01 Jul 2003 13:25:55 -0400

OK - the non-child named secondary is out.

Let's try and bring this back to the question that I really want answered.

Assuming that a parent will update NS records based on what a child sends 
it under the secure notify (let's not argue this assumption for now),  what 
is a reasonable set of checks the parent should apply to the data sent to 
it by the child?

Select one or more.
a) None - trust the child to do what it is supposed to and just update the 
records when told to do so.
b) Check to make sure the systems named in the NS records can be resolved 
(e.g. either glue records exist or other resolution)
c) check...can be reached
d) check... are serving the child zone
e) Check that there are at least 2 distinct servers listed in the NS 
records (e.g. resolve to different A records?)

Note that the child will be checking to see if the parent actually 
publishes the new records and will repeat the notify if the new records 
aren't published after some period of time.  Should the child zone, 
regardless of any secure notify capability, check its delegation status at 
the parent periodically?  (Actually, probably a topic for another thread, 
but could add this to the secure notify document as the code to do secure 
notify will have to do this in part).

---

From: Robert Elz <[email-masked]>
Date: Wed, 02 Jul 2003 04:23:23 +0700

Date:        Tue, 01 Jul 2003 13:25:55 -0400
    From:        Mike StJohns <[email-masked]>
    Message-ID:  <5.2.1.1.2.20030701130715.024b0168@localhost>

  | Select one or more.

(b) (c) & (d).

(e) would be nice, but is very difficult to do in a meaningful
way, and I'm not sure that doing half a job is worth it - that is,
really determining for sure that there are 2 servers is very hard
to accomplish, just knowing that there are 2 different A records
isn't really sufficient, so I probably wouldn't bother with that
one.

  | Note that the child will be checking to see if the parent actually 
  | publishes the new records and will repeat the notify if the new records 
  | aren't published after some period of time.

One would hope that if the child is automating a delegation request, that
it is also checking to make sure that all the servers are functioning
correctly, before sending a request to the parent.   We cannot, of course,
depend upon that for anything, but operationally, it is what should be
happening, so the parent getting lots of repeated update requests which it
is just refusing to carry out shouldn't be normal.

  | Should the child zone, 
  | regardless of any secure notify capability, check its delegation status at 
  | the parent periodically?

Most likely, but it isn't clear to me what it should do when it finds itself
no longer listed.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Jul 2003 09:10:40 -0000

> d) check... are serving the child zone

Please don't use vague words like ``serving.'' Very few people know what
service is actually necessary for interoperability. The average parent
script writers certainly don't; I've seen them try TCP queries in 
violation of RFC 1123, treat the SOA suggestions from a particular book
as requirements, demand root addresses from the child servers, et al.

> (e.g. either glue records exist or other resolution)

This is a better suggestion, because it's hard for parent script writers
to screw up. They'll use gethostbyname() rather than trying to write
their own resolver. But it's important to emphasize that glue is allowed
and encouraged, even though it means that gethostbyname() will fail.

> records (e.g. resolve to different A records?)

If tiddlywinks.dom consists of a single machine running an HTTP server,
an SMTP server, and a DNS server, then demanding a second DNS server is
a really bad idea: it adds expense while decreasing reliability. See
http://cr.yp.to/djbdns/third-party.html.

DNS servers should be spread as widely as the other servers at the site.
For some sites this means DNS servers all over the globe. For others it
means a grand total of one DNS server. ``Two different A records'' is a
wild oversimplification, horribly inadequate for some sites and actively
counterproductive for others.

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