Skip to content

Latest commit

 

History

History
50 lines (31 loc) · 3.17 KB

README.md

File metadata and controls

50 lines (31 loc) · 3.17 KB
Raw

Rear View RPZ

status: public beta, I expect it to work if you satisfy the prerequisites. tested with python 3.6 & 3.8; dnspython 1.15 & 2.1; bind 9.12.3 & 9.16.23

Turn your recursive DNS (BIND) server into a network investigation enabler with DnsTap and Response Policy Zones!

What are "DnsTap" and "Response Policy Zones"?

DnsTap and Response Policy Zones (RPZ) are features available with the ISC BIND 9 DNS server. BIND is open source and is nearly ubiquitous in software distributions as either the "go to" or an optional recursive DNS service / server.

Unfortunately DnsTap and RPZ are generally considered to be optional features and so may not be available with the BIND binary installed by your operating system, although ISC's alternate packages are compiled with support. It's not hard to compile it from source, particularly on linux (or in a linux container). These features are documented as part of the regular BIND reference manual.

What's perhaps unusual about usage here is putting DnsTap to work to update a zone served and utilized by the same DNS server as an RPZ and utilizing that RPZ not as a "ban hammer" but as a source of preferred information.

How does this work?

Rear View RPZ Agent runs as a service and interacts with the BIND Server in two ways:

  1. It listens for DnsTap telemetry generated by the BIND Server, and uses that telemetry to derive "best guess" name-to-address mappings.
  2. It uses dynamic DNS updates sent to the BIND Server to maintain PTR entries in an RPZ which targets the in-addr.arpa. namespace.

BIND runs as a service answering user (and application) DNS requests. In the process it does two things:

  1. Generates DnsTap telemetry concerning the DNS request and response.
  2. Consults any Response Policy Zones for "overrides" or edits to be applied in place of what is provided by the global DNS database.

Put it together and you get PTR responses enhanced with local knowledge.

Run the policy incorporating this RPZ as a view, possibly bound to a special address, and any client which wants "xray vision" for tools which support it just has to point their network configuration at the appropriate address for DNS services. (If you're running a service which needs the "ground truth" for DNS, have a different view on a different address for that.) In other words: you can do all the admin in BIND.

Here is a post with an example: https://lists.isc.org/pipermail/bind-users/2021-December/105450.html or see Examples.txt in this directory.

What are the prerequisites?

At the present time, you'll probably be frustrated unless you meet the following prerequisites. If we get some more road dirt, maybe we can get some more playbooks: by all means submit a PR or open an issue.

  • You are familiar with running and configuring BIND
  • You are familiar with:
    1. building from source...
      • satisfying prerequisites
      • configure; make; make install...
    2. ...or installing BIND using ISC's packages (https://www.isc.org/bind/)
  • You can use git clone
  • You are familiar with Python syntax
  • You can figure out a systemd service file