Nu sunt sigur că văd cu adevărat întrebarea ta.
ADIŢIONAL este definit ca opțional (deci clientul este liber să ignore acele date și din motive de securitate ar trebui într-adevăr să le ignore de cele mai multe ori)... cu excepția cazului în care nu există altă modalitate de a realiza ceva, care sunt lipici.
Dar problema este că cleiurile SUPLIMENTARE aka nu sunt acoperite de DNSSEC, prin urmare nu sunt autentificate, așa că trebuie manipulate cu grijă.
Rețineți că cazul dvs. de adobe.net folosind servere de nume sub omtrdc.net nu este definiția „în-bailiwick”. Ar fi fost in-bailiwick dacă numele serverelor de nume ar fi fost și sub adobe.net. Deci, cazul dvs. este doar ceea ce se numește „servere de nume interne”, deoarece numele serverelor de nume sunt interne aceluiași registru cu numele de domeniu pe care sunt autorizați.
[ Nota personală laterală pentru a fi sincer: consider că această configurație a domeniului A care folosește servere de nume sub domeniul B ale căror servere de nume sunt din nou sub domeniul A este cu adevărat periculoasă. Orice eroare în A sau B dezactivează posibil rezoluția ambelor A și B; acesta este un fel de bucle, iar buclele din DNS ar trebui evitate (sau tratate cu grijă și măsuri de atenuare și garanții adecvate) ].
Puteți găsi o mulțime de definiții grozave în RFC 8499 despre terminologia DNS.
Are asta de exemplu:
Bailiwick: „In-bailiwick” este un modificator pentru a descrie un server de nume
al cărui nume este fie un subdomeniu al sau (rar) același cu
originea zonei care contine delegarea la nume
Server.
Cât despre
Are sens sau am uitat câteva părți importante?
Te descurci grozav arătând ieșirile DNS ale dig sau similar, dar ceea ce lipsește/vag este serverul de nume pe care îl întrebi pentru date, ar trebui să arăți asta și să studiezi asta pentru a avea o imagine clară. În majoritatea cazurilor de neînțelegere în DNS, văd că provine dintr-o confuzie între serverele de nume autorizate și recursive.
ADIŢIONAL secțiunea este definită așa în RFC 1034:
Adiţional
Poartă RR-uri care pot fi utile în utilizarea RR-urilor în
alte secțiuni.
Apoi vine complet în §4.3.2 care descrie algoritmul de rezoluție:
Copiați NS RR pentru subzonă în autoritate
secțiunea răspunsului. Pune orice adrese ar fi
disponibil în secțiunea suplimentară, folosind lipici RR
dacă adresele nu sunt disponibile de la autoritate
date sau cache-ul. Treceți la pasul 4.
Întorcându-ne la RFC 8499, primiți mai multe explicații:
Un răspuns care are doar o trimitere conține un răspuns gol
secțiune. Conține NS RRset pentru zona la care se face referire din
Secțiunea de autoritate. Poate conține RR-uri care furnizează adrese în
secțiunea suplimentară. Bitul AA este clar.
și
În cazul în care interogarea se potrivește cu un alias, iar serverul este
nu este autorizat pentru ținta aliasului, dar este autorizat
pentru un nume deasupra țintei aliasului, rezoluția
algoritmul va produce un răspuns care conține atât
răspuns autorizat pentru alias și o trimitere. Un astfel de parțial
răspunsul și răspunsul la recomandare au date în secțiunea Răspuns. Aceasta
are NS RRset pentru zona la care se face referire din Autoritate
secțiune. Poate conține RR-uri care furnizează adrese în
secțiune suplimentară.
Cât despre:
Cu toate acestea, am văzut unele implementări
Da, conținutul ADIŢIONAL se poate schimba în funcție de serverul de nume pe care îl întrebați și de modul în care este configurat. Vezi de exemplu răspunsuri minime opțiunea Bind, documentată la https://bind9.readthedocs.io/en/latest/reference.html afirmând: „Această opțiune controlează adăugarea de înregistrări la autoritate și secțiuni suplimentare de răspunsuri. Astfel de înregistrări pot fi incluse în răspunsuri pentru a fi utile clienților; de exemplu, înregistrările NS sau MX pot avea înregistrări asociate de adrese incluse în secțiunea suplimentară, evitând necesitatea unei căutări separate de adrese. Cu toate acestea, adăugarea acestor înregistrări la răspunsuri nu este obligatorie și necesită căutări suplimentare în bazele de date, provocând o latență suplimentară atunci când distribuirea răspunsurilor." Are 4 valori posibile atât de multe comportamente diferite online.
Și în sfârșit pentru:
deoarece serverul TLD administrează rețeaua. zona, putem crede orice sub net.
Da și nu :-). Luați, de exemplu, „experimentul” Verisign SiteFinder din trecut: interogați orice server de nume autorizat pentru orice nume care nu există și ați primit înapoi un A record. Crezi sau nu?
