This error often occurs when a longstanding Windows Server network is given a much newer domain controller. The WINS records embedded in DNS, don’t work anymore; when you try to delete them or change them, you get the error message in the title of this article.
The best thing to do, is PowerShell:
Remove-DNSServerResourceRecord -ZoneName dns_zone.local -Force -RRtype "WINS" -Name "@"
Try that (substituting dns_zone.local for your LAN DNS zone!), then right-click on the zone name, choose “All Tasks” and then “Reload”, then press F5 for refresh. The error-causing situation will go away, you can then reconfigure easily. If there are other zones, you’ll want to repeat for all of them. If there is a WINS record in a reverse lookup zone, the RRtype is
WINSR instead of
WINS, the result being something akin to this:
Remove-DNSServerResourceRecord -ZoneName 1.168.192.in-addr.arpa -Force -RRtype "WINSR" -Name "@"
Sometimes the actions above only take effect, and show up in the servers, if you reload and refresh (often both) the zones.
The following TXT record:
v=DMARC1; p=reject; pct=100; adkim=s; aspf=s
at least theoretically, should harden SPF and, if present, DKIM. “=s” means “strict”. According to DMARC documentation, DMARC can be used without DKIM, and experiences with a first setup of the above without DKIM are playing out well so far.
Some info is here:
This is amazing:
Submitted by the amazing Zach Hogan.
A great place for general DNS lookup info:
The best WHOIS:
And one for info about IP addresses:
Awhile ago it came to light that the following needed to be added to SPF records for email-enabled domains using Constant Contact:
include:ccsend.com include:constantcontact.com include:confirmedcc.com
Things have gotten a lot better. The following now covers all of the above:
Microsoft is heavily using something called GeoIP, to optimize Internet data routing for its services, including Skype, Office 365, and all of the others.
All of the code below is within ‘nslookup’, running in CMD on Windows.
The way this works, basically, is different IP sets are reported by DNS lookups, depending on the upstream DNS server being polled. So if, like many right now, you were using Google’s DNS (188.8.131.52 and 184.108.40.206) on your LAN, and did nslookup on the recommended test hostname, outlook.office365.com, you would see this:
But on the other hand, if you were using OpenDNS (220.127.116.11/222.222), you would see this:
The most important thing to observe in the above, is that the IP set is different. And if you try pings from your test PC to each of the above IPs, you will notice major differences. In recent testing, most of Google’s results ping much slower (higher, in milliseconds) than OpenDNS’s. But we found OpenDNS’s pings noticeably slower than our current known best of breed, Level3 (18.104.22.168/4):
We have also noticed that the lists of IPs do not correspond to names, i.e., outlook-namsouth3 does not return the same IP list each time. So there is a lot of highly complex geographically-centered IP routing by DNS, going on, by Microsoft, and Level3 seems to cooperate best.
The upshot is, if you see any Microsoft cloud-based services being slow, hesitating, freezing up, or losing connection regularly, switch your LAN’s DNS forwarders to Level 3, and you may well knock the problem out most easily.
As of this writing, the current authoritative list, from here:
|| VeriSign, Inc.
|| University of Southern California (ISI)
|| Cogent Communications
|| University of Maryland
|| NASA (Ames Research Center)
|| Internet Systems Consortium, Inc.
|| US Department of Defense (NIC)
|| US Army (Research Lab)
|| VeriSign, Inc.
|| RIPE NCC
|| WIDE Project
Google is a good place to start:
OpenDNS is often good too:
And one new to us, is Level 3. Level 3 provides DNS to most ISPs in the U.S.A., and does provide geo-routing for speed and compatibility.
Increasingly, nslookup is not installed by default in major Linux distros. On Arch-based and Debian-based distros, it’s in package dnsutils,