[Dnsmasq-discuss] Finding actual DNS server used

[Albert ARIBAUD]

Hi Chris,

Le Sun, 15 Jan 2017 09:53:00 +0000
Chris Green <cl at isbd.net> a écrit:

> On Sun, Jan 15, 2017 at 09:21:25AM +0100, Albert ARIBAUD wrote:
> > Hi Chris,
> > 
> > Le Sat, 14 Jan 2017 19:27:28 +0000
> > Chris Green <cl at isbd.net> a écrit:
> > 
> > (re getting dnsmasq to say which upstream servers it uses)
> >   
> > > Why is is so difficult to provide this information?  At the very
> > > least it would provide a confidence check that all is working as
> > > intended. It might very well help if something isn't working
> > > too.  
> > 
> > It is not difficult at all to get this information. It's just that
> > dnsmasq does not provide any "API" to get it, because it's easy to
> > get it  otherwise for diagnosis purposes.
> > 
> > For diagnosis, the operator can:
> > 
> > - read the configuration file(s) dnsmasq uses and find "server="
> >   lines in it, and read the /etc/resolv* tree, if dnsmasq uses them,
> >   and that will give the list of servers dnmasq uses at any point in
> >   time.
> >   
> There aren't any! These are systems where dnsmasq is run by Network
> Manager rather than directly, thus there is no spcific dnsmasq
> configuration file.

... and then the configuration is known from the dnsmasq process command
line. So let me amend my statement above: "... read the configuration
options, from the dnsmasq process command line if it contains any, and
from the configuration file or files if applicable".

> > - log DNS queries, which will give the additional info about
> >   which client actually queried dnsmasq, which queries were cached
> > vs sent upstream (to which server), and what the answer was.
> > 
> > - run tcpdump or wireshark on the dnsmasq host or on the DNS client
> > (or both for troubleshooting e.g. timing-related issues). This will
> > give a full view of DNS exchanges on the considerd machine, to the
> > last bit, litterally.
> > 
> > So, from a diagnosis point of view, pulling the actual list of
> > servers from a running dnsmasq is not that much of a need.
> >   
> It would be a whole lot easier than the above though wouldn't it?

It would be more straightforward, but not a whole lot easier: the
tcpdump command is dead simple, as is reading the wireshark log.

> To 'log DNS queries' one may have to actually stop and start the
> system and that may well make the problem one is trying to look at
> disappear.

So would modifying the dnsmasq code to add diagnostics-related
features, actually. :)

Seriously, though: diagnostics always run the risk of affecting the
issue anyway. Even doing a tcpdump could stop a time-sensitive bug fom
appearing.

So I don't personally consider the 'debugging risks affecting the
issue' criterion much.

Besides, in my empirical experience, the specific act of turning
logging on for DNS or DHCP never affected any issue I ever came
across, except in the sense that it helped pinpoint the root cause, but
of course YMMV.

Note: if stopping/starting the dnsmasq server [without any logging
added or removed] makes Lars' client work again, then it is valuable
input to diagnosing the issue.

> Both tcpdump and wireshark are quite esoteric utilities, it would take
> quite a bit of knowledge of using them to extract the required
> information.

I would disagree on the 'esoteric' point, or at least I would make a
difference between becoming generally proficient with tcpdump/wireshark
and using it for a given purpose.

Indeed, if trying to master all of tcpdump/wireshark's features, these
tool will look quite esoteric.

But one does not need to /master/ tcpdump in order to get a capture of
DNS traffic; one does just need to install the tools (which is *not*
esoteric) and to know which commands to run (and finding thes commands
it not an esoteric task either; it takes less than a minute's googling).

Granted, that won't make this person a tcpdump guru, but it will get
the DNS diagnostic job done.

> Surely there's a case for something that simply lists the upstream DNS
> servers that a dnsmasq instance is using.

Which would it be? For DNS troubleshooting, equally simple tools can be
used (and put to good profit later on for other network issues).

Amicalement,
-- 
Albert.