Google’s DNS registration of .PROD through its Charleston Road Registry has caused some name resolution issues internally when using non fully qualified domain names (non-FQDNs). For those of us who have DNS search suffix lists that attempt to resolve shorter names in a PROD domain by appending an example.com suffix to yield .prod.example.com, you may see now unexpected answers in DNS.
Any names being resolved that end in “.prod” with “example.com” in your search list no longer works. Since .prod is now a valid gTLD (generic top-level domain), DNS is attempting to resolve this through Google’s registry. Google, in their infinite wisdom, is returning valid responses instead of negative answers as intended by the RFCs.
RFC 1035 section 4.1.1 stipulates that the RCODE (response code) to be returned is a Name Error (code 3) when the domain name does not exist; note, any record in DNS is considered a domain in this context. RFC 2308 expounded the understanding of the Name Error as the NXDOMAIN response status.
In any case, records with .prod will stop processing by your client DNS resolver and return bogus records such as these (as if everything under the .prod gTLD has wildcard records):
C:\Windows\System32> host web101.prod
web101.prod has address 127.0.53.53
web101.prod mail is handled by 10 your-dns-needs-immediate-attention.prod.
Upon seeing the “your-dns-needs-immediate-attention.prod” in queries today, my first assumption lead me to believe that DNS got hacked. Further investigation of the SOA record for .prod (shown below) lead me to Google.
C:\Windows\System32> dig soa prod. +short
ns-tld1.charlestonroadregistry.com. dns-admin.google.com. 268435492 21600 3600 1209600 300
I’d like to plea to Google to make this right, but when you complain to the cloud, no one hears you.