Category: DNS

Free Public DNS Servers
article #883, updated 219 days ago

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.

Categories:      

==============

Handy ISP DNS
article #1474, updated 220 days ago

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

Categories:      

==============

Internet DNS with built-in IPv6+IPv4 blacklisting: 9.9.9.9
article #1473, updated 222 days ago

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.

Categories:      

==============

Eliminate Hesitations in Microsoft Services with Better DNS
article #1067, updated 606 days ago

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.

Categories:      

==============

The WINS resolution information was not updated. The record format is corrupt.
article #1227, updated 1033 days ago

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.

Categories:      

==============

Use DMARC to harden SPF and DKIM
article #1255, updated 1373 days ago

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:

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

Categories:      

==============

'dig' web interface for DNS studies
article #1137, updated 1794 days ago

This is amazing:

http://digwebinterface.com

Submitted by the amazing Zach Hogan.

Categories:      

==============

DNS, Whois, et cetera
article #12, updated 1883 days ago

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

Categories:      

==============

Test DMARC record for a domain
article #1086, updated 1908 days ago

A free tool:

https://www.dmarcanalyzer.com/dmarc/dmarc-record-check/

Categories:      

==============

SPF for Constant Contact
article #873, updated 1915 days ago

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:

ip4:208.75.120.0/22

Categories: