[dns-operations] requirements for TLD servers
Jim Reid
jim at rfc1035.com
Mon Mar 22 22:21:14 UTC 2010
On 22 Mar 2010, at 19:00, Jay Daley wrote:
> the random comments of the ICANN CEO highlight the need for this
> more than ever so that we have an independent standard we can be
> assessed against.
Indeed. And we can expect more of these kinds of things coming from
all sorts of quarters. That's one of the reasons why I'd like to see a
reworked and up to date version of RFC2870. It's needed. And if the
technical people don't do it, others will come up with multiple
divergent versions of something to fill that space.
> However, there are some differences of opinion on this that are so
> fundamental we may never be able to resolve them.
I doubt it. Is there anything in RFC2870 that anyone would reasonably
disagree with? IMO the main points in a new requirements doc should be
the usual motherhood and apple pie stuff: strict access controls; no
SPOFs; define processes for trouble ticketing; monitoring and
escalation; proper change control, test and audit procedures; defences
for DDoS attacks; suggested SLAs; etc, etc. It wouldn't define these
things and shouldn't define these things. For example, the document
would discuss the characteristics of a good monitoring system without
laying down the law about the One True Way how monitoring MUST be done.
> One good example is "for TLD x should all the nameservers be in-
> bailiwick or not."
I'm not sure that question is appropriate for revising the sorts
operational criteria discussed in RFC2870. If it was, I think it would
be reasonable to mention the advantages and disadvantages of in-
bailiwick delegations without making a decision either way. Unless
there was a consensus behind one view. Which as you say seems
unlikely. Even so, it would be good to capture these sorts of issues
so that if/when they get revisited in the future, the motivations
behind today's conclusions and how they were arrived at get remembered.
More information about the dns-operations
mailing list