This is an old revision of the document!

PFSense - DNS - Troubleshooting - Slow DNS Response

Change Firewall Maximum Table Entries

Navigate to System → Advanced > Firewall & Nat:

Firewall Maximum Table Entries: 2000000

Monitor the Status

Navigate to Status → Monitoring.

Click the Settings Icon.

Left Axis: Quality.
Right Axis: None.
Click Update Graphs.

NOTE: This will show the status of a continuous ping to your default gateway over time.

Check if there is any recent slowness being reported:

Check what interfaces are running

Navigate to Diagnostics → Command Prompt.

pciconf -lv | grep -A1 -B3 network

returns:

em0@pci0:1:0:0:	class=0x020000 card=0x00008086 chip=0x150c8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82583V Gigabit Network Connection'
    class      = network
    subclass   = ethernet
em1@pci0:2:0:0:	class=0x020000 card=0x00008086 chip=0x150c8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82583V Gigabit Network Connection'
    class      = network
    subclass   = ethernet
em2@pci0:3:0:0:	class=0x020000 card=0x00008086 chip=0x150c8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82583V Gigabit Network Connection'
    class      = network
    subclass   = ethernet
em3@pci0:4:0:0:	class=0x020000 card=0x00008086 chip=0x150c8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82583V Gigabit Network Connection'
    class      = network
    subclass   = ethernet
em4@pci0:5:0:0:	class=0x020000 card=0x00008086 chip=0x150c8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82583V Gigabit Network Connection'
    class      = network
    subclass   = ethernet
em5@pci0:6:0:0:	class=0x020000 card=0x00008086 chip=0x150c8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82583V Gigabit Network Connection'
    class      = network
    subclass   = ethernet

NOTE: This shows Intel NICs.

Intel usually works well with pfSense.

If on the otherhand this was not Intel, this could be a cause for the slowness.

Check DNS Resolver Caching Figures

Navigate to Diagnostics → Command Prompt.

unbound-control -c /var/unbound/unbound.conf stats_noreset | egrep 'total.num|cache.count'

returns:

total.num.queries=11060
total.num.queries_ip_ratelimited=0
total.num.cachehits=10669
total.num.cachemiss=391
total.num.prefetch=342
total.num.expired=295
total.num.recursivereplies=438
msg.cache.count=2073
rrset.cache.count=4222
infra.cache.count=6734
key.cache.count=174

NOTE: This combines the output of:

unbound-control -c /var/unbound/unbound.conf stats_noreset | grep total.num
unbound-control -c /var/unbound/unbound.conf stats_noreset | grep cache.count

Output is:

num.queries: number of queries received by thread.
num.cachehits: number of queries that were successfully answered using a cache lookup.
num.cachemiss: number of queries that needed recursive processing.
num.prefetch: number of cache prefetches performed.
- This number is included in cachehits, as the original query had the unprefetched answer from cache, and resulted in recursive processing, taking a slot in the requestlist.
- Not part of the recursivereplies (or the histogram thereof) or cachemiss, as a cache response was sent.
num.zero_ttl: number of replies with ttl zero, because they served an expired cache entry.
num.recursivereplies: The number of replies sent to queries that needed recursive processing.
- Could be smaller than threadX.num.cachemiss if due to timeouts no replies were sent for some queries.
msg.cache.count: The number of items (DNS replies) in the message cache.
rrset.cache.count: The number of RRsets in the rrset cache. This includes rrsets used by the messages in the message cache, but also delegation information.
infra.cache.count: The number of items in the infra cache.
- These are IP addresses with their timing and protocol support information.
key.cache.count: The number of items in the key cache.
- These are DNSSEC keys, one item per delegation point, and their validation status.

Check System Logs for the DNS Resolver

Navigate to Status → System Logs → System → DNS Resolver.

Check if the DNS Resolver is restarting when this issue occurs.

NOTE: This shows Unbound restarting!

See: https://forum.netgate.com/topic/115482/frequent-unbound-restarts/67

It seems that Unbound restarts when the WAN DHCP lease gets renewed.

Compare the DNS and DHCP logs will probably show there is a correlation.
Every time a Remote Client connection is initiated or stopped, Unbound has to restart.
- The DHCP code is currently sending a HUP signal to the DNS Resolver, which Unbound takes as needing to do a restart.
- Ideally, when a new host enters the DNS local zone because it gets a DHCP release the correct thing to do is reload that zone, not restart the DNS service. Unbound needs to be fixed.
If pfBlockerNG is being used, this could mean upwards of 60 seconds of downtime whilst it reloads any blocklists.

A temporary workaround is not to use DHCP.

For every DHCP entry, you could set and maintain, at the bottom of the page, the DHCP Static Mappings for this Interface.
On the Status → DHCP Leases page you can also choose what lease you want to add as a Static lease.

Other options to try:

Reduce the number of pfBlockerNG blocks.
This should speed up the restart of Unbound.

References

https://forum.netgate.com/topic/115482/frequent-unbound-restarts/67

Wiki

Table of Contents