Re: PROJECT: Redundancy of DNS Servers

avo wrote:
> 
> In my testing of distributed DNS, ...
> 
> Hosts configured as Master don't repond to NOTIFY. That's why I ended up 
> with all hosts configured as Slaves (in named.conf).
> 
> There is also special significance to the Master as declared in the 
> zone's SOA record. I ended up with a hostname which had an A record for 
> each of the hosts serving the distributed DNS "master"
> 
> As has been pointed out on this list recently, having a distributed 
> master for the opennic root isn't necessarily more useful than what is 
> provided in the standard slave configuration which exists. What has been 
> a picture of the change history of the opennic root? Other than adding 
> or removing TLDs, the only records are NS delegations and their 
> associated A glue records, eh?
> 
> Individual TLD roots might want to use a decentralized root however if 
> they choose to decentralize their name registration services. In that 
> case I expect that the NSUPDATE provisions of Bind9 are the appropriate 
> way to proceed, even with a distributed Master.
> 
> I agree with Aaron's suggestion that Tier-1 hosts not be recursive, but 
> do provide full transfer; while Tier-2 hosts are configured the 
> opposite. Not all resolvers will find their way to a second DNS server 
> after their first attempt responds with NXDOMAIN.
> 

The idea sounds good. Lets get a test configuration going. I have got my 

Re: "Roles", was PROJECT: Bug Tracking

Robin wrote:
> hostmasters
>    krystal <at> devnull.net (root, opennic.glue, .null)
>    dennisthetiger <at> gmail.com (root, opennic.glue, .fur)
>    shdwdrgn <at> sourpuss.net (.oss)
Interzone is willing to operate a Tier 1 server in the US (not least of
which because we want to set up .iz) and either an Australian based tier
1 or tier 2 server. I'm not sure if that makes me a Hostmaster or not
?(i would be the primary maintainer of that system)
######################################################################
This is the discussion list for the Open Network Information
Center.  You can unsubscribe by sending an email containing the words
"unsubscribe discuss" in the body of the message to
"majordomo <at> opennic.glue" or "majordomo <at> opennic.unrated.net".
######################################################################

Re: PROJECT: Redundancy of DNS Servers

Isn't DNS actually running now?  

(Seriously, though, zero does seem to be functioning fine and I never 
lost DNS resolution when zero barfed last week; I haven't finished the 
audit script yet, but what I'm seeing so far is that the problem is 
missing servers, not architecture.)

-robin

Julian De Marchi wrote:
...
>
> The quicker we can get the DNS back up an reliable, the better. Then 
> we can work on smoothing it out.
...
######################################################################
This is the discussion list for the Open Network Information
Center.  You can unsubscribe by sending an email containing the words
"unsubscribe discuss" in the body of the message to
"majordomo <at> opennic.glue" or "majordomo <at> opennic.unrated.net".
######################################################################

Re: PROJECT: Redundancy of DNS Servers

The strange thing was that the day I noticed that DNS resolution was 
lost, my tld-root file was exactly 1 week old (I hadn't received any 
updated to it), and there is a 1-week timeout on that file.  It doesn't 
seem like that's the way the timeout is supposed to work, but that is 
what happened here. 

Robin wrote:
> Isn't DNS actually running now?  
>
> (Seriously, though, zero does seem to be functioning fine and I never 
> lost DNS resolution when zero barfed last week; I haven't finished the 
> audit script yet, but what I'm seeing so far is that the problem is 
> missing servers, not architecture.)
>
> -robin
>
> Julian De Marchi wrote:
> ...
>>
>> The quicker we can get the DNS back up an reliable, the better. Then 
>> we can work on smoothing it out.
> ...
> ######################################################################
> This is the discussion list for the Open Network Information
> Center.  You can unsubscribe by sending an email containing the words
> "unsubscribe discuss" in the body of the message to
> "majordomo <at> opennic.glue" or "majordomo <at> opennic.unrated.net".
> ######################################################################
######################################################################
This is the discussion list for the Open Network Information

Re: "Roles", was PROJECT: Bug Tracking

Robin wrote:
> OK, here's a list of the folks who've volunteered for the teams so far:
> 
> admins
>    krystal <at> devnull.net
>    shdwdrgn <at> sourpuss.net
>    julian <at> jdcomputers.com.au
> 
> architects
>    krystal <at> devnull.net
>    shdwdrgn <at> sourpuss.net
>    thatoneguy <at> aaronjangel.us
> 
> auditor
> 
> bugmeister
>    shdwdrgn <at> sourpuss.net
> 
> dbadmins
>    thatoneguy <at> aaronjangel.us
> 
> hostmasters
>    krystal <at> devnull.net (root, opennic.glue, .null)
>    dennisthetiger <at> gmail.com (root, opennic.glue, .fur)
>    shdwdrgn <at> sourpuss.net (.oss)
> 
> list admins
> 
> pr reps      
> webmasters

