Puncte:0

Spuneți lui bind să ignore verificarea domeniului SOA în zonele de expeditor

drapel in

Am o problemă ciudată cu bind.

Premisa: folosesc bind (versiunea 9.16_11) instalat pe pfSense, dar, în ciuda acestui lucru, pot schimba aproape orice în configurația bind.

Am configurat o zonă simplă înainte, configurația este cam așa:

zona „dom001.my-domain.com” {
        tastați înainte;
        numai înainte;
        expeditori { 192.168.29.10; };
};

Acum, dacă încerc să fac un nslookup la o gazdă din acest domeniu, văd o eroare. Exemplu:

Răspuns neautorizat:
Nume: mail2.dom001.my-domain.com
Adresa: 192.168.210.126
** serverul nu poate găsi mail2.dom001.my-domain.com: SERVFAIL

Lucrul ciudat este că răspunsul este primit (puteți vedea adresa în răspuns) dar în ciuda acestui lucru văd eroarea SERVFAIL.

Alt lucru ciudat, dig nu raportează nicio eroare:

; <<>> DiG 9.16.6 <<>> mail2.dom001.my-domain.com
;; opțiuni globale: +cmd
;; Am răspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 53129
;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1

;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 4096
; COOKIE: 3218b8a1b8f64565eb9bd6636124bf73640809a4347f3bcf (bine)
;; SECȚIUNEA DE ÎNTREBĂRI:
;mail2.dom001.my-domain.com. ÎN A

;; SECȚIUNEA RĂSPUNSURI:
mail2.dom001.my-domain.com. 30 IN A 192.168.210.126

;; Timp de interogare: 30 ms
;; SERVER: 172.16.0.2#53(172.16.0.2)
;; CÂND: marți, 24 august, 11:44:19 CEST 2021
;; MSG SIZE rcvd: 110

În timpul acestor interogări, văd câteva „avertismente” în jurnalele lui bind:

24 august 10:42:58 numit 19540 lame-server: info: FORMERR rezolvarea „mail2.dom001.my-domain.com/AAAA/IN”: 192.168.29.10#53
24 august 10:42:58 numit 19540 resolver: notă: eroare de format DNS de la 192.168.29.10#53 rezolvarea mail2.dom001.my-domain.com/AAAA pentru clientul 10.16.16.41#38299: Numele cluster.local (SOA) nu subdomeniul zonei dom001.my-domain.com -- răspuns nevalid

Am verificat în continuare și se pare că problema este legată de înregistrările SOA pe serverul de expeditor:

;; SECȚIUNEA DE ÎNTREBĂRI:
;mail2.dom001.my-domain.com. ÎN SOA

;; SECȚIUNEA RĂSPUNSURI:
cluster.local. 30 ÎN SOA ns.dns.cluster.local. hostmaster.cluster.local. 1629766398 7200 1800 86400 30

De fapt, răspunsul este cluster.local în loc de dom001.domeniul-meu.com.

Această problemă provoacă un comportament ciudat în funcție de sistemul de operare utilizat.De exemplu, văd că majoritatea serverelor Linux funcționează bine, în timp ce unele versiuni de Alpine Linux nu pot rezolva numele de gazdă pe acel domeniu.

Și chiar și cu serverul care funcționează bine, am jurnalele bind pline de erori din cauza acestei probleme.

Din păcate, nu pot controla serverul de expeditor și nu pot schimba înregistrarea SOA.

Întrebarea mea este: cum pot configura legătura pentru a ignora înregistrarea SOA a acelui expeditor și a accepta răspunsul chiar dacă SOA nu este coerent?

Știu că nu este cea mai bună soluție, dar trebuie să rezolv expeditorul configurat greșit.

Multumesc anticipat pentru ajutor!

Patrick Mevzek avatar
drapel cn
Aș fi destul de surprins că problema este cu SOA, deoarece acele cereri nu sunt făcute, cu excepția, poate, pentru a găsi tăieturi de zonă. Ai înfundat totul, așa că este greu să te ajut cu adevărat.Pe de o parte se pare că aveți un domeniu real, pe de altă parte aveți `.local` cu care ar trebui folosit doar pentru MDNS și nimic altceva. Întrebarea ta ar fi mai bună cu detaliile complete...
Puncte:1
drapel cn

Nu cred că există opțiuni în BIND care să-l facă să accepte acel răspuns, deoarece pare să nu aibă legătură cu interogarea.
Dacă văd acest tip de răspuns inconsecvent, cu siguranță nu este de așteptat și cred că, dacă doriți cu adevărat (temporar?) să acceptați și să transmiteți aceste răspunsuri (nici clienții s-ar putea să nu le placă, desigur), poate fi necesar să vă uitați la alt software care nu-i pasă de conținutul răspunsului în același mod.
(Bănuiesc că dnsdist, fiind mai degrabă un proxy decât un recursor, ar putea face acest lucru pentru tine.)

Acestea fiind spuse, cred că pot clarifica oarecum o parte din confuzia...

The nslookup situația se bazează pe cum nslookup trimite implicit două interogări separate, una pentru A si unul pentru aaaa.
The A interogarea este de succes și a avut în mod clar relevante A înregistrați ca răspuns, the aaaa interogarea nu a avut succes, probabil că nu a existat aaaa înregistrați și ca răspunsurile negative vin întotdeauna cu (presupuse a fi) relevante SOA înregistrare care probabil declanșează exact problema pe care ați descris-o.

Mă aștept să puteți reproduce și problema cu săpa foarte bine dacă îl faci să trimită aceeași interogare care a eșuat, așa că ar trebui să trimiți o interogare pentru aaaa pentru a obține același eșec ca nslookup primit pentru una dintre cele două interogări ale sale.

În ceea ce privește comportamentul celuilalt server de nume, nu este chiar un caz de „editare a SOA", este mai degrabă un fel de eroare logică în software-ul serverului de nume. De fapt, nu ar trebui să fie posibil să găsești un cluster.local înregistrați când priviți în sus mail2.dom001.my-domain.com, adică într-o ramură complet diferită a copacului.

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.