A couple of comments on draft-kurtis-tld-ops-00.txt.
I think the high-order bit right at the beginning of the writing
process would be to consider whether it would be best to revise and
generalize BCP40 (the root server operational requirements), to also
include TLD operations, or to write a separate document about them.
Based on quick reading of this draft, and taking a look at BCP40, I think
having just one document might make sense as I believe many operational
requirements are common, and BCP40 could probably use a brush-up. The key
point would be, however, whether there are folks interested in revisiting
the root server doc or not. In any case, I could live with either way, but
if this becomes a separate document, I think the overlap with root server
ops doc would be significant, which would be a bad thing.
substantial
-----------
5.1.4 Protocol requirements
==> I was a bit surprised that the doc didn't say more about specific DNS
protocol features which should or should not be required. For example,
EDNS0, RFC3596 [xxx: or the one about being able to handle unknown record
types], support for v6 record types, ...
Recursion: The slave-service should not be providing recursive name-
service.
==> "should not" in lowercase leaves a bit open how strong the
requirement/recommendation really is. For TLD servers, my hunch is that at
least for recursion, we'd want to sent an even stronger signal, like "must
not"
semi-editorial
--------------
Redundant power feeding: The servers should be located so that a
single interrupt of power into the site where these are located
does not effect the servers, or the network infrastructure
servicing the slave-servers.
==> the doc doesn't mention how long redundant power feed/cooling should (in
minimum) be able to sustain the service. It probably doesn't need to pick a
number, but maybe it should recommend that whoever decides the requirements
in the specific scenario needs to decide on that as well.
Backups: The slave-server systems should be backed up regularly.
This includes zone data, system configurations and other data and
configurations needed for a quick system recovery in the case of a
failure. The procedures and systems for backup should be tested
for resteration regularly.
==> the last sentence probably requires a reword; "tested for resteration
(sic)" sounds a bit awkward.
10. References
==> these need to be split
5.2.1 Dimensioning the infrastructure
The network infrastructure should be dimensioned to handle a network
load of three times the normal load, measured in packets-per-seconds,
pps. The infrastructure should also be able of dropping packets at
line-rate in order to protect the service in the case of an attack.
What "line-rate" corresponds to in absolute numbers is depending on
local conditions, such as affordability, need and uplink speeds.
==> there seems to be some overlap with Software requirements (5.1.3):
capacity here, or was 5.1.3 talking about the capacity of the DNS server
software and this section about the capacity of the host or the infra in
general?
editorial
---------
there were about a couple of dozen clear typos or other editorial things I
noted but didn't see worth reporting here. Another editorial pass should
clear most of these.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
