[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