Quoting Kim Oldfield (luv@oldfield.wattle.id.au):
On 14/10/18 18:12, Rick Moen via luv-talk wrote:
Here's the RFC wording: It is recommended that three servers be provided for most organisation level zones
Servers, not IP addresses. These days with load balancers and anycast addresses a company could have 100 DNS servers which look like one IP address from the outside.
On 03/10/18 14:28, Rick Moen via luv-talk wrote:
I note that a depressingly large number of allegedly professional outsourced DNS providers violate the RFCs with dangerously thin nameservice, e.g.:
:r! whois baycon.org | grep "Name Server"
Name Server: NS1.BLUEHOST.COM Name Server: NS2.BLUEHOST.COM
There, friends, I present: Bluehost, Inc., a supposedly professional hosting company. And that is the sort of incompetence you all too frequently get when you outsource. They are using 2 DNS names (which happen to translate into 2 IP addresses). Do you know what technology (load balancers, anycast, etc) they are (not) using so you can substantiate your claim that are violating the RFC?
...oh, and also that on _many_ occasions I've smoke-tested the response from cron-scripted 'dig' queries to NS1.BLUEHOST.COM and NS2.BLUEHOST.COM on behalf of my local volunteer-run science fiction convention BayCon that hosts all of baycon.org there, gotten connection failures from one or the other, and manually double-checked and confirmed that outage to be real and persist for _days_ on end. If those FQDNs' IPs are serviced by load balancers and/or anycast networks or similar redundancy mechanisms, those must be mechanisms struck frequently with improbably severe misfortune, And it would appear that their service monitoring must be likewise frequently struck by meteors or something like that. :r /etc/cron.weekly/baycondomain #!/bin/sh # baycondomain Cron script to sanity-check the BayCon domain's SOA records at # all of its authoritative nameservers, as a quick and # dirty way of making sure (1) they're all online and # (2) they're all serving up the same data (or at least # data with the same zonefile serial number). # # The script queries all nameservers for their current # SOA value (for baycon.org), and then uses awk to parse # out of that verbose record just the S/N field, which is # field #3. The point is that you can visually spot offline # or aberrant nameservers by their S/Ns being (respectively) # missing or an out-of-step value. # # Written by Rick Moen (rick@linuxmafia.com) # $Id: cron.weekly,v 1.01 2011/05/08 07:04:55 rick set -o errexit #aka "set -e": exit if any line returns non-true value set -o nounset #aka "set -u": exit upon finding an uninitialised variable test -x /usr/bin/mail || exit 0 { dig -t soa baycon.org. @NS1.BLUEHOST.COM. +short | awk {'print $3'} dig -t soa baycon.org. @NS2.BLUEHOST.COM. +short | awk {'print $3'} } | /usr/bin/mail -s "Domain baycon.org SOA check" rick@linuxmafia.com