Discuss mailing list

[Julian DeMarchi <julian AT jdcomputers.com.au>]

On 28/04/14 15:09, Jeff Taylor wrote:
> With the recent serial changes for the oss/parody/pirate zones, we are
> once again facing a problem with T1 operators not being available to
> ensure that these changes get completed.  There has been some discussion
> on IRC about policy changes, but I wanted to start a thread here so
> everyone could lay out their thoughts on the matter...
> 
> Let's start with an explanation of how things are now... We currently
> have a policy that all T1s are listed as masters for all TLDs.  This was
> enacted to help ensure two things: 1) that all zones would always be
> available from all T1s, and 2) that if there was an issue with a TLD and
> the owner was not immediately available to correct the problem, another
> T1 operator would be able to push an updated zone file to override the
> problem.  Nobody expects all operators to be available 24/7, but since
> we have a global community we have a better chance of somebody noticing
> and correcting a problem sooner.
> 
> Unfortunately this policy is also what's causing the problem.  If a zone
> serial gets reverted to an earlier number (or sometimes if a script
> malfunctions and a very high number is accidentally put out), we need to
> get ALL of the T1 admins to closely watch their server and make sure the
> correct zones stay active.  The scripts that I have written were
> supposed to help automate that process, but through incompatibilities
> between different server types there have been problems with that
> working reliably.
> 
> What we really need is a policy that still allows for 1 and 2 above, but
> reduces the problem of all operators manually performing updates.
> 
> I would like to propose the following:  If we set up NS0 to answer TLD
> queries from T1 servers, it could be considered as a backup master for
> all zones.  We would effectively change the configuration on all T1
> servers so that the only masters they recognize for each zone would be
> the actual TLD owner, and NS0.  There are several people with access to
> NS0 who would also be most likely to be correcting failures in the zone
> files anyway.  This setup reduces the number of masters for every zone
> to only 2, making it *much* easier to propagate changes in the serials
> if/when we need to.
> 
> In case my explanation isn't clear, an example named.conf zone entry
> would look like this...
> 
> zone "free" in {
>     type slave;
>     masters {
>         185.19.105.30;          # ns1.opennic.glue
>         75.127.96.89;           # ns0.opennic.glue
>     }
> }
> 
> The TLD SOA records would still list all of the T1 servers as
> nameservers for that zone, so queries could still be made to any of the
> T1s, allowing for the large redundancy that we have now.  The only
> difference would be within BIND, where it would see only two allowable
> sources for the zone files.
> 
> So my question to all of you...  Does anyone see any pitfalls with such
> a policy?  Would it solve the problems we have now without creating any
> new problems?  Would it still provide the same global redundancy that we
> are trying to maintain with opennic services? Does anyone have other
> suggestions on how we might achieve all of the above?

This is a great start. Lets expand on this thought pattern.

I propose the following ideas to deal with unresponsive operators.

- must idle in IRC
- 1 week to communicate with community on any issues that are
occurring(server failure, etc...)
- 2 weeks to fix an issue

Failure to meet any of these means that the server and admin will be
dropped from the OpenNIC root.

A current example of this is ns5 and ns6. ns6 has had old NS records for
a very long time, and ns5 has been down for over a month.

--julian