How to remediate – Host Fully Qualified Domain Name (FQDN) Resolution

1. Introduction

The vulnerability “Host Fully Qualified Domain Name (FQDN) Resolution” refers to the ability to resolve a remote host’s fully qualified domain name. This matters because it can allow attackers to map out network infrastructure, identify potential targets, and gather information for reconnaissance. Systems affected are typically those that perform DNS lookups or have publicly resolvable names. A successful resolution does not directly indicate compromise but increases the attack surface. Confidentiality, integrity, and availability may be impacted if this information is used in a subsequent attack.

2. Technical Explanation

Nessus was able to resolve the fully qualified domain name (FQDN) of the remote host. This means that the DNS server successfully translated the hostname into an IP address. While not inherently malicious, this information can be used by attackers for reconnaissance. There is no specific CVE associated with this finding as it’s a basic network function. An attacker could use this to identify live systems on a network and then attempt further exploitation of known vulnerabilities on those hosts.

• Root cause: The DNS server is responding to queries for the host’s FQDN, indicating public resolvability.
• Exploit mechanism: An attacker uses tools like nslookup or dig to resolve the hostname and identify the associated IP address. This information can then be used in further attacks such as port scanning or vulnerability exploitation.
• Scope: Any system with a publicly resolvable FQDN is potentially affected.

3. Detection and Assessment

You can confirm whether a system’s hostname resolves by performing a DNS lookup. A quick check involves using command-line tools, while thorough assessment uses network scanning tools.

• Quick checks: Use the nslookup or dig commands to resolve the FQDN. For example: nslookup example.com
• Scanning: Nessus and other vulnerability scanners will typically flag this as an informational finding during a network scan.
• Logs and evidence: DNS server logs may show queries for the host’s FQDN.

nslookup example.com
Server:         192.168.1.1
Address:        192.168.1.1#53
Non-authoritative answer:
Name:   example.com
Address: 192.0.2.1

4. Solution / Remediation Steps

Resolving a hostname is generally expected behavior, so the “fix” involves understanding and accepting the risk or taking steps to limit exposure if appropriate.

4.1 Preparation

• No backups or service stops are typically required for this issue.
• There are no dependencies or pre-requisites. A roll back plan is not needed as there’s no change being made.
• Change windows and approvals are generally not necessary unless restricting public DNS access.

4.2 Implementation

1. Step 1: Review the necessity of having a publicly resolvable FQDN for the host.
2. Step 2: If public resolution is not required, consider using internal DNS or removing the public record.

4.3 Config or Code Example

Before

;example.com A 192.0.2.1  (Public DNS record)

After

;example.com A 192.168.1.1 (Internal DNS record only)

4.4 Security Practices Relevant to This Vulnerability

Practices that directly address this vulnerability type include network segmentation and least privilege access.

• Practice 1: Network segmentation can limit the exposure of internal systems by restricting public DNS access.
• Practice 2: Least privilege access to DNS servers reduces the risk of unauthorized changes to DNS records.

4.5 Automation (Optional)

Automation is not typically suitable for this vulnerability, as it involves a policy decision about DNS resolution rather than a technical fix.

5. Verification / Validation

Confirm the fix by verifying that the hostname no longer resolves publicly if public resolution was removed.

• Post-fix check: Use nslookup or dig from an external network to confirm the FQDN does not resolve.
• Re-test: Re-run the initial DNS lookup command; it should fail to resolve if public resolution was removed.
• Smoke test: Ensure any services relying on hostname resolution continue to function correctly (e.g., web server access).
• Monitoring: Monitor DNS logs for unexpected queries or changes to DNS records as an example alert.

nslookup example.com
Server:         192.168.1.1
Address:        192.168.1.1#53
**non-existent domain**

6. Preventive Measures and Monitoring

Preventive measures include regularly reviewing DNS records and implementing network segmentation policies.

• Baselines: Update security baselines to reflect the desired state of public DNS resolution for each system.
• Asset and patch process: Review DNS records as part of a regular asset inventory process.

7. Risks, Side Effects, and Roll Back

Removing public DNS resolution may impact services that rely on hostname access from external networks.

• Risk or side effect 1: Services inaccessible from the internet if public resolution is removed. Mitigation: Ensure internal access remains functional.
• Roll back: Re-add the public DNS record to restore external accessibility.

8. References and Resources

Links only to sources that match this exact vulnerability. Use official advisories and trusted documentation. Do not include generic links.

• Vendor advisory or bulletin: Not applicable for this informational finding.
• NVD or CVE entry: Not applicable for this informational finding.
• Product or platform documentation relevant to the fix: Documentation on DNS configuration for your specific DNS server software.