dnsmasq aruncă un răspuns DNS privat: este protecția anti-rebinding?

Serverul DNS al companiei returnează adresa privată așteptată, iar totuși o interogare prin resolverul local de forwardare eșuează. Răspunsul există, ceea ce exclude zona din amonte și înregistrarea în sine. Rămâne pasul în care resolverul decide dacă returnează acel răspuns clientului. Dacă acel resolver este dnsmasq, respingerea este probabil deja în jurnal.

A primi un răspuns și a alege să îl returnezi sunt doi pași diferiți.

Comparați același nume pe ambii resolveri

Notați ce resolver folosește de fapt aplicația și numele exact de gazdă pe care îl interoghează. Apoi comparați rezultatul din amonte cu evenimentul resolverului de forwardare pentru același nume. Un răspuns din amonte lipsă, un răspuns negativ din cache și o respingere în jurnal necesită trei corecturi diferite.

O adresă vizibilă într-o interogare de diagnostic directă nu dovedește că aplicația a primit-o pe calea ei obișnuită. Cele două interogări pot pleca de la resolveri diferiți sau de la același resolver sub politici diferite. Notați ambele rezultate înainte de a teoretiza, pentru că în acest pas oamenii înlocuiesc unul cu celălalt. Comparația este întreaga diagnoză.

Citiți respingerea, nu simptomul

Opțiunea stop-dns-rebind din dnsmasq respinge răspunsurile cu adresă privată care îndeplinesc condițiile și vin din amonte, și le înregistrează în jurnal când o face. Această protecție există dintr-un motiv bun: un nume public care se rezolvă brusc la o adresă privată este atacul clasic de rebinding. Ea se intersectează însă și cu un serviciu intenționat privat, iar acesta este cazul dumneavoastră.

Căutați respingerea în jurnal înainte de a schimba ceva, pentru că mesajul numește mecanismul.

Dacă nu există nici respingere, nici răspuns din amonte, protecția anti-rebinding nu este problema dumneavoastră, iar dezactivarea ei ar fi o schimbare care nu repară nimic și lărgește expunerea. Este mai rău decât defecțiunea inițială, pentru că elimină un control și lasă defectul. Confirmați mai întâi linia specifică din jurnal. Apoi decideți.

Limitați excepția la un singur domeniu

Pentru un domeniu verificat, manualul dnsmasq oferă o excepție limitată la domeniu în locul unui comutator global.

rebind-domain-ok=corp.example

Domeniul de mai sus este doar ilustrativ. Folosiți domeniul administrativ pe care îl operați efectiv și înțelegeți sfera de potrivire a opțiunii înainte de a o aplica, pentru că o regulă de sufix acoperă mai mult decât gazda testată. Generatorul de configurație al unui router poate expune aceeași setare prin propriul control în loc de o directivă brută. Ambele căi sunt bune atât timp cât sfera rezultată este cea dorită.

O excepție de la detectarea rebindingului face exact un lucru: lasă să treacă răspunsurile acelui domeniu.

Ea nu configurează un forwarder split-DNS, nu face accesibil un amonte inaccesibil și nu creează o rută către adresa returnată. Fiecare dintre acestea este o cerință separată, cu propria semnătură de defect, și fiecare eșuează diferit în client.

Verificați fără a elimina granița

Interogați din nou numele de gazdă prin calea de forwardare, apoi conectați-vă la serviciu cu verificările lui obișnuite de identitate. O excepție DNS nu este un motiv să acceptați un certificat neașteptat, iar cele două defecte se confundă ușor când ambele apar ca eroare de browser. Testați numele și serviciul separat. Doar unul dintre ele a fost vreodată o problemă DNS.

Păstrați motivul excepției lângă configurație, cu o dată și un responsabil.

Verificați-o din nou când serviciul privat se mută sau domeniul se schimbă. Dezactivarea globală a protecției ar schimba modul în care sunt tratate răspunsurile fără legătură și ar lăsa totuși defectul de rută sau de serviciu pe loc dacă rebindingul nu a fost niciodată cauza.