[conspire] How not to muck up DNS & domain registration
Daniel Gimpelevich
daniel at gimpelevich.san-francisco.ca.us
Tue Apr 12 20:33:36 PDT 2005
Thanks for the pointer on the DNS report site. I have used it to check my
domain, and one of the warnings it issued troubles me, regarding an SPF
record. I have never heard of one of those before. Do you have any
pointers on how not to muck one of those up? I also noticed the lack of a
check for validity of my RP record. Any online checks for that?
On Tue, 12 Apr 2005 13:22:42 -0700, Rick Moen wrote:
>
> 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