Re: Authoritative Server - Referrals to root

> On Apr 8, 2005, at 02:26, Joe Greco wrote:
>
> >>> Watching with some amusement the raging RFC1918 debate over in NANOG,
> >>> I'll even note that our authoritative nameservers claim authority
> >>> for the
> >>> relevant in-addr.arpa zones, plus an artificial TLD aptly named
> >>> "internal",
> >>> and our recursive resolvers are configured with zone stanzas listing
> >>> them as type forward; forward only pointing at our authoritatives.
> >>>
> >>> But of course that's how we intend for it all to operate. Tough
> >>> nuts to
> >>> whoever tries to open a new TLD named "internal". :-)
> >>
> >> Nope. It'll be tough nuts for you and your users if the TLD "internal"
> >> gets created one day.
> >
> > Not really. Use your head.
>
> Let's see if I have. You've rigged your local network so that it knows
> about this artificial TLD called internal. All your local users will
> get directed to the local name servers that answer for this bogus TLD.
> So far, so good. One day ICANN, in its infinite wisdom, creates a new
> TLD called internal. This goes in the root zone so all of the internet
> can resolve this domain. Except your local users. They get pointed at
> your bogus version of this zone because that's where the local name
> servers are told to send their queries for this zone.
>
> Suppose a local user looks up foo.internal. How is anything supposed to
> know if that's a query for foo.internal on the internet or foo.internal
> in your private world? What if the name exists in one and not the
> other? How are your name servers going to know what answer to return?
> Do they respond with what's in this bogus TLD and perhaps give the
> wrong answer? Or do they respond with what's in the real TLD and
> perhaps give the wrong answer?
> Now suppose www.foo.internal exists in both places, but with different
> data. Which web site does the local user want to visit? How will your
> local name servers know that? Where would these problems arise and
> where would they need to be addressed? Hint: it's not the rest of the
> internet or those places using the real .internal TLD.
>
> The rest of the internet knows nothing about your bogus TLD and cares
> even less. So they resolve the real .internal TLD, no problem. The same
> goes for the operator of that TLD. Who's got the problem because of
> your bogus TLD? Hint: it's not the real TLD operator or the rest of the
> internet.
>
> If there's something I've overlooked, please tell us.

1) /IF/ a TLD named "internal" were created, it seems likely and obvious
that there's a good chance it would be created for purposes apparently
relating to the meaning of the word, and hence would likely be the
equivalent of 10-net space. I point to RFC2606 as a trivial example
of past naming policy for DNS. In such a case, we would merely be
leading the way. :-)

2) /IF/ a TLD named "internal" were created which was not actually intended
for internal use, but, perhaps, was meant for domain names for doctors
of internal medicine, or some other lameness, well, really, it's /not/
that hard to do s/internal/foo/ in your zones tree. It seems highly
unlikely to happen.

3) There's generally plenty of warning of up and coming new TLD's, so
neither 1 nor 2 are currently an issue, and by the time it would be, it
still isn't because we'd have done something about it.

I count that as three obvious points you've missed.

Now, really, the interesting bit here is that there's a bit of a gap in
the way things really work. The historical answer for what I'm doing has
been to use split horizon servers, with both internal and external views, so
that 10-net stuff doesn't get inadvertently advertised out on the 'net.

That's nice where you have a big intranet or something like that.

We, however, have lots of boxes out at customer sites, and since our
customers are allowed to renumber and move equipment on their networks as
dictated by their own engineering needs, the complexity of such a solution
started to get a bit much. Our particular deployment design involves
having a private 10-net address for each server (simply the public IP
address/netmask, with the first octet changed to 10) for intraserver
transfer, management, and other various purposes. This particular solution
allows us to call the external interface "${hostname}", and the internal
interface "${hostname}.internal", which has a nice symmetry, and can be
automatically derived.

We don't really want or need one name to map to different IP addresses
based on internal or external. We really don't want to maintain maps of
what hosts are to be considered internal or external. Some other
considerations went into it.

The end result is, it works, and it works very well. I'd prefer to see
it codified as a reserved TLD for the purpose, but I realize that certain
folks will not be open to accepting something like this, even though we
already have baggage like 10.in-addr.arpa which is essentially maintained
the same way at many sites.

I guess the interesting question is how many operational resolution issues
are there at sites that have installed RFC1918 zones as local masters?

.... 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.