Проследете DNS заявката стъпка по стъпка, за да намерите истинския източник
Натрапеният адрес на резолвер не решава кой източник вижда резолвер. Проследете клиента, препращача и приемащия сървър, после запишете пътя.
Даването на адрес на резолвер на клиент определя накъде се изпращат заявките, а не кой източник ще види резолвер. Маршрутизацията, препращането и транслацията получават своя ред между двата края. Ръководството за въпроси за източника проследява заявката стъпка по стъпка и записва какво е видял всеки наблюдател в действителност. Редът е важен, защото твърдение, направено преди наблюдението, е само догадка в по-добро оформление.
Запишете подредбата, преди да събирате доказателства
Четири места могат да ви кажат нещо за DNS източник и не всички казват едно и също. Ядрото на клиента знае кой източник би използвало, препращачът знае какво е изпратил нагоре, устройството, което транслира, знае какво е презаписало, а приемащият резолвер знае какво е пристигнало. Запишете до кои от тях наистина можете да стигнете, преди да съберете каквото и да е.
| 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 |
Запишете и очакването си, включително резолвера, който смятате, че се използва. Разделен маршрут може да изпрати заявка съвсем другаде, а кешът може да отговори без никакъв обмен нагоре, затова предположение, държано само в паметта, няма да преживее първата изненада. Дръжте заявената схема и наблюдавания път в отделни колони на една и съща бележка; когато двете не съвпадат, намерили сте въпроса, който си заслужава да бъде проследен.
Проверете кой процес в действителност е изпратил заявката
Започнете от клиента: запишете адреса на резолвера, името на заявката и времето, после потвърдете кой процес я е изпратил. Първият ред по-долу назовава процеса, който държи UDP сокета, и това е проверката, която обещава това заглавие. Ако този процес е помощник на браузъра или среда за изпълнение на контейнер вместо системния резолвер, остатъкът от следата описва път, който никой не е поискал.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53На хост с няколко интерфейса първо разберете кой адрес на източника избира ядрото за тази дестинация, преди да гледате другаде. Това е последната точка, в която пътят е напълно под ваш контрол, и това е стойността, която ще сравните с онова, което съобщава резолверът. Разминаването е сигнал, че нещо по средата е презаписало пакета или че са изпратени две различни заявки.
Дръжте тестовите имена вътрешни, защото вътрешно име, изпратено до публичен резолвер, не доказва нищо за вътрешния път и публикува име, което не е трябвало да публикувате. Браузър с включен защитен DNS изобщо няма да се появи в този списък със сокети, и самото това отсъствие е отговорът.
Препращачът прави втора, отделна заявка
Препращачът превръща един обмен в два. Заявката отдолу пристига, а след това препращачът изпраща своята собствена заявка нагоре от адрес, който избира. Неговата конфигурация, а не клиентът, решава какво вижда горният резолвер.
Ръководството на dnsmasq си заслужава четенето точно поради тази причина: то документира как препращачът избира сървъри нагоре и обвързва своята страна за слушане, и нищо в тази подредба не носи източника на клиента нагоре. Затова журнал на резолвер, който показва адрес на шлюз, е нормален, а не доказателство за повреда. Отсъствието е също толкова лесно да се прочете погрешно, защото попадение в кеша не създава никаква заявка нагоре и изглежда идентично на заявка, която никога не е пристигнала. Прочетете конфигурацията на препращача и състоянието на кеша му, преди да направите който и да е от двата извода. Два въпроса, две места за гледане.
Прочетете източника на приемащия резолвер
Единственото наблюдение, което решава това, се прави от страната на сървъра. Всичко, изведено от списъка с интерфейси на клиента, остава хипотеза, докато резолверът не съобщи какво в действителност е пристигнало.
tcpdump -ni any port 53 and host 10.20.30.53Снимайте на хоста на резолвера, дръжте снимката кратка и ограничена и я съхранявайте там, където политиката позволява. Ако наблюдаваният източник е транслиран адрес, следващият въпрос е кое устройство е извършило транслацията и дали неговата политика е предвидената. Снимката отговаря какво е пристигнало; тя не обяснява защо политиката го е позволила. Назовете наблюдателя и стъпката в бележката, защото твърдение за поверителност относно шлюз се отнася до тази стъпка, а не до целия път.
Запишете находката като път, а не като адрес
Запишете клиента, резолвера, всеки препращач, наблюдавания източник на всяка стъпка и политиката, която го управлява. Такъв запис отговаря на повечето бъдещи въпроси без нова снимка. Начертайте го като верига, защото списъкът с адреси скрива коя стъпка е дала кой.
Приложете към чертежа датата, версията на клиента и ревизията на конфигурацията, за да може по-късен читател да каже дали тя все още е в сила. Отделете транспортния източник от всичко останало, което услугата обработва, защото гледката на адрес на шлюз не казва нищо за това какво друго се съхранява. Нито местоположението на резолвера казва нещо за това кой клиент е питал. Именно разделянето на тези твърдения прави извода защитим при преглед.