Resolv local network names [Newbie question]

Kevin Darcy kcd at
Mon May 14 22:44:30 UTC 2007

Curt Sampson wrote:
> On Wed, 9 May 2007, Kevin Darcy wrote:
>>> It doesn't matter at all that it's a private range; that has no
>>> connection with how records (at least, or "reverse"
>>> records) resolve.
>> Please read what I wrote. "... it's likely that other folks are already
>> using it for their own purposes, or they want to reserve the option of
>> doing so".
> And they can continue doing so, with no problems whatsoever, unless the
> original poster happens to want matching entries, which is
> often not necessary. (Nice, yes, but absolutely necessary, often not.)
The OP may not want matching entries, but, depending on the 
tools that the provider uses, entries may get generated 
automatically, and then this may become a "legacy problem" if they want 
to use that range later for their own purposes, with their own entries pointing to their own resources. That's why I added 
the disclaimer "or they want to reserve the option of doing so". 
Sometimes things that are technically feasible in the here-and-now are 
likely to lead to problems down the road. You've got to look ahead. It's 
always been understood that RFC 1918 doesn't scale well across 
organizations in the long term (at least, Bob Moskowitz understood it, I 
assume the other co-authors understood this as well).
>> Granted, being in a private address range doesn't *directly*
>> affect how DNS names resolve, but it may affect the *availability* of
>> other people and/or organizations to be master for the zone....
> I don't see why. It's perfectly possible to have several a single server
> resolving different names from different organizations to the same IP
> address, that would route differently depending on where you use it. A
> server has no problem returning, say, for both and
> $ host
> Using domain server:
> Name:
> Address:
> Aliases:
> has address
See above. The reverse DNS is likely to be a showstopper.
>> For DNS and pretty much any other "core" network service, practically
>> speaking, persistent IP addresses are considered a prerequisite.
> Perhaps you consider this a prerequesite, but I've successfully run
> these sorts of things within and between organizations while using
> RFC1918 addresses extensively. (I assume you really meant RFC 1918
> addresses where you said "persistent" addresses; you really need to sort
> out your terminology.)
You assume too much. You said "reasonably reliable and stable", I echoed 
that loosely as "persistent". RFC 1918 doesn't really have any relevance 
to either of those terms/phrases.

- Kevin

More information about the bind-users mailing list