Authoritative Server - Referrals to root

[Joe Greco]

> > Seems to have been the way the names were devised in RFC2606.  Of 
> > course,
> > past performance is no indicator of future results, but I'd still find 
> > it
> > hard to believe that "internal" would end up being created for 
> > something
> > unrelated to the meaning of the word "internal".
> 
> With ICANN, anything is possible. :-) And the word internal can be used 
> for other contexts
> besides a private name space. You yourself mentioned internal medicine 
> for instance.

One could reasonably use that argument in other fashions.  Since anything
is possible, what if ICANN decrees that there shall always be a TXT RR
named "abusefoo" under every SOA?  Does it make it right?  Does it mean
that every delegation in the world will instantly gain one?  What's the
bigger meaning?

ICANN is responsible for coordinating things at a global level and making
sure that there will be no conflicts.  Local administrators are
responsible for coordinating things at a local level, and are ultimately
the people responsible for making networks actually work.

I'll concede that ICANN is allowed to do stupid things (and in fact has
done stupid things).

> > Your point is....?  Yeah, right, nothing.  They've discovered some 
> > purposes
> > for which defined TLD's could be useful.  They reserved them.  Their 
> > failure
> > to reserve "internal" as one of them does not lessen the utility of it.
> > BCP on the Internet is a moving target.  There will be things in ten 
> > years
> > that we've not even thought of today.
> 
> So what? That's not an excuse for conjuring up ad-hoc naming schemes 
> which could
> conflict with a real domain name on the internet.

So what?  It's been done before.  .BITNET.  .CSNET.  .UUCP.  These were
all used in potential conflict with a real domain name on the Internet.
Back in the golden pre-commercial days when RFC's were considered more
like ghod's word, too, for that matter.

Again, I make the point, and encourage you to think about, the fact that
a lot of RFC's are reactionary documentation of things that people have
done and which were found to work.

If we prohibit ourselves from doing things which are not officially
sanctioned by RFC's, then we lose a lot of ability to generate new things
which then result in new RFC's.

Again, the experience of ".invalid" is educational.  I desired a way to
limit users creating ad-hoc From: lines that could cause various problems.
There were users posting as "user at nomail.com", which I thought was 
particularly unfair to whoever owned that domain.  There were users who
were posting as "x at x.x", which didn't bother me so much, since it was
undeliverable and not likely ever to become deliverable, but there were
also border cases where the TLD could possibly have been something that
would someday come into being, such as "i.am at at.work".  Using
"user at invalid.ispname.com" kind-of works, except for the hazard that such 
an address could at a future date pop into being.  Using "x at x.x.invalid",
on the other hand, looked like a winner for many reasons.  It was obviously
invalid to any reader, was invalid within DNS (even if it was theoretically
something which could be delegated), and eventually it may have contributed
towards someone writing an RFC to officially sanction its invalidity.

So.  Was it right or wrong to do that, and does your answer depend on the
date on which that question is asked (i.e. 1999)?

Next.  Would it be wrong to repeat that sequence of events?

> >> Secondly, you're confusing a bogus, internal-use-only TLD, with a 
> >> valid
> >> domain name. Creating your own private copy of 10.in-addr.arpa (or any
> >> other reverse zone for RFC1918 nets) is mostly harmless.  On the
> >> internet, 10.in-addr.arpa already exists and has a defined purpose.
> >
> > The difference between these being?
> 
> I'm sorry if you don't/can't understand the above paragraph.

I do.  Perhaps you didn't understand the answer I was trolling for.  You 
could have said semantics or formalization or any of a number of other 
things.  You would have been correct, and then my point would have been that 
the differences are still approximately zero from an operational and 
engineering viewpoint.

You chose not to answer the question, however, avoiding the conclusion.

> >> Note that I'm not saying having a TLD like .internal for private
> >> purposes is a Bad Thing. It's just that the name of that TLD needs to
> >> be agreed and documented. The name shouldn't just be plucked out of
> >> thin air. If a domain name is to be used for internal purposes, its
> >> name should be one that's been expressly set aside for that purpose. 
> >> ie
> >> Those using that name can be certain it's not going to appear on the
> >> public internet. That holds irrespective of whether the chosen
> >> internal-only domain is a TLD or not.
> >
> > All right, then, what would /you/ have done?
> 
> I would not have plucked a TLD name out of thin air and  used it to 
> create an ad-hoc naming scheme which had the (possibly hypothetical) 
> potential to conflict with a real domain name on the Internet.

At this point, the potential to conflict is not "possibly hypothetical".
It exists.  However, potential is not my concern.  There is the potential
for botnets (fleets of mostly Microsoft controlled virus-infected machines)
to take down the Internet's root nameservice.  Today.  The sheer number of
infected machines, even the conservative estimates, is terrifyingly large.
Yet we do not build root nameserver infrastructure such that it could
weather any conceivable attack.  Anycast projects (F, etc) are not deployed
at a scale that would guarantee continued availability under such an
attack.  We're clearly not so terrified of this major potential disaster
that we've actually solved this problem.  I'd rather be addressing that
sort of potential problem, though, if we were actually solving potential
problems.

