[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