Puncte:0

Este posibil să aveți diferite DNS interne și publice cu DNSSEC?

drapel in

Încerc să obțin următoarele:

  • Un server de nume public pentru domeniul meu care indică exemplu.com la o adresă IP publică.
  • Un server de nume privat pentru același domeniu care rulează într-o rețea LAN, care direcționează în schimb clienții către o adresă IP privată pe același LAN.
  • DNSSEC activat.

Atingerea primului și ultimului puncte împreună este, desigur, relativ ușoară, așa că problema este ca componenta privată să funcționeze.

În ceea ce privește configurația mea reală:

  • Folosesc serviciul DNS Cloudflare, unde am o înregistrare A pentru domeniul meu care indică către o adresă IP publică și DNSSEC activat.
  • La registratorul meu, am adăugat o înregistrare DS pe baza a ceea ce îmi oferă Cloudflare și am configurat serverele de nume Cloudflare. Toate acestea funcționează bine, așa cum v-ați aștepta.
  • Pe plan intern, rulez Pi-Hole (setat ca server DNS pentru clienții de pe LAN-ul meu) care este configurat cu DNSSEC activat și indicând o instanță CoreDNS locală ca soluție în amonte.
  • În CoreDNS, am o zonă configurată pentru exemplu.com care este semnat cu chei generate de coredns-keygen. Acesta are o înregistrare A care indică o adresă IP internă.
  • Am o a doua înregistrare DS la registratorul meu, bazată pe cheia utilizată intern de CoreDNS.

Ce se întâmplă:

  • Configurația generală funcționează pentru rezolvarea domeniilor care nu sunt ale mele.
  • Pi-Hole răspunde cu SERVFAIL și bușteni ABANDONAT când încerc să-mi rezolv domeniul.
  • Dar, dacă direc un client direct către CoreDNS (de exemplu, cu săpa), primesc răspunsul așteptat cu adresa IP LAN.
  • De asemenea, dacă dezactivez DNSSEC în Pi-Hole, funcționează bine.

Deci intrebarile mele sunt:

  • Este chiar posibil ceea ce încerc să obțin?
  • Încep să mă întreb dacă a avea înregistrări DS separate la registratorul meu este greșit, dar nu cred că pot recupera cheia privată pe care o folosește Cloudflare și nici nu pot încărca chei personalizate, așa că nu sunt sigur cum pot folosi aceleași chei pentru public și privat.
  • Există vreun motiv pentru care lucrurile par să funcționeze dacă îmi direc clienții direct către CoreDNS, dar Pi-Hole refuză să coopereze?

Mulțumiri!

Patrick Mevzek avatar
drapel cn
Următoarea întrebare din coloana Related poate ajuta: https://serverfault.com/questions/745270/using-dnssec-with-private-tld?rq=1
Patrick Mevzek avatar
drapel cn
„Încep să mă întreb dacă a avea înregistrări DS separate la registratorul meu este greșit” DNSSEC se așteaptă la O cale validă existentă pentru a dovedi lanțul de încredere. Nu tot. Deci este „bine” să ai DS în plus. Puteți găsi diferite TLD-uri/domenii folosind o configurație „DS pre-publicată” în care DS este publicată la părinte, fără DNSKEY-ul relevant publicat la copil. Funcționează atâta timp cât există ALTA înregistrare DS cu DNSKEY-ul corespunzător. S-ar putea să doriți ca din Pi-Hole să depanați în continuare SERVFAIL. Poate fi legat de DNSSEC sau nu. Dacă aveți EDE, vă ajută, dar în caz contrar încercați să săpați cu și fără `+cd`
Patrick Mevzek avatar
drapel cn
Un nume adevărat ar fi ajutat. Bănuiesc că problema este mai mult legată de înregistrările tale `NS`. „În CoreDNS, am o zonă configurată pentru example.com care este semnată cu chei generate de coredns-keygen.” Dar probabil cu înregistrări NS diferite decât versiunea publică a zonei? Ceea ce poate induce erori asupra semnăturilor, deoarece NS rrset nu se va mai potrivi.
drapel in
Mulțumesc, am văzut această întrebare, dar, din păcate, linkurile din răspuns sunt moarte. De asemenea, dețin domeniul meu real, așa că probabil că este mai ușor. Deci, a avea mai multe înregistrări DS este bine? Dar când spui că DNSSEC se așteaptă la o cale, probabil că asta înseamnă nu DOAR o cale. Dacă încerc să sap cu `+cd`, primesc `NOERROR`, deci această problemă este cu siguranță legată de verificare. — Dar probabil cu înregistrări NS diferite decât versiunea publică a zonei? - Ah, da.Tocmai am încercat să setez SOA și NS ale zonei interne la aceeași cu publicul, nicio schimbare până acum.
drapel in
De asemenea, voi încerca să obținem ceva mai utile erori de la Pi-Hole. Mă voi uita dacă pot activa EDE cumva.
Patrick Mevzek avatar
drapel cn
„Dar când spui că DNSSEC se așteaptă la o singură cale, probabil că asta înseamnă nu DOAR o cale.” Resolverul ia toate DS-urile pe care le vede și toate DNSKEY-urile pe care le vede, iar dacă găsește o potrivire (plus toate cripto-urile și datele devin ok), atunci este bine să afirmăm că lanțul de încredere este verificat (și continuă cu următorul nivel de delegare și așa mai departe). Odată găsită o cale validă, alte DS/DNSKEY la același nivel sunt irelevante, chiar dacă funcționează și ele.
Patrick Mevzek avatar
drapel cn
Consultați §5.3.3 din RFC4035 dacă este mai clar decât explicația mea: „Rețineți că este posibil ca mai mult de un DNSKEY RR să se potrivească cu condițiile din Secțiunea 5.3.1. În acest caz, validatorul poate doar determinați care DNSKEY RR este corect încercând fiecare public care se potrivește cheie până când validatorul fie reușește să valideze semnătura sau rămâne fără chei pentru a încerca." Deci o potrivire este suficientă pentru a conta care dintre ele (în prezența mai multor DNSKEY/DS; amintiți-vă, de asemenea, că un anumit DNSKEY, chiar și singur, poate avea mai multe înregistrări DS, pentru diferite rezumate)
drapel in
Mulțumesc, are sens. Sunt încă blocat pe asta, din păcate. Tot ce pot vedea din jurnalele este că Pi-Hole trimite interogarea către CoreDNS, care răspunde cu înregistrarea A. Apoi Pi-hole solicită înregistrarea DS, CoreDNS înregistrează un răspuns `NOERROR`, dar Pi-Hole înregistrează apoi `validation mydomain.com is ABANDONED`.Încercând lucruri cu `dig` și `drill` interogând direct serverul CoreDNS, tot ceea ce pot spune este că, din câte am înțeles, răspunsurile par corecte. Deci nu am idee de ce Pi-Hole renunță la validare.

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.