Puncte:0

ISC-DHCP și BIND 9 DNS: Actualizarea DDNS eșuează pentru subrețeaua /27

drapel ph

Am o problemă cu actualizarea DDNS cu serverul ISC-DHCP.

Secțiunea mea de subrețea /etc/dhcp/dhcpd.conf care nu funcționează este:

subrețea 193.198.186.192 mască de rețea 255.255.255.224 {
  gama 193.198.186.200 193.198.186.222; # MT 20211210
  opțiunea subnet-mask 255.255.255.224;
  opțiunea nume-domeniu-servere 161.53.235.3, 161.53.2.70;
  opțiune nume-domeniu „slava.alu.hr”;
  ddns-domainname "slava.alu.hr";
  zona slava.alu.hr. {
   primar 127.0.0.1;
   cheie DDNS_UPDATE;
  }
  zona 192-27.186.198.193.in-addr.arpa. {
   primar 127.0.0.1;
   cheie DDNS_UPDATE;
  }
  opțiune broadcast-adresa 193.198.186.223;
  routere opționale 193.198.186.193;
  default-lease-time 43200;
  max-lease-time 86400;
}

Delegația mea de rețea pentru 193.198.186.192/27 este un 192/27.186.198.193.in-addr.arpa literal. și nu par dispuși să o schimbe.

Vezi aici:

root@domac:~# gazdă -t orice 193.198.186.195
195.186.198.193.in-addr.arpa este un alias pentru 195.192/27.186.198.193.in-addr.arpa.
195.192/27.186.198.193.in-addr.arpa domain name pointer test-record.slava.alu.hr.
root@domac:~#

Acest lucru obligă intrarea mea /etc/bind/named.conf.local la:

zona „192/27.186.198.193.in-addr.arpa” în {
        tip master;
        fișierul „/var/cache/bind/192-27.186.198.193.in-addr.arpa.db”;
        allow-update { cheie DDNS_UPDATE; };
};

Cu toate acestea, ISC DHCPd consideră un „/” în numele zonei o eroare de sintaxă.

Există vreo modalitate de a spune fie BIND, fie ISC DHCPd să accepte nume diferite în declarațiile de zonă /etc/bind/named.conf.local și /etc/dhcp/dhcpd.conf?

Când schimb declarația în dhcpd.conf în:

  zona 186.198.193.in-addr.arpa. {
   primar 127.0.0.1;
   cheie DDNS_UPDATE;
  }

și /etc/bind/named.conf.local intrare la:

zona „186.198.193.in-addr.arpa” în {
        tip master;
        fișierul „/var/cache/bind/192-27.186.198.193.in-addr.arpa.db”;
        allow-update { cheie DDNS_UPDATE; };
};

apoi actualizarea dinamică DHCPd funcționează:

Dec 10 15:42:59 domac dhcpd[11512]: DHCPREQUEST pentru 193.198.186.211 de la e8:48:b8:5b:8c:46 (LAPTOP-MTODOROV) prin 193.198.186.193
10 decembrie 15:42:59 domac dhcpd[11512]: DHCPACK pe 193.198.186.211 la e8:48:b8:5b:8c:46 (LAPTOP-MTODOROV) prin 193.198.186.193
Dec 10 15:42:59 domac dhcpd[11512]: A fost adăugată o nouă hartă înainte de la LAPTOP-MTODOROV.slava.alu.hr la 193.198.186.211
Dec 10 15:42:59 domac dhcpd[11512]: S-a adăugat harta inversă de la 211.186.198.193.in-addr.arpa. la LAPTOP-MTODOROV.slava.alu.hr

și îl pot vedea din domeniul serverului meu DNS:

root@domac:~# host laptop-mtodorov.slava.alu.hr
LAPTOP-MTODOROV.slava.alu.hr are adresa 193.198.186.211
root@domac:~# gazdă -t orice 193.198.186.211
211.186.198.193.in-addr.arpa indicator pentru nume de domeniu LAPTOP-MTODOROV.slava.alu.hr.
root@domac:~#

... dar acum delegația DNS este spartă. Nu pot avea întregul 186.198.193.in-addr.arpa. zona pentru subrețeaua domeniului nostru și nici nu vor aproba actualizări dinamice pe serverul DNS central.

Se pare că nu le am pe ambele, cu excepția cazului în care există o modalitate de a instrui DHCP sau BIND să adauge la o zonă cu un nume diferit în BIND față de cel din DHCP.

Se pare că rămân fără opțiuni.

Vă mulțumesc foarte mult dacă știți un răspuns.

Salutări calde, Marvin

P.S.

Am incercat urmatoarele si nu a mers:

zona „192-27.186.198.193.in-addr.arpa” în {
        tip master;
        fișierul „/var/cache/bind/192-27.186.198.193.in-addr.arpa.db”;
};

zona „186.198.193.in-addr.arpa” în {
        tip master;
        fișierul „/var/cache/bind/192-27.186.198.193.in-addr.arpa.db”;
        allow-update { cheie DDNS_UPDATE; };
};

(Două zone cu același fișier.)

Ce am primit a fost:

root@domac:/etc/bind# named-checkconf
/etc/bind/named.conf.local:49: fișier care poate fi scris „/var/cache/bind/192-27.186.198.193.in-addr.arpa.db”: deja în uz: /etc/bind/named.conf .local:44
root@domac:/etc/bind#

