-----Original Message----- From: Jeff Chan [mailto:jeffc@surbl.org] Sent: Tuesday, August 24, 2004 7:44 AM To: SURBL Discuss Subject: [SURBL-Discuss] Improved name server status page
I've set up a better SURBL name server status page at:
http://www.surbl.org/nameservers-output.html
which is also linked from the main page.
It shows some latency in zone file propagation, and it also shows one of the name servers down. (Bjorn is that coming back eventually?)
We may want to ask all the public name servers to rsync every 10 minutes.... Would that be OK Raymond?
Currently I have the DNS timeout set to 10 seconds with two retries. What kind of values are more typical or standard for resolvers?
I will use the scripts that generate the page to send notifications (probably to myself at first) once things stabilize. Since events don't happen very often, it's probably not necessary to show a history on the page.
Comments?
That is very cool! However do you think it is wise to make public the IP's of the servers?
--Chris (Paranoid little monkey.)
Hi!
Currently I have the DNS timeout set to 10 seconds with two retries. What kind of values are more typical or standard for resolvers?
I will use the scripts that generate the page to send notifications (probably to myself at first) once things stabilize. Since events don't happen very often, it's probably not necessary to show a history on the page.
That is very cool! However do you think it is wise to make public the IP's of the servers?
<BOFH mode=on>
No, indeed, lets hide them, it will only cause problems if we list them ;)
<BOFH mode=off>
Chris, you paranoid DONKEY :) how do you think people should lookup the zones if we dont publish where to get them. DNS does the exact same thing.
; <<>> DiG 9.2.1 <<>> ns surbl.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21524 ;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 12
;; QUESTION SECTION: ;surbl.org. IN NS
;; ANSWER SECTION: surbl.org. 13466 IN NS ns9.surbl.org. surbl.org. 13466 IN NS ns8.surbl.org. surbl.org. 13466 IN NS ns7.surbl.org. surbl.org. 13466 IN NS ns6.surbl.org. surbl.org. 13466 IN NS ns5.surbl.org. surbl.org. 13466 IN NS ns3.surbl.org. surbl.org. 13466 IN NS ns2.surbl.org. surbl.org. 13466 IN NS ns13.surbl.org. surbl.org. 13466 IN NS ns12.surbl.org. surbl.org. 13466 IN NS ns11.surbl.org. surbl.org. 13466 IN NS ns10.surbl.org. surbl.org. 13466 IN NS ns1.surbl.org.
;; ADDITIONAL SECTION: ns9.surbl.org. 14175 IN A 209.234.97.11 ns8.surbl.org. 14175 IN A 66.59.111.182 ns7.surbl.org. 14175 IN A 130.161.128.84 ns6.surbl.org. 14175 IN A 128.255.17.20 ns5.surbl.org. 14175 IN A 128.255.17.19 ns3.surbl.org. 14175 IN A 139.130.4.5 ns2.surbl.org. 14175 IN A 209.204.159.15 ns13.surbl.org. 14175 IN A 66.170.2.60 ns12.surbl.org. 14175 IN A 66.170.2.50 ns11.surbl.org. 14175 IN A 64.21.208.212 ns10.surbl.org. 14175 IN A 66.251.133.4 ns1.surbl.org. 14175 IN A 208.201.249.238
;)
Bye, Raymond.
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.)
Jeff C.
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.
-
Chris Santerre -
Jeff Chan -
Raymond Dijkxhoorn