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-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Joseph S D Yao > Sent: 19 June 2009 02:43 > To: Chris Buxton > Cc: Braebaum, Neil; bind-us...@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. ***************************************************************************** _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
