On Tuesday, August 24, 2004, 6:40:22 AM, Jeff Chan wrote:
On Tuesday, August 24, 2004, 6:32:44 AM, Chris Santerre wrote:
That is very cool! However do you think it is wise to make public the IP's of the servers?
Yeah that kind of raised some flags for me too, but the servers are easy enough to find, and the names of the servers are not unique due to the round robin.
For example e.surbl.org resolves to two different name servers.
So the only thing unique and used for the subdomains are their IP addresses. I suppose we could set up another set of aliases for them, but kind of don't want another set to maintain. (The old style ns1, ns2, etc. names remain but for BIND type servers for the parent zone. They have already diverged from the rbldnsd servers.)
OK, In the name of obscurity I've created some unique name server names only used for monitoring:
e IN A 66.170.2.48 e1 IN A 66.170.2.48 e IN A 66.170.2.61 e2 IN A 66.170.2.61 [...]
The nameserver names with only the letter continue to be used in round-robin for the subdomain delegations, as before.
The names with a letter and number are used for monitoring purposes so that a specific server is being checked.
I also changed the program logic slightly to not check freshly updated zone files until after 30 minutes has passed. This allows 30 minutes for propagation via rsync or BIND zone transfers, then starts checking.
That prevents serials showing up as red simply because the previous version was more than two hours old but the new version has not had a chance to propagate out yet.
However zones with special errors that perl evaluates to a zero value for the serial, like "Not Authoritative" or "No SOA", etc. are checked without the 30 minute delay.
The only case probably not well handled is when the serial is older than 2 hours, is not updating due to some problem, and a new zone file comes along. Then I think it will go from red to green, then back to red again in 30 minutes. On the other hand that could make effective nagging when alarms are added.
The program producing the web page is:
http://spamcheck.freeapp.net/monitor-html
And the input data is:
http://www.surbl.org/nameservers-output.txt
Sanity checks welcome.
Can anyone tell me what timeouts and retries are typical for common resolvers?
Jeff C.