De ce un server de nume autorizat nu își validează DNSSEC propriile rezultate?
Pentru că nu poate, nu fără a fi un server de nume recursiv în sine, ceea ce ar fi rău.
Pentru a valida pe deplin DNSSEC, trebuie să porniți de la rădăcină și să treceți prin întreaga legătură de DS/DNSKEY înregistrările, iar soluția autorizată pe care o consultați nu este autorizată în toate acestea, doar partea sa din link.
A se vedea, de exemplu, secțiunea 6 din RFC 4033, „Considerarea rezolutorului”:
Un rezolutor conștient de securitate trebuie să poată efectua criptografii
funcțiile necesare pentru verificarea semnăturilor digitale folosind cel puțin
algoritm(i) obligatoriu de implementat. Resolverii conștienți de securitate trebuie
de asemenea, să poată forma un lanț de autentificare dintr-un nou
zona învățată înapoi la o cheie de autentificare, așa cum este descris mai sus. Acest
Procesul poate necesita interogări suplimentare către zonele DNS intermediare pentru a obține înregistrările DNSKEY, DS și RRSIG necesare. Un conștient de securitate
resolverul ar trebui să fie configurat cu cel puțin o ancoră de încredere ca
punctul de plecare de la care va încerca să stabilească autentificarea
lanţuri.
Și RFC 4035, secțiunea §3.2.3 „The AD Bit” sub „Recursive Name Servers”:
Partea serverului de nume a unui server de nume recursiv care conștientizează securitatea TREBUIE
NU setați bitul AD într-un răspuns decât dacă serverul de nume ia în considerare toate
RRsetează în secțiunile Răspuns și Autoritate ale răspunsului să fie
autentic. Partea serverului de nume TREBUIE să seteze bitul AD dacă și numai dacă
partea de rezolvare ia în considerare toate RRset-urile din secțiunea Răspuns și orice
RR-urile de răspuns negative relevante în secțiunea Autoritate să fie
autentic. Partea rezolutorului TREBUIE să urmeze procedura descrisă în
Secțiunea 5 pentru a determina dacă RR-urile în cauză sunt autentice.
Cu toate acestea, pentru compatibilitate cu versiunea anterioară, un server de nume recursiv MAI setat
bitul AD când un răspuns include RR-uri CNAME nesemnate dacă acele CNAME
Se poate demonstra că RR-urile ar fi putut fi sintetizate dintr-un DNAME autentic
RR care este inclus și în răspuns conform sintezei
regulile descrise în [RFC2672].
Cât despre:
face diferența dacă un răspuns este validat sau nu
Desigur, acesta este întregul scop al DNSSEC. Dar clienții finali nu consultă serverele de nume autorizate direct în timpul operațiunilor normale. Ei folosesc un server de nume recursiv, care, la rândul său, iterează peste diferite servere de nume autorizate pentru a obține răspunsul final și care poate valida DNSSEC dacă este configurat pentru a face acest lucru.
Mă întrebam de ce înregistrările SSHFP nu au funcționat făcând ssh -o VerifyHostKeyDNS de la serverul de nume însuși
Orice problemă ai aici nu are legătură cu nimic de mai sus. ssh ar trebui să folosească orice soluție de nivel de sistem de operare este configurată pentru a obține datele.
Vedea https://github.com/openssh/libopenssh/blob/05dfdd5f54d9a1bae5544141a7ee65baa3313ecd/ssh/dns.c#L191 care se află în interiorul verify_host_key_dns funcţie:
rezultat = getrrsetbyname(nume gazdă, DNS_RDATACLASS_IN,
DNS_RDATATYPE_SSHFP, 0, &rentele);
dacă (rezultat) {
verbose("Eroare de căutare DNS: %s", dns_result_totext(rezultat));
întoarcere -1;
}
dacă (amprente->rri_flags și RRSET_VALIDAT) {
*steaguri |= DNS_VERIFY_SECURE;
debug("au găsit %d amprente securizate în DNS",
amprente->rri_nrdatas);
} altfel {
debug("au găsit %d amprente nesigure în DNS",
amprente->rri_nrdatas);
}
și getrrsetbyname este definit în https://github.com/openssh/openssh-portable/blob/2dc328023f60212cd29504fc05d849133ae47355/openbsd-compat/getrrsetbyname.c și este practic un înveliș în jur res_query care este legarea libc de nivel scăzut pentru a face interogări DNS.
Am gasit la https://weberblog.net/sshfp-authenticate-ssh-fingerprints-via-dnssec/ câteva detalii despre ssh comportament între un validat (DNSSEC) SSHFP inregistreaza sau nu.
