Re: draft-manning-dnssvr-criteria-01.txt

[Robert Elz <[e-mail]>]

    Date:        Mon, 6 May 1996 14:53:57 -0700 (PDT)
    From:        [e-mail]
    Message-ID:  <[e-mail]>

    -02 was some editorial changes that Paul had asked for
    and Brians excise of the draft nature of the docuement.

Did it ever appear in the I-D directories?  I don't see it.


    Abstract
    
    This draft proposes criteria for name servers and their environments that 
    will support zones for root domains. It is expected that the machines 
    running root name service will be different than the machines 
    running TLD name service. Although there are differences, the same basic
    criteria may hold. For example, it is expected that TLD servers may 
    field more queries and the root servers may be more concerned with cache 
    pollution. There are some feelings that if you want to (and have the
    resources to) run a high quality nameserver anywhere in the DNS hierarchy, 
    these criteria may be considered.

I kind of understand why, but this has gotten a bit wishy washy...
Its also more than the abstract, there is stuff stated there that
doesn't appear elsewhere.  The abstract is supposed to be for
people who can't be bothered reading the entire doc, or who want
to decide if they should.   When I'm going to read something, I
almost always skip it - like I did here.   It was only when your
message indicated things existed that I hadn't seen that I went
back and read this part, and found the missing bits.   You should
move the substance someplace else - or retitle this as
"Introduction" and create a new (real) abstract - which is probably
just about 3 lines.

    Design Goals:
    
    Define a basic set of requirements for high availablity name server 
    systems.  Make them all objectively verifiable.

OK, now TLDs are gone.

    Selected Operational Qualifications:
    
    1. Modern BIND or equivalents (if any exist).

This is probably better expressed without reference to
BIND, as "Latest release qquality versions of nameserver software"

    The upgrade process will be coordinated with the zone-master staff
    and will occur within 96 hours of initial notification. Zone-master
    senior staff will specify the software and version(s) that will
    be run in a particular zone.

I assume the body of this is directed at people running secondary
servers.  It doesn't say so, and probably should.   96 hours is
very short though, for many people this kind of mod only happens
weekends, when the consequences of a failure are smaller.  Weekends
are more than 96 hours from mondays...

    3. Dedicated host. 
    No user accounts, just the operations & admin or root account.
    No other services except NTP. (remove telnet, SMTP, FTP etc).
    This requires support to be from the console or other specified
    secure channel. It is expected that one-time tokens will be used
    for authentication.

This is still not explained.
    
    4. Singly homed (only one interface).
    Name service should always answer out the same interface as requests
    come in on. Also, delegations will usually list a single A RR, so there
    should only be a single canonical name.

This is still not explained.

    7. Sufficient resources. 
    Each system must be able to support a transaction rate of 1200/sec and
    mean time to respond of 5 milliseconds per transaction as a baseline.  
    There should be enough extra resources available to support a 50% growth
    per month in the number of transactions per second without affecting the
    response time. Note that these numbers involve system selection and 
    available infrastructure bandwidth.

50% a month is high, wasn't it 15% a while ago (with no mention
of a month)?   The internet doubles (so its said) every 8-12 months.
50% a month is almost a total of a 130 fold increase in a year.
That's immense, even the internet isn't doing that!   Make the
number a little more reasonable.  Even 20% a month is 9x in a
year, 10% is probably a safer (and more reasonable) number, that's
just over 3 times growth over a year.   (now you know why the
maffia like to charge the interest rates they do on loans...)

    8d. an escalation/delegation list that has at least three levels of
    hierarchy.

this is still meaningless for any server, unless you're
presupposing some kind of guaranteed staff and order of
processing queries.   At the very least you need to state all
the assumptions and rationale here.
    
    9. Named.boot file will specify:

Again, it would be better if this could be expressed in more
generic terms.  Or perhaps change the title to

	Proposed technical Criteria for [Major] Name Servers running BIND

Also, for each point, say what the beenfit is - why you want it
this way.
    
    (#) BIND 4.9.3-R-P1 01may96

Definitely don't include that, it will be out of date soon.
    
    10. Network and name server outages will be reported.

You're still asking for too much here, there's not even a guarantee
that the DNS admin 9or staff) will ever even learn about all net
outages (even now and then a router crashes and reboots, in about
a minute, most people barely even notice - but it is an outage).

    12. Address PTR points (only) to ?.root-servers.net, not a "local" name.

Now this one is very very very specific to root servers only.
All the rest is attempting to be generic to any major DNS server.
Does this mean I should have the PTR record for munnari changed to
be X.root-servers.net ?

    Security considerations of this memo
    
    None.

Surely this isn't right, security is appraently the reason for
some of the recommendations.   How can there be no security
implications?

kre