When Exchange servers query AAAA records through Windows Server 2012R2 DNS servers, they receive SERVFAIL responses for certain domains instead of the expected NOERROR with empty results. This causes Exchange to abort mail delivery without attempting A record fallback.

The issue manifests with specific domains that exhibit unusual DNS characteristics. Two confirmed problematic domains are:

smtpgw1.gov.on.ca
mxmta.owm.bell.net

Packet captures reveal the Windows DNS server receives a valid NOERROR response from upstream servers, but transforms it into SERVFAIL:

;; ANSWER from authoritative server:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3e6c
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Transformed response from Windows DNS:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: a61e
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

• EDNS probing appears to be the root cause (dnscmd /config /enableednsprobes 0 resolves it)
• Domains missing authority sections in AAAA responses trigger the issue
• Forwarders configuration affects behavior but doesn't solve the core problem
• Non-domain joined 2012R2 DNS servers don't exhibit the behavior

To identify affected domains, use these diagnostic commands:

# Check for missing authority section
dig @8.8.8.8 smtpgw1.gov.on.ca AAAA +noadditional +noauthority +nocomments

# Compare with working domain
dig @8.8.8.8 google.com AAAA +noadditional +noauthority +nocomments

Temporary Fix:
Disable EDNS probing (requires DNS service restart):

dnscmd /config /enableednsprobes 0
net stop dns && net start dns

Alternative Approach:
Configure conditional forwarders for problematic domains:

Add-DnsServerConditionalForwarderZone -Name "gov.on.ca" -MasterServers 204.41.8.237
Add-DnsServerConditionalForwarderZone -Name "bell.net" -MasterServers 206.108.34.30

Microsoft has confirmed this as a bug in the Windows DNS server's handling of empty AAAA responses without authority sections. The fix requires:

1. Install all current Windows Updates (tested with November 2015 rollup)
2. Apply hotfix KB3094220 specifically addressing EDNS handling
3. Rebuild DNS cache after updates: dnscmd /clearcache

For immediate Exchange relief while waiting for DNS fixes, modify the transport service to prefer A records:

Set-TransportService -Identity SERVERNAME -ExternalDNSAdapterEnabled $false
Set-TransportService -Identity SERVERNAME -InternalDNSAdapterEnabled $false

---

When troubleshooting DNS resolution issues on Windows Server 2012R2, I encountered a specific scenario where AAAA record queries for certain domains (like smtpgw1.gov.on.ca and mxmta.owm.bell.net) were returning SERVFAIL responses instead of the expected NOERROR with empty result sets. This behavior was particularly problematic for applications like Exchange Server that perform AAAA lookups before falling back to A records.

Using dig to test the queries revealed the following behavior patterns:

# Problematic query against local DNS
dig @192.168.5.5 smtpgw1.gov.on.ca -t AAAA
;; status: SERVFAIL

# Working query against public DNS
dig @4.2.2.1 smtpgw1.gov.on.ca -t AAAA
;; status: NOERROR

After extensive testing, several important patterns emerged:

• The issue occurs only on domain-joined DNS servers, not on standalone instances
• Forwarders configuration significantly impacts the behavior
• EDNS appears to be a contributing factor (disabling it temporarily resolves the issue)

DNS debug logs revealed the complete query path:

1. Client → Local DNS: EDNS-enabled AAAA query (flags: AD=1)
2. Local DNS → Authoritative DNS: Basic AAAA query (no EDNS)
3. Authoritative DNS → Local DNS: NOERROR response (AA=1)
4. Local DNS → Client: SERVFAIL response

Two effective workarounds were identified:

Option 1: Disable EDNS Probes

dnscmd /config /enableednsprobes 0
net stop dns
net start dns

Option 2: Modify Forwarders Behavior

For domains showing this issue, either:

• Remove all forwarders to use root hints exclusively, or
• Add conditional forwarders for affected domains

The most robust solution combines several adjustments:

1. Apply all Windows updates (particularly KB3004539 and KB3014171)
2. Configure forwarders carefully with EDNS compatibility in mind
3. Consider implementing a DNS forwarding hierarchy with:

# Example PowerShell to set up conditional forwarding
Add-DnsServerConditionalForwarderZone 
   -Name "gov.on.ca" 
   -MasterServers 204.41.8.237 
   -ForwarderTimeout 2 
   -ReplicationScope "Forest"

Use these commands to verify the resolution:

# Basic test
nslookup -type=aaaa smtpgw1.gov.on.ca

# Extended test with packet details
Resolve-DnsName smtpgw1.gov.on.ca -Type AAAA -DnsOnly 
   -Server 192.168.5.5 -Trace

The issue stems from how Windows Server 2012R2 handles the interaction between:

• EDNS capabilities negotiation
• Forwarder selection logic
• Response validation for empty AAAA responses

For enterprise environments:

• Consider upgrading to newer Windows Server versions where this behavior is fixed
• Implement DNS policies to handle AAAA queries differently for problematic domains
• Monitor DNS query patterns using Performance Monitor counters