Block misconfigured DNS entries on BIND DNS Cache

Posted on

Block misconfigured DNS entries on BIND DNS Cache – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, networking, domain-name-system, bind, .

I’m running a web crawler with its own BIND DNS Cache. Our code resolves using our DNS cache and makes GET request with Python’s requests library.

The problem is that many FQDNs are misconfigured and they point to RFC1918 IP addresses or loopback IPs like 127.0.0.1 or 10.0.0.0/8. As a result our crawler was trying to connect these IPs and it ended with a scan report from our datacenter.

We made changes to the crawler and now it resolves ip for FQDN at first and skips it if IP is in private/loopback/reserved ranges.

After sniffing with tcpdump I found that there’s still traffic going to private IP addresses. I suppose they occur because of HTTP redirects because we check the original FQDN but we don’t check redirected hosts as this part occurs within Python’s requests library.

Is there any option for BIND to block the resolving of private, loopback or reserved IP addresses? Can I set it to return some kind of a “not resolved” error?

Edit: I tried to dump BIND cache to file and checked it, now I’m sure it happens because of HTTP redirects but it’s not easy to change code and I’m looking for a shortcut like configuring BIND or I will block them on firewall.

Solution :

With BIND you could use the Response Policy Zone (RPZ) functionality to block resolution of address records (A/AAAA) referring to certain addresses.

Specifically the RPZ-IP type of entry is relevant:

RPZ-IP

IP triggers are IP addresses in an A or AAAA record in the ANSWER
section of a response. They are encoded like client-IP triggers except
as subdomains of rpz-ip.

As an example use-case the manual uses this:

; IP policy records that rewrite all responses containing A records in 127/8
;       except 127.0.0.1
8.0.0.0.127.rpz-ip      CNAME   .
32.1.0.0.127.rpz-ip     CNAME   rpz-passthru.

The general idea regarding what the configuration is summarized in the manual as:

For example, you might use this option statement

response-policy { zone "badlist"; };

and this zone statement

zone "badlist" {type master; file "master/badlist"; allow-query {none;}; };

with this zone file

$TTL 1H 
@                       SOA LOCALHOST. named-mgr.example.com    (1 1h 15m 30d 2h)
                        NS  LOCALHOST.
; [snip]

; IP policy records that rewrite all responses containing A records in 127/8
;       except 127.0.0.1
8.0.0.0.127.rpz-ip      CNAME   .
32.1.0.0.127.rpz-ip     CNAME   rpz-passthru.

; [snip]

Do read up on the details to understand the overall setup as well as the rather specific semantics inside an RPZ zone! (It has the normal zone syntax but as you can see some special names have very specific meaning.)

I suppose they occur because of HTTP redirects because we check the
original FQDN but we don’t check redirected hosts as this part occurs
within Python’s requests library.

I hope for your sake that you flushed BIND’s DNS cache after you changed your code. Moving on…

The killer is in saying “I supposed.” You need to make sure. First, check to see if there are any private IP addresses in your BIND cache with rndc dumpdb. Look through that file for offenders.

If there are: Flush your cache. See if they come back. I’m not convinced that private IP addresses would be in your cache as a result of HTTP redirects. It would be very unusual for a publicly accessible website to have many instances of a HTTP redirect that brings a visitor to a hostname that resolves to a RFC 1918 IP address. Private IP addresses in public zones… shudder.

If there aren’t: Then the traffic to private IP addresses is coming into the application elsewhere. Perhaps an application cache of some kind. Something in memory that you’re not aware of. Perhaps a totally different process and maybe it’s not your application after all.

Is there any option for BIND to block the resolving of private,
loopback or reserved IP addresses? Can I set it to return some kind of
a “not resolved” error?

No. BIND resolves, and so in your scenario you have a theoretical race condition where: You don’t want the IP address, but to find out if it’s an IP address you don’t want, you have to get it. What you want is something of a reverse DNS RPZ, which does not exist.

I am wrong. Yes, you will probably be able to use RPZ-IP as the illustrious HÃ¥kan Lindqvist points out. Check this out: http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html#id2589969 Also upvote his answer.

In this case, you need to pull the logic into the application and check each and every hostname more carefully against your local cache and disallow the crawler from going to RFC 1918 addresses.

Let’s break down what you say a just a bit closer:

…we don’t check redirected hosts…

So check redirected hosts and the problem is solved without any over engineering. =)

Leave a Reply

Your email address will not be published. Required fields are marked *