înregistrare Logare
Puncte:-1
avatar Server

bind9: redirecționarea către serverul de nume local nu funcționează când conexiunea la internet este întreruptă

drapel cz
p.g.

Am urmatoarea configuratie:

O instanță bind9 (denumită mai jos L) pe hardware foarte limitat pentru rezolvarea numelor din rețelele mele locale. Este un maestru autorizat pentru zona home.mydomain.com. Interogările către acest server funcționează și returnează homedns.home.mydomian.com ca NS și IP-ul 192.168.1.77 al acestuia ca înregistrare suplimentară.

O instanță bind9 (denumită mai jos M) pentru a rezolva numele de internet și locale. Nu este utilizată nicio opțiune globală de redirecționare aici. Există o zonă înainte configurată:

zona „home.mydomain.com” în {
        tastați înainte;
        numai înainte;
        expeditori { 192.168.1.77; };
};

Notă 1: mydomain.com este un domeniu existent, înregistrat, dar nu există nicio înregistrare pentru home.mydomain.com

Nota 2: Versiunea bind9 a lui M este foarte veche: 9.8.1-P1

Această configurare funcționează atâta timp cât conexiunea la internet este activată, dar interogările de nume locale nu primesc răspuns când conexiunea este întreruptă. Log este syslog este

30 august 09:05:42 M numit[1611]: eroare (fără DS valid) la rezolvarea „xxx.home.mydomain.com/A/IN”: 192.168.1.77#53

Capturarea rețelei pentru o rezolvare de succes atunci când conexiunea este întreruptă dezvăluie că M interogează pentru mydomain.com pe internet după ce a primit răspunsul de la L. În răspunsul de la M către client se modifică SECȚIUNEA DE AUTORITATE:

sapa la L:

;; SECȚIUNEA RĂSPUNSURI:
syslog.home.mydomain.com. 3600 IN A 192.168.1.99

;; SECȚIUNEA AUTORITATE:
home.mydomain.com. 3600 ÎN NS homedns.home.mydomain.com.

;; SECȚIUNE SUPLIMENTARĂ:
homedns.home.mydomain.com. 3600 IN A 192.168.1.77

sapa la M:

;; SECȚIUNEA RĂSPUNSURI:
syslog.home.mydomain.com. 2134 IN A 192.168.1.99

;; SECȚIUNEA AUTORITATE:
net. 171334 ÎN NS j.gtld-servers.net.
net. 171334 ÎN NS m.gtld-servers.net.
net. 171334 ÎN NS i.gtld-servers.net.
net. 171334 ÎN NS k.gtld-servers.net.
net. 171334 ÎN NS g.gtld-servers.net.
net. 171334 ÎN NS e.gtld-servers.net.
net. 171334 ÎN NS h.gtld-servers.net.
net. 171334 ÎN NS a.gtld-servers.net.
net. 171334 ÎN NS d.gtld-servers.net.
net. 171334 ÎN NS f.gtld-servers.net.
net. 171334 ÎN NS b.gtld-servers.net.
net. 171334 ÎN NS c.gtld-servers.net.
net. 171334 ÎN NS l.gtld-servers.net.

Nu înțeleg de ce M nu returnează doar răspunsul de la L către client și nu mai am idei, ce aș putea încerca să evit interogarea pe internet pentru zona redirecționată.

105
1 + 0
Puncte:0
avatar Server
drapel cn
Håkan Lindqvist

Intrarea de jurnal citată în întrebare sugerează că eroarea este legată de eșecul validării DNSSEC atunci când nu există conexiune la internet.

Rețineți partea „no valid DS” a mesajului de eroare:

30 august 09:05:42 M numit[1611]: eroare (fără DS valid) la rezolvarea „xxx.home.example.com/A/IN”: 192.168.1.77#53

Probabil că răspunsurile pentru interogările care lovesc această zonă înainte sunt în mod normal acceptate doar pentru că publicul exemplu.com zona există ca zonă nesemnată (adică, există dovada nr DS ca parte a delegării propriei exemplu.com zone), dar când această dovadă nu mai poate fi preluată deoarece nu există conexiune la internet, răspunsurile nu mai pot fi acceptate, deoarece nu mai este posibil să se verifice dacă/cum trebuie semnate acestea.

O opțiune ar fi semnarea home.example.com zonă și adăugați o static ancoră de încredere special pentru această zonă.

O alta ar fi dezactivarea selectivă a validării; curentul BIND are a validare-cu excepția opțiune care vă permite să specificați o listă de nume de domenii în care nu trebuie efectuată nicio validare, conform:

validare-cu excepția

Aceasta specifică o listă de nume de domenii la și sub care validarea DNSSEC nu ar trebui efectuată, indiferent de prezența unei ancori de încredere la sau deasupra acestor nume. Aceasta poate fi folosită, de exemplu, la configurarea unui domeniu de nivel superior destinat doar utilizării locale, astfel încât lipsa unei delegări securizate pentru acel domeniu în zona rădăcină să nu cauzeze eșecuri de validare. (Acest lucru este similar cu setarea unei ancore de încredere negative, cu excepția faptului că este o configurație permanentă, în timp ce ancorele de încredere negative expiră și sunt eliminate după o anumită perioadă de timp.)

Există, de asemenea, posibilitatea de a dezactiva complet validarea folosind dnssec-validare opțiune, pe care nu aș recomanda-o dacă această instanță BIND are o utilizare mai largă decât acest forward specific.

(Rețineți că am înlocuit numele de domeniu folosit în întrebare cu exemplu.com deoarece pare puțin probabil ca întrebarea să aibă vreo legătură cu numele de domeniu la care face referire sau cu afacerea care o deține.)

0 + 2
drapel cz
p.g.
Aceasta pare o explicație excelentă pentru problemă. Din păcate, versiunea foarte veche de bind 9.8.1 nu acceptă validate-except și documentul de pe bind9.readthedocs.io nu mai acoperă versiunea. Momentan, nu pot verifica soluția. O actualizare la cel mai recent Ubuntu LTS este planificată pentru sfârșitul acestui an. Probabil că trebuie să aștept până atunci.
0
Răspunde
drapel cz
p.g.
Cea mai recentă versiune Bind9 împreună cu validate-except rezolvă problema perfect.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.