Cum se confirmă cine este responsabil pentru deservirea solicitărilor DNS inverse (PTR) unui bloc IP?

Înainte ca cineva să răspundă „întreaba-ți ISP-ul” sau „întreaba-ți furnizorul de găzduire”, te rugăm să citești integral.

Scenariu:

• Detin un nume de domeniu domeniul meu.exemplu, și un bloc IP direcționat public (de exemplu 192.0.2.0/28)
• Înregistrările NS (GLUE) pentru acest domeniu sunt configurate la registratorul meu - ns1.mydomain.exemplu și ns2.mydomain.exemplu care indică serverele mele (servere DNS auto-găzduite)
• DNS invers pentru mine bloc IP direcționat public sunt deservite de aceleași servere. Acest lucru este astfel încât să pot actualiza intrările dns inverse pentru IP-urile mele în timpul liber pe echipamentul meu.

Problemă: Am mers să migrez găzduirea DNS pentru domeniul meu (domeniul meu.exemplu) de la propriile mele servere la cloudflare, hotărând că nu merită bataia de a-l găzdui. Am mai făcut acest lucru de mai multe ori, cu setări identice și nu am experimentat efecte negative.

Cu toate acestea, când înregistrările NS s-au actualizat la cloudflare, am constatat că DNS-ul meu invers a încetat complet să funcționeze.

Întrebare: Ce / cine determină cine răspunde la întrebările pentru DNS invers pentru blocul meu IP? Am înțeles că, de obicei, DNS direct și DNS invers se fac independent unul de celălalt, așa că nu mă așteptam la migrarea serverelor de nume de căutare directă din infrastructura auto-găzduită -> cloudflare la căutarea DNS inversă.

Am înțeles că entitatea care răspunde la DNS-ul dvs. direct (cloudflare) este independentă de cea care răspunde la DNS-ul dvs. invers (de exemplu, furnizorul dvs. de găzduire, ISP etc.). Dar, cum pot confirma cine este cu adevărat responsabil pentru asta - cum aș face pentru DNS-ul meu direct? pot face o % dig +scurt mydomain.exemplu NS pentru a confirma ce servere sunt responsabile pentru interogările DNS de redirecționare, care este procedura pentru a afla cine este responsabil pentru DNS-ul invers al unei adrese IP pe care le folosesc?

Daca adresa ta ip ar fi 192.0.2.4 și utilizați nslookup, ați rula următoarele:

set q=ns

4.2.0.192.in-addr.arpa

Acest lucru vă va arăta serverele de nume responsabile pentru blocul de adrese IP în care există adresa dumneavoastră IP.

Soluția la problema dvs.:

În acest caz, nu cred că problema este cu înregistrările dvs. PTR, ci mai degrabă cu modul în care funcționează sistemul Reverse Proxy al Cloudflare. Dacă domeniul tău folosește proxy-ul Cloudflare, atunci de fapt nu mai indică către serverul tău.

Soluția este să dezactivați proxy-ul Cloudflare pentru domeniile/subdomeniile în care se află serverele de e-mail.

Răspuns la întrebarea ta:

Interogările DNS și rDNS apar separat, dar interogarea DNS are loc mai întâi pentru a determina ce IP să interogă pentru rDNS/PTR. În acest caz, Cloudflare înlocuiește în esență IP-ul dvs. în răspunsul DNS cu al lor, ceea ce cauzează problema.

De exemplu, dacă ai domeniul meu.exemplu, iar setările dvs. DNS Cloudflare sunt o înregistrare A care indică 192.0.2.1 cu Proxy activat, atunci domeniul indică de fapt serverele Cloudflare, care apoi redirecționează traficul către al tău.Cu toate acestea, aceasta înseamnă că căutarea PTR va interoga serverele Cloudflare mai degrabă decât ale dvs., care nu vor raporta nicio înregistrare prezentă:

⯠dig proxied.mydomain.example # Serverul de e-mail de la distanță interogează înregistrarea A a unui domeniu proxy.
;; SECȚIUNEA DE ÎNTREBĂRI:
;proxied.mydomain.exemplu. ÎN A
;; SECȚIUNEA RĂSPUNSURI:
proxy.mydomain.exemplu. 300 ÎN A 104.21.30.252 # Cloudflare Server
proxy.mydomain.exemplu. 300 ÎN A 172.67.174.61 # Server Cloudflare
⯠dig -x 104.21.30.252 # Serverul de e-mail la distanță verifică PTR/rDNS ale ambelor IP-uri (Acesta este de la un IP Cloudflare real)
;; SECȚIUNEA DE ÎNTREBĂRI:
;252.30.21.104.in-addr.arpa. ÎN PTR
;; SECȚIUNEA AUTORITATE:
21.104.in-addr.arpa. 3600 IN SOA cruz.ns.cloudflare.com. dns.cloudflare.com. 2034580120 10000 2400 604800 3600 
# Serverul nu returnează nicio înregistrare PTR, deoarece este serverul Cloudflare care este interogat.

Dacă dezactivați proxy-ul Cloudflare pentru înregistrarea DNS a serverului de e-mail, arată mai mult astfel:

⯠dig unproxied.mydomain.example # Serverul de e-mail de la distanță interogează înregistrarea A a unui domeniu non-proxiat.
;; SECȚIUNEA DE ÎNTREBĂRI:
;unproxied.mydomain.exemplu. ÎN A
;; SECȚIUNEA RĂSPUNSURI:
unproxied.mydomain.exemplu. 300 IN A 192.0.2.1 # Serverul DNS returnează IP-ul serverului dumneavoastră.
⯠dig -x 192.0.2.1 # Serverul de e-mail interogează serverul DVS. pentru PTR.
;; SECȚIUNEA DE ÎNTREBĂRI:
;117.8.209.209.in-addr.arpa. ÎN PTR
;; SECȚIUNEA RĂSPUNSURI:
117.8.209.209.in-addr.arpa. 86400 IN PTR unproxied.mydomain.example.
# PTR returnează valoarea corectă.

(Vă rugăm să rețineți că am omis căutările MX/SPF/DKIM/DMARC în acest răspuns, deoarece, din câte știu eu, Cloudflare nu se încurcă cu acestea decât dacă vă îndreptați înregistrarea către o înregistrare proxy A/AAAA/CNAME .)