0.0 Executive Summary
This report outlines the identification and resolution of a DNS failure in a hardened pfSense network environment. The issue prevented systems from resolving external domain names, impacting normal internet functionality despite active network connectivity.
Systems were able to reach external IP addresses but failed to resolve domain names, indicating a service-layer failure rather than a connectivity issue.
The objective was to restore domain name resolution while maintaining a strict “Default Deny” security posture. The investigation followed a structured OSI-based approach, progressing from Layer 3 connectivity validation to Layer 7 service analysis.
The result is a stable and secure network configuration where DNS traffic is explicitly permitted and monitored. By implementing targeted firewall rules for TCP/UDP Port 53 and enabling DNS Forwarding Mode in Unbound, the environment now enforces least privilege while maintaining required functionality.
1.0 Troubleshooting pfSense DNS Resolution
1.1 Project Description
The goal of this task was to diagnose and resolve DNS failures caused by transitioning a network to a hardened security state.
The approach focused on controlled outbound access through explicit firewall policy by:
- Enforcing Secure Behavior: Transitioning from an open network to a default-deny model where all traffic requires explicit authorization.
- Controlled Outbound Access: Allowing only required DNS traffic to the internal resolver.
- Improved Visibility: Differentiating between connection timeouts (connectivity/firewall issues) and service failures (configuration issues).
This ensures critical system operations, such as software updates and domain-based access, function correctly without exposing the network to unnecessary outbound risk.
1.2 Technical Task / Troubleshooting Process
The troubleshooting process followed the OSI model to isolate the failure point between the client system and upstream DNS services.
Key Actions & Observations
- Layer 3 Validation
- Verified external connectivity using IP-based testing (
ping 8.8.8.8), confirming gateway routing and NAT functionality. - Observed failure when using domain names, isolating the issue to DNS resolution.
- Verified external connectivity using IP-based testing (
- Service Analysis (Port 53)
- Identified that the default-deny firewall policy on the LAN interface was blocking DNS traffic.
- Confirmed DNS requires both UDP and TCP Port 53 for standard queries and larger responses.
- Policy Remediation
- Firewall Rules: Implemented an explicit allow rule for TCP/UDP Port 53 from the LAN network to the pfSense resolver.
- Unbound Configuration: Enabled DNS Forwarding Mode to ensure queries are properly forwarded to upstream resolvers.
- Rule Optimization
- Positioned the DNS allow rule at the top of the firewall rule set to prevent it from being overridden by broader deny rules.
Root Cause: The failure was caused by a correctly enforced default-deny firewall policy that lacked a required exception for DNS traffic (TCP/UDP Port 53), resulting in all name resolution requests being blocked.
1.3 Resolution and Validation
The DNS service was restored by applying targeted access controls and validating both functionality and policy enforcement.
| Parameter | Implemented Configuration |
|---|---|
| Management Tool | pfSense / Unbound / dig |
| Protocol | TCP/UDP |
| Service Port | 53 |
| Security Mode | Explicit Allow (Default Deny) |
Validation Steps
-
Query Validation:
Executednslookupanddig google.com, confirming successful responses and transition from timeout to non-authoritative answers. -
Functional Testing:
Performed hostname-based connectivity tests to verify end-to-end resolution and routing. -
Log Verification:
Reviewed pfSense firewall logs to confirm DNS traffic is correctly permitted and matches the configured allow rule.
2.0: CONCLUSION
2.1 Key Takeaways
- Hardened environments require explicit allow rules for all essential services, including DNS.
- Troubleshooting should follow a structured OSI-based approach to separate connectivity issues from service-level failures.
- DNS validation must include both UDP and TCP to ensure compatibility with modern network behavior.
- Secure configurations must balance restrictive policies with operational requirements.
2.2 Security Implications & Recommendations
Risk: Unauthorized Outbound Communication
Description: Open DNS configurations can be abused for data exfiltration through DNS tunneling.
Mitigation: Enforce centralized DNS through pfSense and monitor query logs for abnormal frequency or payload size.
Risk: Firewall Rule Misconfiguration
Description: Incorrect rule ordering can result in allow rules being overridden by broader deny policies.
Mitigation: Implement rule hierarchy validation to ensure critical service rules are evaluated before default deny rules.
Best Practices
- Implement DNS over TLS (DoT) to protect query confidentiality.
- Restrict clients from using external DNS servers to enforce centralized control.
- Conduct periodic negative testing to confirm only required ports are permitted.
- Maintain documented firewall and DNS configurations as a source of truth.
Framework Alignment
- Aligns with NIST Cybersecurity Framework PR.AC (Access Control) through enforcement of least privilege network policies.
- Supports DE.CM-1 (Network Monitoring) by enabling visibility into DNS traffic patterns.
- Reinforces secure network design principles for both lab and production environments.