Логирование DNS клиента

я бы через iptables попробовал пособирать статистику по пакетам.

iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
iptables -I INPUT -p udp --sport 53 -j ACCEPT

Смотреть через `iptables -L -v -n |grep 53`

И, кстати, проверьте, не пропадают ли фреймы на канальном уровне:

ip -s link show dev eth0

А чем это отличается от способа с tcpdump? Кроме как автозапуском?

Правильно ли я понимаю что в моем случае если запрос посылается двумя пакетами то в логах будут две записи?

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 49794197 212204 0 0 0 0 TX: bytes packets errors dropped carrier collsns 186769477 297548 0 0 0 0

Вроде все пучком

Вообще соглашение о том какие потери допустимы определяется договором. В литературе это называется SLA (Service Layer Agreement). Посмотри что у тебя в договоре написано. А так, вообще комстар в последних договорах писал «не более 1%», но вообще это кто как придумает.

Я не знаю есть ли на это нормы, один препод на учебе говорил что в нашем «Царстве» это не оговорено... :(

Имхо, я бы тоже пошел доказывать через tcpdump, но сложил бы логи и принятых и отправленных пакетов в один файл. Достать из него лог входящих или исходящих пакетов - просто:

grep «> 10.1.100.34» dns.log -это ответы, добавишь -v будут запросы :), добавить | wc -l - получишь количество :)

Зато потом можно будет прямо носом тыкать что «вот смотрите запрос, а вот уже следующий» чем в два файла смотреть и время сравнивать.

Только хочется спросить, а проблемы с самим dns-ом или с доступностью сервера ? Может чем ругаться с провом - завести локальный DNS ?

Вообще конечно интересный для меня прецедент, не приходилось ещё ругаться с операторами :)

Может я не прав, надеюсь меня поправят, но мне кажется что tcpdump дампит пофреймово, а iptables считает по ip-пакетам, а это не одно и то же. Вероятно я не прав в этом вопросе :) Но iptables мне как-то привычнее

Да, то сообщения улетают кусками - маловероятно, у тебя MTU на линке 1500, имхо сложно придумать имя на 1500 байт, думаю что можешь смело считать количество пакетов за количество запросов :)

Через других операторов эти же имена нормально разрешаются ? А то может резолвишь что-нибудь типа su.per.mega.bolshoi.uroven.ru ?

фрейм - это, если по дуратски говорить, пакет в ethernet если на ip интерфейсе стоит mtu 1500 то один ip пакет влезет в один фрейм. Да и вообще, господа, не парьтесь с этим - 1500 байт это много много много :)

grep «> 10.1.100.34» - хитро. Я сразу не догадался со значком «>» сделать. спасибо за наводку.

Но главный чайницкий вопрос: одна запись в логе это один запрос/ответ или нет? Просто хотелось бы заранее эти нюансы выяснить чтобы не выглядеть уж полным лохом. И иметь «доказательства» а не предположения.

Можно и так только я бы сделал так:

iptables .... -j LOG --log-prefix DNSDEBUG

и смотрел бы потом статистику: grep DNSDEBUG /var/log/messages но из tcpdump меня больше прильщает :)

Имеются проблемы с интернетом и очевидно из-за того что DSN сервера провайдера

А что другой dns нельзя использовать ?

Если у тебя не DNS сервер а только клиент то один пакет - один запрос. один входящий - один ответ. При условии что работает через UDP. В логе протокол tcp или udp показывает. Да и в логе ведь всё видно что там в пакете (tcpdump слегка разбирает данные в пакете).

настрой себе BIND и пусть он общается напрямую с корневыми DNS серверами, нафиг тебе провайдерский

А что другой dns нельзя использовать ?

А за что я тогда плачу деньги? Чтобы использовать «левый» сервак? А вдруг он мне адреса на поддельные сайты начнёт выдавать? Я не параноик но за каждую уплаченную копейку вытрясу душу. Не так легко они достаются чтобы так разбрасываться.

попробуй поискать локальный серврер умеющий вести, скажеш ему перенаправлять запросы на сервера провайдера, таким образом получиш статистику, а вообще поставил бы действительно локальный сервер и не парился, на узких каналах если которые еще как правило перегружены днс запросы основной тормоз получаются, локальный кеш в таких случаях очень кстати.

