<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I figured I'd come here to these two lists for feature
criticism/input because this is where all the cool kids for both
DnsTap and RPZ hang out...</p>
<p>I wrote ShoDoHFlo (<a class="moz-txt-link-freetext" href="https://github.com/m3047/shodohflo">https://github.com/m3047/shodohflo</a>) and one of
the things it lays bare are the shortcomings of reverse DNS (PTR
records). But basically what I've written there are the necessary
pieces for dynamically populating a reverse lookup zone to point
back to the initial FQDN queried. It occurs to me that if it was
an RPZ, then it would override the reverse lookups for whatever
(sparse) content it contained.</p>
<p>That's the initial thought in a nutshell. I'm here for your
criticism and input on use cases and implementation architecture.</p>
<p>The use case in my mind is that I can (literally) do</p>
<blockquote>
<p>dig -x 10.0.0.1</p>
</blockquote>
<p>and it gives me back actual.example.com when in reality</p>
<blockquote>
<p>actual.example.com. CNAME 10-0-0-1.example.com.<br>
10-0-0-1.example.com. A 10.0.0.1</p>
</blockquote>
<p>I mean "literally" as I see this as a command line tool, although
it could also be accessed programmatically. I suppose I'm also
thinking that tools which support a -n option (tshark, iptables,
etc.) to disable the feature would avail themselves of it to tell
me what the initial FQDN was, in the absence of said option, as a
bonus.<br>
</p>
<p>In some cases there might also be a legitimate PTR record. In
other cases there might be multiple initial FQDNs. So what would
be best to populate the zone with:</p>
<ul>
<li>Just the initial FQDN?</li>
<li>Initial FQDN and legitimate PTR?</li>
<li>Multiple initial FQDNs or just one? (Which one?)</li>
<li>Intermediate FQDNs in a CNAME chain? (Or a reverse CNAME chain
in the reverse lookup zone?)<br>
</li>
<li>All the things?</li>
</ul>
<p>Any suggestions for encoding a desire for a different flavor of
any of the above?</p>
<p>What about architecture: I already have flow going to Redis. What
would be the most accessible architecture, knowing that that might
be different for someone already running the ShoDoHFlo agents and
someone who is not:</p>
<ul>
<li>A periodic task running against the existing Redis database?</li>
<li>A daemon monitoring a Redis queue?</li>
<li>A brand new agent which performs the dynamic updates itself?</li>
</ul>
<p><br>
</p>
<p>As far as drawbacks: this interferes with the reverse lookups
which occur for some authentication and logging schemes, most
commonly with email and web requests. Any others I'm missing? Any
suggestions for mitigations? I've thought of two mitigations:</p>
<ul>
<li>Use a different view or server without the reverse zone for
services utilizing such schemes.</li>
<li>Exclude DNS queries produced by such services when populating
the reverse zone.</li>
</ul>
<p>I note the two are not mutually exclusive.</p>
<p><br>
</p>
<p>You can respond here or privately, or open an issue on GitHub.<br>
</p>
<p>Thanks in advance...</p>
<p>--</p>
<p>Fred Morris<br>
</p>
</body>
</html>