Puncte:0

Leagă modificarea DDNS primind `actualizare eșuată: NOTAUTH`, cum se rezolvă problema de autorizare?

drapel cn

Am următoarea definiție de zonă:

zona „madetoorder.software” {
  tip master;
  fișierul „/var/lib/bind/example.com.zone”;
  allow-transfer { servere-de-încredere; };
  numele de verificare avertizează;
  update-policy {
    acorda local-ddns zonesub orice;
    acordați letsencrypt_wildcard. nume _acme-challenge.example.com. TXT;
  };
  dimensiune max-jurnal 2M;
};

După cum se arată, este de așteptat să îmi permită să adaug și să elimin subdomenii (alias foo.example.com) folosind nactualizare. Am încercat următoarele, dar primesc un NOTAUTH eroare:

$ sudo nsupdate
> local 165.232.146.181
> zone madetoorder.software
> actualizare șterge ve-vlc.madetoorder.software.
> trimite
NOTAUTH
> actualizați adăugați ve-vlc.madetoorder.software. 60 A 165.232.146.181
> trimite
NOTAUTH
> renunta

După cum putem vedea, trimite comanda eșuează cu a NOTAUTH.

stiu local-ddns cheia este încărcată cu succes de când am încercat fără sudo Primesc următoarea eroare:

$ nsupdate -l
19-apr-2022 21:50:16.831 deschis: //run/named/session.key: permisiunea refuzată
nu pot citi cheia din //run/named/session.key: permisiunea refuzată

Privind fișierul, arată ca o cheie validă.Exact așa cum era de așteptat.

De asemenea letsencrypt modificări la un lucru de teren TXT conform așteptărilor. Deci, ce este greșit în:

acordă local-ddns zonesub orice

Notă:

După cum se arată în definiția zonei, fișierul .zone se află sub /var/lib/bind. Și directorul este deținut de rădăcină:bind cu permisiuni -rwxrwxr-x. Fișierul în sine are permisiuni -rw-------. Asa de numit (care rulează ca lega) are acces la fișiere.

Patrick Mevzek avatar
drapel cn
„Așa numit (care rulează ca bind) are acces la fișiere.” Este utilizatorul sub care rulați `nsupdate` care nu poate citi fișierul din cauza permisiunilor. În plus, este puțin ciudat să puneți cheia în`/run` deoarece acesta este un director efemer care va dispărea la repornire.
drapel cn
@PatrickMevzek Cheia `local-ddns` este specială prin faptul că este generată de named la pornire. Cel puțin, așa funcționează sub Ubuntu. Funcționează în timp ce rulează. Dacă reporniți named, acesta este regenerat din nou. Deci nu este necesar să păstrați acea cheie peste cizme și, prin urmare, poate locui sub `/run`.
Puncte:0
drapel cn

Am găsit o soluție la problema mea.

am repornit numit.

Nu sunt prea sigur ce se întâmplă. Se pare că rulează:

Stare $ systemctl numită
â named.service - BIND Domain Name Server
     Încărcat: încărcat (/lib/systemd/system/named.service; activat; prestabilit furnizor: activat)
     Activ: activ (în rulare) din miercuri 20-04-2022 14:25:48 UTC; acum 9 ore
       Documente: man:named(8)
   PID principal: 2334296 (numit)
      Sarcini: 14 (limită: 9508)
     Memorie: 44,3 M
     CGroup: /system.slice/named.service
             ââ2334296 /usr/sbin/named -f -u bind

Dar nu pot accesa nimic. Mi-a luat puțin timp să observ că sistemul a fost de fapt mort.

Când testez utilizarea dig @ns1.example.com www.example.com eșuează când este în acea stare. Cu toate acestea, portul UDP este deschis și, așa cum se arată mai sus, starea spune OK (punctul marcator este verde în consola mea).

Sper că asta ajută pe altcineva pentru că este o stare ciudată.

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.