Re: Re: Re: zone not loaded in one of view

du.cn wrote: Hi, I have a bind9 authoritative name server running, but I found a strange problem. One of zone in a specific view not loaded when I view the cache_dump.db after I execute `rndc dumpdb -all`. The zone data file is almost the same for difference views execpted some few domain

Re: Re: zone not loaded in one of view

e a bind9 authoritative name server running, but I found a > strange problem. One of zone in a specific view not loaded when I view the > cache_dump.db after I execute `rndc dumpdb -all`. > > > The zone data file is almost the same for difference views execpted some > few domain reso

Re: Re: zone not loaded in one of view

2, liudong...@ynu.edu.cn wrote: Hi, I have a bind9 authoritative name server running, but I found a strange problem. One of zone in a specific view not loaded when I view the cache_dump.db after I execute `rndc dumpdb -all`. The zone data file is almost the same for difference views execpted some f

Re: zone not loaded in one of view

Read your logs and/or use named-checkzone and/or tell name-checkconf to load the zones. -- Mark Andrews > On 17 Dec 2023, at 15:22, liudong...@ynu.edu.cn wrote: > >  > Hi, I have a bind9 authoritative name server running, but I found a strange > problem. One of zone in

zone not loaded in one of view

Hi, I have a bind9 authoritative name server running, but I found a strange problem. One of zone in a specific view not loaded when I view the cache_dump.db after I execute `rndc dumpdb -all`. The zone data file is almost the same for difference views execpted some few domain resolution

Re: in-view RPZ definitions

for getting this all going. I'm also not sure if it would actually solve my problems, since I need to provide different responses based on which view/user population the request comes from, and it doesn't look like the client IP is made available to any of the SQL queries that run when querying a DLZ

Re: in-view RPZ definitions

do did not work at the time of this > thread 8 years ago, but I'm wondering if anything has changed by now. Many things have, but not this particular thing yet. To explain the problem, each view has an "RPZ summary database" which is an index of all the rules in the response-policy zo

in-view RPZ definitions

, and define RPZ zones that can be shared among multiple views using the "in-view" config. I'm attempting to use a config like the following: view Child { match-clients { Child; }; allow-recursion { any; }; response-policy { zone "cf1"; zone "cf2"; }; zone "cf1&qu

Re: BIND-9.10.2-P4: Cannot use in-view to refer to RPZ zone definitions: "'$RPZ_ZONE' is not a master or slave zone"

processes, resulting in long startup times and very high memory utilization. So I wanted to use views to reduce named to a single process, and define RPZ zones that can be shared among multiple views using the "in-view" config. I'm using a config like the following: view Child { mat

Fwd: In-View Support for RPZ Slave Zones

> Hello Gurus, > > I am in an urgent need to have a workaround of getting the in-view feature > supported for RPZ slave zones which I know isn’t supported by default. > > I am implementing a multi tenant recursive DNS where I have multiple views > and I need to unify

Re: In-View Support for RPZ Slave Zones

Hello Gurus, > > I am in an urgent need to have a workaround of getting the in-view feature > supported for RPZ slave zones which I know isn’t supported by default. > > I am implementing a multi tenant recursive DNS where I have multiple views > and I need to unify the

Re: dnssec-policy syntax error in options but not in view

an tell named to use the policy. Move the definition outside of options. -- Mark Andrews On 4 Aug 2023, at 08:26, E R wrote:  My understanding from the ARM is that the dnssec-policy can be in the "options", "view" or "zone".  I have mine in "view"

Re: dnssec-policy syntax error in options but not in view

You can’t define a policy there. You can tell named to use the policy. Move the definition outside of options. -- Mark Andrews > On 4 Aug 2023, at 08:26, E R wrote: > >  > My understanding from the ARM is that the dnssec-policy can be in the > "options", "

dnssec-policy syntax error in options but not in view

My understanding from the ARM is that the dnssec-policy can be in the "options", "view" or "zone". I have mine in "view" and when I try to move into "options" I get a syntax error that I cannot seem to understand what is wrong. I stripped out

Re: ,Re: caching does not seem to be working for internal view

On Wed, 3 Aug 2022 15:10:39 -0400 Timothe Litt wrote: > Hmm.  Your resolv.conf says that it's written by NetworkManager. > > What I suggested should have stopped it from updating resolv.conf. > > See >