Re: "Roles", was PROJECT: Bug Tracking

I've got a lot more experience with OTRS as a ticket tracking system 
(since I set it up and use it for our ISP), but I've never seen Request 
Tracker.

I should probably learn Nagios anyway, though, and since we don't have a 
volunteer for auditor I suppose I can see about getting it set up on 
zero to monitor the other servers.

I have a rough audit script that reads in the config files (from which 
the scripts build our root zone and decide which servers to show on the 
web page) and does SOA queries against all the servers for each OpenNIC 
zone.  I need to clean up its output so it can give a synopsis of which 
machines are serving what data corectly, at which point I'll set it up 
to run on a schedule and email its output to a mailing list.

-robin

Julian De Marchi wrote:
> ...
> Just putting some more ideas into the pot for support and monitoring.
>
> Request Tracker 3.0 to run a support system, where we all share equal 
> responsibilities for support issues and monitor the RT for support 
> tickets. I feel that using RT will give everyone an idea of what the 
> common issues for OpenNIC users are.
>
> Also for monitoring of the OpenNIC systems, Nagios[0] might be a good 
> choice to monitor all host systems. Nagios also has great graphing 
> tools so we can put together a downtime chart, and various other 
> informative charts.

Re: "Roles", was PROJECT: Bug Tracking

I should also take a shot at nagios for other purposes as well, so don't 
feel obliged or alone :)

avo

######################################################################
This is the discussion list for the Open Network Information
Center.  You can unsubscribe by sending an email containing the words
"unsubscribe discuss" in the body of the message to
"majordomo <at> opennic.glue" or "majordomo <at> opennic.unrated.net".
######################################################################

Re: "Roles", was PROJECT: Bug Tracking

Re: "Roles", was PROJECT: Bug Tracking

Robin wrote:
> I've got a lot more experience with OTRS as a ticket tracking system 
> (since I set it up and use it for our ISP), but I've never seen Request 
> Tracker.
> 
> I should probably learn Nagios anyway, though, and since we don't have a 
> volunteer for auditor I suppose I can see about getting it set up on 
> zero to monitor the other servers.
> 
> I have a rough audit script that reads in the config files (from which 
> the scripts build our root zone and decide which servers to show on the 
> web page) and does SOA queries against all the servers for each OpenNIC 
> zone.  I need to clean up its output so it can give a synopsis of which 
> machines are serving what data corectly, at which point I'll set it up 
> to run on a schedule and email its output to a mailing list.
> 
> -robin

The nagios monitoring host should not be a critical system in the 
OpenNIC network. The host should be on a machine whos sole purpose is to 
monitor the state of the OpenNIC network. I have nearly finished my 
nagios setup on a host.

I am unsure who should have access to the charts and graphs and other 
information nagios contains. Who should have access?

Also the alerts nagios outputs, should go to a list like 
alerts <at> opennic.unrated.net? I have also been testing nagios to produce a 
voice alert if the internet connection of the host goes down.

Julian
######################################################################
This is the discussion list for the Open Network Information
Center.  You can unsubscribe by sending an email containing the words
"unsubscribe discuss" in the body of the message to
"majordomo <at> opennic.glue" or "majordomo <at> opennic.unrated.net".
######################################################################

Re: "Roles", was PROJECT: Bug Tracking

I agree completely; I figured it would be useful to have zero monitoring 
things as well (and no one else had volunteered to be auditor, so I 
figured I could at least start with that).

At the very least, the admins should all have access; it'd probably be 
best to let any member access any stats or charts that wouldn't contain 
any private info on a server or a member and restrict those to the folks 
who are on any of the operational teams.

I'll add "alerts <at> " to the list of lists I need to get set up with mailman.

-robin

Julian De Marchi wrote:
> . ..
> The nagios monitoring host should not be a critical system in the 
> OpenNIC network. The host should be on a machine whos sole purpose is 
> to monitor the state of the OpenNIC network. I have nearly finished my 
> nagios setup on a host.
>
> I am unsure who should have access to the charts and graphs and other 
> information nagios contains. Who should have access?
>
> Also the alerts nagios outputs, should go to a list like 
> alerts <at> opennic.unrated.net? I have also been testing nagios to produce 
> a voice alert if the internet connection of the host goes down.
>
> Julian
...
######################################################################
This is the discussion list for the Open Network Information
Center.  You can unsubscribe by sending an email containing the words
"unsubscribe discuss" in the body of the message to
"majordomo <at> opennic.glue" or "majordomo <at> opennic.unrated.net".
######################################################################