Can two views be layered?

[Novosielski, Ryan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/06/2013 01:05 AM, Joseph S D Yao wrote:
> On Fri, Apr 05, 2013 at 04:24:24PM -0400, Novosielski, Ryan wrote: 
> ...
>> One followup question to this: are there any limits to how the
>> SOA section is handled in this case? Can the SOA record be in
>> the $INCLUDE'd file, or does it have to be in the defined zone
>> files (which then would mean maintaining I guess two serial
>> numbers)? I was originally thinking that in that case, whenever
>> changes are made to the zonename.shared file, all that was really
>> needed to be updated was the "for-the-many" zone but I believe
>> then the "for-the-few" machines would begin to see an
>> increasingly out of date version of the shared file.
> 
> The bit stream that the computer "sees" is just what you would see
> if you removed the $INCLUDE line and stuck all the bytes from the 
> $INCLUDE'd there instead.  You can't tell what was $INCUDE'd and
> what was not.  Every other line might have been $INCLUDE'd from a
> different file, if you wanted to be a bit crazy, and the computer
> would never care.

So I messed around with this a little before your reply and realized
that almost immediately. So I did things a little differently...

> BUT you may ONLY have one SOA record per zone.  That's not a
> per-file thing, that's a per-zone thing.  Use RCS archiving and
> $Version:$ strings in comments [or TXT records] if you want to keep
> track of file version numbers.  Or something more recent, if you
> want.

Yeah, that I know... but where to place them to me seems less written
in stone...

> Just as a logistical thing, the SOA record should be in the zone
> file that $INCLUDEs the rest of the information, anmd no SOA record
> in the latter.

Is there any reason that that necessarily should be so? What I did was
create two views of the zone, let's call them "few" and "many" like
you did. Those views both contain example.com, with zone files
"db.example.com-few" and "db.example.com-many". Instead of what you
suggested, I flipped the order in the contents of the two files
(honestly, I'm not even certain that was necessary). So for example,
"db.example.com-many":

$INCLUDE db.example.com
@	IN	A	192.168.50.50

...where db.example.com is basically the same zone file I've used for
example.com all along, just with the A record for the domain removed.

> Which means, I should have added, that any time you update the
> $INCLUDEd file, you must update the serial numbers in the zone
> files doing the $INCLUDEs.  That's a small disadvantage of this
> method - but one which good discipline should overcome.

Yeah, this is what caused me to ask the question and, frankly, sounded
annoying, mainly because I was now maintaining three files to edit
just one DNS record, and the other two files contain a record that
will probably not change once in the next 5 years. So is there
anything wrong with doing it the way I've tried? It appears to work
just fine.

- -- 
- ---- _  _ _  _ ___  _  _  _
|Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Sr. Systems Programmer
|$&| |__| |  | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFfsyQACgkQmb+gadEcsb4Z4QCgoZV5PCRPJVrXUPgOhsUFMrW1
p6oAn2Rvj8ecZ4zwLNNWtzpP9zN21vAR
=M+Zf
-----END PGP SIGNATURE-----