Re: caching does not seem to be working for internal view

On 8/3/22, Robert Moskowitz via bind-users wrote: > thanks Greg. Yes I need to figure out how to troubleshoot this. But > here is some stuff: > > # cat resolv.conf > # Generated by NetworkManager > search attlocal.net htt-consult.com > nameserver 23.123.122.146 > nameserver 2600:1700:9120:4330::1

Re: caching does not seem to be working for internal view

Hi Robert. Turn on query logging by doing "rndc querylog". You should see a message saying that has been done in "named.log", to where each query will now be logged. If you have views, part of the query log will contain which view was matched. So this will tell y

Re: caching does not seem to be working for internal view

the zones in the Internal View, not all public stuff looked up by internal clients? I say this because I get fast responses to internal servers, but slow if at all to external ones. Grasping here because my search foo is weak and I can't find where it is defined exactly what IS cached. On 8/

Re: ,Re: caching does not seem to be working for internal view

Hmm.  Your resolv.conf says that it's written by NetworkManager. What I suggested should have stopped it from updating resolv.conf. See

Re: caching does not seem to be working for internal view

Perhaps this is only caching the zones in the Internal View, not all public stuff looked up by internal clients? I say this because I get fast responses to internal servers, but slow if at all to external ones. Grasping here because my search foo is weak and I can't find where it is defined

Re: ,Re: caching does not seem to be working for internal view

On 8/3/22 12:59, Timothe Litt wrote: Try echo -e "[main]\ndns=none" > /etc/NetworkManager/conf.d/no-dns.conf systemctl restart NetworkManager.service Same content in resolv.conf.  BTW this is on Centos7. Timothe Litt ACM Distinguished Engineer -- This

Re: ,Re: caching does not seem to be working for internal view

On 8/3/22 13:10, Anand Buddhdev wrote: On 03/08/2022 18:36, Robert Moskowitz wrote: Hi Robert, [snip] ARGH! I want the IPv6 addr from my firewall/gateway.  But I don't want that IPv6 nameserver! Calm down. Just add "PEERDNS=no" in your ifcfg-eth0 file. This way, the resolv.conf file

Re: ,Re: caching does not seem to be working for internal view

On 03/08/2022 18:36, Robert Moskowitz wrote: Hi Robert, [snip] ARGH! I want the IPv6 addr from my firewall/gateway.  But I don't want that IPv6 nameserver! Calm down. Just add "PEERDNS=no" in your ifcfg-eth0 file. This way, the resolv.conf file will only contain your specified DNS

Re: ,Re: caching does not seem to be working for internal view

Try echo -e "[main]\ndns=none" > /etc/NetworkManager/conf.d/no-dns.conf systemctl restart NetworkManager.service Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. On

Re: ,Re: caching does not seem to be working for internal view

On 8/3/22 11:35, Timothe Litt wrote: On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote: # cat resolv.conf My server is 23.123.122.146.  That IPv6 addr is my ATT router. You don't want to do that.  The ATT router will not know how to resolve internal names.  There is no guarantee

,Re: caching does not seem to be working for internal view

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote: # cat resolv.conf My server is 23.123.122.146.  That IPv6 addr is my ATT router. You don't want to do that.  The ATT router will not know how to resolve internal names.  There is no guarantee that your client resolver will try

Re: caching does not seem to be working for internal view

lv.key";     managed-keys-directory "/var/named/dynamic";     pid-file "/run/named/named.pid";     session-keyfile "/run/named/session.key"; }; logging {    channel default_debug {     file "data/named.run";     severity

Re: caching does not seem to be working for internal view

em is that caching does not seem to be working in my > internal view. > > Something is happening such that my internal systems AND the server > itself cannot resolve names and looses it even 5 min later, indicating > not caching. > > I read https://kb.isc.org/docs/aa-0

caching does not seem to be working for internal view

Part of my problem is that caching does not seem to be working in my internal view. Something is happening such that my internal systems AND the server itself cannot resolve names and looses it even 5 min later, indicating not caching. I read https://kb.isc.org/docs/aa-00851 In my include

Re: Rear View RPZ: PTR records from local knowledge

