Some Notes on the Machines

As of Q4 2023, Google and Yahoo are requiring DMARC to be set on the sender side, for many emails to be delivered. Some Office 365 tenants have exhibited similar behavior.

The following TXT record contents:

v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=s

indicate that both DKIM and SPF are checked, and any email not satisfying both entirely, will be marked such that a spam filter should quarantine it. The =s means “strict”; there is a “relaxed” mode, =r, which allows subdomains. But if you have to allow for some email to be transmitted without DKIM, e.g. from a web site’s or application’s email generator, go with either this:

v=DMARC1; p=quarantine; pct=100; aspf=s

which does not look at DKIM; or if you must, this:

v=DMARC1; p=none

which is a kind of ‘null’ DMARC, it’s a placeholder such that DMARC exists, but doesn’t do anything. At least one cloud-application vendor is recommending this, but it’s far from clear how Google, Yahoo, and other machines will respond to it, either now or in the future.

To use the above, create a TXT record of name _dmarc with chosen contents.

Some more info is here:

www.dmarcanalyzer.com/how-to-create-a-dmarc-record/

Appears to be very very good. Better ping than many from some major ISPs. Also very sophisticated and configurable, and considerably less expensive for the features, than some.

https://nextdns.io

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:

www.networksolutions.com/manage-it/transfer-status.jsp

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:

www.networksolutions.com/my-account/order-history

and the account number will be listed with the order for the transfer.

In this space, we used to recommend CloudFlare’s, 1.1.1.1/1.0.0.1. However, a GeoIP lookup shows 1.1.1.1 is Australia, and we found that using the nines (9.9.9.9/149.112.112.112) 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.

Cox
Primary 68.1.16.107
East Coast 68.1.16.108
West Cost 68.111.106.68

AT&T
68.94.156.1
68.94.157.1

Something new. quad9.net is doing this, and it appears both very fast and very worthwhile. Same feature space as 1.1.1.1 and 8.8.8.8, 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 9.9.9.9, secondary 149.112.112.112.

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 (8.8.8.8 and 8.8.4.4) on your LAN, and did nslookup on the recommended test hostname, outlook.office365.com, you would see this:

> outlook.office365.com
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    outlook-namsouth2.office365.com
Addresses:  2603:1036:0:26::2
          2603:1036:102:90::2
          2603:1036:404:a4::2
          2603:1036:102:107::2
          2603:1036:102:b8::2
          2603:1036:404:11b::2
          2603:1036:404:3f::2
          2603:1036:3:12e::2
          2603:1036:102:3e::2
          2603:1036:404:11c::2
          40.97.170.162
          40.97.30.130
          40.97.170.178
          40.97.142.18
          40.97.41.98
          40.97.162.130
          40.97.154.66
          40.97.166.178
          40.97.117.242
          40.97.119.178
Aliases:  outlook.office365.com
          outlook.ha.office365.com
          outlook.office365.com.g.office365.com

>

But on the other hand, if you were using OpenDNS (208.67.220.220/222.222), you would see this:

> outlook.office365.com
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:    outlook-namsouth4.office365.com
Addresses:  2603:1036:d01:2::2
          2603:1036:101:2::2
          2a01:111:f400:31ab::2
          2603:1036:902:a3::2
          2603:1036:906:4d::2
          2603:1036:405:2::2
          2603:1036:405:15::2
          2603:1036:404:67::2
          2603:1036:100::2
          40.97.142.18
          40.97.41.98
          40.97.162.130
          40.97.154.66
          40.97.166.178
          40.97.117.242
          40.97.119.178
          40.97.170.162
          40.97.30.130
          40.97.170.178
Aliases:  outlook.office365.com
          outlook.ha.office365.com
          outlook.office365.com.g.office365.com

>

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 (209.244.0.3/4):

> outlook.office365.com
Server:  resolver1.level3.net
Address:  209.244.0.3

Non-authoritative answer:
Name:    outlook-namsouth.office365.com
Addresses:  2603:1036:404:16::2
          2603:1036:404:b6::2
          2603:1036:102:16::2
          2603:1036:405:29::2
          2603:1036:906:4f::2
          2603:1036:d00::2
          2603:1036:102:8f::2
          2603:1036:405:4a::2
          2603:1036:4:4c::2
          40.97.133.130
          40.97.132.194
          40.97.125.114
          40.97.132.226
          40.97.126.50
          40.97.31.50
          40.97.164.146
          40.97.136.194
          40.97.166.34
Aliases:  outlook.office365.com
          outlook.ha.office365.com
          outlook.office365.com.g.office365.com

>

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.

This is amazing:

http://digwebinterface.com

Submitted by the amazing Zach Hogan.

A great place for general DNS lookup info:

http://www.dnsstuff.com/

The best WHOIS:

https://whois.icann.org/en

And one for info about IP addresses:

http://www.arin.net/index.shtml