[sf-lug] SF-LUG DNS
Rick Moen
rick at linuxmafia.com
Mon Nov 16 08:55:16 PST 2009
Hi, Jim. Good to hear from you.
Quoting jim (jim at well.com):
> we replaced the old machine with a new one. the
> old machine was pretty much a classic unix box
> (CentOS 4 or 5). the new machine uses debian XEN
> to implement two virtual machines, one for balug,
> the other for sf-lug (which is now using the
> correct ip address).
Um... I hope your mailing list posting (quoted above) wasn't intended to
close out the list of what I said you need to do. You still need to do
those things. Please consult my rundown of that matter, which I'll
re-quote (below) to correct typos.
I'm sorry if I sound like I'm barking orders at you guys, but you
shouldn't move master nameservice for a domain to a new IP without
coordinating closely with your secondaries (which, again, should number
at least two, not just one). Omitting that coordination is pretty much
guaranteed to break your DNS, which I'm assuming is deemed A Very Bad
Thing. sf-lug.com's DNS is currently damaged and dangerously thin. If
not corrected, is going to fail completely, when the secondary's
copy of the zonefile hits its expire limit.
In that area, it's kind of a good thing that you're not relying on the
sf-lug.COM domain very much, compared to sf-lug.ORG, but IMO you should
use this as a learning experience to help with handling of your
more-vital domain in the future.
> i'll have to bring up the old machine and find
> the dns files then copy them to the new machine.
So, you're saying you retired the old nameserver entirely? And the new
nameserver is on a different IP and doesn't yet have the old one's DNS
zonefiles (or presumably its nameserver configuration)?
Ideally, you would take a zone's master nameservice completely
down only when you're about to bring up its replacement. You would have
shortened the TTL values in advance of changeover. You would let your
secondaries know as soon as feasible about the new IP to point to,
verify that zone transfers are working, and verify that the NS lines in
_both_ the served zonefiles and the WHOIS records are updated.
To be clear: It's OK if master nameservice goes offline. That's what
secondaries are for. But you want to let your secondaries know what's
going on, and bring up replacement master nameservice before the expire
limit.
> probably a poor idea to have a master dns
> server on the box that the dns points to, yes?
Um, no. Why would that be a problem? I'm sorry, but I don't follow
your reasoning.
Consider NS1.LINUXMAFIA.COM, IP 198.144.195.186. That nameserver and
its hostname are usable in DNS because the parent .COM zone has a record
for it. Such a record is called a "glue record", and is what bootstraps
the process, preventing a chicken-and-egg problem where
NS1.LINUXMAFIA.COM cannot be resolved because you would first have to
resolve NS1.LINUXMAFIA.COM in order to ask it that question.
When I first attempted to use record "NS1.LINUXMAFIA.COM" at a domain
registrar, I had to use the regisrar's Web interface to define that
entity as a valid nameserver and provide its IP. Behind the scenes,
taking that action resulted in the registrar adding a glue record to
the parent .COM zone's own zonefile. Only _then_ was I permitted to
reference "NS1.LINUXMAFIA.COM" in the domain's "Name Server" roster
within the domain record (with resulting change to the WHOIS) results.
You can observe the glue record directly, using dig. First, find out
where the namservers for .COM are:
$ dig -t ns com. +short
A.GTLD-SERVERS.NET.
L.GTLD-SERVERS.NET.
J.GTLD-SERVERS.NET.
H.GTLD-SERVERS.NET.
M.GTLD-SERVERS.NET.
C.GTLD-SERVERS.NET.
K.GTLD-SERVERS.NET.
B.GTLD-SERVERS.NET.
D.GTLD-SERVERS.NET.
I.GTLD-SERVERS.NET.
F.GTLD-SERVERS.NET.
E.GTLD-SERVERS.NET.
G.GTLD-SERVERS.NET.
$
Now, ask one of those (I'll use the first of them) to ask about the NS
records for zone linuxmafia.com . In this case, I'll omit the "+short"
flag, because I want to call attention to the Additional Section data:
$ dig -t ns linuxmafia.com. @A.GTLD-SERVERS.NET.
; <<>> DiG 9.4.2-P1 <<>> -t ns linuxmafia.com. @A.GTLD-SERVERS.NET.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41884
;; flags: qr rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 6
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;linuxmafia.com. IN NS
;; ANSWER SECTION:
linuxmafia.com. 172800 IN NS ns.primate.net.
linuxmafia.com. 172800 IN NS ns.tx.primate.net.
linuxmafia.com. 172800 IN NS ns1.linuxmafia.com.
linuxmafia.com. 172800 IN NS ns1.thecoop.net.
linuxmafia.com. 172800 IN NS ns2.linuxmafia.com.
;; ADDITIONAL SECTION:
ns.primate.net. 172800 IN A 198.144.194.12
ns.primate.net. 172800 IN AAAA 2001:470:1f00:ffff::6b7
ns.tx.primate.net. 172800 IN A 72.249.38.88
ns1.linuxmafia.com. 172800 IN A 198.144.195.186
ns1.thecoop.net. 172800 IN A 66.220.20.163
ns2.linuxmafia.com. 172800 IN A 63.193.123.122
;; Query time: 138 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Nov 16 08:21:39 2009
;; MSG SIZE rcvd: 250
$
You'll notice that there are five nameservers for this domain.
NS1.LINUXMAFIA.COM is the third one listed in the Answer Section.
(Order is not significant, nor is it in WHOIS results or domain
records.) Notice that the Additional Section provides the IP address
for each of the five nameservers as "Oh, and by the way, you didn't ask
for this, but I'm throwing it in, in case you need it" data. That is
what is meant by "glue". It's how the chicken-and-egg problem gets
averted.
By the way, I find it really, _really_ useful to annotate my nameserver
configuration file with comments. In particular, I put in whose domain
it is (full contact data), what host each referenced IP address is, plus
contact information about the administrators of each nameserver (name,
e-mail address, and telephone number). That way, you never have the
"Oh, dear, who are my secondaries and how do I reach them to tell them
I'm moving the master DNS to a new IP" problem.
Here is my snippet of /etc/bind/named.conf.local concerning
linuxmafia.com:
//For Rick Moen, rick at linuxmafia.com, 650-283-7902
zone "linuxmafia.com" {
type master;
file "/etc/bind/linuxmafia.com.zone";
allow-query { any; };
allow-transfer {
//Drew Bertola <drew at drewb.com>, 408-123-4567
//ns1.thecoop.net is:
66.220.20.163;
//was: 216.218.255.165;
//Aaron T. Porter <atporter at primate.net>, 925-123-4567
//http://www.lbl.gov/cgi-bin/ds/ds.cgi?include=n&peopleName=atporter
//ns.primate.net is:
198.144.194.12;
//Aaron T. Porter <atporter at primate.net>, 925-123-4567
//http://www.lbl.gov/cgi-bin/ds/ds.cgi?include=n&peopleName=atporter
////ns.on.primate.net is:
//207.44.185.143;
//ns.tx.primate.net is:
72.249.38.88;
//David Wolfskill <david at catwhisker.org>, 650-123-4567
//ns2.linuxmafia.com aka ns.catwhisker.org is:
63.193.123.122;
};
};
Here's the snippet for sf-lug.com:
//For Nathan Kuriger, nathank at evilmonkeys.com, 415-123-4567, and
//Jim Stockford, jim at well.com, 415-123-4567
zone "sf-lug.com" {
type slave;
file "/var/cache/bind/sf-lug.com.zone";
allow-query { any; };
allow-transfer { none; };
masters {
//ns1.sf-lug.com is:
208.96.15.252;
};
};
(Most telephone numbers have been changed to "123-4567" for privacy,
as only some of those people make their telephone numbers public
information.)
I am of course reachable at e-mail address rick at linuxmafia.com, and
cellular tel. # 650-283-7902. I recommend you use that, along with
information about what my IP is, in comment lines in your
/etc/bind/named.conf.local file (or named.conf, or whatever), on the
master nameserver for sf-lug.com .
If you look at the WHOIS data for linuxmafia.com, you'll note that:
(1) I cite e-mail address "rick at deirdre.net" (in my wife's domain) to
avoid having the domain contact be in-band for the domain it concerns.
That is, it's important that the cited address be reachable even if the
domain and its underlying hardware and/or network goes offline. So,
"rick at deirdre.net" is picked because it's handled completely outside the
domain, machine, and network that serves linuxmafia.com.
(2) I carefully do not cite myself as the sole contact (which would
create a single point of failure problem), and have someone else as
Technical Contact.
> i wish i could find a tutorial that succinctly
> and completely explains the rudiments of setting
> up dns for and on a linux system: this would
> summarize the concepts and then specify the files
> to create and/or modify and finally present
> several examples to exemplify common use cases.
I published a short article a few years ago in _Linux Gazette_ that
details how to do every variety of DNS _other_ than master authoritative
DNS, which is covered only in part. I partially punted on that variety,
because it would take a long, very intricate article to cover how to do
it _properly_, i.e., to avoid common mistakes and explain why they are
mistakes. http://linuxgazette.net/121/moen.html
I hope that is useful, despite my having punted on the details of master
authoritative DNS.
Here's that list of what you should do, to move a domain's master
namservice to a new IP:
You need to closely coordinate with your DNS secondaries' sysadmins
whenever you move your domain's master DNS to a different IP. Send
e-mail (not mailing list mail) to the guys who run your secondaries (in
this case, just me), saying that a specified domain needs to be
repointed to a new master IP. You need to say when this should happen.
You need to fix obsolete IPs in NS lines in the zone you're serving from
the master. You need to make sure the secondaries' IPs are all in the
new master nameserver's allow-transfer ACL. You need to verify that the
secondary successfully has done an AXFR (zone transfer) from the new
master IP, you need to query using dig to make sure master and slaves
are serving the new S/N (query for the SOA). Last, you then need to
update the nameserver list in the domain record, which ensures that the
parent zone (.com, in this case) has the correct glue records.
Again, (non-mailing list) e-mail or telephone.
More information about the sf-lug
mailing list