I posted just such a thing a few weeks ago on the dnsrpz list at redbarn. Hrm, seems to be down at the moment. On 12/2/21 11:00 AM, Grant Taylor via bind-users wrote: > On 12/2/21 9:59 AM, Fred Morris wrote: >> Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now >

Re: Rear View RPZ: PTR records from local knowledge

On 12/2/21 9:59 AM, Fred Morris wrote: Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now generally available: turn your local BIND resolver into a network investigation enabler with locally generated PTR records. Would you please elaborate on what Rear View RPZ does

Re: Rear View RPZ: PTR records from local knowledge

On Thursday, 2 December 2021 10:59:17 CST Fred Morris wrote: > And I have one small favor to ask: if you know of a Linux distribution > which ships BIND compiled with Dnstap support, please let me know! > The Linux packages that ISC provide[1] all have dnstap enabled. Also, the FreeBSD BIND port

Rear View RPZ: PTR records from local knowledge

Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now generally available: turn your local BIND resolver into a network investigation enabler with locally generated PTR records. Ok, sure, some of you may be using it as a network investigation tool already. If so, you're probably

Re: Possible to condition a view based on the interface the query comes in on?

Thanks for the suggestions, folks. Using views with RPZs just gets problematic. Sharing vs forwarding: forwarding seems cleaner and although there are two copies of /BIND/ I don't know that that visibility really hurts anything. Plus that potentially allows the "rear view" resolv

Re: Possible to condition a view based on the interface the query comes in on?

On Thu, Nov 18, 2021 at 04:06:01PM -0800, Fred Morris wrote: > Thanks for the encouragement folks, I forged ahead and I've got a > different error now: > > "response-policy zone 'rpz1.m3047.net' for view standard is not a > master or slave zone" >

Re: Possible to condition a view based on the interface the query comes in on?

Thanks for the encouragement folks, I forged ahead and I've got a different error now: "response-policy zone 'rpz1.m3047.net' for view standard is not a master or slave zone" That's the final denoument. There are several intermediate steps, such as moving all zone d

Re: Possible to condition a view based on the interface the query comes in on?

Look in to "match-destination" in a view, i.e. acl abcd.anycast { 10.10.10.1; }; view "abcd" { match-clients { any; }; match-destinations { abcd.anycast; }; ... }; The response-policy definition

Re: Possible to condition a view based on the interface the query comes in on?

Fred Morris wrote: > > Didn't see any reason that it had to be separate instances of BIND, > thought maybe I could do it with views, but I've run into a couple of > roadblocks: > > 1. listen-on isn't supported in views. Right, listen-on is for the server as a whole. To

Re: Possible to condition a view based on the interface the query comes in on?

match-destinations ? ⁣--- >From an Android device, using BlueMail, which forces top-posting.​ On 18 Nov 2021, 20:40, at 20:40, Fred Morris wrote: >I wanted to provide enhanced recursive DNS to (internal) clients on an >"opt in" basis, which is to say that clients could choose whether or >not

Possible to condition a view based on the interface the query comes in on?

I wanted to provide enhanced recursive DNS to (internal) clients on an "opt in" basis, which is to say that clients could choose whether or not to receive enhanced replies based on what they configured as their local caching resolver. The enhanced services come in the form of a Response Policy

Re: Logging statements w.r.t. view in Bind 9.16.18

these queries from the outside world with dnstap or similar, logging packets possibly without even involving named. You certainly would not need a view for that. If your clients are not hitting your public address, you could also tell named not to listen on the public address, so that those

Re: Logging statements w.r.t. view in Bind 9.16.18

Hi Ged, Actually recursion is only enabled for selected set of users , using geo ip feature of bind. As server is on public IP, i have added PUBLIC view to log the users who are scanning/attempting to connect my server. I hope i have explained my use case. Thanks. - Original Message

Re: Logging statements w.r.t. view in Bind 9.16.18

Hi there, On Tue, 24 Aug 2021, Gaurav Kansal wrote: I want a clarity whether we can have individual logging statement per view basis ? Whatever i found on google, i think we can't. My use case for separate logging statement is as follows - In my recursive server, i have 2 views, one for my

Logging statements w.r.t. view in Bind 9.16.18

Hi guys, I want a clarity whether we can have individual logging statement per view basis ? Whatever i found on google, i think we can't. My use case for separate logging statement is as follows - In my recursive server, i have 2 views, one for my internal clients and one for Internet ; i

