This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Sat, 30 Dec 2000 11:36:24 -0800
To: "Derek J. Balling" <dredd@megacity.org>
Cc: svlug@svlug.org
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
From: Rick Moen <rick@linuxmafia.com>
begin Derek J. Balling quotation:
> NSI will happily allow you to delete host records, provided that no
> domain is using that host record as a nameserver. If a domain IS using
> it as a nameserver, then those domains must be corrected first.
Exactly. Which raises the related question of _who_ is authorised to
delete a host record. Let me tell you a story:
When my nameserver was hosted at 744 Harrison, San Francisco (the
CoffeeNet building), bearing IP address 140.174.70.21, the first person
to use it in as a DNS entry for a domain record was Don Marti, when he
registered lincexpo.ORG. Accordingly, his registrar (which happened to
be NSI, at the time) created a host record for IP address 140.174.70.21,
imputing the name "HUGIN.LINCEXPO.ORG" to the host record.
Later, I sought to use my nameserver in other domain records, and all my
efforts to do so failed. Upon investigation, it turned out that NSI
would not accept any attempt by rick@linuxmafia.com or
root@linuxmafia.com to use host record HUGIN.LINCEXPO.ORG, because Don
Marti owned the domain of which that host record was a part (i.e.,
LINCEXPO.ORG). Likewise, I would not be allowed to delete the host
record. Only Don Marti would, and only if/when the host record was no
longer referenced in any domain record.
My temporary fix was for Don to have my NIC contact handle, RM1000,
added as an administrative contact for the host record. NSI still
considered Don to _own_ my nameserver's host record, but I was allowed
to administer it (e.g., use it for domain records).
In the longer term, in essence IP address 140.174.70.21 became
administratively damaged the day that Don caused NSI to create a host
record for it. The easiest way for me to regain full use of my
nameserver would be to switch to a different IP address, and let my
landlord Richard Couture grapple with the fscked-up administrative
status of 140.174.70.21 on his own.
Fortunately for me, this situation resolved itself in early 2000, when I
moved my machine down to my new house in Menlo Park, and thus onto a
new IP address. One of the first things I did was create a host record
for IP address 209.81.22.250 that *I* would solely own, making sure that
_my_ DNS registrar, Domain Discover, created it with name
NS1.LINUXMAFIA.COM, i.e., as part of a domain that I likewise owned.
As far as I'm aware, the host record HUGIN.LINCEXPO.ORG still exists,
and continues to impair the use of IP address 140.174.70.21. (It'd
be a neighbourly act for Don do request its deletion.) But this is
no longer my problem, as its mere existence in no way affects my
nameserver or my domains.
Which is why I said that the mere existence of an obsolete host record
does not constitute a candidate explanation for bogus DNS results.
I've been there.
===
From: Alvin Oga <alvin@planet.fef.com>
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243 - moving domains etc
To: rick@linuxmafia.com (Rick Moen)
Date: Sat, 30 Dec 2000 15:56:00 -0800 (PST)
Cc: svlug@svlug.org, alvin@planet.fef.com (Alvin Oga)
hi ya rick
> Exactly. Which raises the related question of _who_ is authorised to
> delete a host record. Let me tell you a story:
>
> When my nameserver was hosted at 744 Harrison, San Francisco (the
> CoffeeNet building), bearing IP address 140.174.70.21, the first person
> to use it in as a DNS entry for a domain record was Don Marti, when he
> registered lincexpo.ORG. Accordingly, his registrar (which happened to
> be NSI, at the time) created a host record for IP address 140.174.70.21,
> imputing the name "HUGIN.LINCEXPO.ORG" to the host record.
>
> Later, I sought to use my nameserver in other domain records, and all my
> efforts to do so failed. Upon investigation, it turned out that NSI
> would not accept any attempt by rick@linuxmafia.com or
> root@linuxmafia.com to use host record HUGIN.LINCEXPO.ORG, because Don
> Marti owned the domain of which that host record was a part (i.e.,
> LINCEXPO.ORG). Likewise, I would not be allowed to delete the host
> record. Only Don Marti would, and only if/when the host record was no
> longer referenced in any domain record.
yeah.... this sounds goood for most cases... but....
( that only don or lincexpo.org can make changes to itself...
I also know that people that is not on record for a domain be able
to move a domain to their own isp's ip#....
- they were not the tech contact, not the admin contact
and not the billing contact.... nor share the same ip# range
- yet they moved the domain to their own isp...
( probably a legal dept move...lawyer talking to other lawyers ?
and with more mergers and shutdowns....guess "stealing domains"
or ability to transfer domains with no notices sent might become
a bigger issue ???
- used to like getting "hey...this person is doing this
to the domain you are on record for....do you approve ??"....
- and yet... when we are associated with the DNS server ip# range or
listed as one or more of the contacts... we cannot do simple 2 minute changes
of moving the dns server to a different ip# or street address changes etc..etc...
===
Date: Sat, 30 Dec 2000 16:39:30 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243 - moving domains etc
begin Alvin Oga quotation:
> yeah.... this sounds goood for most cases... but....
> ( that only don or lincexpo.org can make changes to itself...
>
> I also know that people that is not on record for a domain be able
> to move a domain to their own isp's ip#....
> - they were not the tech contact, not the admin contact
> and not the billing contact.... nor share the same ip# range
>
> - yet they moved the domain to their own isp...
> ( probably a legal dept move...lawyer talking to other lawyers ?
That's a case of someone taking advantage of a domain not using the
registrars' security options. Different subject.
===
Date: Sat, 30 Dec 2000 20:01:14 -0800
To: SVLUG <svlug@svlug.org>
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
From: Rick Moen <rick@linuxmafia.com>
begin Bill Schoolcraft quotation:
> Jeez, I'm currently using http://he.net (Hurricane Electric) to
> redirect billschoolcraft.com to my house which is 63.193.247.201 and
> want to resolve my own site. I'm currently reading the book by Craig
> Hunt called "Linux DNS Server Administration"
> http://www.amazon.com/exec/obidos/ASIN/0782127363/ref=sc_b_6/107-0789789-
> 5551725 and I'm hesitant to do so till I fully understand this.
>
> I was going to try it this weekend till I read your (Rick Moen's)
> email, I see I need more knowledge on this subject.
Bill --
The reason this stuff isn't covered in books on DNS administration is
that -- in a weird way -- it isn't really part of DNS. It's a different
subject, namely understanding how DNS registration works.
In studying DNS, you've read about authoritative vs. non-authoritative
DNS, right? Just setting up a nameserver that purports to have
information about foo.com or subdomain.foo.com doesn't do much good
unless the rest of the world knows that it should consult your
nameserver for that information. This is the DNS concept of authority;
your nameserver is respected as a source of information for foo.com or
subdomain.foo.com because of a convention we share about how to
determine where to find authoritative information on particular domains:
Authority is delegated downwards from the _root servers_.
For the generic top-level domains (gTLDs) -- com, org, and net (but not
gov or mil) -- authority was traditionally invested in an organisation
called the InterNIC, operated by NSI under contract to the first the
Defense Advanced Research Projects Agency (DARPA), then the National
Science Foundation (NSF) -- with the U.S. Department of Commerce
stepping in most recently. NSI's registry division maintains a database
to keep track of what nameservers are to be listed as authoritative for
all the vast number of second-level domains (SLDs) of com, org, and net
-- e.g., linuxmafia.com .
Three different types of records figure in that database: domain
records, contact ("handle") recods, and host records. Here's a domain
record:
rick@chico:/home/rick$ whois -h whois.networksolutions.com imat.com
[NSI cruft snipped]
Domain Name: IMAT.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
Name Server: IRIDIUM.NIVENSMITH.COM
Name Server: MYRDDIN.IMAT.COM
Updated Date: 06-aug-2000
[more administrative cruft snipped]
Registrant:
Imagine That (IMAT-DOM)
P. O. Box 190217
San Francisco, CA 94119-0217 US
Domain Name: IMAT.COM
Administrative Contact:
Couture, Richard R (RRC459) rrc@NIVENSMITH.COM
Linux Cabal
P. O. Box 190217
San Francisco, CA 94119-0217 US
(415) 647-2347
Technical Contact, Billing Contact:
Couture, Richard (RC334) rrc@MYRDDIN.IMAT.COM
Imagine That
P. O. Box 190217
San Francisco, CA 94119-0217
(415)495-2806
Record last updated on 30-Nov-2000.
Record expires on 26-Aug-2001.
Record created on 25-Aug-1992.
Database last updated on 30-Dec-2000 10:48:31 EST.
Domain servers in listed order:
MYRDDIN.IMAT.COM 140.174.70.1
IRIDIUM.NIVENSMITH.COM 209.152.151.254
You will note the "RRC459" part. That's the InterNIC handle for
Richard Couture as a "contact" for DNS administration. We can query
NSI's whois server (since NSI is his registrar) for the information in
his handle (contact) record, using keyword "HA" to indicate that we're
asking about a handle:
rick@chico:/home/rick$ whois -h whois.networksolutions.com HA RRC459
[NSI cruft snipped]
Couture, Richard R (RRC459) rrc@NIVENSMITH.COM
Linux Cabal
P. O. Box 190217
San Francisco, CA 94119-0217 US
(415) 647-2347
Record last updated on 19-Nov-2000.
Database last updated on 30-Dec-2000 10:48:31 EST.
My NSI handle is "RM100" (not "RM1000" as I mistyped last night):
rick@chico:/home/rick$ whois -h whois.networksolutions.com HA RM100
[NSI cruft snipped]
Moen, Rick (RM100) rick@LINUXMAFIA.COM
2033 Sharon Road
Menlo Park, CA 94025-6246
650-561-9820
Record last updated on 31-Jan-2000.
Database last updated on 30-Dec-2000 22:33:00 EST.
Looking again in the "imat.com" domain record listing, you'll notice
two DNS servers listed under "Domain servers in listed order". Those
will, by definition, become the _authoritative_ nameservers for SLD
imat.com -- because NSI in its registry role furnishes that information
via the root nameservers to the public, when the public's nameservers
wish to determine where to look for information on DNS information for
that SLD.
Using whois again, we can look up a host record by name using the "HO"
(host) keyword:
rick@chico:/home/rick$ whois -h whois.networksolutions.com HO MYRDDIN.IMAT.COM
[NSI cruft snipped]
[No name] (MYRDDIN-HST)
Hostname: MYRDDIN.IMAT.COM
Address: 140.174.70.1
System: ? running ?
Record last updated on 30-Nov-1992.
Database last updated on 30-Dec-2000 22:39:07 EST.
"MYRDDIN-HST" is actually a "handle" within the host record: Doing the
same whois query for that name brings up the same record.
Let's see if Don's troublesome host record for HUGIN.LINCEXPO.ORG still
exists:
rick@chico:/home/rick$ whois -h whois.networksolutions.com HO HUGIN.LINCEXPO.ORG
[NSI cruft snipped]
[No name] (HUGIN2-HST)
Hostname: HUGIN.LINCEXPO.ORG
Address: 140.174.70.21
System: ? running ?
Record last updated on 13-Apr-1999.
Database last updated on 30-Dec-2000 22:39:07 EST.
Yep. That means that any poor bastard who gets reassigned IP address
140.174.70.21 (my old IP) will be unable to use it for DNS purposes
without getting Don Marti to release his hold over it, as owner of
LINCEXPO.ORG . At least, they'll have problems _if_ they use NSI.
The various registrars with whom domains get registered (NSI, Domain
Discover, OpenSRS, etc.) and stored within the NSI registry's database
are accountable to the domain owners for allowing only _authorised_
changes to the records. Each has different security arrangements.
Mine, Domain Discover, doesn't actually appear to use host or contact
records:
rick@chico:/home/rick$ whois -h whois.domaindiscover.com linuxmafia.com
[Domain Discover cruft snipped]
Registrant:
Linux Mafia
2033 Sharon Road
Menlo Park, CA 94025-6246
US
Domain Name: LINUXMAFIA.COM
Administrative Contact, Technical Contact, Zone Contact:
Linux Mafia
2033 Sharon Road
Menlo Park, CA 94025-6246
US
650-561-9820
rick@LINUXMAFIA.COM
Domain created on 18-Jul-1998
Domain expires on 17-Jul-2001
Last updated on 01-Jun-2000
Domain servers in listed order:
MYRDDIN.IMAT.COM 140.174.70.1
NS1.LINUXMAFIA.COM 209.81.22.250
NS1.VARESEARCH.COM 198.186.202.185
_NSI's_ registrar division is one of the most notoriously labyrinthine
about its rules for making changes to domain/host/contact records.
Back in the day when they were the _only_ registrar for the gTLDs, and
thus were the monopoly in charge of the InterNIC, a lot of us used to
spend much time studying their rules, both written and unwritten. It
was a bit like being a Kremlinologist.
So: The stuff I posted about the consequences of someone else's host
record pointing to your IP address was a classic bit of NSIology.
(Richard Couture is an expert NSIologist; one of the best.) Those of us
who've gone on to other and better registrars no longer have to worry
about it.
And none of this has anything to do with the standard subject, covered
in DNS books, of how to set up and operate a nameserver. So, don't feel
bad about not knowing it.
===
Date: Sun, 31 Dec 2000 00:46:09 -0800
To: Rick Moen <rick@linuxmafia.com>
From: "Derek J. Balling" <dredd@megacity.org>
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
Cc: SVLUG <svlug@svlug.org>
>In studying DNS, you've read about authoritative vs. non-authoritative
>DNS, right? Just setting up a nameserver that purports to have
>information about foo.com or subdomain.foo.com doesn't do much good
>unless the rest of the world knows that it should consult your
>nameserver for that information. This is the DNS concept of authority;
Actually, to be pedantic, that's the registered concept of authority.
The DNS concept of authority is based on when a DNS server answers
"Authoritatively" that it knows the answer to a question.
>For the generic top-level domains (gTLDs) -- com, org, and net (but not
>gov or mil)
you forgot .edu. :) Also with InterNIC/NSI, but with its own set of rules. :)
>Looking again in the "imat.com" domain record listing, you'll notice
>two DNS servers listed under "Domain servers in listed order". Those
>will, by definition, become the _authoritative_ nameservers for SLD
>imat.com -- because NSI in its registry role furnishes that information
>via the root nameservers to the public, when the public's nameservers
>wish to determine where to look for information on DNS information for
>that SLD.
Caveat: The information in the whois database is NOT necessarily going to
be authoritative. The NAME will always be authoritative, but not
necessarily the IP address.
For example, looking at my domain, megacity.org:
Domain Name: MEGACITY.ORG
Administrative Contact:
Balling, Derek dredd@megacity.org
1360 The Alameda
Apt 412
San Jose, CA 95126
US
+1-408-998-1716
[duplicate tech/billing contacts deleted]
Record last updated on 26-Dec-2000.
Record expires on 14-Jul-2010.
Record Created on 16-Jul-1996.
Domain servers in listed order:
NS1.MEGACITY.ORG 64.71.143.244
NS1.PYROTECHNICS.COM 207.7.10.2
NS2.PYROTECHNICS.COM 207.7.10.3
Note the IP address of ns1.megacity.org ... 64.71.143.244 .. this is from
OpenSRS' database. Since OpenSRS is the registrar for megacity.org, they're
going to be "authoritative" for any host records inserted into the root
zonefiles within megacity.org (i.e., OpenSRS is the one which feeds the
ns1.megacity.org/64.71.143.244 glue record into the root servers).
However, NSI still has very old data in their whois server. If you query
NSI for an NSI domain that points at NS1.MEGACITY.ORG, they'll list a
completely different IP address:
Domain Name: BJB.ORG
Administrative Contact, Technical Contact, Billing Contact:
Caplin, Barry (BC723) bc@BJB.ORG
MicroWeb Technology, Inc.
P.O. Box 2384
Northbrook, IL 60065-2384
847-480-9715
Record last updated on 30-Apr-2000.
Record expires on 25-May-2001.
Record created on 25-May-1998.
Database last updated on 30-Dec-2000 22:39:07 EST.
Domain servers in listed order:
NS1.MEGACITY.ORG 63.201.65.218
NS1.PYROTECHNICS.COM 207.7.10.2
Even funnier in this is that it is actually impossible for me to CHANGE
that NS1.MEGACITY.ORG host record in their database, because their
automated systems kick the request out (since MEGACITY.ORG isn't an
NSI-registered domain).
Luckily, since NSI cannot insert MEGACITY.ORG glue records in the root
servers, there is no-harm/no-foul, but it certainly can cause confusion.
>Yep. That means that any poor bastard who gets reassigned IP address
>140.174.70.21 (my old IP) will be unable to use it for DNS purposes
>without getting Don Marti to release his hold over it, as owner of
>LINCEXPO.ORG . At least, they'll have problems _if_ they use NSI.
Actually, if the IP is assigned to a host record with any registrar, they
should have problems creating a host record for that IP with ANY registrar,
or so the story goes. Both hostnames and IP addresses are supposed to be
unique in the glue records, or so I'm told.
Although, for the record, I'll say that given the proper amount of
pressure, errant host records CAN be made to disappear. It's simply a
matter of applying the right amount of pressure, usually in the form of
people who put ",Esq." or ",J.D." after their name. I've seen it done
firsthand, but my employer also has significantly more clout than on
average. :)
> It was a bit like being a Kremlinologist.
What mean you, "Was", white man? :-)
>And none of this has anything to do with the standard subject, covered
>in DNS books, of how to set up and operate a nameserver. So, don't feel
>bad about not knowing it.
True, but feel despondant that even if you don't use NSI, you'll still have
to learn it, because you'll always have to deal with people who DO use
them. *sigh*
===
Date: Sun, 31 Dec 2000 01:52:14 -0800
From: Rick Moen <rick@linuxmafia.com>
To: SVLUG <svlug@svlug.org>
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
begin Derek J. Balling quotation:
> Actually, to be pedantic, that's the registered concept of authority.
Yeah, yeah.
> you forgot .edu. :)
Well, realise that I banged all that out in a hurry, between coming back
from one party and going out to another. ;->
> Caveat: The information in the whois database is NOT necessarily going to
> be authoritative. The NAME will always be authoritative, but not
> necessarily the IP address.
I find it somewhat depressing that the fundamental, functional
identities of our nameservers are stored as DNS names, rather than IP
addresses. I'll take on faith that you know what you're talking about,
but it's a bit bizarre that the central mechanism for specifying what
nameserver to query for a specified SLD would use a data type that
itself hinges on name lookups -- when they could use IP addresses
for that purpose.
But I'll admit that some of the details of how the root namservers work
and their coordination with the whois databases are still black magic to
me. E.g., I didn't even become aware of host records until they
suddenly stood in my way, one day.
> However, NSI still has very old data in their whois server.
Tres bizarre.
> Even funnier in this is that it is actually impossible for me to CHANGE
> that NS1.MEGACITY.ORG host record in their database, because their
> automated systems kick the request out (since MEGACITY.ORG isn't an
> NSI-registered domain).
High explosives, Derek.
> Luckily, since NSI cannot insert MEGACITY.ORG glue records in the root
> servers, there is no-harm/no-foul, but it certainly can cause confusion.
Yes.
[the outdated host record for HUGIN.LINCEXPO.ORG:]
> Actually, if the IP is assigned to a host record with any registrar, they
> should have problems creating a host record for that IP with ANY registrar,
> or so the story goes. Both hostnames and IP addresses are supposed to be
> unique in the glue records, or so I'm told.
Ah, glue records are one of those black-magic things I don't yet
properly understand.
I look at the whois records at many non-NSI registrars, such as the
Domain Discover outfit I use, and see a refreshing absence of references
to host records. I had somewhat optimistically assumed that this meant
that (e.g.) Domain Discover didn't use them. But obviously my
understanding of some of these matters still needs some work.
> What mean you, "Was", white man? :-)
Well, NSI as a _registry_ alone (as back-end for registrar Domain
Discover) has been a great deal less trouble than the bad old days when
it held monopoly position as a combined registry and registrar. I can
say that much.
===
Date: Sat, 30 Dec 2000 12:43:49 +0100
From: Marc MERLIN <marc_news@valinux.com>
To: Ian Kluft <ikluft@thunder.sbay.org>
Cc: Rick Moen <rick@linuxmafia.com>, svlug@svlug.org, chris@dibona.com
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
On Fri, Dec 29, 2000 at 06:04:00PM -0800, Ian Kluft wrote:
> You need to have a domain contact (which for SVLUG is Chris DiBona) fill in
> this form with the change in the host address:
> http://www.networksolutions.com/cgi-bin/makechanges/itts/host
>
> Since it is no longer being used as a nameserver, you could use this form
> to have them delete the record.
I somehow remember hearing something about the actual deletion request not
working.
That said, Chris (Cced here), can always give it a shot, but I hold much
higher hopes in moving the domain to opensrs which is quicker and simpler.
This was supposed to be done last week (week of the 18th), and being away
from decent internet connectivity, I assumed (yeah, yeah, I know) that it
had been done.
And this Email will probably not see a modem before two days (monday 1st).
Sigh...
===
Date: Sat, 30 Dec 2000 12:33:55 +0100
From: Marc MERLIN <marc_news@valinux.com>
To: Rick Moen <rick@linuxmafia.com>
Cc: svlug@svlug.org, officers@svlug.org
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
On Fri, Dec 29, 2000 at 05:13:07PM -0800, Rick Moen wrote:
> What I was saying was that the mere existence of an out-of-date host
> record does not provide a plausible mechanism for causing that effect.
And I'm saying it does, whether you believe it's plausible or not.
I've seen it by experience on 3 different domains, including
merlins.org. The minute the host record was fixed/removed or the domain
moved away from NSI, the "problem" got mysteriously fixed.
> If you're meaning to say that the out-of-date host record not only
> _exists_ but is also, contrary to what the rwhois results for domain
> svlug.ORG suggest, getting queries about svlug.ORG referred to it by the
> TLD root servers as an authoritative nameserver for that domain, that is a
> different matter. But that's not what you said, previously.
Nope, that's correct.
All the svlug.org domain data is correct. The only thing that is screwing us
over (besides using NSI obviously) is that host record. If you lookup
anything outside of www.svlug.org, you'll have the up to date record. That's
also why no one has problems sending mails to the list (AFAIK at least)
Of course, accessing the web site as svlug.org instead of www.svlug.org
works too.
I'm writing this in a car on my way to Holland, so obviously I can't do much
about it right now. At this time it's in the hands of VA netops and while I
made arrangements for this to get fixed before I went on vacation, it looks
like it's not gonna get done before next meeting, sorry about that.
We'll make sure to mention the alternate URL to the web site in the
announcement that should get sent on monday or tuesday.
===
Date: Sun, 31 Dec 2000 09:06:28 -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
Cc: Bill Schoolcraft <bill@wiliweld.com>, SVLUG <svlug@svlug.org>
At 4:58 PM +0100 12/31/00, Marc MERLIN wrote:
>On Sat, Dec 30, 2000 at 01:11:32PM -0800, Bill Schoolcraft wrote:
>> I'm currently seeing conflicting instructions on a "chrooted" jail
>> howto's on this for I'm reading both:
>>
>> http://www.ibiblio.org/pub/Linux/docs/HOWTO/Chroot-BIND-HOWTO
>> and
>> http://www.psionic.com/papers/dns/dns-linux/
>>
>> The differences seem to be in the Makefile.set edits and the
>> directory structure under /chroot/named/*
>>
>> Anyone care to share "Chroot-BIND" tips with me I'd appreciate it.
>
>Configure bind to run as user named instead of root, but don't bother about
>chroot jails, the last bind exploit had code to escape that jail.
Let me just completely argue with Marc's logic, which implies that "since
the last exploit could escape the chroot-jail, we shouldn't bother with
chroot-jail'ing named."
Putting named in a chroot jail involves a sum total of about three file
changes, and two command line switches to named. ( -t /path/to/jail -u
user_to_run_as )
To "skip that" because of past issues with chroot jails on named is
ignoring a valuable potential obstacle for a future exploit to have to
overcome.
===
Date: Sun, 31 Dec 2000 09:10:00 -0800
From: Rick Moen <rick@linuxmafia.com>
To: svlug@svlug.org
Cc: officers@svlug.org
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
begin Marc MERLIN quotation:
> And I'm saying it does, whether you believe it's plausible or not.
Data point: There's an out-of-date host record at NSI for my nameserver
(described elsewhere). Its _mere existence_ has zero effect, because
it is not included in any domain records.
As I said.
--
Cheers, "It ain't so much the things we don't know that get us
Rick Moen in trouble. It's the things we know that ain't so."
rick@linuxmafia.com -- Artemus Ward (1834-67), U.S. journalist
===
Date: Sun, 31 Dec 2000 10:06:20 -0800
To: Rick Moen <rick@linuxmafia.com>
From: "Derek J. Balling" <dredd@megacity.org>
Subject: Re: [svlug] SVLUG sometimes resolving to 209.81.8.243
Cc: svlug@svlug.org, officers@svlug.org
At 9:10 AM -0800 12/31/00, Rick Moen wrote:
>begin Marc MERLIN quotation:
>
>> And I'm saying it does, whether you believe it's plausible or not.
>
>Data point: There's an out-of-date host record at NSI for my nameserver
>(described elsewhere). Its _mere existence_ has zero effect, because
>it is not included in any domain records.
>
>As I said.
Further data point:
If someone were to use the previously-described "efficient" resolver, and
ask the root-server for an A record for that hostname in particular, it
COULD be an issue. The two caveats there are: (1) Is the domain in which
that hostname resides an NSI domain (if not, there is no issue), and (2)
what are the chances of someone actually attempting to do a lookup on that
hostname, asking a root-server for the answer.
===