Rulez BIND pentru testare și iată o parte din RPZ-ul meu:
exemplu.com ÎN CNAME . ; bloc local împotriva example.com
*.example.com ÎN CNAME . ; bloc local împotriva example.com
Când întreb exemplu.com este blocat cu succes:
dig @127.0.0.1 example.com
;; ->>HEADER<<- opcode: QUERY, stare: NXDOMAIN, id: 28108
;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 0, AUTORITATE: 0, SUPLIMENTARE: 2
;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 1232
;; SECȚIUNEA DE ÎNTREBĂRI:
;example.com. ÎN A
;; SECȚIUNE SUPLIMENTARĂ:
rpz.local. 1 ÎN SOA localhost. trebuie.să.știe.numai. 201702121 60 60 432000 60
dar fără recursivitate, trece prin:
dig @127.0.0.1 example.com +norecurse
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 59121
;; steaguri: qr ra ad; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1
;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 1232
;; SECȚIUNEA DE ÎNTREBĂRI:
;example.com. ÎN A
;; SECȚIUNEA RĂSPUNSURI:
exemplu.com. 17130 IN A 93.184.216.34
Înțeleg că nicio recursivitate nu servește ceea ce este în cache, dar de ce nu aplică RPZ pentru a bloca domeniul?
De asemenea, de ce se rezolvă cererea? nu ar trebui să blocheze interogarea DNS la început, deoarece domeniul se potrivește cu RPZ și revine cât mai repede posibil?
pot observa asta PowerDNS a optimizat chestia pentru a evita rezolvarea interogării dacă este necesar:
Acest lucru ar necesita amânarea evaluării politicilor RPZ până la finalizarea întregului proces de rezoluție, ceea ce ar însemna că interogările ar fi putut fi trimise deja către un server de nume rău intenționat, pe lângă problemele de performanță.
Sunt foarte curios să știu motivul și dacă există o modalitate de a bloca interogarea inainte de rezolutia.
