Re: Clients Matching Multiple Views
On Apr 9, 2014, at 4:14 AM, Steven Carr wrote: However, assuming you are using views on the same IP address and not splitting it across internal/external servers as that would screw up NS records), you can reuse the same zone file so those zones that appear in both internal and external views refer back to the same zone file, then when you update that zone file both views are updated. My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. If I'm wrong, that would be a good thing to know. John Wobus Cornell U ___ 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
Re: Clients Matching Multiple Views
On 11 Apr 2014, at 18:59, John Wobus jw...@cornell.edu wrote: On Apr 9, 2014, at 4:14 AM, Steven Carr wrote: However, assuming you are using views on the same IP address and not splitting it across internal/external servers as that would screw up NS records), you can reuse the same zone file so those zones that appear in both internal and external views refer back to the same zone file, then when you update that zone file both views are updated. My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. If I'm wrong, that would be a good thing to know. John Wobus Cornell U If you were to use a DLZ for the dynamic zone rather than a file, then the multiple writer integrity can be handled by the DLZ code (i.e. palming it off to a RDBMS to deal with). Just a thought - but generally I agree that multiple writers to a file is just asking for trouble… - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: Clients Matching Multiple Views
On 04/11/2014 10:59 AM, John Wobus wrote: My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. You are correct. Include statements that reference the common data between the zones on the master has been the canonical way to handle this situation since day 1. Doug ___ 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
Re: Clients Matching Multiple Views
I had something similar a while back.
view 1
{
include external tables
include common tables
}
view 2
{
include internal tables
include common tables
}
Read that as tables for ONLY-internal or ONLY-external view.
I define each entry exactly once, also pushing stuff off to
the common include means I don't have to have two entries for
the same machine (one per view).
On Wed, Apr 09, 2014 at 08:37:20AM +0100, Mike Meredith wrote:
Hi!
Using BIND 9.9 here ...
I have a collection of secondaries with various zone masters (the
majority BIND, some ActiveDirectory). Some of the secondary DNS servers
are for internal use only; some are externally visible, but all are
configured with a common configuration file.
I have a need to make _some_ zones visible only internally with an
alternate zone visible externally. But the overwhelming majority of the
zones remain as they are. I guess you could call this partial
split-view.
I can do this in either of two rather inconvenient ways ... either I
split the configuration of the secondaries with the externally visible
ones configured differently to the internal ones, or I create two views
(internal and external) with the overwhelming majority of the zones
defined twice.
Neither option seems appealing.
What I've also tried is to create three views with configurations
like :-
view default {
match-clients { any; };
recursion no;
/* The majority of the zones */
};
view internal {
match-clients { internal; };
recursion yes;
/* The internal zones */
};
view external {
match-clients { external; };
recursion no;
/* The external zones */
};
... so that if a client matches multiple views, it tries each in turn.
However that doesn't seem to work, and the documentation implies that
it won't.
Am I missing something obvious? Such as it should work, but I've
somehow messed up? Or perhaps there's some option I've missed? Or am I
out of luck?
--
Mike Meredith, University of Portsmouth
Principal Systems Engineer, Hostmaster, Security, and Timelord!
___
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
---
Brian R Cuttler brian.cutt...@wadsworth.org
Computer Systems Support(v) 518 486-1697
Wadsworth Center(f) 518 473-6384
NYS Department of HealthHelp Desk 518 473-0773
___
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
Re: Clients Matching Multiple Views
On 9 April 2014 08:37, Mike Meredith mike.mered...@port.ac.uk wrote: Am I missing something obvious? Such as it should work, but I've somehow messed up? Or perhaps there's some option I've missed? Or am I out of luck? That's not how views work. When you match a view then that's it, you don't continue to check other views. The two ways you suggested are the way to do this. However, assuming you are using views on the same IP address and not splitting it across internal/external servers as that would screw up NS records), you can reuse the same zone file so those zones that appear in both internal and external views refer back to the same zone file, then when you update that zone file both views are updated. Steve ___ 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
Re: Clients Matching Multiple Views
On 09/04/2014 11:14 πμ, Steven Carr wrote: On 9 April 2014 08:37, Mike Meredith mike.mered...@port.ac.uk wrote: Am I missing something obvious? Such as it should work, but I've somehow messed up? Or perhaps there's some option I've missed? Or am I out of luck? That's not how views work. When you match a view then that's it, you don't continue to check other views. The two ways you suggested are the way to do this. However, assuming you are using views on the same IP address and not splitting it across internal/external servers as that would screw up NS records), you can reuse the same zone file so those zones that appear in both internal and external views refer back to the same zone file, then when you update that zone file both views are updated. But when the zone is dynamic, this file sharing cannot be done between views. Updates only match one zone, and are kept in memory (or .jnl). So how would we make this work in dynamic zones? Maybe we should have one view axfr from the other? Sot. ___ 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
Re: Clients Matching Multiple Views
On 9 April 2014 10:05, Sotiris Tsimbonis sts...@forthnet.gr wrote: But when the zone is dynamic, this file sharing cannot be done between views. Updates only match one zone, and are kept in memory (or .jnl). So how would we make this work in dynamic zones? Maybe we should have one view axfr from the other? Move anything dynamic to a dedicated master DNS server and make it a hidden master so it's not bogged down with handling queries, then slave the zones from that on your other DNS servers. Steve ___ 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
Re: Clients Matching Multiple Views
On Wed, 09 Apr 2014 12:05:07 +0300, Sotiris Tsimbonis sts...@forthnet.gr may have written: On 09/04/2014 11:14 πμ, Steven Carr wrote: That's not how views work. When you match a view then that's it, you don't continue to check other views. Thanks. As I suspected views select _clients_. It might be a handy new feature to define and group zones outside of views, and select which zone groups are visible inside a view. Updates only match one zone, and are kept in memory (or .jnl). So how would we make this work in dynamic zones? Maybe we should have one view axfr from the other? What I did in testing (and not very much at that) was to define the zones twice with different file names. Seemed to work fine ... at least the zone files and the journal files were created for both file names. -- Mike Meredith, University of Portsmouth Principal Systems Engineer, Hostmaster, Security, and Timelord! ___ 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
Re: Clients Matching Multiple Views
On 9 April 2014 13:09, Mike Meredith mike.mered...@port.ac.uk wrote: What I did in testing (and not very much at that) was to define the zones twice with different file names. Seemed to work fine ... at least the zone files and the journal files were created for both file names. BIND will allow you to configure it like that but remember clients can only update a _single_ view, so if you have the same zone in multiple views then they will quickly get out of step if they are accepting dynamic updates as some updates will be made in one view, others in the other view. So the easiest way to settle that is to have a _single_ authoritative source for the dynamic zone that both internal/external clients can update, then that zone is slaved to both the views needing to serve it, AKA hidden master. DNS BIND (ISBN:9780596100575) is your friend :) Steve ___ 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
Re: Clients Matching Multiple Views
I faced a similar situation when setting up my servers. The way I handled it (correctly or not) was to built the zones in the internal view as master, and then the external view slaved to the internal master. That way you can simply update your internals, and the external side automatically populates. The end result, is that you still have to define the zones in both views, and that you still end up with multiple data files for the same zone. But you still only have to manage 1 set of those files, and not make the same changes in multiple places. This setup uses TSIG keys to do the transfers, which is handy as you need to use TSIG keys to transfer different views to slave servers. On Wed, Apr 9, 2014 at 9:30 AM, Steven Carr sjc...@gmail.com wrote: On 9 April 2014 13:09, Mike Meredith mike.mered...@port.ac.uk wrote: What I did in testing (and not very much at that) was to define the zones twice with different file names. Seemed to work fine ... at least the zone files and the journal files were created for both file names. BIND will allow you to configure it like that but remember clients can only update a _single_ view, so if you have the same zone in multiple views then they will quickly get out of step if they are accepting dynamic updates as some updates will be made in one view, others in the other view. So the easiest way to settle that is to have a _single_ authoritative source for the dynamic zone that both internal/external clients can update, then that zone is slaved to both the views needing to serve it, AKA hidden master. DNS BIND (ISBN:9780596100575) is your friend :) Steve ___ 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 -- Jason K. Brandt Systems Administrator Bradley University ___ 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
