Classless delegation with a split horizon setup

Joseph S D Yao jsdy at center.osis.gov
Wed Jun 22 16:10:01 UTC 2005


Here's an extract from a message about this back to Andrew.  Andrew,
apologies if you felt you didn't want this on the mailing list.  I have
removed parts _I_ didn't want on the mailing list.

On Wed, Jun 22, 2005 at 08:57:51AM +0100, Andrew Hodgson wrote:
...
> This is what I suggested, and it works - the only issue is if no Internet
> connection and the root data is not cached it fails.  Anyway I got it
> working using comments found at:
> 
> http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.h
> tml
> 
> Thanks - it is fully working now.
> 
> Andrew. 

Here's a suggestion - offer your external server as a server for the 
223.105.2.81.in-addr.arpa zone.  Then, your access will only fail if
your LAN is down anyway.  They may refuse - I probably would if I were
an ISP and didn't know you personally - but it doesn't hurt to ask.

I don't think it would help if your external server slaved the zone
information but wasn't declared as a name server - but I haven't tried
it, it's something to think about.  If the external server does "get it"
in this mode, you'd want to forward all queries from the internal server
to the external server.

...

ISTM that the two methods [cited in the URL above] are themselves flawed
in subtle ways that may not even be triggered by your configuration.
			[fixed an error in original version, here.]
But here is a way to do the above without using RFC 2317 but also
without violating any RFCs.  It just involves using one zone per reverse
rather than one zone for all.  You decide what's easy for you to
maintain.

For block: 81.2.105.208/28

Your ISP inserts into its 105.2.81.in-addr.arpa file:

	208	NS	{name-of-your-server.}
	...
	223	NS	{name-of-your-server.}

None of this mucking around with making up server names and forcing them
to hard-code your IP address in their reverse DNS file.

You create 16 different zones:

zone "208.105.2.81.in-addr.arpa"	{
	type master;
	file "zone.81.2.105.208";
}
...
zone "223.105.2.81.in-addr.arpa"	{
	type master;
	file "zone.81.2.105.223";
}

You create 16 different files:

$TTL	1d
@	SOA	name-of-your-server. dotted.email.addr. (
		... )
	NS	name-of-your-server.
	PTR	{network or name-of-system. or broadcast}

For instance, in zone.*.208, you would put "network", in zone.*.209 you
might put "dad.hodgson.family.", in zone.*.210 you might put
"kitty.hodgson.family." [you do realize I'm making these up], ..., and
in zone.*.223 you would put "broadcast".

[Use of "network" and "broadcast" are things I do for easier
maintenance; most don't do it, and those who eat security-by-obscurity
for breakfast would be horrified.]

Do you see how this works?  And best of all, you are NEVER LYING to the
system or the public Internet about what zones you control!  This means
that versions of DNS software that obey the RFCs, (e.g., BIND, and NOT
[others cited elsewhere]) will never cause your configuration to fail.
"The truth is always the easiest story to remember."

-- 
Joe Yao
-----------------------------------------------------------------------
   This message is not an official statement of OSIS Center policies.



More information about the bind-users mailing list