----- Forwarded message from Rick Moen <rick@linuxmafia.com> ----- Date: Sat, 28 Feb 2009 16:56:46 -0800 From: Rick Moen <rick@linuxmafia.com> To: sf-lug@linuxmafia.com Subject: Re: [sf-lug] balug.org DNS (was: sf-lug.com web site accessibility) Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

No changes regarding balug.org DNS that I'm aware of ... at least that are or would be problematic.

As an additional exercise, I'll now show you how I might check out whether balug.org DNS is OK. This is something _anyone_ can do, even MS-Windows sufferers. (There's a free-of-charge download of "whois" and "dig" programs in MS-Windows executable format on the Web.) In my former e-mail, I was launching shell commands inside of vi, while composing my mailing list reply in that editor -- indicating so doing by typing ":r! " at the beginning of a line to show a vi shell escape. In the following, for clarity's sake, I'll just show "$" to indicate a bash prompt, OK? First, we want to identify balug.org's _authoritative_ nameservers. Anyone can set up a DNS nameserver that claims to be publishing reliable balug.org DNS information, but the only ones people will _consult_ are the ones the parent zone -- that would be .org in the case of balug.org -- identifies as having authority over balug.org. There are two ways to do this. One is to ask the shared "WHOIS" registries that all of the domain registrars communicate with and share. One can do that with the "whois" command, looking specifically for the lines starting with "Name Server": $ whois balug.org | grep "Name Server" Name Server:NS1.DREAMHOST.COM Name Server:NS2.DREAMHOST.COM Name Server:NS3.DREAMHOST.COM Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: Name Server: The other way is to ask the nameservers for "org." directly -- which makes this as two-step process, because you first have to find one of the six nameservers that serve up "org."'s information, and then ask one of them "What are the nameservers for balug.org?" The best tool, as for just about any other DNS query, is "dig": $ dig -t ns org. +short #What are org.'s nameservers? a0.org.afilias-nst.info. a2.org.afilias-nst.info. b0.org.afilias-nst.org. b2.org.afilias-nst.org. c0.org.afilias-nst.info. d0.org.afilias-nst.org. Now that you have the list of org nameservers, you can ask _them_ about balug.org's nameservers. I had to do a little fiddling, because it turns out that the people who now operate org aren't returning exactly correct results any more. (They should be giving data in the Answer Section, not just in the Authority Section that is omitted if you query using the "+short" flag.) $ dig -t ns balug.org @a0.org.afilias-nst.info. [...] ;; AUTHORITY SECTION: balug.org. 86400 IN NS ns3.dreamhost.com. balug.org. 86400 IN NS ns2.dreamhost.com. balug.org. 86400 IN NS ns1.dreamhost.com. Please note: The _order_ in which authoritative nameservers (or, for that matter, "NS" lines in zonefiles) are listed is _not_ significant. You have absolutely no idea which server will get used/consulted during normal DNS operations. dig's "@", by contrast, allows you to send a query directly to a specific nameserver, but DNS generally goes first to wherever that machine's DNS gets shoveled off to, eventually getting to data originated some time back by an unpredictably selected authoritative server and then cached for some period of time (with the result that you can't predict where it came from, and it might be obsolete). You might be thinking, "Hey, wait, what about the fact that one of the authoritative servers for the zone is the master, and all others are slaves?" Master/slave relationship for zonefiles has nothing to do with _serving_ of DNS. It solely concerns which of the authoritative servers publishes the master copy to the others -- and actually isn't essential to DNS at all, as there are other ways of propagating zone information (e.g., having several machines in dispersed locations all drawing data from a single database, as back-end data). Anyway, now that we know what three machines have authority for balug.org we ask them for the SOA record, which includes the zonefile S/N: $ dig -t soa balug.org @ns1.dreamhost.com +short ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400 $ dig -t soa balug.org @ns2.dreamhost.com +short ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400 $ dig -t soa balug.org @ns3.dreamhost.com +short ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400 All of them report zonefile serial number "2008070600", which by convention means that it was last updated on 2008 07 06 (July 6, 2008) and was update #00 on that day. The fact that the three nameservers all report the _same_ S/N is encouraging, as it makes it very likely that they are in proper communication. Incidentally, one of the other SOA subfields, "ns1.dreamhost.com", is supposed to be where you declare the location of the master zonefile copy. However, the field value is strictly informational, and often (for many zones) lacks correct and useful data. (As noted above, the very notion that there's necessarily a master server for each zone doesn't necessarily apply.) Last, there's some merit to actually asking each of the nameservers about some record that's genuinely of interest, such as "www.balug.org" or "lists.balug.org": $ dig www.balug.org @ns1.dreamhost.com +short 208.113.160.236 $ dig www.balug.org @ns2.dreamhost.com +short ;; Truncated, retrying in TCP mode. 208.113.160.236 $ dig www.balug.org @ns3.dreamhost.com +short 208.113.160.236 Notice that Dreamhost is being a bit of a screwup, concerning "ns2.dreamhost.com": It's not giving useful, complete responses to UDP-based queries -- e.g., fragmenting them across multiple packets, which UDP doesn't support -- so, dig went back and tried again using a TCP-type query, which worked. Trying again a moment later worked without switching to TCP, so it was probably a temporary glitch. However, this underscores why it's important that you _not_ firewall off 53/tcp, when you're operating a nameserver. In an ideal world, I'd be in a position to know whether "208.113.160.236" is really the correct IP for www.balug.org, which I'm not, but someone actually running the domain (and especially its DNS) no doubt would. One last point about the SOA record: "hostmaster.dreamhost.com." is supposed to indicate the e-mail address of the administrative person responsible for the contents of the master zonefile, expressed with the "@" turned into a period on account of an antique software limitation that was in place when the RFC was written. So, the e-mail address is "hostmaster@dreamhost.com". It may or may not be in BALUG's interest for (theoretical) queries about the zone's contents to go to Dreamhost's DNS administrator. Does BALUG edit its own DNS? If it does, it might wish to put someone else's e-mail address there. (Note: However, hardly anyone ever uses that data, which is likewise an informational record only, and often doesn't have a useful e-mail address at all. Most often, people will contact the Administrative, Technical, or Registrant contacts from the WHOIS record, or just go straight for the webmaster as indicated on the Web site (if accessible).) _______________________________________________ sf-lug mailing list sf-lug@linuxmafia.com http://linuxmafia.com/mailman/listinfo/sf-lug ----- End forwarded message -----