nsupdate nu actualizează înregistrarea Apex

nsupdate funcționează numai pentru cnames. Se pare că vârful (înregistrare A pentru domeniul rădăcină) nu se actualizează. Am reușit să adaug la fișierul de zonă folosind „update add . 604800 A 1.1.1.1”, dar îl pune în „$ORIGIN”. secțiunea fișierului de zonă și nu pot să o șterg și să o actualizez. Am încercat „update add . 604800 A 2.2.2.2”, dar nu se întâmplă nicio actualizare. Am încercat și „actualizare add example.com. 604800 A 2.2.2.2”. Am plasat o înregistrare a locului în „$ORIGIN”. și „$ORIGIN example.com”. secțiunea fișierului de zonă crezând că trebuie să-l găsească pentru a-l actualiza. Am încercat să-l șterg și să-l actualizez... nimic nu pare să funcționeze. Am citit undeva că bind nu poate scrie în /etc/bind/zones, așa că am pus fișierul de zonă în /var/lib/bind.Bind a scris în fișier, dar o singură dată pentru a introduce o înregistrare în „$ORIGIN”. secțiune. Vreun sfat?

Fișierul Zona mea:

$ORIGINĂ .
$TTL 604800 ; 1 săptămână
exemplu.com. ÎN SOA ns1.example.com. admin.ns1.example.com. (
                24; serial
                604800; reîmprospătare (1 săptămână)
                86400; reîncercați (1 zi)
                2419200; expiră (4 săptămâni)
                604800; minim (1 saptamana)
                )
            NS ns1.example.com.
            NS ns2.example.com.
$ORIGIN example.com
@ A 5.5.5.5
ds1512 A 10.0.0.13
ds1817 A 10.0.0.14
acasă CNAME ds1817
ns1 A 10.0.0.6
ns2 A 10.0.0.3
roma CNAME ds1817
www CNAME example.com.

Comenzile mele cu ieșire de depanare:

brent@dnsdhcpserver:/var/lib/bind$ sudo nsupdate -d
> server 10.0.0.6
> zone example.com
> actualizare ștergere @ A
> update add @ 604800 A 2.2.2.2
> trimite
Se trimite actualizarea la 10.0.0.6#53
Interogare de actualizare trimisă:
;; ->>HEADER<<- opcode: UPDATE, stare: NOERROR, id: 25996
;; steaguri:; ZONA: 1, PRECERERE: 0, ACTUALIZARE: 2, SUPLIMENTARE: 0
;; SECȚIUNEA ZONĂ:
;example.com. ÎN SOA

;; SECȚIUNEA DE ACTUALIZARE:
. 0 ORICE A
. 604800 IN A 172.16.1.10


Răspuns de la interogarea de actualizare:
;; ->>HEADER<<- opcode: UPDATE, stare: NOTZONE, id: 25996
;; steaguri: qr; ZONA: 1, PRECERERE: 0, ACTUALIZARE: 0, SUPLIMENTARE: 0
;; SECȚIUNEA ZONĂ:
;example.com. ÎN SOA

Nu a funcționat așa că am încercat:

> server 10.0.0.6
> prereq nxdomain example.com
> actualizare add example.com. 604800 A 2.2.2.2
> trimite
Răspuns de la interogarea SOA:
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 47462
;; steaguri: qr aa ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 2, SUPLIMENTARE: 2
;; SECȚIUNEA DE ÎNTREBĂRI:
;example.com. ÎN SOA

;; SECȚIUNEA RĂSPUNSURI:
exemplu.com. 604800 ÎN SOA ns1.example.com. admin.ns1.example.com. 24 604800 86400 2419200 604800

;; SECȚIUNEA AUTORITATE:
exemplu.com.   604800 ÎN NS ns2.example.com.
exemplu.com. 604800 ÎN NS ns1.example.com.

;; SECȚIUNE SUPLIMENTARĂ:
ns1.example.com. 604800 ÎN A 10.0.0.6
ns2.example.com. 604800 ÎN A 10.0.0.3

Numele zonei găsite: example.com
Master este: ns1.example.com
Se trimite actualizarea la 10.0.0.6#53
Interogare de actualizare trimisă:
;; ->>HEADER<<- opcode: UPDATE, stare: NOERROR, id: 8484
;; steaguri:; ZONA: 1, PRECERERE: 1, ACTUALIZARE: 1, SUPLIMENTARE: 0
;; SECȚIUNEA PRIVIND CONDIȚII:
exemplu.com. 0 NIMIC NIMIC

;; SECȚIUNEA DE ACTUALIZARE:
exemplu.com. 604800 IN A 172.16.1.11


