3

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.

user3552519
  • 401
  • 4
  • 11
  • 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 05: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 https://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

2 Answers2

2

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.

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:

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

# kdump -f ktrace.out | less

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

# ktrace dig freebsd.org
nbari
  • 25,603
  • 10
  • 76
  • 131
1

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.

arrowd
  • 33,231
  • 8
  • 79
  • 110