This has become fraught with peril lately, even after initiation it can be far from easy to figure out what to do next. What to do next, after the transfer has initiated, is, we browse here:
and we put the transfer authorization code, from the outgoing registrar, after finding the appropriate Network Solutions account number for the order, and scrolling in the above page (if there are more than one; if you do a lot of this, there will be a pile, if not, just one) to find that account number. Then open the account and enter the code.
If you have trouble finding that account number, browse here:
and the account number will be listed with the order for the transfer.
The following TXT record contents:
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.
To use the above, create a TXT record of name
_dmarc with those contents.
Some more info is here:
In this space, we used to recommend CloudFlare’s, 184.108.40.206/220.127.116.11. However, a GeoIP lookup shows 18.104.22.168 is Australia, and we found that using the nines (22.214.171.124/126.96.36.199) gave much better routes for large Axcient backup data transfers. So we’re now suggesting either nines or ISP DNS for maximum results. More when we have more.
Handy ISP DNS
article #1474, updated 401 days ago
East Coast 188.8.131.52
West Cost 184.108.40.206
Something new. quad9.net is doing this, and it appears both very fast and very worthwhile. Same feature space as 220.127.116.11 and 18.104.22.168, adding bad-actor blacklisting in both IPv6 and IPv4 in its default. This is the first real IPv6-enabled security service of which I am aware, I have been watching and waiting for this for quite a while.
Uses primary 22.214.171.124, secondary 126.96.36.199.
There are other features too.
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. CloudFlare’s DNS works as well if not better.
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.
Windows OS-Level Issues
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: