This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Sun, 17 Dec 2000 00:20:21 -0800
From: Marc MERLIN <marc_news@valinux.com>
To: svlug@svlug.org
Subject: [svlug] SVLUG sometimes resolving to 209.81.8.243
Before anyone asks, we know about the problem, it's not new, in the past we
just "fixed" it by putting a 209.81.8.243 IP alias on the SVLUG box.
However, that doesn't work anymore because we moved networks yesterday and
209.81.8.x is no more.
The DNS zone is correct, and so is our slave, thor.sbay.org, but if you ask
some root servers about www.svlug.org, they will tell you 209.81.8.243
without even refering you to our name servers.
Why? Well, apparently because of this:
http://www.networksolutions.com/cgi-bin/whois/whois?!WWW7974-HST&id=0
Yes, NSI sucks (what's new?):
1) This record is not a name server for svlug.org (and hasn't been for more
than one year, if it ever was in the first place)
2) NSI has no business keeping that stale host record
3) Root name servers have no business returning junk that is fed to them by
NSI.
We're going to call them on monday and try to get them to drop this stupid
host record that is screwing us up.
In the meantime, if your name server is returning the bad IP, try querying
http://svlug.org/ or http://svlug.svlug.org/
We'll do what we can to fix this, but since we're dealing with NSI, god
knows...
===
Date: Sun, 17 Dec 2000 08:42:32 -0800
To: Marc MERLIN <marc_news@valinux.com>
From: "Derek J. Balling" <dredd@megacity.org>
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
At 12:20 AM -0800 12/17/00, Marc MERLIN wrote:
>The DNS zone is correct, and so is our slave, thor.sbay.org, but if you ask
>some root servers about www.svlug.org, they will tell you 209.81.8.243
>without even refering you to our name servers.
>Why? Well, apparently because of this:
>http://www.networksolutions.com/cgi-bin/whois/whois?!WWW7974-HST&id=0
>
>Yes, NSI sucks (what's new?):
>1) This record is not a name server for svlug.org (and hasn't been for more
> than one year, if it ever was in the first place)
>2) NSI has no business keeping that stale host record
>3) Root name servers have no business returning junk that is fed to them by
> NSI.
>
>We're going to call them on monday and try to get them to drop this stupid
>host record that is screwing us up.
>In the meantime, if your name server is returning the bad IP, try querying
>http://svlug.org/ or http://svlug.svlug.org/
>
>We'll do what we can to fix this, but since we're dealing with NSI, god
>knows...
Wrong wrong wrong on so many counts.
(1) Irrelevant. The record was CREATED as a nameserver, and so has an A
glue-record in the root servers.
(2) NSI has every reason to keep it around. They have no idea what other
domains registered with non-NSI domains might be dependent upon it. Just
because you've moved the machine elsewhere to another IP address doesn't
make some magic happen at NSI telling them "ok to move"...how do they know
you don't have a domain @ OpenSRS using it? Or even that next week you PLAN
to have a domain @ OpenSRS using the record. You created the record, it is
your responsibility to dispose of or correct the record.
(3) Actually, nameservers are the one type of record that really is
supposed to be included in the root servers.
No registrar would be any different, Marc, because that's how DNS *works*.
===
Date: Mon, 18 Dec 2000 21:38:14 -0800
To: svlug@svlug.org
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
From: Rick Moen <rick@linuxmafia.com>
begin Marc MERLIN quotation:
> Why? Well, apparently because of this:
> http://www.networksolutions.com/cgi-bin/whois/whois?!WWW7974-HST&id=0
The existence of that host record entry means that the indicated IP
address (209.81.8.243) can be included in people's domain records as an
authoritative nameserver. To find out what nameservers _are_ in fact
currently authoritative for SVLUG's second-level domain, you have to
look at the appropriate domain record:
rick@chico:/usr/local/home/rick$ whois -h whois.networksolutions.com svlug.org
[...]
Registrant:
Silicon Valley Linux User's Group (SVLUG-DOM)
1334 Holly Ave
Sunnyvale, CA 94024
US
Domain Name: SVLUG.ORG
Administrative Contact, Technical Contact:
DiBona, Chris J (CJD32) chris@DIBONA.COM
Precognitive Technological Design
1334 Holly Ave
Los Altos, CA 94024
408-621-7046
Billing Contact:
DNS Billing Account (DB1850-ORG) dns-billing@VALINUX.COM
VA Linux Systems
1382 Bordeaux Drive
Sunnyvale, CA 94089
US
408-542-8600 Fax- 408-745-9152
Record last updated on 09-Jun-2000.
Record expires on 08-Aug-2003.
Record created on 07-Aug-1997.
Database last updated on 18-Dec-2000 14:23:20 EST.
Domain servers in listed order:
NS1.VARESEARCH.COM 198.186.202.185
THOR.SBAY.ORG 63.200.41.38
I'm not sure exactly what is (was?) the origin of the symptom, but _no_
number of superfluous host records, per se, could cause it -- no matter
how wrong they are -- as long as they aren't cited in the domain record,
and thus are not authoritative.
===
Date: Sun, 17 Dec 2000 09:02:18 -0800
To: Marc MERLIN <marc_news@valinux.com>, svlug@svlug.org
From: "Derek J. Balling" <dredd@megacity.org>
Subject: [svlug] Re: DNS lesson, followup
>(3) Actually, nameservers are the one type of record that really is
>supposed to be included in the root servers.
Actually, for the uninitiated, I figured I would explain the "why" on that.
When you query for a domain for the first time, you ask the root servers
for an "NS" (Name Server) record for the domain. An NS RR contains a
hostname, for example, the one for megacity.org contains "ns1.megacity.org".
Now wait... to get to www.megacity.org, you now need to find the IP address
for ns1.megacity.org, so you can query it? But how do you get the IP
address for ns1.megacity.org without actually having the IP address to
QUERY ns1.megacity.org?
Simple, the root-server provides it as an informational record, for example:
$ dig @a.root-servers.net megacity.org ns
; <<>> DiG 9.1.0b1 <<>> @a.root-servers.net megacity.org ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44904
;; flags: qr rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;megacity.org. IN NS
;; ANSWER SECTION:
megacity.org. 172800 IN NS NS2.PYROTECHNICS.COM.
megacity.org. 172800 IN NS NS1.megacity.org.
megacity.org. 172800 IN NS NS1.PYROTECHNICS.COM.
;; ADDITIONAL SECTION:
NS2.PYROTECHNICS.COM. 172800 IN A 207.7.10.3
NS1.megacity.org. 172800 IN A 63.201.65.218
NS1.PYROTECHNICS.COM. 172800 IN A 207.7.10.2
These additional records are commonly called "glue records", and are
necessary to keep things actually working.
Since there ARE TLD's outside the control of NSI, they have to keep sending
the glue records up the chain. It's what they're required to do, in case
some OTHER domain they don't know about (maybe in a different registrar,
maybe even in a ccTLD they know nothing about whatsoever) needs to
reference it.
[Silliness of naming the mandatory NS record "WWW.SVLUG.ORG" ignored]
Hope this clears it up for folks. :)
d
===