Re: Forward zone inside a view

2019-02-07 Thread Paul Kosinski
I haven't analyzed the details and pitfalls, but could a Web proxy
mechanism of some sort be of help? In particular, rather than having
your users directly access "teamviewer.org" (or whatever), have them to
access "teamviewer.local", which is resolved by your internal DNS to a
specialized proxy server.

Then set up this proxy server to forward those requests to
"teamviewer.org", *not* its IP address (since that can, of course,
change). This is likely the hard part, but the proxy can at least
assume that it never gets HTTP(S) requests in general. 

In other words, move the mapping one level up in the protocol stack,
from the DNS layer to the HTTP(S) layer.

And, if the proxy can support the equivalent of name-based hosting, then
it could support multiple local domain redirects, if needed in the
future. 

P.S. PRIVOXY is probably able at least to do the redirect for a single
domain -- and it's lightweight.




On Thu, 7 Feb 2019 15:00:47 -0500
Alan Clegg  wrote:

> On 2/7/19 2:30 PM, Roberto Carna wrote:
> > Dear, thanks for your contact. I've used teamviewer.com
> >  just for tests.
> > 
> > Desktops I mentioned can only access to web apps from internal
> > domains, but in some web apps there are links to download
> > Teamviewer client software from Internet. I can create a private
> > zone "teamviewer.com " with all the
> > hostnames and IP's we will use, but if they change I will be in
> > trouble.
> 
> Sounds to me like a use for a global block with RPZ and a passthrough
> for the domain that needs to be ... uh ... passed through.
> 
> And from my experience, this is never going to work because whatever
> the "only thing we want to resolve" is, it will rely on something
> else that you don't (currently) resolve.
> 
> Anyone that has ever tried to block their "smart TV" so that it only
> allows certain apps but not others will know exactly what I'm talking
> about.
> 
> AlanC

___
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: Forward zone inside a view

2019-02-07 Thread Alan Clegg
On 2/7/19 2:30 PM, Roberto Carna wrote:
> Dear, thanks for your contact. I've used teamviewer.com
>  just for tests.
> 
> Desktops I mentioned can only access to web apps from internal domains,
> but in some web apps there are links to download Teamviewer client
> software from Internet. I can create a private zone "teamviewer.com
> " with all the hostnames and IP's we will use,
> but if they change I will be in trouble.

Sounds to me like a use for a global block with RPZ and a passthrough
for the domain that needs to be ... uh ... passed through.

And from my experience, this is never going to work because whatever the
"only thing we want to resolve" is, it will rely on something else that
you don't (currently) resolve.

Anyone that has ever tried to block their "smart TV" so that it only
allows certain apps but not others will know exactly what I'm talking about.

AlanC
___
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: Forward zone inside a view

2019-02-07 Thread Roberto Carna
Dear, thanks for your contact. I've used teamviewer.com just for tests.

Desktops I mentioned can only access to web apps from internal domains, but
in some web apps there are links to download Teamviewer client software
from Internet. I can create a private zone "teamviewer.com" with all the
hostnames and IP's we will use, but if they change I will be in trouble.

So we need to forward the query to our resolvers in order to get a valid
response.

So I think we can use the forward option from BIND, but it doesn't work at
all as I described:

1. "recursion no" can only be set at the top (view) level, not overridden
   at the zone level.

