[TAG] Re: "I'll host it myself, thanks", part II
Rick Moen
rick at linuxmafia.com
Tue Nov 29 07:18:54 MSK 2005
More about Dreamhost, the RFC-compliance-challenged "Web 2.0" hosting
outfit I mentioned earlier.
(I promised Ben I'd send him a copy of this stuff.)
----- Forwarded message from Rick Moen <rick> -----
Date: Wed, 23 Nov 2005 19:05:17 -0800
From: Rick Moen <rick>
To: luv-main at luv.asn.au
Subject: Re: MS Exchange why nots?
I wrote:
> I'd be a _little_ more impressed with Dreamhost if it at least bothered
> to accept postmaster mail for its virthosts, as required by RFC822 6.3,
> RFC1123 5.2.7, and RFC2821 4.5.1. For lack of that basic level of
> competence, a lot of their customers' mail gets filtered out.
>
> If those customers had their own mail servers, they'd be able to fix
> the omission. ;->
Just as a follow-up, Dreamhost are equally inept with DNS -- in a
particular sense that is widely true of cut-rate, commodity hosting
providers. E.g., DomainDirect does it too, as do many others.
To explain: Have a look at this report on the Bay Area Linux User Group
domain's DNS, which along with the Web site itself is hosted at
Dreamhost:
http://www.dnsreport.com/tools/dnsreport.ch?domain=balug.org
Notice that none of the Dreamhost's three nameservers have "glue" at the
parent .ORG zone. The practical consequence of that is that BALUG's
DNS is unnecessarily slow, because each lookup of its NS records must
be followed up by an otherwise unnecessary matching "A" lookup -- for
lack of glue records.
Glue records are "A" records for nameservers within the parent zone,
that get sent back with results of all queries for NS data,
_specifically_ to avert the need for that second lookup. (In special
edge cases, glue records also avoid a chicken-and-egg problem -- if the
nameserver's hostname is _within_ the zone it serves.)
As it happens, there _cannot_ be glue records within .ORG concerning
.COM (or, e.g., .NET) nameservers, because such would be
out-of-bailiwick and hence DNS-illegal on grounds of preventing cache
poisioning -- because the .ORG TLD has no delegated authority over .COM
hostnames.
How _should_ Dreamhost deal with such bailiwick problems? By creating
new NS and A records _within_ the domain in question (e.g., balug.org)
pointing to its nameserver IPs, and adding _those_ to the parent
zonefile. E.g., they'd add lines for NS1.BALUG.ORG, etc.
Why didn't they? Because their one-size-fits-all solution that ignores
bailiwick problems is easier, and doesn't require their staff to know
what they're doing. They either assume their customers don't know better,
or more likely aren't even aware of the issue or the resulting
performance hit.
We keep being told how much more reliable "hosted" services are -- and
yet, why is it that individual Linux hobbyists so often do a better job?
(BALUG are at Dreamhost because one of their volunteers likes the outfit
-- even though more Dreamhost lapses of diligence becoming apparent all
the time, like that bit about rejecting mail to postmaster.)
----- End forwarded message -----
----- Forwarded message from rick -----
[RM comments: This post _immediately_ below, having been a bit rushed,
included some slightly off-target analysis in it -- which I then
corrected in a follow-up post, included below it. Sorry about that.]
Date: Fri, 25 Nov 2005 13:59:38 -0800 To: luv-main at luv.asn.au Subject:
Re: MS Exchange why nots?
Quoting Brian May (bam at snoopy.apana.org.au):
> Are you sure about this? I have seen references that state glue
> records are evil and you should not use them unless you absolutely
> have to, for example if the A record is in the domain being defined.
Well, _wrong_ glue records are evil, as they can be used by malign
nameserver operators (or intruders who've compromised nameservers) for
cache poisoning. (Caches do or should protect aagainst this by vetting
bailiwicks, and rejecting any returned glue information that's outside
the reporting nameserver's bailiwick.) _Correct_ glue records are in the
general case a useful aid to good DNS performance, and in one edge case
are necessary to make nameservice work at all. (See my discussion of
your RFC1537 item, below.)
That is, consider what happens when a caching nameserver gets a client
request, doesn't yet have what's asked for in cache, and has to find the
target domain's nameservers: It queries for "NS" records for that
domain, like this:
[rick at linuxmafia]
~ $ dig -t ns balug.org
; <<>> DiG 9.3.1 <<>> -t ns balug.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52687
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;balug.org. IN NS
;; ANSWER SECTION:
balug.org. 14313 IN NS ns2.dreamhost.com.
balug.org. 14313 IN NS ns3.dreamhost.com.
balug.org. 14313 IN NS ns1.dreamhost.com.
;; ADDITIONAL SECTION:
ns1.dreamhost.com. 12931 IN A 66.33.206.206
ns2.dreamhost.com. 1034 IN A 66.201.54.66
ns3.dreamhost.com. 170293 IN A 66.33.216.216
;; Query time: 55 msec
;; SERVER: 198.144.192.2#53(198.144.192.2)
;; WHEN: Fri Nov 25 13:15:02 2005
;; MSG SIZE rcvd: 142
[rick at linuxmafia]
~ $
The three lines in "ANSWER SECTION" are the information requested:
Notice that what are provided are _hostnames_: Before the querying
nameserver can proceed with using those nameserver locations, it must
resolve the nameserver hostnames to IPs, which would thus be (in the
absensce of valid glue information) a separate lookup.
Now, it happens to be the case that the NS results above _were_
accompanied by glue information, that being the three "A" lines in the
"ADDITIONAL SECTION" -- but DNS cache software will in general (if
correctly written) reject those glue records as being _invalid_ on
grounds of being outside the responding .ORG nameserver's bailiwick:
.ORG has no authority for .COM names.
Therefore, since it can't (or shouldn't, for security reasons) accept
the glue information it just received from .ORG, the querying nameserver
has to follow up with an "A" query to the .COM TLD servers, instead:
[rick at linuxmafia]
~ $ dig -t a ns1.dreamhost.com
; <<>> DiG 9.3.1 <<>> -t a ns1.dreamhost.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21232
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION:
;ns1.dreamhost.com. IN A
;; ANSWER SECTION:
ns1.dreamhost.com. 11665 IN A 66.33.206.206
;; AUTHORITY SECTION:
dreamhost.com. 10712 IN NS ns2.dreamhost.com.
dreamhost.com. 10712 IN NS ns3.dreamhost.com.
dreamhost.com. 10712 IN NS ns1.dreamhost.com.
;; ADDITIONAL SECTION:
ns2.dreamhost.com. 14206 IN A 66.201.54.66
ns3.dreamhost.com. 169027 IN A 66.33.216.216
;; Query time: 54 msec
;; SERVER: 198.144.192.2#53(198.144.192.2)
;; WHEN: Fri Nov 25 13:36:08 2005
;; MSG SIZE rcvd: 133
[rick at linuxmafia]
~ $
Thus, _two_ queries required (versus one), for lack of valid glue.
By way of comparison, consider this similar query:
[rick at linuxmafia]
~ $ dig -t ns randometry.com
; <<>> DiG 9.3.1 <<>> -t ns randometry.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46422
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;randometry.com. IN NS
;; ANSWER SECTION:
randometry.com. 56390 IN NS myrddin.imat.com.
randometry.com. 56390 IN NS ns.zork.NET.
;; ADDITIONAL SECTION:
ns.zork.NET. 28346 IN A 70.85.129.199
myrddin.imat.com. 142790 IN A 207.214.84.142
;; Query time: 54 msec
;; SERVER: 198.144.192.2#53(198.144.192.2)
;; WHEN: Fri Nov 25 13:39:18 2005
;; MSG SIZE rcvd: 116
[rick at linuxmafia]
~ $
In this case, the querying nameserver _can_ safely accept the glue
records furnished in the "ADDITIONAL SECTION" pair of lines, because the
nameservers for the .COM TLD have authority over both .NET and .COM (and
thus are said to be in-bailiwick).
> However, see RFC1537 section 2.
Yes?
Glue records need only be in a zone file if the server host is within
the zone and there is no A record for that host elsewhere in the zone
file.
This accurately describes the above-mentioned edge case, where glue
records are necessary to avoid a chicken-and-egg problem. In the
general case, they are not necessary, merely helpful to good DNS
performance, averting the need for a second query to look up and use NS
records. Which is what I said.
Old BIND versions ("native" 4.8.3 and older versions) showed the
problem that wrong glue records could enter secondary servers in a
zone transfer.
When done with malign intent, this is "cache poisoning". This is one of
the reasons why running antique versions of BIND is a really bad idea:
They don't check bailiwick.
RFC author P. Beertema says, in short, wrong glue records are bad. I
agree: I recommend _correct_ glue records.
If you prefer for every NS record to require two lookups instead of one,
then go ahead and dislike glue records. ;->
----- End forwarded message -----
----- Forwarded message from Rick Moen <rick> -----
Date: Mon, 28 Nov 2005 09:34:27 -0800
From: Rick Moen <rick>
To: luv-main at luv.asn.au
Subject: Re: MS Exchange why nots?
A couple of days ago, I wrote:
> Well, _wrong_ glue records are evil, as they can be used by malign
> nameserver operators (or intruders who've compromised nameservers) for
> cache poisoning. (Caches do or should protect aagainst this by vetting
> bailiwicks, and rejecting any returned glue information that's outside
> the reporting nameserver's bailiwick.) _Correct_ glue records are in the
> general case a useful aid to good DNS performance, and in one edge case
> are necessary to make nameservice work at all. (See my discussion of
> your RFC1537 item, below.)
>
> That is, consider what happens when a caching nameserver gets a client
> request, doesn't yet have what's asked for in cache, and has to find the
> target domain's nameservers: It queries for "NS" records for that
> domain, like this:
[snip my "dig -t ns balug.org" example.]
Apologies for having been too rushed in picking that example: It was
slightly wrong, in that I should have queried NS records at the
_parent_ zone, i.e., in .ORG. One suitable place to ask would be
tld6.ultradns.co.uk[1] , like this:
[rick at linuxmafia]
~ $ dig -t ns balug.org @tld6.ultradns.co.uk
; <<>> DiG 9.3.1 <<>> -t ns balug.org @tld6.ultradns.co.uk
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2447
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;balug.org. IN NS
;; 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.
;; Query time: 85 msec
;; SERVER: 198.133.199.11#53(198.133.199.11)
;; WHEN: Mon Nov 28 09:14:54 2005
;; MSG SIZE rcvd: 94
[rick at linuxmafia]
~ $
You'll notice that, this time, there _is_ no "ADDITIONAL SECTION"
information (and thus, no glue records). Thus there must be an
otherwise avoidable follow-up "A" query for every "NS" query, on this
domain. That's because the listed .COM nameservers are out-of-bailiwick
for the .ORG parent zone's nameservers: They have no authority in that
namespace.
Contrast those results with the same sort of test for a different domain,
randometry.com, whose two nameservers are both in-bailiwick for the
parent .COM domain. In this case, an appropriate server to ask would be
m.gtld-servers.net[2].
[rick at linuxmafia]
~ $ dig -t ns randometry.com @m.gtld-servers.net
; <<>> DiG 9.3.1 <<>> -t ns randometry.com @m.gtld-servers.net
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39527
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;randometry.com. IN NS
;; ANSWER SECTION:
randometry.com. 172800 IN NS myrddin.imat.com.
randometry.com. 172800 IN NS ns.zork.net.
;; ADDITIONAL SECTION:
myrddin.imat.com. 172800 IN A 207.214.84.142
ns.zork.net. 172800 IN A 70.85.129.199
;; Query time: 271 msec
;; SERVER: 192.55.83.30#53(192.55.83.30)
;; WHEN: Mon Nov 28 09:27:16 2005
;; MSG SIZE rcvd: 116
[rick at linuxmafia]
~ $
Please notice that the returned results include not just the hostnames of
the NS entries asked about, but also their IP addresses in the
"ADDITIONAL SECTION" stanza, thus averting the aformentioned second
lookup.
I hope that example makes my point clearer, and apologise for muffing it
the first time.
[1] http://www.iana.org/root-whois/org.htm
[2] http://www.iana.org/root-whois/com.htm
--
Cheers,
Rick Moen "Anger makes dull men witty, but it keeps them poor."
rick at linuxmafia.com -- Elizabeth Tudor
----- End forwarded message -----
More information about the TAG
mailing list