Volg de DNS-query hop voor hop om de echte bron te vinden
Een doorgeschoven resolveradres bepaalt niet welke bron de resolver ziet. Volg de client, de forwarder en de ontvangende server en schrijf het pad op.
Een client een resolveradres geven bepaalt waar queries naartoe gaan, niet welke bron de resolver zal zien. Routing, doorsturen en vertalen krijgen elk een beurt tussen de twee uiteinden. Een runbook voor bronvragen volgt de query hop voor hop en legt vast wat elke waarnemer werkelijk zag. De volgorde is van belang, want een bewering vóór de waarneming is gewoon een gok met betere opmaak.
Schrijf de opzet op voordat je bewijs verzamelt
Vier plaatsen kunnen je iets over een DNS-bron vertellen, en ze vertellen niet allemaal hetzelfde. De clientkernel weet welke bron hij zou gebruiken, een forwarder weet wat hij upstream heeft gestuurd, een vertalend apparaat weet wat het heeft herschreven, en de ontvangende resolver weet wat er is aangekomen. Schrijf op welke daarvan je werkelijk kunt bereiken voordat je iets verzamelt.
| 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 |
Schrijf ook je verwachting op, inclusief de resolver waarvan je denkt dat die in gebruik is. Een splitroute kan een query heel ergens anders heen sturen, en een cache kan antwoorden zonder enige upstream-uitwisseling, dus een aanname die alleen in het geheugen zit, overleeft de eerste verrassing niet. Houd het opgegeven ontwerp en het waargenomen pad in aparte kolommen van dezelfde notitie; als de twee het oneens zijn, heb je de vraag gevonden die de moeite waard is.
Controleer welk proces de query werkelijk heeft verstuurd
Begin bij de client: noteer het resolveradres, de querynaam en de tijd en bevestig dan welk proces hem heeft verstuurd. De eerste regel hieronder noemt het proces dat de UDP-socket vasthoudt, en dat is de controle die deze kop belooft. Is dat proces een browserhulp of een container-runtime in plaats van de systeemresolver, dan beschrijft de rest van de trace een pad waar niemand om vroeg.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Zoek op een host met meerdere interfaces eerst uit welke bronadres de kernel voor die bestemming kiest, voordat je ergens anders kijkt. Dat is het laatste punt waar het pad volledig onder jouw controle is, en het is de waarde die je vergelijkt met wat de resolver meldt. Een verschil is het signaal dat iets ertussen het pakket heeft herschreven, of dat er twee verschillende queries zijn verstuurd.
Houd de testnamen intern, want een interne naam die naar een openbare resolver gaat, bewijst niets over het interne pad en publiceert een naam die je niet hoefde te publiceren. Een browser met beveiligde DNS aan verschijnt helemaal niet in die socketlijst, en dat ontbreken is zelf het antwoord.
De forwarder doet een tweede, aparte query
Een forwarder maakt van één uitwisseling twee. Het downstreamverzoek komt aan, en de forwarder stuurt dan zijn eigen query upstream vanaf een adres dat hij kiest. Zijn configuratie, niet de client, bepaalt wat de upstreamresolver ziet.
De dnsmasq-handleiding is om die reden de moeite waard: hij documenteert hoe een forwarder upstreamservers kiest en zijn luisterzijde bindt, en niets in die opzet draagt de clientbron upstream. Een resolverlog met een gatewayadres is dus normaal en geen bewijs van een fout. Afwezigheid is net zo makkelijk verkeerd te lezen, want een cachetreffer levert geen upstreamquery op en ziet er precies zo uit als een query die nooit aankwam. Lees de forwarderconfiguratie en de cachestatus voordat je een van beide conclusies trekt. Twee vragen, twee plaatsen om te kijken.
Lees de bron bij de ontvangende resolver
De enige waarneming die dit beslecht, wordt aan de serverkant gedaan. Alles wat uit de interfacelijst van de client wordt afgeleid, blijft een hypothese tot de resolver meldt wat er werkelijk is aangekomen.
tcpdump -ni any port 53 and host 10.20.30.53Leg vast op de resolverhost, houd de opname kort en beperkt en bewaar hem waar het beleid dat toestaat. Is de waargenomen bron een vertaald adres, dan is de volgende vraag welk apparaat de vertaling heeft gedaan en of zijn beleid het bedoelde is. Een opname beantwoordt wat er is aangekomen; zij verklaart niet waarom het beleid het heeft toegestaan. Noem de waarnemer en de hop in de notitie, want een privacybewering over een gateway is een bewering over die hop en niet over het hele pad.
Schrijf de bevinding op als pad, niet als adres
Noteer de client, de resolver, elke forwarder, de waargenomen bron bij elke hop en het beleid dat die beheerst. Die registratie beantwoordt de meeste toekomstige vragen zonder nog een opname. Teken hem als een keten, want een lijst met adressen verbergt welke hop welke heeft opgeleverd.
Voeg datum, clientversie en configuratierevisie toe aan de tekening, zodat een latere lezer kan zien of zij nog geldt. Scheid de transportbron van al het andere dat de dienst verwerkt, want een gatewayadres zien zegt niets over wat er verder wordt bewaard. Een resolverlocatie zegt ook niets over welke client heeft gevraagd. Die beweringen uit elkaar houden is wat de conclusie onder herziening verdedigbaar maakt.