[conspire] How not to muck up DNS & domain registration
Rick Moen
rick at linuxmafia.com
Tue Apr 12 12:22:42 PDT 2005
Key phrases:
single point of failure
out of band
authoritative nameserver
glue records
reference record (RR)
I mentioned, a short while back, that I would soon be extending my domain
registration by a bunch of years, and why. I thought it might be useful
to follow up on that with an examination of the registry "whois" and DNS
RR ("reference record") information, to show one guy's notion of how to
do it right. A "RR" is one datum of DNS in the global DNS records.
In the BIND nameserver, it would be recorded as one single line in a
zonefile, e.g., an A=address, NS=nameserver, MX=mail exchanger,
CNAME=canonical name (alias), or PTR=pointer (reverse DNS) record.
For .com and .net registrations (among others), domain registration
information is kept in a database reachable via the remote "whois"
protocol and administered by Network Solutions, Inc. aka NetSol (now
part of Verisign, Inc.) under contract to the USA Commerce Department.
NetSol is required by that contract to make access to that registry
database available to third-party registrars in addition to its own
registrar division: This lead to development of a set of bureaucratic
procedures for such access by accredited registrars, called the Shared
Registry System (SRS).
Note the category distinction (above):
o registry = where the data are stored, i.e., the back-end datastore.
o registrar = the customer-facing organisation that takes in money and
tells the registrar when & what to change in its records, when to
extend expiration dates., etc.
Within the .com/.net world, there is only one registRY. Access to it is
mediated by whichever of many distinct organisations serve as the
registRAR whom you pay to keep your domain registration alive.
My domain is, of course, "linuxmafia.com". That's sometimes called as
second-level domain or SLD, because it's one level down from one of the
top-level domains (TLDs), namely ".com". In conceptual theory, all of
the very numerous TLDs -- com, net, org, gov, int, biz, us, ca, mx, uk,
jp, (etc.) -- live as nodes right below the top or "root" of the
namespace, designated as a period symbol ("."). Thus, the absolutely
fully qualified, full-length name of my domain is "linuxmafia.com.", and
you'll see this usage in some places in DNS records.
Let's have a look at the "whois" record for my domain, as of right now.
Back in the day, NetSol claimed to deploy pending changes to the whois
records twice a day. I don't know what they claim is the case right
now.
rick at alfredo:/tmp$ whois -H linuxmafia.com | more
Whois Server Version 1.3
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Interesting suggestion. InterNIC used to be the name of the central
combined registry/registrar run by NetSol as a consortium of four
sponsoring companies before they were bought by Verisign and started to
suck mightily. We spoke of "the InterNIC", which I believe for a long
time was at SRI International in Menlo Park. After that, it moved to
NetSol in Virginia.
However, the above-mentioned InterNIC Web site is a new creation, a
semitechnical thing put up by ICANN, the jerks who keep competing with
NetSol for loathesomeness and have aspirations of running the Internet
over the objections of most sane people.
There's a Web-ified "whois" linked from the site. We'll not be using
it. Instead, we're using the command-line whois client. It tries to
make an intelligent guess which whois server to query, depending on what
you're asking about. If you want to specify a particular server, you
can.
The "-H" is our order to hold the legal boilerplate disclaimers sent by
most whois servers (don't bother to show them to us; we've seen 'em
before).
Domain Name: LINUXMAFIA.COM
Registrar: TUCOWS INC.
Whois Server: whois.opensrs.net
Referral URL: http://domainhelp.tucows.com
Our query is getting referred to the "whois.opensrs.net" whois server
run by Tucows, Inc., which is identified as my domain registrar.
Tucows, quite a few years ago, set up a subsidiary called "OpenSRS" as a
sort of cooperative: People who do a lot of domain registrations were
invited to become "OpenSRS resellers". To do that, you send in $100 to
open your "reseller" account and are give a $100 credit to apply towards
your or anyone else's domain registrations. You have access to some Web
forms and other tools, and basically Tucows outsources to you the hassle
of dealing with customers, if any. What Tucows brings to the table is
the ability for all of those resellers collectively to be an accredited
registrar, and thus use SRS access to NetSol's registry database.
Make sense, so far?
The http://domainhelp.tucows.com/ is presumably where you can go if your
reseller is flaking out, or some such -- and for information that he
might not be providing, etc. Notice that the page goes to some trouble
to clarify that you should be working through your reseller on almost
all matters. Tucows wants to be a wholesaler; you're being told to talk
to the retailers.
Name Server: NS1.LINUXMAFIA.COM
Name Server: NS.PRIMATE.NET
Name Server: NS1.VASOFTWARE.COM
Name Server: NS.ON.PRIMATE.NET
This is the complete listing of DNS nameservers that are to be regarded
as _authoritative_ for my domain. That is, they're the ones people are
told to consult. Any other DNS nameservers could offer up what _they_
claim is my DNS information, but those would have no authority.
So, there's a common gotcha: Novices attempting to manage their DNS
will often add nameservers to the "NS" lines in their DNS zonefiles, and
then be very surprised later when they learn that the public at large
made no use of them -- because they weren't authoritative. Likewise,
it's important to _remove_ from the authoritative list nameservers that
have ceased to do DNS for you (or ceased to do it competently).
Why four nameservers? Redundancy. RFC2182 recommends at least 3, and
preferably no more than seven. I usually have five, actually, but
recently disabled one because it was having problems. More about that,
later.
Status: REGISTRAR-LOCK
This is a safeguard. It's just a flag in the whois record, but
supposedly means that no _other_ registrar is able to grab my records,
as long as the flag is set. (No "slamming", to borrow the telco
metaphor.) It also imposes the minor inconvenience that I can't change
the records (e.g., to add or remove nameservers from the authoritative
list) without removing the lock first, either.
Updated Date: 08-apr-2005
Creation Date: 18-jul-1998
Expiration Date: 17-jul-2010
Here's some vital stuff, especially the last of those lines: My
reseller has come through on my recent four-year extension, from 2006 to
2010.
The "Creation" means creation within Tucows's records: My domain's a
lot older than that. "Updated" is the day my reseller caused Tucows to
send in the extension over the SRS pipeline.
>> Last update of whois database: Mon, 11 Apr 2005 08:27:07 EDT <<<
This is the "twice a day" stuff I mentioned earlier: This is the
timestamp of when the whois database we're querying got updated chugged
out to it.
Registrant:
Linux Mafia
"Registrant" is an extremely vital datum: It's the person or
organisation regarded as the ultimate owner of the domain. For your
domain, if that's not you or someone you really trust, you're in a heap
of trouble over the long term.
How mine came to be regarded as owned by the nonexistent-or-maybe-it-isn't
organisation is a long and rather droll story. Some other time, perhaps.
2033 Sharon Road
Menlo Park, CA 94025-6246
US
And this, of course, is where the owner is considered to hang his hat.
If there were ever any dispute over domain ownership, I'd be cranking
out "Linux Mafia" letterhead with my street address on it, for the
purpose. It would be difficult to resist signing any letters as "Capo".
Domain name: LINUXMAFIA.COM
Again, clarifying what specific SLD this domain record concerns.
Administrative Contact:
Moen, Rick rick at deirdre.net
2033 Sharon Road
Menlo Park, CA 94025-6246
US
650-561-9820
The whois records draw a distinction among four roles that are present
(at least impliedly) for each domain record. You've already heard about
registrant. The others:
o Administrative Contact
o Technical Contact
o Billing Contact
In theory, "Hey, what's a Linux mafia?" mail is supposed to go to the
Administrative Contact, "Dude, your mail server is down" mail should go
to the Technical Contact, and renewal bills from the registrar should go
to the Billing Contact.
Please notice that I've specified "rick at deirdre.net" as my
Administrative Contact e-mail address. Why? Because it's an
out-of-band contact mechanism: It'd be pretty stupid for "Dude, your
mail server is down" mail to be unable to reach me because... my mail
server is down.
It's amazing how many people flub this simple concept. You want at
least one of your listed contact e-mail addresses to be out of band:
It should work if your entire DNS is out of commission, not to mention
your mail server. Otherwise, there's no point in having such a contact
listed at all: The WHOLE POINT is to enable people to contact you if
something's wrong.
And, yes, you really _should_ have a useful telephone number listed
there. It doesn't have to be your 24x7 person cellular number, but it
shouldn't go nowhere.
Technical Contact:
Brown, Iain iain.srs at mail.webl.com
PO Box 1614
McKinney, TX 75070
US
(972) 568-7653 Fax: (214) 853-5253
This is my Tucows OpenSRS reseller. Please don't bug him: He doesn't
want more business.
He put himself down as Technical Contact when I moved my domain over
from Domain Discover (San Diego), a number of years ago. I was right
about to replace his information, there, with my own, when I stopped and
thought, "Well, no. The extra redundancy is good." But I could, e.g.,
put my wife's contact information there, instead, since she's also a DNS
admin. The main thing is for there to be more than one contact listed:
Don't make the extremely common mistake of having the Technical,
Administrative, and Billing contacts all be the same: That's a good way
to increase the likelihood of being unreachable in case of problems -- a
single point of failure.
Ordinarily, I would expect to see a separate paragraph for Billing
Contact. My record seems to lack one, and I'm not really sure why.
Registration Service Provider:
The Web Headed League, iain.srs at mail.webl.com
(972) 568-7653
This company may be contacted for domain login/passwords,
DNS/Nameserver changes, and general domain support questions.
This seems to be some sort of registrar blurb.
Last, there's a redundant report of some of the same information as
before:
Registrar of Record: TUCOWS, INC.
Record last updated on 08-Apr-2005.
Record expires on 17-Jul-2010.
Record created on 18-Jul-1998.
Domain servers in listed order:
NS1.LINUXMAFIA.COM 198.144.195.186
NS.PRIMATE.NET 198.144.194.12
NS1.VASOFTWARE.COM 12.152.184.135
NS.ON.PRIMATE.NET 207.44.185.143
Domain status: REGISTRAR-LOCK
Now, I wanted to point out to you an extremely useful CGI on the Web:
Try entering "linuxmafia.com" into the "DNS Report" field on
http://www.dnsreport.com/
The report that will result will be un-exciting, specifically because
I use that form occasionally to as a quick check on everything. But
have a look. Some highlights:
Status: PASS
Test name: Glue at parent nameservers
Information: OK. The parent servers have glue for your nameservers.
That means they send out the IP address of your nameservers, as well
as their host names.
Status: PASS
Test name: Mismatched glue
Information: OK. The DNS report did not detect any discrepancies
between the glue provided by the parent servers and that provided by
your authoritative DNS servers.
A lot of people mess up their domains' glue records, and never figure
out why their DNS is unreliable as a result. Most have never even heard
the term, and are unaware of their gaffe.
Glue records are a key part of the mechanism by which a nameserver is
declared to be authoritative. Here's how it works: A user asked to
browse a page at "linuxmafia.com". His local machine's DNS resolver
(client) asks a nearby DNS server for the IP address. The DNS server
happens to not have the information in cache (doesn't know it), and so
refers the question elsewhere. In fact, the DNS server didn't even know
which nameserver to ask (let's say), so it consults the root
nameservers, which refer the query to the .com TLD nameservers, which
has the glue information:
Domain servers in listed order:
NS1.LINUXMAFIA.COM 198.144.195.186
NS.PRIMATE.NET 198.144.194.12
NS1.VASOFTWARE.COM 12.152.184.135
NS.ON.PRIMATE.NET 207.44.185.143
1. This speeds up the process, because the querying nameserver doesn't
need to do a _separate_ lookup of the nameservers' IPs, before
contacting the nameservers themselves, to do the original lookup.
2. It also solves a chicken-and-egg problem concerning nameservers that
are _within_ the domain being asked about, such as "NS1.LINUXMAFIA.COM":
Given that the query is about how to look up stuff in linuxmafia.com,
telling the nameserver "Um, ask the ns1 server in linuxmafia.com -- if
you can figure out its IP address" would have been less than useful.
Anyhow, a very frequent domain-administration error is to establish glue
records (NS records at your "parent zone" for DNS, which also get
replicated by the registrar to the TLD servers) at the time you first
set up DNS, but then _never update_ that information as you drop and add
nameservers over time. I made this error myself for a while: I would
change the "NS" entries in my linuxmafia.com.zone zonefile, and then be
puzzled that my new nameservers never seemed to be contacted, whereas
obsolete, no-longer-useful machines apparently still were. The problem
was that the obsolete nameservers were still (via glue records) regarded
as authoritative, and the new ones weren't.
If your domain registrar doesn't let you edit your
authoritative-nameservers list (and thus the glue records), then you
need to switch registrars.
Status: PASS
Test name: Nameservers on separate class Cs
Information: OK. You have nameservers on different Class C
(technically, /24) IP ranges. You must have nameservers at
geographically and topologically dispersed locations. RFC2182 3.1 goes
into more detail about secondary nameserver location.
This goes back to the "single point of failure" point. The whole point
of having multiple nameservers is to have redundancy of service, which
would be undermined if the same power outage or service outage of a
single backbone Internet provider took out _all_ your DNS at once. So,
you (ideally) want to have your nameservers geographically distant from
each other, and on networks not likely to have common-mode failures
("topologically dispersed").
Status: WARN
Test name: Multiple MX records
Information: WARNING: You only have 1 MX record. If your primary mail
server is down or unreachable, there is a chance that mail may have
troubles reaching you.
This "warning" reflects is a policy decision I made deliberately and for
what I think are good and compelling reasons: The old-school advice was
to have several, geographically and topologically diverse _mail_ servers
to accept SMTP mail on your domain's behalf -- in addition to your
diverse nameservers. All third party "mail exchangers" (MXes) would
then forward received mail to your primary one, which would be
designated in the DNS as the highest "priority" exchanger, i.e., the one
that should be the preferred drop-off point if/when possible, using
others just as fallbacks.
That was before the spam explosion. Spammers quickly figured out that
they should reverse normal reasoning and _preferentially_ use the
lower-"priority" MXes as drop-off points. Why? Because they are less
likely to have effective anti-spam measures and will more likely be
idle. Yes, having to needlessly redeliver that mail wastes machine
time and bandwidth, but it's not the _spammer's_ machine time and
bandwidth being wasted, it's the victims'.
My current policy that I will list as MXes _only_ machines (1) under my
personal administrative control, and (2) implementing the exact same
antispam regime. Currently, that means just one box.
The disadvantage of using just one box is, as the warning implies, that
it's a single point of failure. My take on that is that I'm very
confident that, in the event of outage, I can bring some MX for
linuxmafia.com back online, somewhere in the world, within the usual
four-day SMTP timeout period. Given that assumption, having multiple
MXes wouldn't actually buy me anything.
Status: WARN
Test name: Acceptance of abuse address
Information: WARNING: One or more of your mailservers does not accept
mail to abuse at linuxmafia.com. Mailservers are expected by RFC2142 to
accept mail to abuse.
linuxmafia.com's abuse response:
>>> RCPT TO:<abuse at linuxmafia.com>
<<< 550 Only one recipient accepted for NULL sender.
The CGI's testing code isn't perfect: Here, it's tripping on one of my
antispam tests: It's (apparently) trying to combine three tests of my
domain's RFC compliance into one test e-mail.
1. My domain's supposed to accept mail from the null sender ("<>").
This is used for delivery status notifications, e.g., "Your message
is in queue and has not been deliverable for the past four hours...."
2. My domain's supposed to accept mail TO the abuse@ user.
3. My domain's supposed to accept mail TO the postmaster@ user.
So, the test initiates test e-mail from the null sender, CCed to those
two recipients -- immediately tripping over one of my antispam rules
requiring that mail from the null sender be addressed to one recipient
only.
The CGI's warning is thus slightly bogus, and is repeated several times
in other forms.
Using the www.dnsreport.com CGI on properly administered domains is
slightly boring, though. Let's have a look at the report for
"linuxjournal.com"!
Status: FAIL
Test name: Missing (stealth) nameservers
Information: FAIL: You have one or more missing (stealth)
nameservers. The following nameserver(s) are listed (at your
nameservers) as nameservers for your domain, but are not listed at
the parent nameservers (therefore, they may or may not get used,
depending on whether your DNS servers return them in the authority
section for other requests, per RFC2181 5.4.1). You need to make
sure that these stealth nameservers are working; if they are not
responding, you may have serious problems! The DNS Report will not
query these servers, so you need to be very careful that they are
working properly.
Status: FAIL
Test name: Stealth NS record leakage
Information: Your DNS servers leak stealth information in non-NS
requests:
Stealth nameservers are leaked [ns3.ssc.com.]!
This can cause some serious problems (especially if there is a TTL
discrepancy). If you must have stealth NS records (NS records listed
at the authoritative DNS servers, but not the parent DNS servers),
you should make sure that your DNS server does not leak the stealth
NS records in response to other queries.
Uh oh! Someone's not been updating his glue records!
Status: WARN
Test name: SOA MNAME Check
Information: WARNING: Your SOA (Start of Authority) record states
that your master (primary) name server is: hydra.ssc.com.. However,
that server is not listed at the parent servers as one of your NS
records! This is probably legal, but you should be sure that you
know what you are doing.
I made this error for a while, myself. It's a matter of putting the
wrong hostname in your SOA header in your zonefile as the "master
nameserver": I put "linuxmafia.com." there, originally, even though the
name of the _nameserver_ at linuxmafia.com is "NS1.LINUXMAFIA.COM". The
error slipped by me for years, until I used this CGI to check my work.
(If you check the report for microsoft.com, they're making the same
error. As is penguincomputing.com.)
At a brief glance at other reports:
o svlug.org is pretty messed up (missing glue records, mismatched
glue records, nameservers not responding, unresponsive MX).
o baylisa.org has a minor glue-record problem.
o balug.org has a few problems.
o stanford.edu has all its nameservers on-campus. (Hubris.)
o oreilly.com has missing glue at the parent domain, and some other
errors.
o vasoftware.com has some non-responding nameservers. (That's what
you get when you lay off all your sysadmins, guys.)
o penguincomputing.com is screwing up its SOA records in multiple ways.
I do recommend checking one's DNS using the www.dnsreport.com CGI
report. It gives (in general) good advice and information.
More information about the conspire
mailing list