Puncte:0

Bind9 Response Policy Zone (RPZ), does not work on clients

drapel bm

On my single DNS server, bind9 (version 9.11.5-P4-5.1), I have configured a Response Policy Zone (RPZ) to block certain domains. The IP of the DNS server is 192.168.1.5

Now I am going to put the relevant parts to the configuration of the different files and commands:

On the server:

In /etc/bind/named.conf.options

acl trusted {
    localhost; # this server
    192.168.1.0/24; #my net
}

Also

// Only allows trusted client to use the service
allow-query { trusted; };

forwarders {
    The IP of the NS1 of IPS#1;
    The IP of the NS2 of IPS#1;
    The IP of the NS1 of IPS#2;
    The IP of the NS2 of IPS#2;
    8.8.8.8;
    8.8.4.4;
    1.1.1.1;
};

And also

    // For Ad-Blocking/Blacklisting/Whitelisting
    response-policy {
        zone "rpz.blacklist";
        zone "office.local" policy passthru;
        zone "1.168.192.in-addr.arpa" policy passthru;
    };

In /etc/bind/named.conf.local

  zone "rpz.blacklist" {
      typemaster;
      file "/etc/bind/zones/rpz.blacklist.db";
      allow-query { trusted; };
      allow-transfer { localhost; };
  };

And finally in /etc/bind/zones/rpz.blacklist.db

  ; BIND reverse data file for empty rfc1918 zone
  ;
  ; DO NOT EDIT THIS FILE - it is used for multiple zones.
  ; Instead, copy it, edit named.conf, and use that copy.
  ;
  $TTL 86400
  @ IN SOA localhost. root.localhost. (
  1     ; Serial
  604800; Refresh
  86400; Retry
  2419200; expire
  86400); Negative Cache TTL
  ;

  @ IN NS localhost.

  ;.:#====================#:.
  ; Blacklist Domains
  ;.:#====================#:.

  ads2000.hw.net IN A 127.0.0.1

There are more domains but I leave one only for the example.

The commands [named-checkconf] and [named-checkconf "rpz.blacklist" /etc/bind/zones/rpz.blacklist.db] return OK and the service starts successfully

Now if I ping ads2000.hw.net from the same server it works fine

  ping -c 5 ads2000.hw.net
  PING ads2000.hw.net (127.0.0.1) 56(84) bytes of data.
  64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.037 ms
  64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.037 ms
  64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.037 ms
  64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.201 ms
  64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.034 ms

  --- ads2000.hw.net ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 105ms
  rtt min/avg/max/mdev = 0.034/0.069/0.201/0.066ms

Now if I do it from a linux client, it does not :

  ping -c 5 ads2000.hw.net
  PING ads2000.hw.net (65.8.181.28) 56(84) bytes of data.
    64 bytes from server-65-8-181-28.mia3.r.cloudfront.net (65.8.181.28): icmp_seq=1 ttl=246 time=131 ms
    64 bytes from server-65-8-181-28.mia3.r.cloudfront.net (65.8.181.28): icmp_seq=2 ttl=246 time=131 ms
    64 bytes from server-65-8-181-28.mia3.r.cloudfront.net (65.8.181.28): icmp_seq=3 ttl=246 time=131 ms
    64 bytes from server-65-8-181-28.mia3.r.cloudfront.net (65.8.181.28): icmp_seq=4 ttl=246 time=131 ms
    64 bytes from server-65-8-181-28.mia3.r.cloudfront.net (65.8.181.28): icmp_seq=5 ttl=246 time=131 ms

This is my dns settings on that computer

  cat /etc/resolv.conf
  ## Generated by NetworkManager
  domain office.local
  search office.local
  nameserver 192.168.1.5
  nameserver 1.1.1.1
  nameserver 8.8.8.8