Re: Expert view of core dump related to catalog zone

Hi Scott, the latest upstream release is 9.16.16 where we fixed deadlock in addzone/modzone/delzone interaction. If you can I would recommend waiting until Wednesday where 9.16.17 will be published. If you still encounter the assertion failure, feel free to fill an issue with us at

Expert view of core dump related to catalog zone

:50:35 ns1 named[3500]: deleting zone p1305.cecc.ihost.com in view public via delzoneJun 13 03:50:35 ns1 named[3500]: client @0x7fff245997a0 127.0.0.1#56939/key rndc-key: view public: signer "rndc-key" approvedJun 13 03:50:35 ns1 named[3500]: client @0x7fff245997a0 127.0.0.1#56939/key rndc

RE: reverse lookup for RFC1918 in view failed

@lists.isc.org Subject: Re: reverse lookup for RFC1918 in view failed MAYER Hans wrote: > I can see why the behaviour of your server is confusing! I'll explain what is happening in detail below, but here's the basic idea: Each view in a configuration is separate from the others: `named` fi

Re: reverse lookup for RFC1918 in view failed

MAYER Hans wrote: > I can see why the behaviour of your server is confusing! I'll explain what is happening in detail below, but here's the basic idea: Each view in a configuration is separate from the others: `named` first chooses which view to use (based on match-clients etc.) then hand

reverse lookup for RFC1918 in view failed

Dear All, I have a strange behaviour which I can’t explain. So I am asking for help. In my named.conf I have two views. One view is called „intern“ ( German internally ) and the other is called „fueralle“ ( German "for everyone" ) In the internal view I have a response-policy with

Re: Does bind9 support adding acl and view through commands, not by updating config file?

On Thu, Apr 15, 2021 at 03:35:38PM +0800, Zhengyu Pan wrote: > I want to implement intelligent DNS through bind9. I need to add a custom > line(IP address ranges) to bind9 using acl and view when add a user. > Because when add a tenant, i need to define a new acl and view. I don't > wa

Re:Re: Re: Does bind9 support adding acl and view through commands, not by updating config file?

>do you mean, the same domains with different content, depending on clients' >IPs? That's common multiple-view setup >(nothing special or intelligent). Yes, I will create a view and acl for every client. Because every client has the unique IP address. >Why? Do you have that

Re: Re: Does bind9 support adding acl and view through commands, not by updating config file?

me domains with different content, depending on clients' IPs? That's common multiple-view setup (nothing special or intelligent). I need to update config file name.conf frequently Because The views and ACLS are added frequently. Why? Do you have that many clients constantly with changing I

Re:Re: Does bind9 support adding acl and view through commands, not by updating config file?

The views and ACLS are added frequently. So i want to know whether have commands or API to add acl and view like the command "rndc addacl" or "rndc addview"? Updating config file frequently may affect other zones in this dns server. At 2021-04-15 15:08:26, "Matus UHLAR - f

Re: Does bind9 support adding acl and view through commands, not by updating config file?

On 15.04.21 15:35, Zhengyu Pan wrote: I want to implement intelligent DNS through bind9. I need to add a custom line(IP address ranges) to bind9 using acl and view when add a user. Because when add a tenant, i need to define a new acl and view. I don't want to update named.conf config file

Does bind9 support adding acl and view through commands, not by updating config file?

Hi, I want to implement intelligent DNS through bind9. I need to add a custom line(IP address ranges) to bind9 using acl and view when add a user. Because when add a tenant, i need to define a new acl and view. I don't want to update named.conf config file frequently. Does bind9 support

Re: "in-view" behavior

> On 31 Oct 2020, at 06:07, John Thurston wrote: > > > I need to define several views. They will be largely identical, probably > differing in only one zone definition. What I had hoped to do was define all > the common zones in an unused-view, and then use &quo

"in-view" behavior

I need to define several views. They will be largely identical, probably differing in only one zone definition. What I had hoped to do was define all the common zones in an unused-view, and then use "in-view" to reference the several zones in the other views. view "in

Re: Dynamic update rejected within a view

