[DNSfirewalls] RPZ and client perception
Vernon Schryver
vjs at rhyolite.com
Sun Jul 6 18:31:53 UTC 2014
> From: "David A. Evans" <Evans_David_A at cat.com>
> appear to be related to the RPZ and the amount of time it takes to
> complete all the extra queries for the NSDNAME checks.
NSDNAME or both NSDNAME and NSIP? If both, then why not turn off
NSIP checks?
If only NSDNAME, then I don't understand. Getting A and AAAA records
for a bunch of NS names to do NSIP checks can take a lot of time, but
with the default setting of 1 for min-ns-dots, why does it take too
much time to do only NSDNAME checks for a domain like banque-france.org?
Have you overridden the default value for min-ns-dots?
> these issues they seem to fit into 2 groups.
> 1. DNS zones with "slightly" broken infrastructure. These would
> 2. DNS zones with a large number of NS records and the name
> servers have FQDN's in several different DNS zones. I found some where the
> Is there a RPZ log event that says "It took over (X) seconds to
> complete this query because of RPZ"? Basically, I got a good answer back
> for the 'real' query but I did not provide it to the client within X
> seconds because the RPZ check was still ongoing.
No, but I think that by turning on enough debugging logging and then
crunching it, one could synthezise such log events.
> I can imagine there
> would be a huge amount of noise in those messages but they could
> conceivably be acted on before the client calls with an issue.
What action would be taken after such a log event? Answering the
request including doing the RPZ checks would still have taken too long.
Distinguishing Group #1 (broken infrastructure) from Group #2 (lots
distributed NS RRs) would requirea lot of processing and perhaps human
work. Is the idea to have a good story to tell clients when they call?
Or to add to a local RPZ whitelist?
Would be be effective to sift SMTP and perhaps HTTP server logs for
customer and provider domains to build a private RPZ whitelist?
Vernon Schryver vjs at rhyolite.com
More information about the DNSfirewalls
mailing list