Now if I do it from a windows client, it does not work either:

  ping ads2000.hw.net
  Ping ads2000.hw.net [65.8.181.28] with 32 bytes of data:
  Response from 65.8.181.28: bytes=32 time=131ms TTL=246
  Response from 65.8.181.28: bytes=32 time=131ms TTL=246
  Response from 65.8.181.28: bytes=32 time=131ms TTL=246
  Response from 65.8.181.28: bytes=32 time=131ms TTL=246
  Ping statistics for 65.8.181.28:
      Packets: sent = 4, received = 4, lost = 0
(0% lost),
  Approximate round trip times in milliseconds:
Minimum = 131ms, Maximum = 131ms, Average = 131ms

This is my dns settings on that computer

   Ethernet Ethernet Adapter:
      Specific DNS suffix for the connection. . : office.local
      DNS servers. . . . . . . . . . . . . . : 192.168.1.5
                                          1.1.1.1
                                          8.8.8.8

If I remove the servers "1.1.1.1" and "8.8.8.8" from the clients, it works but from them I lose Internet

What am I doing wrong?

I thank you in advance for your help.

PS: Sorry for my bad English

PS 2:

They told me not to use ping and to use dig.

I have discovered something new from a comment that was made to me, and it also fails me on the same server when using dig, instead of putting @localhost, I put @192.168.1.5 (which is the ip of my server)

With the IP

dig @192.168.1.5 ads2000.hw.net

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @192.168.1.5 ads2000.hw.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

With localhost

dig @localhost ads2000.hw.net

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @localhost ads2000.hw.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21521
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2ce3f4f1d313ffad11763e9a623e3a8023aa719aef8f2ec4 (good)
;; QUESTION SECTION:
;ads2000.hw.net.                        IN      A

;; ANSWER SECTION:
ads2000.hw.net.         5       IN      A       127.0.0.1

;; Query time: 433 msec
;; SERVER: :127.0.0.1#53(127.0.0.1)
;; WHEN: vie mar 25 18:56:16 -03 2022
;; MSG SIZE  rcvd: 87
Patrick Mevzek avatar
drapel cn
„;; conexiune a expirat; niciun server nu a putut fi atins” înseamnă că serverul dvs. la 192.168.1.5 nu poate fi accesat deloc de unde încercați (și, prin urmare, clienții vor folosi următorul solutor posibil), așa că ar trebui să remediați asta. Verificați regulile firewall și rutarea după ce verificați pe serverul însuși că acesta rulează într-adevăr la ascultarea adresei IP date. DNS are nevoie de portul 53 atât pentru UDP, cât și pentru TCP.
Jordán E Moisés avatar
drapel bm
Porturile sunt deschise. Nu am încă configurat firewall netstat -a -n |grep 53 tcp 0 0 192.168.1.5:53 0.0.0.0:* ASCULTĂ tcp 0 0 127.0.0.1:53 0.0.0.0:* ASCULTĂ tcp 0 0 127.0.0.53:53 0.0.0.0:* ASCULTĂ
Jordán E Moisés avatar
drapel bm
netstat -a -n |grep 53 |grep udp udp 0 0 192.168.1.5:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp6 0 0 ::1:53 :::* udp6 0 0 :::5353 :::* Poate apparmor sau un selinux permisiv să blocheze conexiunile la portul 53 192.168.1.5?
Jordán E Moisés avatar
drapel bm
Mulțumesc celor care m-au ajutat. Am găsit soluția, începând cu un Debian proaspăt instalat și configurând pas cu pas. Problema nu a fost copierea 100% din configurația serverului dns și am omis problema. În „named.conf.options” aveam următoarele acl bogusnets { ...192.168.0.0/16; ... }; // Interziceți rețelele false blackhole { rețele false; }; Cu care mi-a blocat reteaua de tip C. Atat de la clienti cat si de la interfata serverului propriu-zis cu IP-ul retelei. Am scos acea plasă și masca din acel acl și a început să funcționeze. Salutari.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.