No subject

Roberto Carna robertocarna36 at gmail.com
Tue Feb 19 12:45:48 UTC 2019


Dear Kevin, I am sorry but I didn't see your past response.

Please can you show me with an example what you say: "Define root zone.
Delegate teamviewer.com from root. Define teamviewer.com as 'type forward'".

An also what is the benefit in defining a root zone with the teamviewer.com
delegated into it??? Because I put to work this zone just as a forward
zone, without a root zone definition.

Special thanks again!!!

El lun., 18 feb. 2019 a las 17:00, Kevin Darcy (<kevin.darcy at fcagroup.com>)
escribió:

> I've already posted a solution for this. Basically, "Define root zone.
> Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
> forward'".
>
> "Recursion yes" is implied. No views necessary. It doesn't make any sense
> anyway, to have the same match-clients list for all of one's views, since
> the first one matched is the one that's used.
>
> Did you not see my response, or did you perhaps dislike the approach I
> suggested?
>
> There was some subsequent discussion about not relying on DNS resolution
> as one's *only* control over what sites one's clients can or cannot access.
> While I agree with that, my position is that there's nothing wrong with
> controlling DNS resolution, in addition to other controls.
>
>                                               - Kevin
>
> On Mon, Feb 18, 2019 at 10:44 AM Roberto Carna <robertocarna36 at gmail.com>
> wrote:
>
>> Dear I've implemented two views, one for local resolution and the other
>> for forward a public zone to our resolver.
>>
>> But now I have a problem:
>>
>> If I define the same clients for the local zone view and forward view,
>> depending on the order of the views the client can resolve or not the
>> query. In this case client 10.12.1.1 will match view INT and not view
>> EXT:
>>
>> acl internal { 10.12.1. <https://10.12.1.4>1; };
>> acl external { 10.12.1.1; };
>>
>> view "INT" {
>> match-clients { internal; };
>> recursion no;
>> zone "company.com" {
>> type master;
>> file "/etc/bind/zones/company.com.db";
>> };
>>
>> view "EXT" {
>> match-clients { external; };
>> recursion yes;
>> zone "teamviewer.com" {
>> type forward;
>> forward only;
>> forwarders {
>> 172.1 <https://172.17.10.25>8.1.1;
>> };
>> };
>>
>> If I define just one view with local and forward zones, I have to define
>> "recursion yes" because the forward zone need this option, but in this case
>> a query for a local zone is trying to be resolved against ROOT Servers and
>> finally against master zone but it takes some seconds:
>>
>> acl unique { 10.12.1. <https://10.12.1.4/>1; };
>>
>> view "INT-EXT" {
>> match-clients { unique; };
>> recursion yes;
>> zone "company.com" {
>> type master;
>> file "/etc/bind/zones/company.com.db";
>> };
>> zone "teamviewer.com" {
>> type forward;
>> forward only;
>> forwarders {
>> 172.1 <https://172.17.10.25/>8.1.1;
>> };
>> };
>>
>> How can I define same clients to try resolving first view and -if there
>> is no response- they try with second view ???
>>
>> Or is there any other way to do what I want?
>>
>> Regards
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190219/c0c47707/attachment-0001.html>


More information about the bind-users mailing list