Điểm:0

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

lá cờ 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
lá cờ cn
";; hết thời gian kết nối; không thể truy cập máy chủ nào" có nghĩa là không thể truy cập máy chủ của bạn tại 192.168.1.5 từ nơi bạn thử (và do đó, máy khách sẽ sử dụng trình phân giải khả thi tiếp theo), vì vậy bạn nên khắc phục điều đó. Kiểm tra các quy tắc tường lửa và định tuyến sau khi kiểm tra trên chính máy chủ rằng nó thực sự đang chạy khi nghe trên địa chỉ IP đã cho. DNS cần cổng 53 cho cả UDP và TCP.
Jordán E Moisés avatar
lá cờ bm
Các cổng đang mở Tôi chưa cấu hình tường lửa netstat -a -n |grep 53 tcp 0 0 192.168.1.5:53 0.0.0.0:* NGHE tcp 0 0 127.0.0.1:53 0.0.0.0:* NGHE tcp 0 0 127.0.0.53:53 0.0.0.0:* NGHE
Jordán E Moisés avatar
lá cờ 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 :::* Apparmor hoặc selinux có thể chặn kết nối tới 192.168.1.5 cổng 53 không?
Jordán E Moisés avatar
lá cờ bm
Cảm ơn những người đã giúp đỡ tôi. Tôi đã tìm ra giải pháp, bắt đầu với một debian mới được cài đặt và cấu hình từng chút một. Sự cố không sao chép 100% cấu hình máy chủ dns và tôi đã bỏ qua sự cố. Trong "named.conf.options" tôi đã có những điều sau đây bogusnet acl { ...192.168.0.0/16; ... }; // Cấm các mạng không có thật hố đen { bogusnets; }; Nó đã chặn mạng loại C của tôi. Cả từ máy khách và từ giao diện của chính máy chủ với IP của mạng. Tôi đã gỡ bỏ mạng và mặt nạ khỏi acl đó và nó bắt đầu hoạt động. Trân trọng.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.