[DNSfirewalls] Using DnsTap to populate a reverse DNS RPZ

[Andrew Fried]

Fred,

In a perfect world every IP would have a one to one matching PTR record.
 In the real world this isn't often the case.

You will often see generic 4-3-2-1.some.domain ptr records despite an
actual host/domain points at the ip, particularly in cloud environments.

Furthermore, a rewrite triggered by some query won't necessarily match
the ptr record, especially if the query was for a hostname but the
rewrite triggered, for example, on a bad nameserver.

The only useful logs I've found over time are the actual rewrite logs
that bind or unbound generates.

Andrew


On 3/19/21 2:47 PM, Fred Morris wrote:
> 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
> 
> 
> _______________________________________________
> DNSfirewalls mailing list
> DNSfirewalls at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/dnsfirewalls
> 

-- 
Andrew Fried
afried at deteque.com
+1.703.667.4050