foscarini
commented
8 years ago 220,232c220,236
< #Check if the answer already exist
< my ($ttl, $rdata);
< my $query = $CHI_CACHE->get($qname);
< if ($query) {
< foreach my $rr ($query->answer) {
< next unless $rr->type eq "A";
< $rdata= $rr->address;
< push @ans, new Net::DNS::RR("$qname $TTL $qclass $qtype $rdata");
< }
< if(@ans) {
< $rcode = "NOERROR";
< } else {
< $rcode = "NXDOMAIN";
---
> #Check if the answer already exist in cache only if Active Directory access is allowed in registration vlan (domain.conf)
> my $size = keys %domain_dns_servers;
> if( $size > 0) {
> my ($ttl, $rdata);
> my $query = $CHI_CACHE->get($qname);
>
> if ($query) {
> foreach my $rr ($query->answer) {
> next unless $rr->type eq "A";
> $rdata= $rr->address;
> push @ans, new Net::DNS::RR("$qname $TTL $qclass $qtype $rdata");
> }
> if(@ans) {
> $rcode = "NOERROR";
> } else {
> $rcode = "NXDOMAIN";
> }
233a238,239
>
> #Provide the default DNS answer to unregistered clients
julsemaan
We use packetfence as a wireless Captive Portal solution in a University (UFRGS), which has more than 10.000 active users each day, using 6 packetfence hosts.
We updated one of our gateways to version 5.4 last november, and detected a huge performance loss and decrease in the number of successful registered users, as seen in the graphs below.
After some investigation, we detected that the pfdns process was using 100% CPU most of the time, and that several DNS queries were being lost, or taking several seconds to be answered. We activated the DEBUG level in the logs, and realized that the CHI L1 cache (memcache) was taking almost 40 milliseconds to deliver an answer to each query of unregistered clients.
Being an open wifi with a Captive Portal, we always have hundreds of unregistered users, and these "rogue" clients were delaying the DNS resolution of "good" clients, sometimes not redirecting them to the Captive Portal.
In version 5.4 a new feature was introduced, allowing Active Directory access from registration network, and was implemented as an allowed bypass domain saved to a CHI cache object. We patched pfdns, to perform a CHI cache get only if Active Directory access is enabled. This test solved our performance problem. The patch for version 5.4 is attached bellow.
I believe that should have a better way to discover if the Active Directory bypass is active, perhaps explicitly enabling it in the configuration menu.