2. If I set "recursion no" at the view level, then a "type forward"
   zone has no effect:

  view "foo" {
recursion no;
...
zone "teamviewer.com" {
  type forward;
  forward only;
  forwarders {172.18.1.1; 172.18.1.2;};
};

-- query for foo.teamviewer.com fails and tell it's not a recursive query

3. If I define "recursion yes" at view level:

  view "foo" {
recursion yes;
...
zone "teamviewer.com" {
  type forward;
  forward only;
  forwarders {172.18.1.1; 172.18.1.2;};
};

-- query for foo.teamviewer.com is OK, but also I get response OK from
foo.ibm.com, foo.google.com, and any other public domain from Internet
(and this is not what I want, it's what I'm trying to prevent))

So can you help me please???

Regards.


El jue., 7 feb. 2019 a las 15:40, Matus UHLAR - fantomas ()
escribió:

> On 07.02.19 14:58, Roberto Carna wrote:
> >In our company we have several desktops from two different cities
> accessing
> >only to internal domains distributed in two views in a private BIND with
> >authoritative zones, where I've defined "recursion no;".
> >
> >But now we have to let them access to *.teamviewer.com hostnames, just
> this
> >public domain and not other.
>
> btw, when did linux.org change to teamviewer.com?
>
> >So I've implemented the forwarding of "teamviewer.com" zone to our BIND
> >resolvers servers (they forward DNS queries to 8.8.8.8). So I've created a
> >third view with this information in named.conf.local:
> >
> >acl internet { 10.0.0.0/24 };
> >
> >view "internet" {
> >
> >   match-clients { internet; key "custom"; };
> >
> > recursion yes;
> >
> > zone "teamviewer.com" {
> >
> >type forward;
> >
> >forward only;
> >
> >forwarders {
> >
> >172.18.1.1;
> >
> >172.18.1.2;
> >
> >};
> >
> >};
>
>
> >I defined "recursion yes" but the BIND servers forwards all the public
> >domains queries to our resolvers and not just for "teamviewer.com", so it
> >doesn't work. And if I change for "recursion no", the query
> >www.teamviewer.com is refused and at the client side appears an error
> >telling that recursion is necessary.
>
> of course, BIND will resolve other domains (recurse) only when you allow it
> to recurse.
>
> >So I let desktops resolve all the Internet domains or neither, and this is
> >not what I want because I just want to let them resolve just
> teamviewer.com.
> >
> >How can I do to forward only teamviewer.com zone queries to my
> resolvers???
>
> what is the point of running DNS server with only two hostnames allowed to
> resolve?
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Despite the cost of living, have you noticed how popular it remains?
> ___
> 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
>
___
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: Forward zone inside a view

2019-02-07 Thread Matus UHLAR - fantomas

On 07.02.19 14:58, Roberto Carna wrote:

In our company we have several desktops from two different cities accessing
only to internal domains distributed in two views in a private BIND with
authoritative zones, where I've defined "recursion no;".

But now we have to let them access to *.teamviewer.com hostnames, just this
public domain and not other.


btw, when did linux.org change to teamviewer.com?


So I've implemented the forwarding of "teamviewer.com" zone to our BIND
resolvers servers (they forward DNS queries to 8.8.8.8). So I've created a
third view with this information in named.conf.local:

acl internet { 10.0.0.0/24 };

view "internet" {

  match-clients { internet; key "custom"; };

recursion yes;

zone "teamviewer.com" {

   type forward;

   forward only;

   forwarders {

   172.18.1.1;

   172.18.1.2;

   };

};




I defined "recursion yes" but the BIND servers forwards all the public
domains queries to our resolvers and not just for "teamviewer.com", so it
doesn't work. And if I change for "recursion no", the query
www.teamviewer.com is refused and at the client side appears an error
telling that recursion is necessary.


of course, BIND will resolve other domains (recurse) only when you allow it
to recurse.


So I let desktops resolve all the Internet domains or neither, and this is
not what I want because I just want to let them resolve just teamviewer.com.

How can I do to forward only teamviewer.com zone queries to my resolvers???


what is the point of running DNS server with only two hostnames allowed to
resolve?

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Despite the cost of living, have you noticed how popular it remains? 
___

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: Forward zone inside a view

2019-02-07 Thread Roberto Carna
Ok Tony, please let me explain to you.

In our company we have several desktops from two different cities accessing
only to internal domains distributed in two views in a private BIND with
authoritative zones, where I've defined "recursion no;".

But now we have to let them access to *.teamviewer.com hostnames, just this
public domain and not other.

So I've implemented the forwarding of "teamviewer.com" zone to our BIND
resolvers servers (they forward DNS queries to 8.8.8.8). So I've created a
third view with this information in named.conf.local:

acl internet { 10.0.0.0/24 };

view "internet" {

   match-clients { internet; key "custom"; };

 recursion yes;

 zone "teamviewer.com" {

type forward;

forward only;

forwarders {

172.18.1.1;

172.18.1.2;

};

};

I defined "recursion yes" but the BIND servers forwards all the public
domains queries to our resolvers and not just for "teamviewer.com", so it
doesn't work. And if I change for "recursion no", the query
www.teamviewer.com is refused and at the client side appears an error
telling that recursion is necessary.

So I let desktops resolve all the Internet domains or neither, and this is
not what I want because I just want to let them resolve just teamviewer.com.

How can I do to forward only teamviewer.com zone queries to my resolvers???

Sorry for my new message, special thanks Tony !!!

El jue., 7 feb. 2019 a las 13:41, Tony Finch () escribió:

> Roberto Carna  wrote:
> >
> > So how can I define "recursion yes" just for the zone "linux.org" ???
>
> You can turn recursion on and off for the entire server, or per view, but
> not per zone.
>
> It isn't clear to me what you want this server to do. If it is providing
> DNS service to end-user devices (if it is configured in /etc/resolv.conf
> or advertised by DHCP) then it needs to provide recursive service. If not,
> then I am even more confused about what you are trying to do!
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> St Davids Head to Great Orme Head, including St Georges Channel: Southwest
> 5
> or 6, increasing 7 to severe gale 9. Moderate or rough becoming very rough.
> Rain and drizzle, squally showers later. Moderate or good, occasionally
> poor.
>
___
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: Classless Reverse Zones PTR Dig Format Issue

2019-02-07 Thread G.W. Haywood via bind-users

Hi there,

On Thu, 7 Feb 2019, Matus UHLAR - fantomas wrote:

On 07.02.19 12:53, Nagesh Thati wrote:

I have created a network with *199.192.0.0/11 * and
created 4 subnets with */13* mask in that network,
Network: *199.192.0.0/11  : 192.199.in-addr.arpa*,
Subnet1: *199.192.0.0/13  : 0-13.192.199.in-addr.arpa*,
Subnet2: *199.200.0.0/13  : 0-13.200.199.in-addr.arpa*,
Subnet3: *199.208.0.0/13  : 0-13.208.199.in-addr.arpa*,
Subnet4: *199.216.0.0/13  : 0-13.216.199.in-addr.arpa*.


holy shit ...


H.

$ dig +short -x 199.192.0.1
dhhs1.dhhs.state.nh.us.
$ dig +short -x 199.200.10.10
www.winamonga.com.
$ dig +short -x 199.208.121.1
dha-121-1.health.mil.
$ dig +short -x 199.216.0.1
gov.ab.ca.

--

73,
Ged.
___
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: Forward zone inside a view

2019-02-07 Thread Tony Finch
Roberto Carna  wrote:
>
> So how can I define "recursion yes" just for the zone "linux.org" ???

You can turn recursion on and off for the entire server, or per view, but
not per zone.

It isn't clear to me what you want this server to do. If it is providing
DNS service to end-user devices (if it is configured in /etc/resolv.conf
or advertised by DHCP) then it needs to provide recursive service. If not,
then I am even more confused about what you are trying to do!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Southwest 5
or 6, increasing 7 to severe gale 9. Moderate or rough becoming very rough.
Rain and drizzle, squally showers later. Moderate or good, occasionally poor.
___
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: Forward zone inside a view

2019-02-07 Thread Roberto Carna
When I query www.teamviewer from a desktop, I fail and get this error in
dig:

 WARNING: recursion requested but not available

In BIND I have in named.conf.local:

zone "linux. org" {
type forward;
forwarders {
172.18.1.1;
172.18.1.2;
};

and "recursion no;" is defined in named.conf.options.

How can enable the recursion for linux.org queries in order to forward them
to my resolvers???

Thanks a lot

El jue., 7 feb. 2019 a las 11:40, Roberto Carna ()
escribió:

> Tony, as you said forwarding requires recursion but when I define:
>
> zone "linux. org" {
> recursion yes;
> type forward;
> forward only;
> forwarders {
> 172.18.1.1;
> 172.18.1.2;
> };
>
> and after that I restart bind9 service, it fails:
>
> unknown option 'recursion'
>
> So how can I define "recursion yes" just for the zone "linux.org" ???
>
> Sorry for my newquestion, I'd appreciate your help.
>
> Regards!!!
>
>
> El jue., 7 feb. 2019 a las 11:26, Tony Finch () escribió:
>
>> Roberto Carna  wrote:
>>
>> > Dear Tony, I forward the "linux.org" queries from our private Bind to
>> our
>> > Bind resolvers (they have authoritative public zones and also they are
>> > resolvers that forward the queries to 8.8.8.8).
>> >
>> > So why you say they are authoritative only servers?
>>
>> Oh, I misread your explanation, I thought the "recursion no" in your
>> configuration was on the target server. But it is on the server with the
>> "type forward" zone, and since forwarding requires recursion, it will not
>> work.
>>
>> Tony.
>> --
>> f.anthony.n.finchhttp://dotat.at/
>> Shannon: Southwest 7 to severe gale 9, veering west gale 8 to storm 10
>> later.
>> Very rough, becoming high or very high. Rain or squally showers. Poor.
>>
>
___
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: Forward zone inside a view

2019-02-07 Thread Roberto Carna
Tony, as you said forwarding requires recursion but when I define:

zone "linux. org" {
recursion yes;
type forward;
forward only;
forwarders {
172.18.1.1;
172.18.1.2;
};

and after that I restart bind9 service, it fails:

unknown option 'recursion'

So how can I define "recursion yes" just for the zone "linux.org" ???

Sorry for my newquestion, I'd appreciate your help.

Regards!!!


El jue., 7 feb. 2019 a las 11:26, Tony Finch () escribió:

> Roberto Carna  wrote:
>
> > Dear Tony, I forward the "linux.org" queries from our private Bind to
> our
> > Bind resolvers (they have authoritative public zones and also they are
> > resolvers that forward the queries to 8.8.8.8).
> >
> > So why you say they are authoritative only servers?
>
> Oh, I misread your explanation, I thought the "recursion no" in your
> configuration was on the target server. But it is on the server with the
> "type forward" zone, and since forwarding requires recursion, it will not
> work.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Shannon: Southwest 7 to severe gale 9, veering west gale 8 to storm 10
> later.
> Very rough, becoming high or very high. Rain or squally showers. Poor.
>
___
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: Forward zone inside a view

2019-02-07 Thread Tony Finch
Roberto Carna  wrote:

> Dear Tony, I forward the "linux.org" queries from our private Bind to our
> Bind resolvers (they have authoritative public zones and also they are
> resolvers that forward the queries to 8.8.8.8).
>
> So why you say they are authoritative only servers?

Oh, I misread your explanation, I thought the "recursion no" in your
configuration was on the target server. But it is on the server with the
"type forward" zone, and since forwarding requires recursion, it will not
work.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon: Southwest 7 to severe gale 9, veering west gale 8 to storm 10 later.
Very rough, becoming high or very high. Rain or squally showers. Poor.
___
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: Forward zone inside a view

2019-02-07 Thread Roberto Carna
Dear Tony, I forward the "linux.org" queries from our private Bind to our
Bind resolvers (they have authoritative public zones and also they are
resolvers that forward the queries to 8.8.8.8).

So why you say they are authoritative only servers?

A I said, can I still use the forward option for "linux.org" ???

Thanks a lot again!!!

El jue., 7 feb. 2019 a las 11:05, Tony Finch () escribió:

> Roberto Carna  wrote:
>
> > Dear, I have Bind 9.10.3 as our private DNS service with two views, one
> of
> > them let some clients to query linux.org domain from Internet forwarding
> > the query to our Bind resolvers, but the query is refused by our private
> > Bind.
>
> You can't forward to an authoritative-only server. Use a static-stub zone
> configuration instead.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Tyne: West, backing south, 5 to 7. Slight or moderate, occasionally rough
> later. Showers. Good occasionally moderate.
>
___
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: Forward zone inside a view

2019-02-07 Thread Tony Finch
Roberto Carna  wrote:

> Dear, I have Bind 9.10.3 as our private DNS service with two views, one of
> them let some clients to query linux.org domain from Internet forwarding
> the query to our Bind resolvers, but the query is refused by our private
> Bind.

You can't forward to an authoritative-only server. Use a static-stub zone
configuration instead.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Tyne: West, backing south, 5 to 7. Slight or moderate, occasionally rough
later. Showers. Good occasionally moderate.
___
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


Forward zone inside a view

2019-02-07 Thread Roberto Carna
Dear, I have Bind 9.10.3 as our private DNS service with two views, one of
them let some clients to query linux.org domain from Internet forwarding
the query to our Bind resolvers, but the query is refused by our private
Bind.

The private Bind has these main parameters in named.conf.options:

options {
directory "/var/cache/bind";
allow-transfer {"none";};

   dnssec-validation auto;
dnssec-enable yes;
auth-nxdomain no;
allow-query { any; };
recursion no;
version "none";
};

And this is te relevant part of named.conf.local:

acl internet { 10.0.0.0/24; };

view "INTERNET" {
   match-clients { internet; key "custom";};

zone "linux. org" {
type forward;
forward only;
forwarders {
172.18.1.1;
172.18.1.2;
};
};

};

Please can you help me in forward the query for linux.org hostnames from
the private BIND with the views to our resolvers?

Thanks a lot!!!
___
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: Classless Reverse Zones PTR Dig Format Issue

2019-02-07 Thread Matus UHLAR - fantomas via bind-users

On 07.02.19 12:53, Nagesh Thati wrote:

I have created a network with *199.192.0.0/11 * and
created 4 subnets with */13* mask in that network,
Network: *199.192.0.0/11  : 192.199.in-addr.arpa*,
Subnet1: *199.192.0.0/13  :
0-13.192.199.in-addr.arpa*,
Subnet2: *199.200.0.0/13  :
0-13.200.199.in-addr.arpa*,
Subnet3: *199.208.0.0/13  :
0-13.208.199.in-addr.arpa*,
Subnet4: *199.216.0.0/13  :
0-13.216.199.in-addr.arpa*.


holy shit, gmail formats IP addresses as URLS and messes it up even more and
more.  Try avoiding gmail web interface whenever possible.



I fallowed the *RFC 2317 to create CNAME and NS records* in parent zone
which is 192.199.in-addr.arpa


It's useless to create classless delegations in this case.
Classless delegation is useful only for delegations less than /24

simply delegate 192.199.in-addr.arpa to 199.199.in-addr.arpa etc.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Remember half the people you know are below average. 
___

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: Advice for DNS reverse zones

2019-02-07 Thread Mik J via bind-users
 Hello Bob, Tony,
Thank you for your answers, I'm going to study this topic.
Regards

Le mercredi 6 février 2019 à 21:11:59 UTC+1, Bob Harold 
 a écrit :  
 
 
On Wed, Feb 6, 2019 at 1:03 PM Mik J via bind-users  
wrote:

Hello,
I would like to know how do you manage reverse zones and the 10.x.x.x zone 
particularly.
I can see three choices:- One global 10.in-addr.arpa zone- Many /24 zones 
1.1.10.in-addr.arpa zone- Something in between
One global zone:The problem is that I end having a very populated zone and if 
someone asks me to setup an acl or anything like that it has to be global.This 
solution might be the easiest but definatly not the best in terms of scalability
Many /24 zones:The problem is that I end creating zones all the time or make 
them first in one go, so 65536 zones...And when someone has a /16 network I 
need to delete the 256 x /24 zones to make one single.
What do you people do on your DNS servers ?

And is it possible to make a 1.1.10.in-addr.arpa for the 16 first adresses (a 
/28 network) ?
Regards

For ranges with few records, that don't need to be acl'ed or delegated, put 
them in the 10.in-addr.arpa zone.Any /16 that has a lot of records can be split 
off into its own 2.10.in-addr.arpa.An if a /24 gets really busy, you can split 
it out 5.1.10.in-addr.arpa
There is no need to create all 256 /16's or all the /24's, just create them as 
needed.
If having different sizes is too confusing, I suggest all /16's.
-- Bob Harold
  ___
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