Logging DNS queries on your EdgeRouter
I really like my EdgeRouter Lite: it’s a simple device, yet powerful and quite hackable. Most of the options and the tweaks are hidden and undocumented, but if you keep in mind that the OS is actually Vyatta-based there’s not much you can’t make it do.
Prerequisites
dnsmasq
The following supposes that you are already using dnsmasq
as your DHCP server instead of the default ISC DHCPD
. If you are not using it, please refer to this support article on how to set it up - it’s quite straightforward and officially supported.
By using dnsmasq you get some neat advantages such as extended configurability and, most importantly, automated resolution of DNS names of your DHCP-served hosts. The only drawback I noticed is that, in EdgeOS versions older than v1.9.7 (so v1.9.1.1 and priors) you lose the ability of viewing current leases from the router’s web UI; adding and viewing static leases still works since they are backed by the config tree itself.
Note: you can still check the leases by ssh’ing into the router and running cat /var/run/dnsmasq-dhcp.leases
.
You can also add this quicker alias to your
.bashrc
:~/.bashrc
1 alias leases='cat /var/run/dnsmasq-dhcp.leases'
syslog
It is also given that you have already set up proper syslog forwarding in your device. If you are still not exporting the logs anywhere you might want to look into this support article and something like Graylog or Splunk.
Logs management truly is a fundamental addition to your network, being it “just” a homelab or any other kind of deployment: it usually is not so complex to set up and brings a new level of manageability and searchability to your precious, data-dripping log entries. Plus it enables you to create all those cool dashboard and monitoring/reporting shenanigans, but that’s another story.
Needed changes
The following changes are easy but not painless: you’ll need to modify a Vyatta system file that handles dnsmasq’s config generation (don’t worry, Ubiquiti empolyees themselves suggested to do it this way), and as such this file won’t be copied over during a firmware upgrade; you’ll have to remember to re-patch it yourself unless Ubiquiti decides to implement this hack in the configuration tree in a future release.
The change itself is really simple: you just need to have a configuration line commented out in the script’s output, so that it’ll be ignored in the generated dnsmasq config. Here are the steps:
SSH into your router and create a backup copy of the file:
1
sudo cp /opt/vyatta/sbin/vyatta-dns-forwarding.pl ~/vyatta-dns-forwarding.pl.bak
Edit the file so that the line
$output .= "log-facility=/var/log/dnsmasq.log\n";
becomes$output .= "# log-facility=/var/log/dnsmasq.log\n";
(notice the#
at the head of the string); it should be at line #52 or so of the file, depending on your fw version:1
sudo sed -i 's/\$output \.= "log-facility/\$output \.= "# log-facility/' /opt/vyatta/sbin/vyatta-dns-forwarding.pl
This will divert dnsmasq’s logs to the syslog instead of its own file.
Actually enable the logging of DNS queries and force the regeneration of dnsmasq’s config files:
1
2
3
4
5configure
set service dns forwarding options log-queries
commit
save
exitNote: you can have multiple
options
values in the/service/dns/forwarding
section: each of them will end up as a different line in the final config.Verify that the changes took place by looking at the current config:
1
cat /etc/dnsmasq.conf
You should see the
log-facility
key commented out and the newlog-queries
key added around the bottom of the file.
Et voilà, you’re done! Now all your DNS queries, updates, and cache hits will be forwarded to the remote syslog destination, ready to be further inspected, parsed, graphed, or generically analyzed at your will.
Bonus section: Graylog
You might want to create a new stream in Graylog with the following settings (YAML format used purely for formatting lazyness, this has no formal meaning at all):
1 | title: DNS queries |
The artistic interpretation of the rules above will yield you a stream of pure DNS requests, ignoring the results (matches, cache hits, etc.) and other noisy log tags (configuration made by new DHCP-server hosts, etc).
To aid targeted searches without falling back to resource-intensive globbing, a DOMAIN
pattern with value (?:[a-zA-Z0-9-]+\.){1,2}[A-Za-z$]+
can also be added in System > Grok Patterns and used as an extractor for your relevant Input. An example Grok pattern for these packets could be %{DOMAIN:dns_request} from %{IP:dns_source}
.