Re: Queries regarding forwarders
On 8/9/18, Grant Taylor via bind-users wrote: > On 08/08/2018 10:02 PM, Blason R wrote: >> Due to the architecture since I have my internal DNS RPZ built I wanted >> my other internal DNS servers should send traffic to RPZ server and >> then RPZ would resolve on behalf of client. > > Speaking of PRZ and forwarding… > > Does anyone know off hand if BIND, with RPZ configured to filter answers > that resolve to private IPs, can actually respond with private answers > from a local authoritative zone? yes, it works just fine > My long standing fear is that RPZ would filter replies from local > authoritative zones. it does, so you have to flag your local zones as rpz-passthru. eg: *.home.net CNAME rpz-passthru. localhost CNAME rpz-passthru. 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 8.0.0.0.10.rpz-ip CNAME . ; 10.0.0.0/8 12.0.0.16.172.rpz-ipCNAME . ; 172.16.0.0/12 16.0.0.168.192.rpz-ip CNAME . ; 192.168.0.0/16 Regards, Lee ___ 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
Need help on RPZ sever, bit urgent
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though wall-gardened
those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no;# conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};
___
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: Need help on RPZ sever, bit urgent
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
0/1/0 (102)
On Thu, Aug 9, 2018 at 6:59 PM Blason R wrote:
> Hi Bind-Users,
>
> I would really appreciate if someone can help me understanding my issue
> with BIND RPZ server?
>
> I have one windows server say 192.168.1.42 and then RPZ server with
> 192.168.1.179. I noticed that there are certain domains which are not
> getting resolved from end users.
>
> Ideally since those end user has 192.168.1.42 DNS Server set and has
> forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
>
> But certain domains from my response-policy are even though wall-gardened
> those are being catered as NXdomain.
>
> Anything I am missing pertaining to RPZ?
>
> Or if I am querying all those domains directly to RPZ server then I am
> getting proper answer. This issue is noticed when I have forwarder server
> is between
>
> options {
> version "test";
> allow-query { localhost;subnets; };
> directory "/var/cache/bind";
> recursion yes;
> querylog yes;
> forwarders {
> 1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
> };
> // dnssec-validation auto;
> request-ixfr yes;
> auth-nxdomain no;# conform to RFC1035
> // listen-on-v6 { any; };
> listen-on port 53 { any; };
> listen-on port 15455 {any;};
> response-policy { zone "whitelist.allow" policy passthru;
> zone "wg.block";
> zone "bad.trap";
> zone "block.tld";
> zone "ransomwareips.block"; };
> };
>
>
>
>
___
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: Need help on RPZ sever, bit urgent
On 2018-08-09 14:00:55 +, Blason R said: For example this one. 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A? 0351dag.com. (29) 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain 0/1/0 (102) $ dig 0351dag.com ; <<>> DiG 9.8.3-P1 <<>> 0351dag.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44466 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;0351dag.com. IN A ;; AUTHORITY SECTION: com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1533828275 1800 900 604800 86400 Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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: Need help on RPZ sever, bit urgent
Is it a big?? I mean certain domains from my rpz feeds are properly getting resolved while few are giving nxdomain though they appear in zone. On Thu, Aug 9, 2018, 8:57 PM Sam Wilson wrote: > On 2018-08-09 14:00:55 +, Blason R said: > > > For example this one. > > > > 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A? > > 0351dag.com. (29) > > 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 > > NXDomain 0/1/0 (102) > > $ dig 0351dag.com > > ; <<>> DiG 9.8.3-P1 <<>> 0351dag.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44466 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;0351dag.com. IN A > > ;; AUTHORITY SECTION: > com.900 IN SOA a.gtld-servers.net. > nstld.verisign-grs.com. > 1533828275 1800 900 604800 86400 > > Sam > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > ___ > 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: Need help on RPZ sever, bit urgent
On Thu, Aug 9, 2018 at 9:31 AM Blason R wrote:
> For example this one.
>
> 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
> 0351dag.com. (29)
> 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
> 0/1/0 (102)
>
With RPZ, the name is looked up normally first, and only if there is an
answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
and does not use RPZ.
If that is not what you want, then you probably want to set the option:
qname-wait-recurse no;
--
Bob Harold
>
> On Thu, Aug 9, 2018 at 6:59 PM Blason R wrote:
>
>> Hi Bind-Users,
>>
>> I would really appreciate if someone can help me understanding my issue
>> with BIND RPZ server?
>>
>> I have one windows server say 192.168.1.42 and then RPZ server with
>> 192.168.1.179. I noticed that there are certain domains which are not
>> getting resolved from end users.
>>
>> Ideally since those end user has 192.168.1.42 DNS Server set and has
>> forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
>>
>> But certain domains from my response-policy are even though wall-gardened
>> those are being catered as NXdomain.
>>
>> Anything I am missing pertaining to RPZ?
>>
>> Or if I am querying all those domains directly to RPZ server then I am
>> getting proper answer. This issue is noticed when I have forwarder server
>> is between
>>
>> options {
>> version "test";
>> allow-query { localhost;subnets; };
>> directory "/var/cache/bind";
>> recursion yes;
>> querylog yes;
>> forwarders {
>> 1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
>> };
>> // dnssec-validation auto;
>> request-ixfr yes;
>> auth-nxdomain no;# conform to RFC1035
>> // listen-on-v6 { any; };
>> listen-on port 53 { any; };
>> listen-on port 15455 {any;};
>> response-policy { zone "whitelist.allow" policy passthru;
>> zone "wg.block";
>> zone "bad.trap";
>> zone "block.tld";
>> zone "ransomwareips.block"; };
>> };
>>
>>
___
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: Queries regarding forwarders
On 08/09/2018 01:01 AM, Lee wrote: yes, it works just fine Good. it does, so you have to flag your local zones as rpz-passthru. eg: *.home.net CNAME rpz-passthru. localhost CNAME rpz-passthru. 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 8.0.0.0.10.rpz-ip CNAME . ; 10.0.0.0/8 12.0.0.16.172.rpz-ipCNAME . ; 172.16.0.0/12 16.0.0.168.192.rpz-ip CNAME . ; 192.168.0.0/16 That makes sense. RPZ would filter the private IPs by default, but zones with said records can be told to not be blocked by RPZ. Thank you for the clarification Lee. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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: Promote slave DNS server
On 08/06/2018 07:40 AM, Leroy Tennison wrote: If there is already an ISC document I didn't find it, please provide the URL. I'm not aware of any such best practices type document. I too would be interested in reading it is it exists. I just added a slave of a master for disaster recovery and now need to know how to promote it should the master be offline too long. The first thing I would do is make sure the expiry timer is sufficiently high. I'd likely go with something between multiple days and a month. What I have found so far is: 1. For the zone definitions in /etc/named.conf (or equivalent): (a) Change the “type” statements from ”slave” to “master” and remove the “masters” statement. (b) Add “allow-update” and “allow-transfer” statements as appropriate. (c) Possibly add “also-notify” statements as appropriate. 2. Add key definitions if needed I took a slightly different approach to this the last time I had this problem. I created an intermediary file that was a list of the zones that I needed to be able to quickly switch between master and slave. Then I used that file as data for a script (really different m4 macros) to create the proper configurations (at the same time) for both master and slave operating modes. Each configuration was (effectively) stored in their own file; /etc/named/zones.master.conf and /etc/named/zones.slave.conf. Then I would dynamically update a sym-link to point to the operating mode of the server. Master: /etc/named/zones.conf -> /etc/named/zones.master.conf Slave: /etc/named/zones.conf -> /etc/named/zones.slave.conf My main named.conf file would then simply include the /etc/named/zones.conf file. 3. If “masterfile-format text” wasn't used in named.conf.local convert the zone files to text using named-compilezone including the -j parameter. I prefer to keep my zones in text format. But I thought that the same binary file format could be used for master and slave zones. - I could be wrong about this. 4. If the server's name is different than the former master then the SOA record for each (to be ) master zone must be updated. IMHO the MNAME does not need to be changed. (More details below.) Since rndc freeze/thaw doesn't work on slave zones the server probably needs to be shut down. You are going to need to reconfigure all the zones that you want to change role. IMHO the easiest way to do that is to shut down BIND, change the config file (read: change where the /etc/named/zones.conf file points to) and restart BIND. It may be possible to dynamically reconfigure BIND but I've never gone there as I found the method I'm describing to work satisfactorily well. 5. Change the MNAME to the new server name I decided to go a different route with this. I created a (bogus) record / hostname that was used specifically for the MNAME parameter of the SOA record. I.e. soa.example.com I then created (and properly delegated) the soa.example.com zone in the parent zone, example.com. Then I would have different local versions of the soa.example.com zone on each DNS server. That way, the parent zone would say that the MNAME was soa.example.com, which each local server would resolve from it's local specific version of the zone to itself. Anything I've missed? Thanks for your help. I also have a question about DNS and keepalived but I'll make that another post. I don't know that it applies to your example, but you may need to also allow dynamic updates on the new master. This should be doable, but may be an added complication that you need to overcome. The only other problem that I've seen people run into is what I call the "return to home problem". How do you gracefully make the transition back the other way? Especially if you have any updates that originated on the slave->master that need to be propagated back to the original master. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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: DNS and keepalived
On 08/06/2018 08:14 AM, Leroy Tennison wrote: As previously posted, I just added a slave of a master for disaster recovery and now need to know how to promote it should the master be offline too long. Please see the reply that I just sent for details about how I handled this problem in the past. An additional complicating factor is that the master and slave exist on a failover pair managed by keepalived. Okay. My opinion is that keepalived should be used between two identical servers. Thus between two masters or two slaves. I would not want to try to cross the role between two servers managed by keepalived. My web search has found a few references to this situation but they have either used slave servers or were veery light on the details of bind configuration. I've not dealt with keepalived in a long time, so I can't say for sure. But I believe that most of the configurations I've seen work between two slaves that share a common (optionally hidden) master server. This allows both servers to be identical and a backup for each other and avoids the need for keepalived to significantly reconfigure BIND's operation. I'm converting and existing situation where there was a single server for almost totally non-DHCP clients (servers). Okay. I would prefer to not roll out a different DNS resolver configuration to all those non-DHCP clients I do not see any reason to change the client configuration. Ideally the DNS server's VIP / functional IP will stay the same. Thus no need to reconfigure clients. The change will be in the servers that are capable of hosting said VIP. Aside from potential SOA / MNAME issues (see my other reply) I don't see any issues in adding additional servers; 1 (optionally hidden) master and an additional slave to participate in the keepalived configuration with the existing server. the environment size is sort of "in between" (not small or large). The environment size is immaterial to the BIND configuration. (It may be applicable to you for motivation to doing things.) The issues I see are in the SOA, with keepalived I could leave the SOA the same on both since the IP address for the DNS server (and other functions) moves. I don't think the SOA / MNAME actually need to be the same. They just need to be accessible. (See my other reply.) The question is "Am I missing something?" which will come back to haunt me later? It's hard to say. I don't see anything obvious jumping out at me. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Is it possible to...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Is it possible to... 1) use text only zone files, and 2) keep serials identical between those zone files and what is published in DNS, and 3) automatically handle signatures when adding new RRs, and 4) not have any journal files. Is all of that possible with a(ny)? recent version of Bind9? tia, - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAltsmgYACgkQJxVetMRa JwUWaw/9FU02HPacQQtH6AVhp3IFDlbvCcMgodcxzeYvIrFLiJU0pGUlkg31XqBd T4UZkZViaydmDBpZY2igPvBInF8ZzwrgWdLlpJIFNurdLe67nvptF0qcll+2ExHy 1O4tCK0wG76tOFeiDuB+NQN65227zvTLExGuRTDtYkDo/okqrhfWvmth1soBnuYm dnOXdxfINT8NQpDcpCTXm4pvZzyLbOveRUz6SdWRImLqeQloGhkVBCuLPgJED96J trwvs9HsRnC3YWzGIgbiUDjwovwQU8JWm/73aqcWSX8HDBh/8NBqIozXt4stxDtw nrJuuue3mZx6jD1uGOss84Q5zWNuT0swUebVlXlA4HsfqymBrkr9w6S2lI87m020 X5Ve0fUX7PD+7d0GC5tav6+Jdxccb4m5RMuxZGkSsUssnufyddfSHI9KWf5o7kg0 lPW4Jxk5Wa3NPJI4cKDiuHSoXw60ElkLq5yBNepB1KwlJm2DEsYP0NUmKBrPAdQ4 H7JFD8JFtE6EDEBVOIAHm/LNX5e82FOTsJ7wSoOTwVswtad8q8YM3W0e+LFo8LqC LouN+bNCvAszLY0qeP2iVSCH4GpumyFMbOuXV8EdcRySEMDLvRaSSKF4OviDgvs+ q0zVq1s5CMiXxXZj2RPx3iNiuEGCYq/p0+zV4nyjCuYa8VMZ5qM= =0y5L -END PGP SIGNATURE- ___ 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: Is it possible to...
> On 10 Aug 2018, at 5:46 am, Jim Popovitch via bind-users > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Is it possible to... > > 1) use text only zone files, and > > 2) keep serials identical between those zone files and what is > published in DNS, and That’s not even possible with manually edited files. There will always with every system be times when what is on disk does not match what is being published. The world doesn’t allow for perfect synchronisation. There will always be “edit, read” or “update, write”. > 3) automatically handle signatures when adding new RRs, and > > 4) not have any journal files. Named is not designed to update zones without running the updates through a journal. Flat files are really bad performance wise so we use a structured file (the journal) to record changes then write out the master file later when things are less time critical. Even setting the delay between processing a update and starting to write the new master file to zero seconds will not achieve what you want. UPDATE requires name servers to behave like a database. Databases can’t behave like you are requesting. You don’t go reading SQL database stores directly. > Is all of that possible with a(ny)? recent version of Bind9? No. > tia, > > - -Jim P. > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAltsmgYACgkQJxVetMRa > JwUWaw/9FU02HPacQQtH6AVhp3IFDlbvCcMgodcxzeYvIrFLiJU0pGUlkg31XqBd > T4UZkZViaydmDBpZY2igPvBInF8ZzwrgWdLlpJIFNurdLe67nvptF0qcll+2ExHy > 1O4tCK0wG76tOFeiDuB+NQN65227zvTLExGuRTDtYkDo/okqrhfWvmth1soBnuYm > dnOXdxfINT8NQpDcpCTXm4pvZzyLbOveRUz6SdWRImLqeQloGhkVBCuLPgJED96J > trwvs9HsRnC3YWzGIgbiUDjwovwQU8JWm/73aqcWSX8HDBh/8NBqIozXt4stxDtw > nrJuuue3mZx6jD1uGOss84Q5zWNuT0swUebVlXlA4HsfqymBrkr9w6S2lI87m020 > X5Ve0fUX7PD+7d0GC5tav6+Jdxccb4m5RMuxZGkSsUssnufyddfSHI9KWf5o7kg0 > lPW4Jxk5Wa3NPJI4cKDiuHSoXw60ElkLq5yBNepB1KwlJm2DEsYP0NUmKBrPAdQ4 > H7JFD8JFtE6EDEBVOIAHm/LNX5e82FOTsJ7wSoOTwVswtad8q8YM3W0e+LFo8LqC > LouN+bNCvAszLY0qeP2iVSCH4GpumyFMbOuXV8EdcRySEMDLvRaSSKF4OviDgvs+ > q0zVq1s5CMiXxXZj2RPx3iNiuEGCYq/p0+zV4nyjCuYa8VMZ5qM= > =0y5L > -END PGP SIGNATURE- > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Queries regarding forwarders
Well this is valid when users are directly talking to RPZ servers. What if there is one more resolver in between like Active Directory which itself acts as a DNS server? In that case I believe you don't need to do that, right? On Fri, Aug 10, 2018 at 12:33 AM Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > On 08/09/2018 01:01 AM, Lee wrote: > > yes, it works just fine > > Good. > > > it does, so you have to flag your local zones as rpz-passthru. eg: > > *.home.net CNAME rpz-passthru. > > localhost CNAME rpz-passthru. > > 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 > > 8.0.0.0.10.rpz-ip CNAME . ; 10.0.0.0/8 > > 12.0.0.16.172.rpz-ipCNAME . ; 172.16.0.0/12 > > 16.0.0.168.192.rpz-ip CNAME . ; 192.168.0.0/16 > > That makes sense. RPZ would filter the private IPs by default, but > zones with said records can be told to not be blocked by RPZ. > > Thank you for the clarification Lee. > > > > -- > Grant. . . . > unix || die > > ___ > 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: Need help on RPZ sever, bit urgent
Well mine is bit different. I have RPZ and almost 40+ RPZ entries wall
gardened. And in my scenario users are talking to windows based AD/DNS
server and then that server has forwarder set to RPZ.
1. First issue; I observed certain entries from BIND/RPZ zone are being
resolved by windows server directly to their original IPs and not the
wall-gardened IP. Where I believe once the forwarder is set all those
queries should have been routed to RPZ server? [If anyone here having
Windows DNS expertise, pls help]
2. And another, certain RPZ queries if queried through AD/DNS server are
not at all getting resolved. When I captured packets on BIND/RPZ server I
see that those domains are getting NXdomain by RPZ and not sure why.
Thanks and Regards,
Lionel F
On Thu, Aug 9, 2018 at 11:08 PM Bob Harold wrote:
>
> On Thu, Aug 9, 2018 at 9:31 AM Blason R wrote:
>
>> For example this one.
>>
>> 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
>> 0351dag.com. (29)
>> 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
>> 0/1/0 (102)
>>
>
> With RPZ, the name is looked up normally first, and only if there is an
> answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
> and does not use RPZ.
> If that is not what you want, then you probably want to set the option:
> qname-wait-recurse no;
>
> --
> Bob Harold
>
>
>
>
>>
>> On Thu, Aug 9, 2018 at 6:59 PM Blason R wrote:
>>
>>> Hi Bind-Users,
>>>
>>> I would really appreciate if someone can help me understanding my issue
>>> with BIND RPZ server?
>>>
>>> I have one windows server say 192.168.1.42 and then RPZ server with
>>> 192.168.1.179. I noticed that there are certain domains which are not
>>> getting resolved from end users.
>>>
>>> Ideally since those end user has 192.168.1.42 DNS Server set and has
>>> forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
>>>
>>> But certain domains from my response-policy are even though
>>> wall-gardened those are being catered as NXdomain.
>>>
>>> Anything I am missing pertaining to RPZ?
>>>
>>> Or if I am querying all those domains directly to RPZ server then I am
>>> getting proper answer. This issue is noticed when I have forwarder server
>>> is between
>>>
>>> options {
>>> version "test";
>>> allow-query { localhost;subnets; };
>>> directory "/var/cache/bind";
>>> recursion yes;
>>> querylog yes;
>>> forwarders {
>>> 1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
>>> };
>>> // dnssec-validation auto;
>>> request-ixfr yes;
>>> auth-nxdomain no;# conform to RFC1035
>>> // listen-on-v6 { any; };
>>> listen-on port 53 { any; };
>>> listen-on port 15455 {any;};
>>> response-policy { zone "whitelist.allow" policy passthru;
>>> zone "wg.block";
>>> zone "bad.trap";
>>> zone "block.tld";
>>> zone "ransomwareips.block"; };
>>> };
>>>
>>>
___
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: Need help on RPZ sever, bit urgent
Hi there,
Where it should appear? ARM says it should appear inl Global-section of
response-policy which I tried but getting error.
response-policy {zone "whitelist.allow" policy passthru;
zone "malware.trap";
zone "ransomwareips.block";
};
qname-wait-recurse no;
break-dnssec no;
On Fri, Aug 10, 2018 at 8:09 AM Blason R wrote:
> Well mine is bit different. I have RPZ and almost 40+ RPZ entries wall
> gardened. And in my scenario users are talking to windows based AD/DNS
> server and then that server has forwarder set to RPZ.
>
>
>1. First issue; I observed certain entries from BIND/RPZ zone are
>being resolved by windows server directly to their original IPs and not the
>wall-gardened IP. Where I believe once the forwarder is set all those
>queries should have been routed to RPZ server? [If anyone here having
>Windows DNS expertise, pls help]
>2. And another, certain RPZ queries if queried through AD/DNS server
>are not at all getting resolved. When I captured packets on BIND/RPZ server
>I see that those domains are getting NXdomain by RPZ and not sure why.
>
> Thanks and Regards,
> Lionel F
>
> On Thu, Aug 9, 2018 at 11:08 PM Bob Harold wrote:
>
>>
>> On Thu, Aug 9, 2018 at 9:31 AM Blason R wrote:
>>
>>> For example this one.
>>>
>>> 18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
>>> 0351dag.com. (29)
>>> 18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 NXDomain
>>> 0/1/0 (102)
>>>
>>
>> With RPZ, the name is looked up normally first, and only if there is an
>> answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
>> and does not use RPZ.
>> If that is not what you want, then you probably want to set the option:
>> qname-wait-recurse no;
>>
>> --
>> Bob Harold
>>
>>
>>
>>
>>>
>>> On Thu, Aug 9, 2018 at 6:59 PM Blason R wrote:
>>>
Hi Bind-Users,
I would really appreciate if someone can help me understanding my issue
with BIND RPZ server?
I have one windows server say 192.168.1.42 and then RPZ server with
192.168.1.179. I noticed that there are certain domains which are not
getting resolved from end users.
Ideally since those end user has 192.168.1.42 DNS Server set and has
forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
But certain domains from my response-policy are even though
wall-gardened those are being catered as NXdomain.
Anything I am missing pertaining to RPZ?
Or if I am querying all those domains directly to RPZ server then I am
getting proper answer. This issue is noticed when I have forwarder server
is between
options {
version "test";
allow-query { localhost;subnets; };
directory "/var/cache/bind";
recursion yes;
querylog yes;
forwarders {
1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
};
// dnssec-validation auto;
request-ixfr yes;
auth-nxdomain no;# conform to RFC1035
// listen-on-v6 { any; };
listen-on port 53 { any; };
listen-on port 15455 {any;};
response-policy { zone "whitelist.allow" policy passthru;
zone "wg.block";
zone "bad.trap";
zone "block.tld";
zone "ransomwareips.block"; };
};
___
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: Need help on RPZ sever, bit urgent
This is the error I am getting
/etc/bind/named.conf.options:24: expected 'zone' near 'qname-wait-recurse'
On Fri, Aug 10, 2018 at 9:10 AM Blason R wrote:
> Hi there,
>
> Where it should appear? ARM says it should appear inl Global-section of
> response-policy which I tried but getting error.
>
> response-policy {zone "whitelist.allow" policy passthru;
> zone "malware.trap";
> zone "ransomwareips.block";
> };
> qname-wait-recurse no;
> break-dnssec no;
>
>
> On Fri, Aug 10, 2018 at 8:09 AM Blason R wrote:
>
>> Well mine is bit different. I have RPZ and almost 40+ RPZ entries
>> wall gardened. And in my scenario users are talking to windows based AD/DNS
>> server and then that server has forwarder set to RPZ.
>>
>>
>>1. First issue; I observed certain entries from BIND/RPZ zone are
>>being resolved by windows server directly to their original IPs and not
>> the
>>wall-gardened IP. Where I believe once the forwarder is set all those
>>queries should have been routed to RPZ server? [If anyone here having
>>Windows DNS expertise, pls help]
>>2. And another, certain RPZ queries if queried through AD/DNS server
>>are not at all getting resolved. When I captured packets on BIND/RPZ
>> server
>>I see that those domains are getting NXdomain by RPZ and not sure why.
>>
>> Thanks and Regards,
>> Lionel F
>>
>> On Thu, Aug 9, 2018 at 11:08 PM Bob Harold wrote:
>>
>>>
>>> On Thu, Aug 9, 2018 at 9:31 AM Blason R wrote:
>>>
For example this one.
18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A?
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074
NXDomain 0/1/0 (102)
>>>
>>> With RPZ, the name is looked up normally first, and only if there is an
>>> answer, is RPZ invoked. If it gets NXDOMAIN or some error, it returns that
>>> and does not use RPZ.
>>> If that is not what you want, then you probably want to set the option:
>>> qname-wait-recurse no;
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>>
>>>
On Thu, Aug 9, 2018 at 6:59 PM Blason R wrote:
> Hi Bind-Users,
>
> I would really appreciate if someone can help me understanding my
> issue with BIND RPZ server?
>
> I have one windows server say 192.168.1.42 and then RPZ server with
> 192.168.1.179. I noticed that there are certain domains which are not
> getting resolved from end users.
>
> Ideally since those end user has 192.168.1.42 DNS Server set and has
> forwarder set to 192.168.1.179 should forward all queries to 1.179, right?
>
> But certain domains from my response-policy are even though
> wall-gardened those are being catered as NXdomain.
>
> Anything I am missing pertaining to RPZ?
>
> Or if I am querying all those domains directly to RPZ server then I am
> getting proper answer. This issue is noticed when I have forwarder server
> is between
>
> options {
> version "test";
> allow-query { localhost;subnets; };
> directory "/var/cache/bind";
> recursion yes;
> querylog yes;
> forwarders {
> 1.1.1.1;9.9.9.9;208.67.222.222;8.8.8.8;
> };
> // dnssec-validation auto;
> request-ixfr yes;
> auth-nxdomain no;# conform to RFC1035
> // listen-on-v6 { any; };
> listen-on port 53 { any; };
> listen-on port 15455 {any;};
> response-policy { zone "whitelist.allow" policy passthru;
> zone "wg.block";
> zone "bad.trap";
> zone "block.tld";
> zone "ransomwareips.block"; };
> };
>
>
___
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: [BIND] Re: Is it possible to...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2018-08-10 at 09:47 +1000, Mark Andrews wrote: > > On 10 Aug 2018, at 5:46 am, Jim Popovitch via bind-users > s...@lists.isc.org> wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Is it possible to... > > > > 1) use text only zone files, and > > > > 2) keep serials identical between those zone files and what is > > published in DNS, and > > That’s not even possible with manually edited files. There will > always with every system be times when what is on disk does not > match what is being published. The world doesn’t allow for perfect > synchronisation. There will always be “edit, read” or “update, > write”. > > > 3) automatically handle signatures when adding new RRs, and > > > > 4) not have any journal files. > > Named is not designed to update zones without running the updates > through a journal. Flat files are really bad performance wise so > we use a structured file (the journal) to record changes then write > out the master file later when things are less time critical. > > Even setting the delay between processing a update and starting to > write the new master file to zero seconds will not achieve what you > want. > > UPDATE requires name servers to behave like a database. Databases > can’t behave like you are requesting. You don’t go reading SQL > database > stores directly. > > > Is all of that possible with a(ny)? recent version of Bind9? > > No. > Ok, and thank you for details. - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEPxwe8uYBnqxkbORSJxVetMRaJwUFAlttDdUACgkQJxVetMRa JwUB/RAAjtJloOz51BI+MhbWcL763RHW9+ZXjb4XW3elHUTNCjharS+HAB+eWfEn wV2DphvcKRZTvcOgrPWP6TUDMK+4t3wNKXC9q/AEhZbc4yp+U7jrLfozuxS2Tgrq 6FDpdLAoOBySQOzQYmo8Owc+yIpXYtqVp02NTx2eZvsQX5eLCW3IAIZW+fv3EQZ0 wnbhPzjdJE/qKFETrAbLGfYUDYfmPtsDA6yNaL+Oymwdq7BhmL2SeeTIGy0wLfbD giripm6qSkRunpXBUNpLbiGijsRFYaxbgXXh/1JEaTc55Jmju5PBEYAwE1a9jHjG 33DxcEyaiM3WAzdkSyXgZ2T2R7wCmLGrg2tPXw9KSfuqIevRMa67yNC8oTyv9JZB odFUVpE01xDVTnKQncezy9yL9wG9fdQMmbQOxexvzgTso5TFHvML/3CfpETlzA2t wkt9Ku6GZDvs0kOqavPgiOshB2aEMbnp+eVuR+CdfwlSbPxvrwINM/FFK+WoyZ3J kJWVsvpxaAyG0EgHw35P71tzgw3D+tc7ADnNNnpeErbxIOubBGgqBwzyoMbaBaX1 GfKu+0oVHuSEmt+E+r1WcMFhvNB/bLYYe4QJ8GtAXYQfJG9puo68z64aTZJK1Am0 V3cRZkXOakwYoHlIH+EDcBPtJ5TCZiE4fAG3IazW+ZNMV24Ek5g= =q9os -END PGP SIGNATURE- ___ 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
