[dnstap] Using DnsTap to populate a reverse DNS RPZ

[Fred Morris]

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...

I wrote ShoDoHFlo (https://github.com/m3047/shodohflo) 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.

That's the initial thought in a nutshell. I'm here for your criticism
and input on use cases and implementation architecture.

The use case in my mind is that I can (literally) do

    dig -x 10.0.0.1

and it gives me back actual.example.com when in reality

    actual.example.com. CNAME 10-0-0-1.example.com.
    10-0-0-1.example.com. A 10.0.0.1

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.

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:

  * Just the initial FQDN?
  * Initial FQDN and legitimate PTR?
  * Multiple initial FQDNs or just one? (Which one?)
  * Intermediate FQDNs in a CNAME chain? (Or a reverse CNAME chain in
    the reverse lookup zone?)
  * All the things?

Any suggestions for encoding a desire for a different flavor of any of
the above?

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:

  * A periodic task running against the existing Redis database?
  * A daemon monitoring a Redis queue?
  * A brand new agent which performs the dynamic updates itself?


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:

  * Use a different view or server without the reverse zone for services
    utilizing such schemes.
  * Exclude DNS queries produced by such services when populating the
    reverse zone.

I note the two are not mutually exclusive.


You can respond here or privately, or open an issue on GitHub.

Thanks in advance...

--

Fred Morris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnstap/attachments/20210319/7ab8b111/attachment-0001.htm>