попробуй поискать локальный серврер умеющий вести статистику... слово пропустил:)

Если у тебя не DNS сервер а только клиент то один пакет - один запрос. один входящий - один ответ. При условии что работает через UDP. В логе протокол tcp или udp показывает. Да и в логе ведь всё видно что там в пакете (tcpdump слегка разбирает данные в пакете).

Ну например:

14:12:49.047079 IP 10.1.100.34.37199 > 82.209.243.241.53: 55418+ A? build.sectokyo.com. (36)
14:12:49.322372 IP 10.1.100.34.52478 > 82.209.243.241.53: 52792+ A? build.sectokyo.com. (36)
14:12:54.458241 IP 10.1.100.34.46363 > 82.209.243.241.53: 41148+ A? build.sectokyo.com. (36)
14:12:54.748016 IP 10.1.100.34.43230 > 82.209.243.241.53: 15462+ A? build.sectokyo.com. (36)

Вот подобные куски в логе начали у меня вызывать сомнения которыми я поделился. Это один запрос или 4?

настрой себе BIND и пусть он общается напрямую с корневыми DNS серверами, нафиг тебе провайдерский

Наверное ты прав. Проще взвалить все на свои плечи чем заставить кого-то выполнять свои обязательства. Но дать звездюлей халтурщикам - святое дело.

Ну или вот так:


15:16:45.418501 IP 10.1.100.34.46021 > 82.209.243.241.53: 60169+ A? build.sectokyo.com. (36)

15:16:50.423618 IP 10.1.100.34.51419 > 82.209.240.241.53: 60169+ A? build.sectokyo.com. (36)

15:16:55.428697 IP 10.1.100.34.46021 > 82.209.243.241.53: 60169+ A? build.sectokyo.com. (36)

15:17:00.433118 IP 10.1.100.34.51419 > 82.209.240.241.53: 60169+ A? build.sectokyo.com. (36)

15:17:00.450933 IP 82.209.240.241.53 > 10.1.100.34.51419: 60169 1/2/1 A 182.48.35.91 (117)


Это ответ на последний запрос или на последовательность из 4-х пакетов? или на последовательность пакетов 2 и 4 ?

очень похоже на 4 разных запроса

ИМХО, достаточно было один раз им сообщить о проблеме. Если они не отреагировали, то либо меняешь провайдера, либо настраиваешь свой локальный днс, если по другим критериям этот провайдер тебя устраивает

ИМХО, достаточно было один раз им сообщить о проблеме. Если они не отреагировали, то либо меняешь провайдера, либо настраиваешь свой локальный днс, если по другим критериям этот провайдер тебя устраивает

Сразу видно что ты не из Беларуси.

15:16:45.418501 IP 10.1.100.34.46021 > 82.209.243.241.53: 60169+ A? build.sectokyo.com. (36)

0сек - твой хост шлет запрос на первый DNS-сервер 243.241 (1)

15:16:50.423618 IP 10.1.100.34.51419 > 82.209.240.241.53: 60169+ A? build.sectokyo.com. (36)

+5мс - шлет запрос на другой DNS-сервер 240.241 (2)

15:16:55.428697 IP 10.1.100.34.46021 > 82.209.243.241.53: 60169+ A? build.sectokyo.com. (36)

+10мс - повторяет запрос N1

15:17:00.433118 IP 10.1.100.34.51419 > 82.209.240.241.53: 60169+ A? build.sectokyo.com. (36)

+15мс - повторяет запрос N2

15:17:00.450933 IP 82.209.240.241.53 > 10.1.100.34.51419: 60169 1/2/1 A 182.48.35.91 (117)

+32мс - наконец приходит ответ от (2); на какой именно из двух запросов был этот ответ скорее всего никак не узнать, да это и неважно

Включив полное логирование я убедился что да - это отдельные запросы. И результаты совсем неутешительны.

# cat dns.log | grep -v «> 10.1.100.34» | wc -l 369 # cat dns.log | grep «> 10.1.100.34» | wc -l 78

Соотношение подтвердило мои опасения.

Спрашивает он одно и тоже но у двух разных серверов. Время измеряется не в миллисекундах а в секундах. И через 32 секунды приходит ответ - это офигенно долго floppy-net

Можешь чисто с этим логом к прову и идти.