nevoie de sfaturi de arhitectură Bind9

Am nevoie de sfaturile voastre pentru o arhitectură DNS.

Această schemă descrie arhitectura DNS așa cum cred că o construiesc:

Arhitectura DNS

În compania mea, fiecare desktop-uri/laptop-uri sunt configurate cu DNS-ul LAN (10.1.1.1), care este un Microsoft AD/DNS și nu am mâna pe el. Alte DNS sunt Bind9 unde eu sunt administrator.Scopul meu este de a adăuga alte servere DNS pentru proiecte noi (într-o rețea separată) fără a schimba nimic pe laptopuri și pe LAN DNS și, desigur, vreau ca laptopurile dezvoltatorilor (în LAN) să poată interoga și să primească răspuns pentru fqdn-ul acelor proiecte noi. .

Din punct de vedere DNS (fqdn), există UN domeniu (project.com) și MULTE subdomenii (subX.project.com). Și fiecare subdomeniu este într-o rețea separată.

Exemplu: pe fiecare vlan, voi avea un server web și vreau să răspundă la subdomeniul său DNS:

web.project.com --> pentru serverul web al zonei de proiect.
web.sub1.project.com --> pentru serverul web al zonei de sub-proiect
web.sub2.project.com ....

Deci, înțelegerea mea despre Bind9, îmi permite să cred că serverul LAN DNS (10.1.1.1) poate redirecționa cereri către serverul DNS al proiectului (10.100.1.1). Și DNS-ul proiectului poate redirecționa cereri către serverele DNS ale sub-proiectului (10.200.1.1 / 10.250.1.1).

În cele din urmă, toate VM-urile unei rețele pot rezolva fqdn-ul public dacă DNS-ul zonei își transmite cererile către DNS-ul de nivel superior. Vreau doar să reafirm că nu am mâna pe DNS-ul principal (în LAN).

Mai jos, veți găsi named.conf.options fișier care reprezintă arhitectura descrisă în schema:

• DNS project.com (10.100.1.1/10.100.1.2)

{
    allow-query { 127.0.0.1; 10.1.1.1; 10.1.1.2; 10.200.1.1; 10.200.1.2; 10.250.1.1; 10.250.1.2; 10.100.1.0/24; };
    recursivitate da;
    anunta da;
    permit-transfer { 10.100.1.2; }; # sclavul
    expeditori {
        10.1.1.1;
        10.1.1.2;
    };
}

• DNS sub1.project.com (10.200.1.1/10.200.1.2)

{
    allow-query { 127.0.0.1; 10.100.1.1; 10.100.1.2; 10.200.1.0/24; }; interogări de la VM din această rețea și DNS din zona superioară
    recursivitate da;
    anunta da;
    permite-transfer { 10.200.1.2; };
    expeditori {
        10.100.1.1;
        10.100.1.2;
    };
}

• DNS sub2.project.com (10.250.1.1/10.250.1.2)

{
    allow-query { 127.0.0.1; 10.100.1.1; 10.100.1.2; 10.250.1.0/24; }; interogări de la VM din această rețea și DNS din zona superioară
    recursivitate da;
    anunta da;
    permit-transfer { 10.250.1.2; };
    expeditori {
        10.100.1.1;
        10.100.1.2;
    };
}

Ce parere aveti despre aceasta arhitectura? Vedeți dezavantaje, greșeli sau neînțelegeri?

Salutari.

Scopul meu este de a adăuga alte servere DNS pentru proiecte noi (într-o rețea separată) fără a schimba nimic pe laptopuri și pe LAN DNS și, desigur, vreau ca laptopurile dezvoltatorilor (în LAN) să poată interoga și să primească răspuns pentru fqdn-ul acelor proiecte noi. .

Doar faceți-vă principalele servere DNS să delege, prin NS înregistrări, un subdomeniu ca proiect1.example.com la serverele dvs. de nume, după care controlați această zonă (de aici totul de mai jos). Și comportamentul recursiv normal în timpul rezolvării numelor va începe fără nicio configurație specifică.

Se pare că confundați rolurile recursive și cele de autoritate ale serverelor de nume. Acestea nu se amestecă. Ar trebui să evitați (în timp ce puteți din punct de vedere tehnic, cu software precum dnsmasq sau chiar nelegat) un server care acționează ca recursiv în general, dar cu autoritate pentru unele nume. Faceți delegații adecvate și aveți un arbore semnificativ și nu veți avea probleme ciudate. Ar trebui să evitați pe cât posibil interogările „redirecționate”.

Setul dvs. de exemple de configurare face doar o rețea de servere de nume recursive, acestea nu sunt autorizate pentru nimic, deci nu este calea de urmat. Faceți delegații.