Puncte:0

DNS intern cu BIND, cum se rezolvă o adresă IP diferit?

drapel ye
raj

Am un DNS intern (este complet intern, adică rețeaua nu este conectată la Internet) pentru un grup de rețele. Ele sunt configurate după cum urmează:

  • Fiecare rețea are un interval de adrese diferit de 10.x.0.0/16 și propriul său domeniu domeniux (este un domeniu de nivel superior) - de exemplu, rețea 10.1.0.0/16 are domeniul 1 (toate gazdele din această rețea au nume DNS somehost.domain1)

  • Pentru fiecare rețea/domeniu, gazdă ns.domainx (10.x.1.1) este un server DNS care gestionează ambele zone înainte domeniux și zona inversă x.10.in-addr.arpa

  • Aceste rețele nu sunt interconectate, cu excepția unui server special multi-homed care are conectivitate la toate aceste rețele (și întrebarea mea este despre acel server de fapt) - dar nu direcționează pachetele între acele rețele, ci doar poate comunica cu fiecare dintre aceste rețele. lor. Este de proiectare, fiecare rețea este proiectată pentru a fi operată separat și independent.

  • Prin urmare, serverul DNS din fiecare rețea știe doar despre domeniul său; nu știe (și nu ar trebui sa stie) orice despre domeniile din alte rețele.

  • Cu toate acestea, serverul multi-homed pe care l-am menționat mai devreme trebuie să aibă o rezoluție DNS funcțională pentru adresele din toate aceste rețele. La cerere, nu pot atinge nimic în niciuna dintre rețele, în special serverele lor DNS. Pot doar să modific configurația serverului multi-homed.

  • Așa că am configurat BIND pe serverul multi-homed care doar definește zona . ca „master”, iar fișierul de zonă conține următoarele înregistrări:

    1.10.in-addr.arpa. ÎN NS ns.domeniul1.
    domeniul 1. ÎN NS ns.domeniul1.
    ns.domeniu1. ÎN A 10.1.1.1
    
    2.10.in-addr.arpa. ÎN NS ns.domeniul2.
    domeniul 2. ÎN NS ns.domeniul2.
    ns.domeniu2. ÎN A 10.2.1.1
    
    3.10.in-addr.arpa. ÎN NS ns.domeniul3.
    domeniul 3. ÎN NS ns.domeniul3.
    ns.domeniu3. ÎN A 10.3.1.1
    

    și așa mai departe pentru toate rețelele.

Totul funcționează bine, dar există o mică problemă.

Uneori, serverul DNS pentru o anumită rețea este oprit. În aceste rețele, serverul DNS este oprit nu considerat un eșec - este doar o stare normală de funcționare care se poate întâmpla. Este de așteptat și normal ca în acel moment să nu existe o rezoluție DNS pentru acea rețea.

Dar există o anumită adresă IP în rețeaua 1 (să zicem, 10.1.10.10) că vreau mereu pentru a rezolva un nume de domeniu - chiar și atunci când DNS-ul pentru rețeaua 1 este inactiv. Deci trebuie rezolvat de serverul local, nedelegat serverului pentru rețeaua 1. De fapt, este de asemenea acceptabil ca NXDOMAIN să fie returnat ca răspuns la interogarea pentru această adresă (dacă aceasta este mai ușor de configurat), dar răspunsul trebuie returnat imediat, fără a încerca să contactăm serverul DNS pentru rețeaua 1 - întârzierea când acel server este în defect este exact ceea ce vrem să evităm.

Și nu știu cum să fac asta.

Adăugarea unei înregistrări PTR pentru 10.10.1.10.in-addr.arpa. la . Fișierul de zonă nu funcționează - pare să fie pur și simplu ignorat, iar când DNS-ul pentru rețeaua 1 nu funcționează, 10.1.10.10 nu este rezolvată.

Cum să rezolvi această adresă la nivel local?

vidarlo avatar
drapel ar
Asta mi se pare o problemă X-Y. Modul normal de a gestiona întreruperile serverului DNS este de a avea mai multe servere DNS. În plus, nu există niciun motiv pentru care un server nu poate avea mai multe vizualizări, astfel încât izolarea poate fi menținută cu un singur server DNS care deservește mai multe rețele.
raj avatar
drapel ye
raj
@vidarlo Am simplificat configurarea de dragul acestei întrebări - de fapt există de obicei 3 servere DNS pentru fiecare rețea. Dar este **de așteptat** ca **toți** să fie în jos. Acesta este modul în care funcționează rețeaua. Adresa unică de care sunt interesat este „specială” (îmi pare rău, nu pot dezvălui detalii) și, prin urmare, ar trebui să fie gestionată la nivel de server multi-homed, chiar dacă toate serverele DNS „subordonate” sunt nefuncționale.
raj avatar
drapel ye
raj
@vidarlo De asemenea, așa cum am scris, este **prin proiect** că fiecare rețea este independentă, deci nu poate exista un singur server DNS care să servească mai multe rețele. Rețelele **trebuie** să nu știe nimic una despre cealaltă. Serverul multi-homed este un strat suplimentar pe care l-am adăugat. Nu există „în câmp”. Vă puteți imagina că toate rețelele (inclusiv serverele lor DNS) sunt produse terțe asupra cărora nu aveți niciun control și nu puteți atinge nimic acolo. Controlați doar serverul multi-homed.
Puncte:0
drapel ye
raj

Am gasit o solutie. A fost de fapt simplu. A fost suficient să adaug 10.10.1.10.in-addr.arpa ca o altă zonă „master” pentru mine numit.conf fișier, cu fișierul zonei fiind numit.gol adică. fișierul implicit inclus în configurația BIND pentru a servi zona 0.in-addr.arpa.

Acum interogarea pentru 10.1.10.10 dă răspunsul că adresa nu are înregistrare PTR, indiferent dacă serverul DNS pentru 10.1.0.0/16 este sus sau jos. Asta elimină întârzierea la rezolvarea adresei, ceea ce este suficient pentru mine. Desigur, aș putea defini un fișier de zonă separat pentru această zonă în loc de numit.gol și adăugați în acest fișier de zonă o înregistrare PTR pentru @ pentru ca adresa IP să se rezolve într-adevăr la un nume de domeniu, dar nu am nevoie de asta acum.

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.