Bună încercare :-( Programatorii au fost suficient de inteligenți pentru a preveni acest hack!

Orice idee despre cum să faci două zone să se refere la aceeași bază de date de zonă, una care se potrivește cu zona de delegare alocată și cealaltă care se potrivește cu 186.198.193.in-addr.arpa zonă pe care ISC DHCP știe doar să o actualizeze?

  1. Am încercat chiar să atașez 192/27.186.198.193.in-addr.arpa între ghilimele pentru a evita eroarea de sintaxă și am primit asta:

    Dec 10 23:17:45 domac dhcpd[26555]: /etc/dhcp/dhcpd.conf linia 187: aștept numele gazdă. 10 decembrie 23:17:45 domac isc-dhcp-server[26545]: /etc/dhcp/dhcpd.conf linia 187: aștept numele gazdă. Dec 10 23:17:45 domac isc-dhcp-server[26545]: zona „192/27.186.198.193.in-addr.arpa”. 10 decembrie 23:17:45 domac isc-dhcp-server[26545]: ^ 10 decembrie 23:17:45 domac isc-dhcp-server[26545]: erori în fișierul de configurare întâlnite -- ieșire Dec 10 23:17:45 domac isc-dhcp-server[26545]: se iese. Dec 10 23:17:45 domac dhcpd[26555]: zona "192/27.186.198.193.in-addr.arpa."

Deci, nici asta nu a funcționat. Singura speranță este găsirea unei modalități de a utiliza aceeași bază de date de zone DNS cu două nume de zone. Nu este un caz atât de rar, presupun, ar trebui să existe o prevedere pentru un astfel de caz?

Marvin

Patrick Mevzek avatar
drapel cn
Vedeți din nou RFC2317 pentru delegația fără clasă in-addr.arpa. Numai înregistrările CNAME ar trebui să aibă numele cu `/` care este apoi legitim pentru un CNAME, dar într-adevăr nu este legitim pentru un NS (delegare). Dacă aveți un CNAME la `129.128/26.2.0.192.in-addr.arpa.` zona de delegat este `2.0.192.in-addr.arpa`.` Deci, în cazul dvs., delegarea ar trebui să fie pentru `186.198.193 .in-addr.arpa` nu `192/27.186.198.193.in-addr.arpa` și apoi ajustați, desigur, înregistrările de resurse din el.
mt42 avatar
drapel ph
Am înțeles că DHCP dorește să actualizeze `186.198.193.in-addr.arpa` și nu poate gestiona sintactic `192/27.186.198.193.in-addr.arpa`. Dar am fost delegat `192/27.186.198.193.in-addr.arpa` de la administratorii de nivel superior și nu pot schimba asta. Nu pot actualiza dinamic nici în zona respectivă. M-am gândit la două nume de zone care partajează aceeași bază de date de fișiere... O zonă definită pentru delegare și numai citire, iar cealaltă pentru actualizări DDNS de la DHCP cu aceeași bază de date. Va permite BIND 9.1.5 un astfel de hack? Citesc referința BIND, dar nu a apărut un astfel de caz...
mt42 avatar
drapel ph
Nu pot actualiza dinamic sau în alt mod `186.198.193.in-addr.arpa` deoarece nu sunt proprietar și nici nu am permisiunea de actualizări dinamice în zona respectivă. Este împărtășită de mai multe organizații. Trebuie să mă gândesc la o soluție. Problema este deoarece adresele IP publice, non-NAT sunt atribuite prin NAT.
mt42 avatar
drapel ph
Si eu sunt delegat `192/27.186.198.193.in-addr.arpa` de la nivelul superior si nici asta nu pot schimba. Trebuie să mă gândesc să folosesc ambele nume pentru aceleași date de zonă, unul doar pentru citire și celălalt actualizat dinamic de ISC DHCP.
Patrick Mevzek avatar
drapel cn
„Nu pot să actualizez dinamic sau altfel 186.198.193.in-addr.arpa, deoarece nu sunt proprietar și nici nu am permisiunea de actualizări dinamice în acea zonă. Este partajat de mai multe organizații.” De ce se ocupă exact RFC2317. Aruncă o privire.
Patrick Mevzek avatar
drapel cn
De asemenea, puteți utiliza orice nume de zonă și puteți înlocui `/` cu `-` dacă este mai simplu pentru cazul dvs. de utilizare. Este precizat în RFC: Exemplele de aici folosesc „/” deoarece s-a simțit a fi mai vizibil și recenzenții pedanți au considerat că argumentul „acestea nu sunt nume de gazdă”. trebuia repetat. Vă sfătuim să nu fiți atât de pedant și să faceți nu copiați exact exemplele de mai sus, de ex. înlocuiți un mai mult caracter conservator, cum ar fi cratima, pentru „/”. . Notați „numele de gazdă” astfel încât să explice de ce nu le puteți utiliza ca nume de gazdă mai târziu, asta intenționat.
Patrick Mevzek avatar
drapel cn
„M-am gândit la două nume de zone care partajează aceeași bază de date de fișiere...” Puteți, dar nu cu actualizări dinamice.
mt42 avatar
drapel ph
Până când apare o soluție mai bună, am folosit soluția descrisă aici: https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update Mulțumesc oricum, Patrick!
mt42 avatar
drapel ph
Am citit RFC 2317 în întregime, dar nu dețin zona de delegare, așa că nu pot schimba sau înlocui `/` cu `-`. Am fost forțat să actualizez dinamic o zonă auxiliară și să deleg înregistrările CNAME din zona delegată în zona auxiliară actualizată dinamic. Dar aceasta este o soluție și un truc. Rezolvatorii sunt uneori confundați cu mai multe redirecționări CNAME. O soluție reală ar fi actualizarea sursei DHCP pentru a adăuga o directivă de alias de zonă (între ghilimele, astfel încât să poată procesa sintactic `/`), astfel încât să poată actualiza zone precum `192/27.186.198.193.in-addr.arpa`.
mt42 avatar
drapel ph
Directiva de alias de zonă este doar un gând care a avut loc, orice metodă de actualizare a subrețelelor sub /24 ar face :-)

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.