If you see an error message like this one in the BIND DNS server's client log, it may be harmless:

24-May-2019 21:00:05.019 client: error: (example.com/A): query_find: query_getdb failed

I couldn't find anything explaining the error (hence this post) so I looked at the source; this message comes from query.c. What's happening here is that BIND is trying to figure out which zone contains the answer it needs, but it can't find the zone, so query_getdb failed is logged and a SERVFAIL response is sent to the client.

As it turns out, the timing of this error in the log coincides exactly with the BIND service being restarted. In this case I had just upgraded a server from 9.11.6-P1 to 9.11.7 and bounced the service. At the precise moment the logged query arrived, BIND hadn't loaded that zone yet, so of course it couldn't be located in memory. The zone in question was loaded a...

One of my DNS servers has been seeing some unusual bursts of traffic over the past month. At random intervals, several hundred rapid queries for qname miep and qtype ANY will arrive, appearing in BIND's security log like this:

03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0cb600 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied
03-May-2019 16:05:18.430 security: info: client @0x7f392c0bcfe0 83.83.115.193#41373 (miep): query (cache) 'miep/ANY/IN' denied

At first glance, this resembles a DNS amplification attack. For one thing, the deprecated ANY qtype is used in such attacks to maximize the size of the answer packets. Secondly, the origin IPs are probably forged, considering the legitimate resolver 1.1.1.1...

DNS Monitoring with SmokePing

SmokePing, the popular network latency monitor, comes bundled with several probes to measure the response time of DNS servers. Instead of just gauging the ping time, they perform DNS queries to test the performance of the service itself. I prefer Christoph Heine's AnotherDNS probe, since it's capable of high-resolution timing and offers a few extra options that the other DNS plugins don't have.

In addition to tracking latency, recently I've wanted to track the contents of DNS responses, too. A spate of high-profile DNS hijacks like the one that hit linux.org got me curious whether I could keep an eye on DNS integrity without installing any new monitoring tools. SmokePing seemed like the obvious choice because I already watch DNS from there, but none of the probes were capable of inspecting response records.

So, I've added some functionality to the AnotherDNS....

After watching the root DNSSEC KSK rollover transpire with no notable fallout, I thought it would be a good time to try a rollover of my own. My attitude towards DNSSEC has been to set it and forget it, so I've never touched a zone's keys after the initial signing procedure. What better time to practice a rollover than when it's top of mind?

While I was poking around, I decided the key tags for this zone were a little boring and could use some spicing up:

[parse@stemmons ~]$ delv DNSKEY shaunc.com. +nocrypto +short
    256 3 8 [key id = 18723]  ; ZSK; alg = RSASHA256 ; key id = 18723
    257 3 8 [key id = 1300]  ; KSK; alg = RSASHA256 ; key id = 1300

Key tags, like 1300 and 18723 above, are generated random-ish-ly when you mint a new key with dnssec-keygen. There's a function that computes the key tag based on the key type, protocol, algorithm, and key text. Considering that the ...

If you have a web application that accepts any user input, you're probably dealing with spam bots. There's been a steady increase in automated spamming of blog comments, contact forms, order forms, and other types of interactive web resources. If they can post to it, they're trying to spam it, even in cases where it makes no sense, like submitting advertising pitches to API endpoints or search forms where no human will ever see the message.

Web spammers have been busy escalating and evolving. The adversary is no longer some guy in Elbonia running XRumer over his dial-up connection; these days you're likely to encounter dedicated and distributed web spamming networks. In these cases, the spammer spins up multiple VPSes at different providers, all communicating with one another as part of the spam operation. Often a recon visit will come from one IP address, followed immediately by several POST requests from other hosts in the spam network. This method attempts to fly under the radar of rate limiting and o...

The launch of Cloudflare's new 1.1.1.1 DNS service has brought much fanfare and a heap of praise. More choice is always a good thing, and support for both DNS-over-TLS and DNS-over-HTTPS make 1.1.1.1 an interesting option. In this post I'm going to explain why I won't use it yet, and why you might not want to switch either without doing some testing first.

Fastest isn't always best

Cloudflare touts 1.1.1.1 as "the Internet's fastest DNS directory." In terms of pure response time, they might be right. But when dealing with DNS, response time is only part of the equation. Just as important are the replies you get from a DNS server, the IP addresses it hands out in response to domain queries. Responses from centralized DNS services are sometimes unsatisfactory and can lead to service degradation. The answers come fast, but are they the right ones?

I like to use a telephone analogy here. Imagine you dial 9-1-1 and your call is answered so quickly you ne...

Facebook's data collection tactics make waves

With Facebook and Cambridge Analytica in the news, Facebook's threat to privacy is finally getting the widespread attention it deserves. Beyond the obvious political propaganda concerns, the wider implications of Facebook's data collection are coming to light, and some of the examples are alarming. Multiple users have downloaded their history and discovered that Facebook had records of all of their phone calls and text messages.

In addition to siphoning up phone-related data, much of the web has become infected with Facebook tracking beacons that collect your browsing history on desktop PCs and mobile devices. When you see a Facebook "Like" or "Share" button on a web page, your browser typically loads these directly from Facebook's servers. Some websites without visi...

Today Bert Huber from PowerDNS announced a new DNS-based geolocation service. Given an IP, it returns the corresponding latitude and longitude coordinates. Using it is simple; to look up the coordinates for IP address 1.2.3.4, just reverse the octets and query the TXT record for 4.3.2.1.geo.lua.powerdns.org. I don't see any official details from PowerDNS yet, just Bert's tweet, but based on the domain, the service appears to be using PowerDNS' Lua capabilities.

The usual caveats about geolocation apply:

$ dig +short TXT 73.52.93.172.geo.lua.powerdns.org
"33.745800 -117.826202"

Despite that server living in Dallas, the coordinates that come back are for Tustin, CA. That's because the ARIN allocation for 172.93.48.0/21 points to a corporate address in Tu...

When downloading and compiling software, it's always a good idea to verify the integrity of the source files you obtain. Package handlers like yum and apt handle this automatically, but it must be done manually when you download software yourself.

ISC, the publisher of the BIND DNS server, provides cryptographic signatures with each release. If you have gpg installed, you can use the signature to validate your downloaded BIND tarball. ISC's download URLs follow a consistent naming pattern; simply change the version number in the URLs below to match the version you need.

Download the BIND source

[root@host /home/files]# wget https://ftp.isc.org/isc/bind9/9.11.17/bind-9.11.17.tar.gz
  `bind-9.11.17.tar.gz' saved [8206030/8206030]

Download the associated signature file

[root@host /home/files]# wget https://ftp.isc.org/isc/bind9/9.11.17/bind-9.11.17.tar.gz.sha256.asc
  `bind-9.11.17.tar.gz.sha256.asc' saved [874/874]
`...

This article outlines the deployment of a recursive, caching, authoritative DNS server running BIND 9.11.17 on CentOS 6.10. Why this combination? The BIND name server is the most feature-rich open source resolver, with decades of development behind it. And despite closing in on its nominal end-of-life, CentOS 6 remains a popular server OS due to its proven stability and the absence of systemd.

Preparing your environment

In order to set up your DNS server, you're going to need:

• A server running CentOS 6.10 (bare metal, VM, or VPS will all work)
• root ssh access to your server
• At least 64MB of available RAM for the named process
• wget or some other utility to download a file

There are also some software dependencies:

• The gcc compiler (yum -y install gcc)
• The file utility (yum -y install file)
• OpenSSL header files (yum -y install openssl-devel)

You don't necessarily ...