<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello, Rear View RPZ (<a class="moz-txt-link-freetext" href="https://github.com/m3047/rear_view_rpz">https://github.com/m3047/rear_view_rpz</a>) is
now generally available: turn your local BIND resolver into a
network investigation enabler with locally generated PTR records.</p>
<p>Ok, sure, some of you may be using it as a network investigation
tool already. If so, you're probably well aware of the problems
with PTR records for local visibility:</p>
<ul>
<li>Whoever controls the address space, not the domain, controls
the PTR record.</li>
<li>They don't necessarily get updated when domains get updated.</li>
<li>Network owners lie.</li>
<li>The records are just ignored.</li>
<li>Many FQDNs can point at an address (vhosting).</li>
<li>CNAMEs confound the intent of PTR records.</li>
</ul>
<p>What FQDN did <i>YOUR</i> users look up which resolved to that
address? Rear View RPZ can tell you.</p>
<p>To have success with it in its present state:</p>
<ul>
<li>You should be familiar with configuring BIND.</li>
<li>You should be capable of building it from source.</li>
<li>You should be capable of resolving prerequisites (e.g. frame
streams, protobuf) when doing so.</li>
<li>You should be familiar with Python syntax.</li>
<li>You should understand a systemd service file.</li>
</ul>
<p>And I have one small favor to ask: if you know of a Linux
distribution which ships BIND compiled with Dnstap support, please
let me know!</p>
<p>Cheers...</p>
<p>--</p>
<p>Fred Morris</p>
<p>This is being posted to the Dnstap, RPZ and BIND Users mailing
lists.<br>
</p>
<p><br>
</p>
</body>
</html>