Este normal răspunsul aleatoriu de la serverul cu autoritate DNS

Încercăm să instalăm Să criptăm eliberarea certificatului folosind cert-manager și rezolvatorul dns01. Noi folosim Dreamhost ca furnizor de DNS și am creat o componentă glue care face legătura între RFC-2136 cert-manager și Dreamhost API.

Ne confruntăm cu o problemă că, deși înregistrările necesare (TXT) sunt adăugate, serverul DNS autorizat le returnează la întâmplare - cu două solicitări, una după alta, returnând răspuns și alta nu returnează nimic. Acest lucru face ca cert-managerul să aștepte o perioadă de timp imprevizibilă până când, din fericire, poate confirma prezența înregistrării TXT și, în unele cazuri, face ca verificarea domeniului Lets Encrypt să eșueze.

Este ceva de așteptat de la serverul DNS autorizat? Sau ar trebui să ridicăm asta cu furnizorul nostru de DNS?

Mai jos este un exemplu de astfel de situație (deocamdată domeniul specific este retras). După cum puteți vedea

sapă @ns1.dreamhost.com. _acme-challenge.keycloak.tenant-a.k8s-dev.redacted.redacted. TXT 

; <<>> DiG 9.16.15-Ubuntu <<>> @ns1.dreamhost.com. _acme-challenge.keycloak.tenant-a.k8s-dev.redacted.redacted. TXT
; (1 server găsit)
;; opțiuni globale: +cmd
;; Am raspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NXDOMAIN, id: 38336
;; steaguri: qr aa rd; ÎNTREBARE: 1, RĂSPUNS: 0, AUTORITATE: 1, SUPLIMENTARE: 1
;; AVERTISMENT: recursiunea este solicitată, dar nu este disponibilă

;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 1232
;; SECȚIUNEA DE ÎNTREBĂRI:
;_acme-challenge.keycloak.tenant-a.k8s-dev.redacted.redacted. ÎN TXT

;; SECȚIUNEA AUTORITATE:
redactat. 300 ÎN SOA ns1.dreamhost.com. hostmaster.dreamhost.com. 2022060209 18661 600 1814400 300

;; Timp de interogare: 20 ms
;; SERVER: 162.159.26.14#53(162.159.26.14)
;; CÂND: czw cze 02 19:40:17 CEST 2022
;; MSG SIZE rcvd: 152

sapă @ns1.dreamhost.com. _acme-challenge.keycloak.tenant-a.k8s-dev.redacted.redacted. TXT 

; <<>> DiG 9.16.15-Ubuntu <<>> @ns1.dreamhost.com. _acme-challenge.keycloak.tenant-a.k8s-dev.redacted.redacted. TXT
; (1 server găsit)
;; opțiuni globale: +cmd
;; Am raspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 41439
;; steaguri: qr aa rd; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1
;; AVERTISMENT: recursiunea este solicitată, dar nu este disponibilă

;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 1232
;; SECȚIUNEA DE ÎNTREBĂRI:
;_acme-challenge.keycloak.tenant-a.k8s-dev.redacted.redacted. ÎN TXT

;; SECȚIUNEA RĂSPUNSURI:
_acme-challenge.keycloak.tenant-a.k8s-dev.redacted.redacted. 300 IN TXT „Uyr1nHC1CRWQcmOWDvObc4RMd-mNhKaE9bbNZTf3L2k”

;; Timp de interogare: 16 ms
;; SERVER: 162.159.26.14#53(162.159.26.14)
;; CÂND: czw cze 02 19:40:18 CEST 2022
;; MSG SIZE rcvd: 144

După cum puteți vedea

• Marcajele de timp ale răspunsurilor sunt aproape aceleași
• Un răspuns conține înregistrări TXT, altele nu
• Același server dns (162.159.26.14 - ns1.dreamhost.com) răspunde și cred că acesta este un server autorizat

Același server dns (162.159.26.14 - ns1.dreamhost.com) răspunde și cred că acesta este un server autorizat

La fel ca în cazul serverelor web, o singură adresă IP ar putea ascunde mai multe servere DNS care răspund solicitărilor dvs. Chiar și interogările din aceeași locație ar putea fi distribuite către mai multe noduri printr-un echilibrator de încărcare sau o rută cu mai multe căi. (Uneori „ns1” și „ns2” sunt în întregime pentru afișare, ambele conducând la același grup de servere.)

Da, în mod ideal, toate serverele autorizate din cluster ar trebui să cunoască exact aceleași date, dar în funcție de modul în care sunt implementate, clusterul ar putea au unele servere temporar nesincronizate cu baza de date autorizată Dreamhost din diverse motive. De exemplu (complet ipotetice – nu știu cum funcționează sistemele Dreamhost), cererile de „reîncărcare” pot fi răspândite în timp pentru a reduce încărcarea bazei de date.

după ce am verificat din altă țară (folosind cloud VPS) am primit un model diferit de răspunsuri

La o scară mai largă, atunci când interogați din locații diferite, BGP anycast vă poate conduce la grupuri complet diferite. Un bun exemplu este fie rezolutoarele DNS publice, fie serverele rădăcină – există multe exemple de 1.1.1.1 în întreaga lume și există multe exemple de „f.root-servers.net”.Dacă Dreamhost folosește anycast pentru a găzdui „ns1” în mai multe locații fizice (ceea ce probabil o fac, pentru o latență redusă), atunci este și mai probabil ca acestea să nu fie sincronizate pentru o perioadă scurtă de timp după ce faceți modificări. (Aceasta este o zonă în care „propagarea DNS” nu este o minciună.)

Multe servere DNS acceptă special hostname.bind și/sau id.server interogări la care răspund folosind numele lor individuale. Încercați acest lucru din diferite locații:

dig +short @ns1.dreamhost.com hostname.bind. haos txt

Dar per total, nimic din cele de mai sus nu schimbă cu adevărat lucrurile â problema dvs. nu este mult diferită de a avea servere separate și de a le menține sincronizate. De exemplu, chiar dacă tocmai ați avut servere ns1/ns2/ns3 obișnuite care utilizează replicarea DNS AXFR tradițională, ori de câte ori sunt încărcate date noi în serverul principal, poate dura câteva secunde pentru ca acesta să trimită NOTIFY către replici și ca acestea să transfere schimbări. Rezolvatorii care se uită la înregistrările dvs. NS nu sunt complet conștienți de acest lucru și ar putea selecta aleatoriu fie un server care are deja noile date, fie un server care nu le are.

Deci, indiferent de modul în care funcționează gazda DNS și de câte servere are, nu trebuie să vă așteptați niciodată ca actualizările să fie 100% instantanee; aflați dacă furnizorul publică timpul așteptat sau așteptați 5 sau 10 secunde.