Many DNS hosting providers, especially those using BIND, include a localhost record in customer zones by default. This creates entries like:

localhost.example.com. 86400 IN A 127.0.0.1

When challenged, providers often claim this is "how BIND works." While BIND doesn't require this, some configurations might include it through:

zone "example.com" {
    // ...
    include "/etc/bind/default-localhost.inc";
};

This legacy practice stems from early internet days when localhost resolution was less standardized.

Public localhost records create several attack vectors:

• XSS attacks using http://localhost.example.com may bypass same-origin policies
• DNS rebinding attacks against internal services
• Confusion in application logic checking for localhost

Examining Alexa Top 20 domains reveals:

Domain	localhost Record	Points To
google.com	No	N/A
amazon.com	Yes	54.239.28.85
microsoft.com	No	N/A

Modern systems should handle localhost resolution via:

1. /etc/hosts entries
2. Operating system resolver libraries
3. RFC 6761 (Special-Use Domain Names)

Use this technical argument when requesting removal:

# Sample email to provider
Subject: Request for localhost record removal from example.com zone

Our security team requires removal of:

localhost.example.com. IN A 127.0.0.1

Rationale:
1. Violates RFC 6761 special-use domain guidelines
2. Creates DNS rebinding vulnerability (CWE-346)
3. No legitimate public use case exists

Please confirm removal timeline.

After removal, verify with:

dig localhost.example.com +short
# Expected: NXDOMAIN or empty response

For BIND administrators, prevent automatic localhost records:

options {
    // Disable automatic localhost records
    add-localhost-glue no;
};

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
    // Explicitly exclude localhost
    exclude { localhost; };
};

If legacy systems depend on this record:

1. Identify all applications using localhost.example.com
2. Migrate to proper service discovery mechanisms
3. Use DNS aliases if absolutely necessary:

internal-localhost.example.com. IN CNAME lb-internal.example.com.

---

Many DNS administrators encounter this scenario: your ISP or DNS hosting provider automatically includes a localhost.example.com record pointing to 127.0.0.1 in your public DNS zone. When questioned, they often respond with "it's just how BIND works" - but is this truly necessary or even advisable?

While BIND doesn't require localhost records in public zones, some ISPs add them by default due to:

• Legacy configurations from when DNS served both internal and external resolution
• Simplified templates that assume all zones need localhost resolution
• Misconceptions about DNS best practices

Here's what a typical zone file might look like:

$ORIGIN example.com.
$TTL 86400
@       IN      SOA     ns1.example.com. admin.example.com. (
                        2023081501 ; serial
                        3600       ; refresh
                        1800       ; retry
                        604800     ; expire
                        86400 )    ; minimum

localhost    IN  A  127.0.0.1

Exposing localhost in public DNS creates several potential attack vectors:

• XSS Vulnerabilities: Some applications might trust *.example.com subdomains improperly
• SSRF Attacks: Services making internal requests could be tricked into contacting localhost
• Confusion: Developers might mistakenly assume this record works for internal resolution

Real-world example from a security advisory:

# Potential vulnerable code pattern
if (request.host.endsWith('.example.com')) {
    // Trusted operation - but localhost.example.com would pass!
}

For modern DNS setups, consider these alternatives:

1. Complete Removal: Simply delete the localhost record from public zones
2. Alternative Resolution: If needed for legacy reasons, point to a real IP:

# Option 2 implementation
localhost    IN  A  203.0.113.45  ; Use your web server's actual IP

When your ISP resists removing the record, try these technical arguments:

• RFC 6303 discourages including localhost in public DNS
• Modern security frameworks treat this as a potential vulnerability
• Offer to sign a waiver accepting responsibility for the change

After making changes, verify with:

dig localhost.example.com +short
# Should return nothing or your designated IP

Remember that DNS changes may take time to propagate due to TTL settings.