Răspuns de la interogarea de actualizare:
;; ->>HEADER<<- opcode: UPDATE, stare: YXDOMAIN, id: 8484
;; steaguri: qr; ZONA: 1, PRECERERE: 0, ACTUALIZARE: 0, SUPLIMENTARE: 0
;; SECȚIUNEA ZONĂ:
;example.com. ÎN SOA

Poate cineva să vadă ce îmi lipsește?

Nu adăugați punctul final la numele RR. Folosește-l așa:

server my.dns.server
zone example.com
exemplu cheie.com unele-date-cheie
actualizare șterge example.com 604800 A
actualizare add example.com 604800 A 192.0.2.1
trimite

Tocmai l-am testat cu înregistrarea A și MX; a funcționat pentru mine, serverul este PowerDNS, clientul este ISC nsupdate de la bind-tools, autentificarea a fost prin TSIG, numele cheii este egal cu numele zonei pentru simplitate.

Am impresia că nu înțelegi pe deplin cum $ORIGINĂ și @ de lucru, așa că iată o mică explicație. Pentru explicația completă vezi RFC1035.

Pe fir acestea nu apar niciodată. Este doar un „zahăr de sintaxă” convenabil care scurtează tastarea și citirea fișierelor de zonă. Următoarele trei exemple definesc zone identice (mi-e lene să completez înregistrările SOA, valorile lor exacte nu contează pentru subiectul nostru):

$ORIGIN example.com.
@ 604800 IN SOA ns1 ....
  604800 ÎN NS ns1
ns1 3600 IN A 192.0.2.1
@ 3600 ÎN A 192.0.2.5 

$ORIGINĂ .
exemplu.com 604800 ÎN SOA ns1.example.com ....
$ORIGIN com.
exemplu 604800 IN NS ns1.exemplu
$ORIGIN ns1.example.com.
@ 3600 ÎN A 192.0.2.1
exemplu.com. 3600 ÎN A 192.0.2.5 

exemplu.com. 604800 ÎN SOA ns1.example.com. ....
exemplu.com. 604800 ÎN NS ns1.example.com.
ns1.example.com. 3600 ÎN A 192.0.2.1
exemplu.com. 3600 ÎN A 192.0.2.5 

În primul exemplu nu am specificat niciun nume RR în a treia linie (NS RR după SOA RR), astfel încât analizatorul îl va prelua din linia anterioară. Acest comportament este motivul precis pentru @ existența sintaxei: nu puteți lăsa câmpul de nume RR gol, deoarece va lua numele înregistrării anterioare. Dacă am sărit peste @ la ultima înregistrare, aș defini o secundă A înregistrare pentru ns1. Deci, pentru a defini o înregistrare cu numele egal cu originea setata în prezent (va fi „apex” dacă originea este setată la numele zonei) nu puteți folosi „nume gol”, deoarece va invoca acest comportament „preluare anterior”.Fie trebuie să scrieți numele complet al înregistrării în mod explicit cu punctul final, astfel încât să nu adăugați o origine (cum este scris în alte exemple), să schimbați originea sau să utilizați un simbol special @ care îi spune parserului: „nu repeta numele anterior, aici vine originea goală”, deci ultima linie din primul exemplu definește exemplu.com..

Al doilea exemplu este doar o demonstrație fantezică cum $ORIGINĂ și @ lucram impreuna.

Al treilea exemplu nu folosește zahăr. Acestea sunt date reale absolute pe care le deține zona în fiecare dintre aceste trei exemple.

Deci, înregistrarea dvs. ar putea fi reprezentată în fișierul de zonă ca exemplu.com după $ORIGINĂ ., sau exemplu.com. oriunde, sau @ după $ORIGIN example.com., sau chiar exemplu după $ORIGIN com., nu contează. Aceste cazuri sunt toate egale. Probabil că vă așteptați să vedeți varianta „@”, dar BIND poate decide să o scrie ca oricare dintre acele variante, așa că fiți pregătit să le recunoașteți pe toate. Și nu îl puteți forța să folosească vreo variantă anume, îmi pare rău.

Un alt avertisment ar putea fi să citiți fișierul de zonă după actualizare fără a-l îngheța mai întâi. Observați fișierul „jnl” de lângă fișierul de zonă; este jurnalul în care datele dvs. actualizate au fost stocate pentru prima dată. Doar când faci rndc freeze example.com datele sunt scrise în fișierul de zonă (dar zona este apoi blocată pentru actualizări, pentru a debloca trebuie să faceți dezgheţ funcționarea sau reîncărcați serverul). Modul corect de a verifica dacă zona este actualizată sau nu este să faceți interogarea DNS reală, cu săpa sau gazdă sau nslookup, oricare îți place:

gazdă -v exemplu.com