Questions about DNAME records

[Braebaum, Neil]

I'm happy with the concept of views, and have used them previously.

Ideally, though (as Chris mentioned) I don't want to have to manage zone
data for the externally used domain, both on my name servers, and those
where it's really provided - on a managed service, hosted and provided
externally.

Having never used DNAME records before, I was really just curious as to
whether I could use them to kind of simply deal with a small number of
records for purely internal usage, without interrupting our internal
resolution of the public names.

But Chris's suggestion of subdomains looks to be very useful - many
thanks for that.

Neil

> -----Original Message-----
> From: bind-users-bounces at lists.isc.org 
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Joseph S D Yao
> Sent: 19 June 2009 02:43
> To: Chris Buxton
> Cc: Braebaum, Neil; bind-users at isc.org
> Subject: Re: Questions about DNAME records
> 
> On Thu, Jun 18, 2009 at 02:12:07PM -0700, Chris Buxton wrote:
> ...
> > Yes, that will absolutely work. But the OP requested a 
> method that did 
> > not involve managing the public data in two places.
> ...
> 
> 
> Which is exactly what views are for.  External data is kept 
> in ONE file,
> as below.
> 
> named.conf:
> 
> 	...
> 
> 	acl localfolk {
> 		localhost;
> 		LOC.AL.NET.WORK/MASK;
> 		...
> 	};
> 
> 	view "internal" {
> 		// This should match our internal networks.
> 		match-clients { localfolk; };
> 
> 		// Provide recursive service to internal clients only.
> 		recursion yes;
> 
> 		// Provide a complete view of the example.com zone
> 		// including addresses of internal hosts.
> 		zone "example.com" {
> 			type master;
> 			file "zone.example.int";
> 		};
> 	};
> 
> 	view "external" {
> 		// Match all clients not matched by the previous view.
> 		match-clients { any; };
> 
> 		// Refuse recursive service to external clients.
> 		recursion no;
> 
> 		// Provide a restricted view of the example.com zone
> 		// containing only publicly accessible hosts.
> 		zone "example.com" {
> 			type master;
> 			file "zone.example.ext";
> 		};
> 	};
> 
> 
> zone.example.ext:
> 
> 	$TTL	1d
> 
> 	@	IN SOA	...
> 		IN NS	...
> 
> 	// Remember to increment the SOA serial number when this is
> 	// updated!
> 	$INCLUDE "data/example.ext.data"
> 
> 
> zone.example.int:
> 
> 	$TTL	1d
> 
> 	@	IN SOA	...
> 		IN NS	...
> 
> 	// Remember to increment the SOA serial number when either of
> 	// these is updated!
> 	$INCLUDE "data/example.ext.data"
> 	$INCLUDE "data/example.int.data"
> 



*****************************************************************************

This email and its attachments are confidential to the intended recipient. If this has come to you in error, please notify the sender immediately and delete this email from your system. You must take no action based on this email, nor must you copy or disclose it or any part of its contents to any person or organisation. Please note that email communications may be monitored. The registered office of Shop Direct Limited is First Floor, Skyways House, Speke Road, Speke, Liverpool, L70 1AB, registered number 04730752.
 
Subsidiary companies of Shop Direct Limited include:

Shop Direct Group Financial Services Limited (SDGFS), Shop Direct Financial Services Limited (SDFS) and Shop Direct Finance Company Limited (SDFC). The registered office of SDGFS, SDFS and SDFC is Aintree Innovation Centre, Park Lane, Netherton, Bootle, L30 1SL, registered numbers 05200103 (SDGFS), 04730706 (SDFS) and 04660974 (SDFC). SDFS and SDFC are authorised and regulated by the Financial Services Authority in respect of arranging insurance products. 

Shop Direct Contact Centres Limited (SDCC) and Shop Direct Home Shopping Limited (SDHS). The registered office of SDCC and SDHS is First Floor, Skyways House, Speke Road, Speke, Liverpool, L70 1AB, registered numbers 05330323 (SDCC), 04663281 (SDHS). 

All companies registered in England.

*****************************************************************************