: include "keys/mydomains-keys.conf"; include "keys/zone1-keys.conf"; include "keys/zone2-keys.conf"; acl external { 10.222.33.0/18; 10.222.44.0/18; }; acl internal { 10.11.0.0/16; 10.12.0.0/16; }; // // zone1 and zone2 keys used to ensure correct zone transfer from

Re: Dynamic update rejected within a view

nfig file contains: > include "keys/mydomains-keys.conf"; > include "keys/zone1-keys.conf"; > include "keys/zone2-keys.conf"; > acl external { 10.222.33.0/18; 10.222.44.0/18; }; > acl internal { 10.11.0.0/16; 10.12.0.0/16; }; > ////// > // zone

Re: Dynamic update rejected within a view

-- Best regards Sten Carlsen For every problem, there is a solution that is simple, elegant, and wrong. HL Mencken > On 14 Jul 2020, at 16.25, Mark Andrews wrote: > > Include the update keys in the view selection. > > -- > Mark Andrews > >> On 14 Jul 2

Re: Dynamic update rejected within a view

Include the update keys in the view selection. -- Mark Andrews > On 14 Jul 2020, at 23:06, Per Weisteen wrote: > >  Hi > > I've a BIND setup with my ISP with two views, one external and one internal. > At the same time I also need to be able to do a dynamic update from

Dynamic update rejected within a view

include "keys/zone2-keys.conf"; acl external { 10.222.33.0/18; 10.222.44.0/18; }; acl internal { 10.11.0.0/16; 10.12.0.0/16; }; // // zone1 and zone2 keys used to ensure correct zone transfer from slave // view "external-sites" {     match-clients { !key zone

Re: Localhost view is not working for me SOLVED!

camper. Marc.. On 3/30/20 11:42 AM, Bob Harold wrote: > Try without the "match-destinations".  Only use match-clients to > determine the view.  (Or try only match-destinations as a separate test.) > (I have never used match-destinations.) > Turn on query loggi

Re: Localhost view is not working for me

Try without the "match-destinations". Only use match-clients to determine the view. (Or try only match-destinations as a separate test.) (I have never used match-destinations.) Turn on query logging and see what source and destination your queries are using. Make fake queries to un

Localhost view is not working for me

one for the external Internet.  (yes this is also a gateway system with 2 NIC cards.) What I am having troubles with is getting the localhost view to work properly. I have tried a number of ways to get this to work and will show the apropos segment of my named.conf file below.  Commented out sections show thing

Re: What is wrong in the view matching below

