Как работает утилита DIG во FreeBSD и BIND?
Я хочу знать, как действительно работает команда DIG (Domain Information Groper), когда дело касается кода и реализации. Я имею в виду, когда мы вводим команду DIG, какая часть кода в FreeBSD или BIND попадает первой.
В настоящее время я вижу, что когда я нажимаю команду DIG, я вижу, что элемент управления переходит в файл client.c. Внутри этого файла вызывается следующая функция:
статическая пустота client_request (isc_task_t * задача, isc_event_t * событие);
Но как элемент управления достигает этого места, все еще остается для меня большой загадкой, даже после того, как я много копался в «именованной» части кода BIND.
Кроме того, я вижу, что эта функция вызывается из двух мест в этом файле. Я пытался поместить журналы в такие места, чтобы знать, достигает ли контроль этого места по этим путям, но, к сожалению, этого не происходит. Похоже, что функция Client_request () каким-то образом вызывается извне, и я не могу понять.
Есть ли здесь кто-нибудь, кто может помочь мне разгадать эту загадку?
Спасибо.
@nos Я хочу знать, где именно элемент управления достигает в named first, пока я даю команду «копать». Как я уже объяснял, в настоящее время я вижу, что элемент управления начинается с функции client_request () в файле client.c. Но как именно он туда попадает и откуда, я не могу понять.
Ваш вопрос очень расплывчатый. URL-адрес, который вы указываете как не связанный с dig, командной строкой (named и dig - это разные вещи). Вместо этого посмотрите на ftp.isc.org/isc/bind9/9.9.0rc1/bind-9.9.0rc1/bin/dig/dig.c. В любой программе на C ОС сначала вызывает функцию main, а затем все, что там происходит, определяет ход выполнения программы. См. Строку 1820 и последующие в предыдущей ссылке.
Ответы 2
Благодаря системе портов FreeBSD вы можете скомпилировать свой собственный BIND с включенной отладкой. Для этого беги
cd /usr/ports/dns/bind913/ && make install clean WITH_DEBUG=1
Затем вы можете запустить его в отладчике (lldb /usr/local/bin/dig), разорвать интересующую вас строку, а затем посмотреть на трассировку, чтобы выяснить, как элемент управления попал туда.
Не только для bind, но и для любой другой команды, в FreeBSD вы можете использовать ktrace, это очень многословно, но может помочь вам получить быстрый обзор того, как ведет себя программа.
Например, в последней версии FreeBSD у вас есть команда drill вместо dig, поэтому, если вы хотите знать, что происходит за кулисами, когда вы запускаете команду, вы можете попробовать:
# ktrace drill freebsd.org
Затем, чтобы отключить трассировку:
# ktrace -C
Once tracing is enabled on a process, trace data will be logged until either the process exits or the trace point is cleared. A traced process can generate enormous amounts of log data quickly; It is strongly suggested that users memorize how to disable tracing before attempting to trace a process.
После запуска ktrace drill freebsd.org должен быть создан файл ktrace.out, который можно прочитать с помощью kdump, например:
# kdump -f ktrace.out | less
Надеюсь, это «раскроет тайну», в вашем случае просто замените drill на dig, а затем используйте что-то вроде:
# ktrace dig freebsd.org
Вы также можете сделать это с помощью dig, используя порт bind-tools
Вы спрашиваете / отладку копаете или называете? (Dig просто отправляет DNS-запрос по сети на указанный сервер)