Care este cazul de utilizare al SVCB (tip 65, serviciu obligatoriu) RR

SVCB/HTTPS În prezent se lucrează la înregistrările DNS (vezi https://github.com/MikeBishop/dns-alt-svc/blob/master/draft-ietf-dnsop-svcb-https.md pentru documentul de lucru sau https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.txt la IETF), dar nefinalizat încă.

Situația ciudată ambiguă de acum este că IANA a înregistrat deja codurile pentru ele (de aceea se pot întâmpla deja în sălbăticie și pot fi interoperabile, prin modul RFC 3597 de a gestiona tipurile de înregistrări generice), chiar dacă RFC nu este încă pregătit. /publicat, iar unii furnizori (Apple și Cloudflare, vezi mai jos) au spus că l-au implementat deja și îl folosesc.

Vedea https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ de exemplu pentru Cloudflare, care oferă și un exemplu de ce este folosit. Vă recomand să îl citiți, probabil înainte de standardul tehnic în sine, cu excepția cazului în care stăpâniți deja DNS și TLS.

Ideea a ieșit practic după/în timpul TLS 1.3 (și client criptatHello/necesități SNI criptate), și HTTP/3 și QUIC.Documentul își propune să rezolve de fapt mai multe probleme, unde o parte dintre ele au fost deja rezolvate SRV înregistrări pe care niciun browser nu a decis să le implementeze atunci.

Preluat din rezumat:

SVCB înregistrările permit furnizarea unui serviciu din alternative multiple puncte finale, fiecare cu parametri asociați (cum ar fi transport configurația protocolului și cheile pentru criptarea TLS ClientHello). Ele permit, de asemenea, aliasarea domeniilor apex, ceea ce nu este posibil CNAME. HTTPS RR este o variantă a SVCB pentru HTTPS și HTTP origini. Prin furnizarea de mai multe informații clientului înaintea acestuia încercări de a stabili o conexiune, aceste înregistrări oferă potențial beneficii atât pentru performanță, cât și pentru confidențialitate.

Acum despre punctele dvs. specifice:

i. Type65 RR poate fi un înlocuitor al CNAME, mai ales în cazurile în care nu putem avea CNAME la nivelul superior al zonei

Da, SVCB/HTTPS au fost concepute pentru a ajuta la tratarea cazului „CNAME at apex”. Consultați „10.3.2. Aliasarea Apex” în proiect:

   Luați în considerare o zonă care utilizează alias CNAME:

   $ORIGIN aliased.example. ; O zonă care utilizează un serviciu de găzduire
   ; Subdomeniu alias la un pool de servere de înaltă performanță
   www 7200 ÎN CNAME pool.svc.example.
   ; Domeniu Apex pe IP-uri fixe, deoarece CNAME nu este permis la vârf
   @ 300 ÎN A 192.0.2.1
                        ÎN AAAA 2001:db8::1

   Cu HTTPS RR, proprietarul aliased.example poate alias vârful prin
   adăugarea unei înregistrări suplimentare:

   @ 7200 IN HTTPS 0 pool.svc.example.

ii. Cum pot instrui browserele să solicite interogări de tip 65 în loc de A sau AAAA pentru domeniul meu, astfel încât să am abc.com direct pe CDN

Va trebui să așteptați ca browserele să-l accepte :-)

Aruncă o privire la firul de la https://mailarchive.ietf.org/arch/msg/dnsop/eeP4H9fli712JPWnEMvDg1sLEfg/ ; există suport în iOS 14 și Safari se pare, într-un mod experimental.

Articolul de blog de la Cloudflare oferă la sfârșit două link-uri pentru a urmări starea funcției în Firefox și Chrome:

• https://groups.google.com/a/chromium.org/g/blink-dev/c/brZTXr6-2PU/m/g0g8wwWwCAwAJ afirmând în aprilie 2021: „Chrome va începe în curând să experimenteze cu interogarea HTTPS și INTEGRITATE prin DNS clasic (Do53) pe platformele în care Chrome gestionează în mod regulat Do53 prin soluția sa încorporată (Android, ChromeOS și MacOS).”
• https://bugzilla.mozilla.org/show_bug.cgi?id=1634793 : arată doar că funcția depinde acum de alte 5 erori încă deschise care probabil trebuie să fie închise mai întâi, fără intervale de timp

Apropo, mulțumit, nu întuneca rău. Utilizare exemplu.com în documentație, vezi RFC2606

iii. ce versiune de bind acceptă SVCB (tip 65) RR

Niciunul nu a fost încă expediat. Aceasta este urmărită https://gitlab.isc.org/isc-projects/bind9/-/issues/1132 A fost comasat 6 zile în urmă :-) Deci, poate că următoarele versiuni îl vor livra, pe baza a ceea ce este în biletul pentru reper: „Septembrie 2021 (9.11.36, 9.11.36-S1, 9.16.21, 9.16.21-S1, 9.17.18)”

Cu toate acestea, datorită RFC 3597, ar trebui să puteți introduce înregistrările folosind sintaxa generică, cu TIP65 în zonefile și bind ar trebui să-l servească. Pierdeți în mod evident verificările de sintaxă și alte caracteristici (vă puteți uita la https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5332/diffs pentru a vedea exact ce înseamnă „adăugarea suportului SVCB/HTTPS pentru a lega” din punct de vedere al codului; vezi §4 din proiectul IETF pentru a vedea ce suport specific trebuie să aibă rezolutorii autoritari și recursivi pentru aceste înregistrări; este un TREBUIE, astfel încât variațiile sunt acceptate dacă există motive întemeiate, cum ar fi nici un suport complet adevărat în software), dar cel puțin puteți servi înregistrările.

Dar amintiți-vă, nu există doar legături acolo:

• PowerDNS are deja suport: https://doc.powerdns.com/authoritative/guides/svcb.html
• Versiunea din iulie a nsd are și suport: https://www.nlnetlabs.nl/news/2021/Jul/22/nsd-4.3.7-released/ cu „Noile funcții sunt XoT, care oferă AXFR și IXFR prin TLS, și suport pentru cookie-uri DNS și suport de tip SVCB și HTTPS RR.”
• Knot DNS, de asemenea, la https://www.knot-dns.cz/2021-08-02-version-310.html cu o versiune din august și un anumit suport: „libs: suport pentru analizarea și descărcarea înregistrărilor de resurse SVCB și HTTPS”

Deci, puteți experimenta deja asistență completă cu alt software.