Tanner Lovelace wrote:
On 5/24/06, Rick DeNatale <[EMAIL PROTECTED]> wrote:
Not quite, top level domains are separated into country code tlds
(ccTLDs) like us. ca. to. etc, and generic top level domains (e.g.
com. edu. net. etc).
Yep, you're right. I completely blanked on the country domains.
Here's an interesting question, though. How many generic
top level domains are there? There were originally six, I believe.
What were they and what are the ones that have been added in
the last few years?
I think that this may be a problem with my being unclear. Let me pick
things apart a tad.
Let's say "Alma Mater University" wants to have a subdomain like
physics.almamater.edu, it can certainly have a name server which
serves up that dns name space, BUT, the question then becomes, how
does an outsider know about THAT name server, presumably the name
server for almamater.edu forwards to it, but that name server needs to
be known to the internet hoi polloi and needs to be listed in the
registry database for edu. I don't see how someone walking the dns
tree from root will ever get to physics.almater.edu without going
through amater.edu to get there. Once any cached records expire they
are going to have to climb down (or is it up? <G>) the tree.
Yes you can move subdomain nameservers by just talking to the
containing domain's nameserver operator, and that might well be
yourself, but you can't move the nameserver which represents your
second level domain without changing an entry which isn't under your
direct control.
So moving that nameserver requires communication with the registry
operator via the registrar.
Ah, I believe I see the confusion here. Yes, you are entirely correct
that if you want to remove that nameserver from the dns chain that is
walked to get the hostname you do have to communicate with
your registrar. However, that's not what I was saying. I was saying
that you could set up that nameserver to delegate to another
nameserver. That is, instead of containing an SOA (Start
Of Authority) record, which indicates that a nameserver is
"authoritative" for that domain, it could instead return *only*
an NS record for a nameserver which would be authoritative
for the domainand an A record for the referenced NS record
(the A record is commonly called a "glue" record). So the chain
to be walked would look like this (for, say, dargo.trilug.org):
"." -> org -> trilug(non-authoritative) -> trilug(authoritative)
The nameserver in this chain that I call "trilug(non-authoritative)"
is the one listed with the registrar and will show up on a
whois query. However, that nameserver doesn't
claim to be authoritative for trilug.org (i.e. it doesn't return
an SOA record) but rather returns a different NS (nameserver)
record which when queried does answer authoritatively.
So this is about as close as anyone came to the original direction I was
headed. Specifically, the consideration that the host named by the NS
returned by the .org. name server, might give you something odd, which
points the resolver back in the right direction. There are actually a
lot of ways you can swing this. You could make it a full slave as I
described, with more current data than the registrar, which gets you
reasonably good service. You could butcher the config of that host such
that it isn't a slave, but only knows NS and A records for trilug.org at
another domain from some other zone, and doesn't think it's
authoritative for trilug.org (very hard config to come up with, but
possible). This would direct traffic pretty much as Tanner describes
above. You could also make it a stub zone, which I *think* might get
you similar behavior to the above. Even more strange you could make it
a recursive caching forwarder to the actual master, which would get you
some interesting results. It might work, I'd have to think about it
more, but it's late. :)
However, this probably isn't what Aaron was referring to.
My guess is he was probably referring to a lame delegation.
This is where you return a hostname as an NS record for
a domain, but that host isn't set up to answer authoritatively
for the domain. I probably ought to go back and re-read his
original question, though, since we've come a long way since
then. :-)
Ah, the irony. They almost arrive, and no one believes it. :)
Aaron S. Joyner
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
