我想知道DIG(Domain Information Groper(命令在代码和实现方面是如何工作的。我的意思是当我们输入一个 DIG 命令时， FreeBSD 或 BIND 中的哪一部分代码首先命中。
目前，我看到当我点击 DIG 命令时，我看到控件转到文件 client.c。在此文件中，调用以下函数：
静态空隙 client_request(isc_task_t*任务，isc_event_t*事件(;
但是，即使在对 BIND 代码的"命名"部分进行了大量挖掘之后，控件如何到达这个地方对我来说仍然是一个大谜团。
此外，我看到从该文件中的两个位置调用此函数。我试图将日志放入这些地方，以了解控制权是否通过这些路径到达这个地方，但不幸的是，这并没有发生。似乎"Client_request(("函数以某种方式从我无法弄清楚的外部调用。
这里有人可以帮助我解开这个谜团吗？
谢谢。
不仅对于bind，而且对于任何其他命令，在 FreeBSD 中你可以使用 ktrace，它非常冗长，但可以帮助你快速了解程序的行为方式。
例如， 在最新的 FreeBSD 中， 你有drill命令而不是dig所以如果你想知道当你运行命令时幕后发生了什么， 你可以尝试：
# ktrace drill freebsd.org
然后，要禁用跟踪：
# ktrace -C
在进程上启用跟踪后，将记录跟踪数据，直到 进程退出或跟踪点已清除。 可跟踪的进程 可以快速生成大量日志数据;它强烈 建议用户在尝试禁用跟踪之前记住如何禁用跟踪 跟踪进程。
运行ktrace drill freebsd.org后，应创建一个文件ktrace.out您可以使用kdump读取的文件，例如：
# kdump -f ktrace.out | less
这将有望"揭示神秘面纱"，在您的情况下，只需将drill替换为dig，然后使用类似以下内容：
# ktrace dig freebsd.org
感谢 FreeBSD Ports 系统，您可以在启用调试的情况下编译自己的 BIND 。为此，请运行
cd /usr/ports/dns/bind913/ && make install clean WITH_DEBUG=1
然后你可以在调试器(lldb /usr/local/bin/dig(中运行它，在你感兴趣的行上中断，然后查看回溯以找出控件是如何到达那里的。