How does DIG utility work in FreeBSD and BIND?

I want to know how does the DIG (Domain Information Groper) command really works when it comes to code and implementation. I mean when we enter a DIG command, which part of the code in FreeBSD or BIND hits first.

Currently, I see that when I hit the DIG command, I see the control going to a file client.c. Inside this file, following function is called:

static void
client_request(isc_task_t *task, isc_event_t *event);

But how does the control reach to this place is still a big mystery for me even after digging a lot into 'named' part of the BIND code.

Further, I see this function being called from two places within this file. I tried to put logs into such places to know if control reaches to this place through those paths, but unfortunately that doesn't happen. It seems "Client_request()" function is somehow being called from outside somewhere that I am not able to figure out.

Is there anybody here who can help me out to resolve this mystery for me ?

Thanks.

Are you asking/debugging dig or named ? (dig just sends a DNS request over the network to the named server)

– nos
Sep 14 '18 at 13:51

@nos I want to know where exactly the control reaches in named first while I give a 'dig' command. As I already explained, currently I see the control starting at "client_request()" function within the client.c file. But how exactly it reaches there and where from, I am not able to figure that out.

– user3552519
Sep 16 '18 at 5:39

Your question is very vague. The URL you give as no relationship with dig, the command line (named and dig are two different things). Look instead at ftp.isc.org/isc/bind9/9.9.0rc1/bind-9.9.0rc1/bin/dig/dig.c In any C program, the OS calls the main function first and then whatever happens there dictates the program flow. See line 1820 and later in previous link.

– Patrick Mevzek
Sep 18 '18 at 17:00

dig

main

2 Answers
2

Thanks to FreeBSD Ports system you can compile your own BIND with debugging enabled. To do so run

cd /usr/ports/dns/bind913/ && make install clean WITH_DEBUG=1

Then you can run it inside debugger (lldb /usr/local/bin/dig), break on the line you are interested in and then look at backtrace to figure out how the control reached there.

lldb /usr/local/bin/dig

Not only for bind but to any other command, within FreeBSD you could use ktrace, it is very verbose but could help you to get a quick overview of how the program is behaving.

bind

For example, in latest FreeBSD's you have drill command instead of dig so if you would like to know what is happening behind scenes when you run the command, you could give a try to:

drill

dig

# ktrace drill freebsd.org

Then to disable tracing:

# 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.

After running ktrace drill freebsd.org a file ktrace.out should be created the one you could read with kdump, for example:

ktrace drill freebsd.org

ktrace.out

kdump

# kdump -f ktrace.out | less

That will hopefully "reveal the mystery", in your case, just replace drill with dig and then use something like:

drill

dig

# ktrace dig freebsd.org

You could also do this with dig using the bind-tools port

– Lucas Holt
Oct 19 '18 at 14:56

Thanks for contributing an answer to Stack Overflow!

But avoid …

To learn more, see our tips on writing great answers.

Required, but never shown

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

搜尋此網誌

Dfyjkt