Urmărește interogarea DNS salt cu salt pentru a găsi sursa reală
O adresă de resolver impusă nu decide ce sursă vede resolverul. Urmărește clientul, forwarderul și serverul care primește, apoi notează traseul.
A da unui client o adresă de resolver stabilește unde se trimit interogările, nu ce sursă va vedea resolverul. Rutarea, forwardarea și traducerea au fiecare rândul lor între cele două capete. Un runbook pentru întrebările despre sursă urmărește interogarea salt cu salt și notează ce a văzut efectiv fiecare observator. Ordinea contează, pentru că o afirmație făcută înainte de observație este doar o presupunere cu formatare mai bună.
Notează aranjamentul înainte de a strânge dovezi
Patru locuri îți pot spune ceva despre o sursă DNS, și nu toate spun același lucru. Nucleul clientului știe ce sursă ar folosi, un forwarder știe ce a trimis în amonte, un dispozitiv care traduce știe ce a rescris, iar resolverul care primește știe ce a ajuns. Notează pe care dintre acestea le poți atinge efectiv înainte de a strânge ceva.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Notează și așteptarea ta, inclusiv resolverul despre care crezi că este în uz. O rută divizată poate trimite o interogare cu totul altundeva, iar un cache poate răspunde fără niciun schimb în amonte, așa că o presupunere ținută doar în memorie nu va supraviețui primei surprize. Ține proiectul declarat și traseul observat în coloane separate ale aceleiași note; când cele două nu sunt de acord, ai găsit întrebarea care merită urmărită.
Verifică ce proces a trimis efectiv interogarea
Începe cu clientul: notează adresa resolverului, numele interogat și ora, apoi confirmă ce proces a trimis-o. Prima linie de mai jos numește procesul care deține socketul UDP, iar aceasta este verificarea pe care o promite acest titlu. Dacă procesul respectiv este un helper de browser sau un runtime de container în locul resolverului de sistem, restul urmei descrie un traseu pe care nimeni nu l-a cerut.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Pe un host cu mai multe interfețe, află ce adresă sursă alege nucleul pentru acea destinație înainte de a te uita în altă parte. Este ultimul punct în care traseul este complet sub controlul tău, și este valoarea pe care o vei compara cu ce raportează resolverul. O nepotrivire este semnalul că ceva de la mijloc a rescris pachetul, sau că au fost trimise două interogări diferite.
Ține numele de test interne, pentru că un nume intern trimis la un resolver public nu dovedește nimic despre traseul intern și publică un nume pe care nu trebuia să-l publici. Un browser cu DNS securizat activat nu va apărea deloc în acea listă de socketuri, iar absența aceea este ea însăși răspunsul.
Forwarderul face o a doua interogare, separată
Un forwarder transformă un schimb în două. Cererea din aval ajunge, iar forwarderul trimite apoi propria interogare în amonte de la o adresă pe care o alege. Configurația lui, nu clientul, decide ce vede resolverul din amonte.
Manualul dnsmasq merită citit din acest motiv: documentează cum un forwarder alege serverele din amonte și își leagă partea de ascultare, iar nimic din acel aranjament nu duce sursa clientului în amonte. Un jurnal de resolver care arată o adresă de gateway este deci normal și nu o dovadă a unei erori. Absența este la fel de ușor de citit greșit, pentru că o lovitură de cache nu produce nicio interogare în amonte și arată identic cu o interogare care nu a ajuns niciodată. Citește configurația forwarderului și starea cache-ului său înainte de a trage oricare dintre cele două concluzii. Două întrebări, două locuri de privit.
Citește sursa la resolverul care primește
Singura observație care lămurește acest lucru este luată pe partea de server. Tot ce se deduce din lista de interfețe a clientului rămâne o ipoteză până când resolverul raportează ce a ajuns efectiv.
tcpdump -ni any port 53 and host 10.20.30.53Capturează pe hostul resolverului, ține captura scurtă și delimitată, și păstreaz-o acolo unde politica permite. Dacă sursa observată este o adresă tradusă, următoarea întrebare este ce dispozitiv a făcut traducerea și dacă politica lui este cea dorită. O captură răspunde la ce a ajuns; nu explică de ce politica a permis. Numește observatorul și saltul în notă, pentru că o afirmație despre confidențialitate privind un gateway este o afirmație despre acel salt, nu despre întregul traseu.
Scrie constatarea ca traseu, nu ca adresă
Notează clientul, resolverul, orice forwarder, sursa observată la fiecare salt și politica ce îl guvernează. Acea înregistrare răspunde la majoritatea întrebărilor viitoare fără o altă captură. Deseneaz-o ca un lanț, pentru că o listă de adrese ascunde care salt a produs-o pe care.
Atașează data, versiunea clientului și revizia configurației la desen, astfel încât un cititor ulterior să poată spune dacă mai este valabil. Separă sursa de transport de tot ce altceva procesează serviciul, pentru că a vedea o adresă de gateway nu spune nimic despre ce altceva este păstrat. Nici locația unui resolver nu spune nimic despre ce client a întrebat. A ține aceste afirmații separate este ceea ce face concluzia apărabilă în cadrul unei revizuiri.