Wait.  That's right.  Nobody seems to give a ****.  Most ISP's won't even
get rudimentary ingress filtering working correctly, which would go a long
way towards defusing this little time bomb.  (We do ingress and egress,
for what little it'd help)

So my puzzle is why such a minor potential conflict as what we're
discussing is such an issue for you.  It's localized, it affects no one 
currently, it's unlikely to affect anyone in the future, if it does affect
someone in the future, it can be fixed in maybe five minutes by picking a
more random string for "internal", etc.

We have a lot more pressing potential problems to worry about.

> My earlier message on this thread have one example of a scheme which 
> would not have had that problem: ie hostname-internal.sol.net (say) or 
> something like that. Another option would have been a naming scheme 
> like customer-server.internal.sol.net. There are other possibilities. 
> Reaching for a bogus TLD isn't necessary.

All were considered.  Each had specific faults that made it less than
desirable. 

For example, I really don't want "news.isp-name.com.internal.sol.net" 
showing up in log records for major ISP clients who were being sold on
having the service private labelled as being their own.  Run a log
sanitizer, you say?  Well, sure...  but we're talking huge log files, 
and we can run out of disk and lose data, so the question then becomes, 
is there an actual engineering reason to do it that way, or is it just 
to avoid offending Jim Reid?

Or, how about that if you do it your way, then you either need to implement
a split horizon DNS service (so you're only serving up the 10-net names
internally) or you need to risk the possibility of someone actually
doing a global lookup on "news.isp-name.com.internal.sol.net" and getting
an answer which resolves?  Okay, well, we don't have the infra in place
to do the split horizon, but if we did, would it help?  Let's see.  No,
customers are allowed to renumber their site equipment, which means that 
we cannot really program our DNS servers with the addresses of the
customer site equipment, without resorting to something hacky like looking
up all the addresses every hour, pushing out changes, bleh.  So, again, is
there an actual engineering reason to do it that way, or is it just to 
avoid offending Jim Reid?

Answer:  save the headache, save the engineering complexity.  Bend DNS
just a little, to do something it's designed to do anyways - resolve
names.  Call it a day.  That's what we chose.

> > Actually, I don't really care if it gets accepted as an RFC.
> 
> This is regrettable. The RFC process is the thing that's fundamental to 
> a coherent and working Internet.

The RFC process is helpful.  It's useful.  It's not absolute.

We've gotten along for years without a modern USENET/NNTP RFC.  I've
personally written lots of code which isn't "compliant" with the ancient
RFC's.  The lack of current standards doesn't prevent portability and 
interoperability, though it does hinder it at times.  We mainly solve
this by following the typical rules:  be liberal in what you accept, 
conservative in what you emit, etc.

In many cases, the RFC process acts to document existing practice, or a
working implementation, etc.

> Undermining that process (or ignoring the bits you don't like) is not 
> healthy for everyone who uses the internet.

That would be true, if I were Microsoft, and I were releasing my own mostly
noncompliant version of the Web, complete with server and browser.  That
would be true in the case of all the idiot networks who block /all/ ICMP
and therefore also break things like PMTU detection.

It would be more correct to say that "undermining that process may be
bad for your network" for smaller infractions.  Particularly in the case
where the administrator doesn't understand the ramifications.  I think the
poster child here would be the state of firewalling in general on the
Internet, where administrators apply what amounts (in aggregate) to random
blocking policies in order to block things that they "feel" are bad,
without bothering to understand the technical facts.

You do need, however, to respect the fact that in the end, the Internet is
built out of many different networks, each of whom have their own policies.
When someone on a different AS has a policy that you don't like, and it is
not affecting you or any other AS in any manner, trying to claim that it
"is not healthy for everyone who uses the internet" is a real chest-beater
of a claim to make, especially when the policy doesn't even interfere with
things working "as expected" at the AS in question.  There is a small
possibility that something might happen at some future point.  If that
comes to pass, /MY/ fix is to make five minutes worth of changes and push
them out, a price which is eminently affordable, especially in light of
the fact that it's unlikely ever to happen.  /YOUR/ solution is to fix it
/now/, at much higher costs and headaches, for no immediate benefit, and
even in the long term, there's no guarantee that it'd even be likely to be
needed.

Hmm.

> Your comment above is the sort of thing I'd expect to hear from the 
> bozos who advocate "alternate roots".

Oh, that's what this is all about.  I see now.

See, there's a difference between an administrator making a policy
decision that isn't intended for the primary purpose of circumventing 
(or, worse, trying to direct) ICANN policy, applying it only locally 
to systems under his control, and the whole alternate root "let me sell 
you a TLD of your last name" (or whatever the modern variants on 
AlterNIC are) bull.

I'm not suggesting you set your nameserver to resolve .internal from
my servers.  If I found out people were doing it, I'd even be likely to
ACL them from doing it.

So.  Now that we've figured out what your issue is, how about you just
accept my word that I have no designs on getting other people to use
me as the TLD NS for .internal, no plans to operate a TLD or 2LD
registry (though we do resell OpenSRS services), etc.  This is nothing
more (and nothing less) than what it appears to be - a local
implementation that is not doing anything that interferes with you, has
not done anything that interfered with you, and is not likely to do
anything that interferes with you.

If you're truly worried that the Internet is going to disintegrate
because this particular pseudo-TLD isn't documented, well, I do encourage
you to write up son-of-2606 and document it.  :-)

Anyways, Brad's sitting over there with a firehose in his hands and a
gleam in his eye.  Hi, Brad.

Regards,

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.