Exceptions for zones with DNS views

Stefan Midjich swehack at gmail.com
Mon Oct 22 10:49:47 UTC 2012


Thank you Sten, that's a great explanation. I had already read the ARM but
the ARM did not explain why it seemed to work at my home.

I will check tcpdump to investigate further but I believe you're on to
something.

2012/10/22 Sten Carlsen <stenc at s-carlsen.dk>

>
> From the Bind ARM
>
> 6.2.24 view Statement Definition and Usage
>  The view statement is a powerful feature of BIND 9 that lets a name
> server answer a DNS query differ- ently depending on who is asking. It is
> particularly useful for implementing split DNS setups without having to run
> multiple servers.
>
> Each view statement defines a view of the DNS namespace that will be seen
> by a subset of clients. A client matches a view if its source IP address
> matches the address match list of the view’s match- clients clause and
> its destination IP address matches the address match list of the view’s match-
> destinations clause. If not specified, both match-clients and match-destinations
> default to matching all addresses. In addition to checking IP addresses match-clients
> and match-destinations can also take keys which provide an mechanism for
> the client to select the view. A view can also be specified as match-recursive-only,
> which means that only recursive requests from matching clients will match
> that view. The order of the view statements is significant — *a client
> request will be resolved in the context of the first **view **that it
> matches. *
>   Your intranet view is recursive, hence it will resolve your "master
> zones" from the root since they don't exist in the view.
>
> My guess is that your DNS server is a hidden master and the recursion will
> point to your slaves, which are not in the same machine and will therefore
> give you the answer, possibly you will have the benefit from a side effect
> of NAT, that in asking the external address, it will look like you come
> from !localnets but from your external address.
>
> Wireshark or similar could tell you exactly how the resolution happens, I
> suggest you trace queries very carefully, noting both addresses of every
> packet involved.
>
>
> On 22/10/12 10:48, Stefan Midjich wrote:
>
> This seems very cumbersome to have copies of every single zone for every
> single view. That would quickly reach thousands of zones, all have to be
> maintained for every single change in a zone.
>
> I'm asking, are you sure? My first venture into views was my private
> router at home. It has very few zones but it has two views, one intranet
> and one wan (internet).
>
> Just to show an example, my wan view has domain1.se and domain2.se. My
> intranet view has domain1.se and nothing else.
>
> domain1.se in intranet and wan point to different IP-addresses, in
> intranet they're internal and in wan they're external.
>
> domain2.se exists only in wan view and points to external IP-addresses.
>
> If I do a query from may LAN for server.domain1.se I get an internal IP,
> if I do a query from my LAN for domain2.se I get an external IP.
>
> That means I don't have a copy of domain2.se in both views, but I can
> still get a response from BIND for domain2.se from the lan and wan views.
>
> This is my configuration at home.
>
> acl lanClients {
>  192.168.22.0/24;
>  127.0.0.1;
> };
>
> view "intranet" {
>  match-clients { lanClients; };
>  recursion yes;
>  notify no;
>
>  // Standard zones
>  //
>  zone "." {
>   type hint;
>   file "etc/root.hint";
>  };
>
>  zone "domain1.se" {
>   type master;
>   file "intranet/domain1.se";
>  };
> };
>
> view "internet" {
>  match-clients { !localnets; any; };
>  recursion no;
>  allow-transfer { slaveDNS; };
>
>  include "master.zones";
> };
>
> The above configuration is just a snippet but it works the way I want. One
> zone exists in two views, it responds differently in intranet as opposed to
> wan. Another zone exists only in wan yet it responds correctly both from
> LAN and wan.
>
> I am unable to copy this configuration to two other name servers with
> hundreds of zones. This is my goal.
>
> 2012/10/22 Sten Carlsen <stenc at s-carlsen.dk>
>
>>
>> On 22/10/12 9:32, Stefan Midjich wrote:
>>
>> I want to have an exception for certain zones that also exist in my main
>> "wan" view.
>>
>> So I created an acl for the network that needs the exception.
>>
>> acl OtherNetwork {
>>  10.0.2.192/28;
>> };
>>
>> Then I made this block.
>>
>> view "OtherNetwork" {
>>  match-clients { OtherNetworkClients; };
>>  allow-recursion { OtherNetworkClients; };
>>  include "/etc/bind/views/othernetwork.zones";
>> };
>>
>> This worked for the othernetwork.zones, but if I request any zones
>> outside of this view I get no response.
>>
>> I want requests for other zones to be forwarded to the "wan" view where
>> the rest of the zones are. How can I accompllish this with Bind? The only
>> solution I can see now is to copy and maintain hundreds of zones for each
>> view, there must be an easier way.
>>
>>  You should look at each view as a separate server without any
>> connection to the other servers.
>>
>> Your "OtherNetwork" server has no other information than what you show
>> here, your other networks will be resolved by normal recursion from the
>> root up.
>>
>> The traditional solution here is to include a copy of the other zones
>> here, separate files, not a reference to the same files, specially if any
>> kind of dynamic DNS is valid.
>>
>>
>> --
>> Hälsningar / Greetings
>>
>> Stefan Midjich
>> [De omnibus dubitandum]
>>
>>
>>  _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> bind-users mailing listbind-users at lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users
>>
>>
>> --
>> Best regards
>>
>> Sten Carlsen
>>
>> No improvements come from shouting:
>>        "MALE BOVINE MANURE!!!"
>>
>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
>
> --
> Hälsningar / Greetings
>
> Stefan Midjich
> [De omnibus dubitandum]
>
>
> --
> Best regards
>
> Sten Carlsen
>
> No improvements come from shouting:
>        "MALE BOVINE MANURE!!!"
>
>


-- 
Hälsningar / Greetings

Stefan Midjich
[De omnibus dubitandum]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20121022/15f9f8b1/attachment.html>


More information about the bind-users mailing list