On 5 Dec 2019, at 13:49, Harshith Mulky wrote: > view "external" { > >   match-clients { any; }; > >   recursion no; > > zone "nixcraft.com" IN { > >     type master; > >     file "internet.master.nixcraft.com"; > >   }; &g

Re: What is wrong in the view matching below

On Thu, Dec 5, 2019 at 8:49 AM Harshith Mulky wrote: > Thank you. I corrected this > > acl internal { >10.54.8.0/24; >localhost; > }; > > view "external" { > match-clients { any; }; > recursion no; > zone "nixcraft.com" IN { >

Re: What is wrong in the view matching below

Thank you. I corrected this acl internal { 10.54.8.0/24; localhost; }; view "external" { match-clients { any; }; recursion no; zone "nixcraft.com" IN { type master; file "internet.master.nixcraft.com"; }; }; view "internal" { match-clie

Re: What is wrong in the view matching below

There’s a space after com O. -- Ondřej Surý ond...@isc.org > On 5 Dec 2019, at 13:29, Sten Carlsen wrote: > >> >> zone "internal.nixcraft.com " IN { >> type master; >> file "lan.master.nixcraft.com"; >> }; >> }; > > Looks like the file lan.master.nixcraft.com has no data. > >> >>

Re: What is wrong in the view matching below

> > zone "internal.nixcraft.com " IN { > type master; > file "lan.master.nixcraft.com "; > }; > }; Looks like the file lan.master.nixcraft.com has no data. > > Dec 05 17:51:54 sataradnsVM1 named[4038]: zone

What is wrong in the view matching below

I have setup view matching as below on my bind server running version "bind-9.9.5P1-2.2.2.x86_64" my /etc/named.conf is as below options { directory "/var/lib/named"; #dnssec-enable yes; managed-keys-directory "/var/lib/named/dyn/"

Re: Bind with views: forward any public domain in one view

Thanks a lot !!! El jue., 15 ago. 2019 a las 13:09, Matus UHLAR - fantomas (< uh...@fantomas.sk>) escribió: > On 15.08.19 12:18, Roberto Carna wrote: > >Dear, I have a BIND 9 working with two views. > > > >One view forwards two public domains to our resolver. > &

Re: Bind with views: forward any public domain in one view

On 15.08.19 12:18, Roberto Carna wrote: Dear, I have a BIND 9 working with two views. One view forwards two public domains to our resolver. And I want the second view to forward any public domain to our resolver in order to let navigate withouth restrictions. what restricions and where

Bind with views: forward any public domain in one view

Dear, I have a BIND 9 working with two views. One view forwards two public domains to our resolver. And I want the second view to forward any public domain to our resolver in order to let navigate withouth restrictions. I need something like this: zone "ANY" { ty

Re: Forward zone inside a view

Grant Taylor via bind-users wrote: > > I know it's not yet an option and won't yet work for Roberto C., but would > BIND's forthcoming "mirror" zone type change any of this? No. Tony. -- f.anthony.n.finchhttp://dotat.at/ safeguard the balance of nature and the environment

Re: Forward zone inside a view

om > authoritative data, i.e. for a hosting-only BIND instance. Since you want > to forward -- selectively -- you need "recursion yes". Nothing outside of > that part of the namespace will be forwarded, since named considers > everything else to be contained in the root zone. > >

Re: Forward zone inside a view

namespace will be forwarded, since > named considers everything else to be contained in the root zone. > >                                                                       >           - Kevin > > On Mon, Feb 11, 2019 at 9:06 AM Roberto Carna > mailto:robertocarn...@gmail.com>> wrote: > > Matus, I've followed whatyou say: > &

Re: Forward zone inside a view

On 02/12/2019 03:45 PM, Kevin Darcy wrote: "recursion no" is incompatible with *any* type of forwarding or iterative resolution. Should only be used if *everything* you resolve is from authoritative data, i.e. for a hosting-only BIND instance. I know it's not yet an option and won't yet work

Re: Forward zone inside a view

On 02/07/2019 07:02 PM, Paul Kosinski wrote: 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

Re: Forward zone inside a view

o Carna wrote: > Matus, I've followed whatyou say: > > view "internet" { >match-clients { internet_clients; key "pnet"; }; > > recursion yes; > > zone "teamviewer.com" { > type forward; > forward only; > for

Re: Forward zone inside a view

Hello. Am Donnerstag, den 07.02.2019, 10:32 -0300 schrieb 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

Re: Forward zone inside a view

> > >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: > > > &g

Re: Forward zone inside a view

Matus, I've followed whatyou say: view "internet" { match-clients { internet_clients; key "pnet"; }; recursion yes; zone "teamviewer.com" { type forward; forward only; forwarders { 8.8.8.8; }; }; }; but clients c

Re: Forward zone inside a view

he 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

Re: Forward zone inside a view

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 overr

Re: Forward zone inside a view

e 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) l

Re: Forward zone inside a view

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

Re: Forward zone inside a view

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

Re: Forward zone inside a view

; 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

Re: Forward zone inside a view

hem 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 w

Re: Forward zone inside a view

hem 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 {

Re: Forward zone inside a view

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 s

Re: Forward zone inside a view

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;

Re: Forward zone inside a view

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

Re: Forward zone inside a view

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

Re: Forward zone inside a view

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

Re: Forward zone inside a view

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

Forward zone inside a view

part of named.conf.local: acl internet { 10.0.0.0/24; }; view "INTERNET" { match-clients { internet; key "custom";}; zone "linux. <http://teamviewer.com>org" { type forward; forward only; forwarders { 172.18.1.1;

Re: Re: Re: checkhints: view “internal”: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints

On Sun, Sep 10, 2017 at 8:15 PM, Mark Andrews wrote: > > In message , Timothe Litt > writes: >> The most sensible thing to do is ignore the message, and keep named >> reasonably up-to-date. > > Well something in the resolution path is

Re: Re: Re: checkhints: view “internal”: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints

In message , Timothe Litt writes: > The most sensible thing to do is ignore the message, and keep named > reasonably up-to-date. Well something in the resolution path is changing the answer to return the old address which is why I suggested that

  1   2   3   4   >