-----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 |$&| |__| | | |__/ | \| _| |novos...@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----- _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
