DNS CAA Records in GoDaddy DNS Manager

Here’s how to do a CAA record in GoDaddy DNS when using LetsEncrypt

Advertisement

Enabling Private Google Access in Google Cloud Platform

By default, calls to the various Google Cloud APIs will resolve to a random Google-owned IP, and require outbound internet access, either via external IP, Cloud NAT, or 3rd party network appliance.

If outbound Internet is not required for the application, or not desired for security reasons, enabling Private Google Access allows VM instances to connect an internally routed prefix.

  1. On the subnet, turn on Private Google Access via the radio button
  2. By default, all egress traffic is permitted. If egress traffic is being denied deliberately, create a rule allowing egress traffic to destination 199.36.153.8/30, tcp ports 80 and 443
  3. Create a Private DNS zone called googleapis.com, and apply it to any networks that will use Google Private Access.

In the DNS zone, create two entries:

An A record called ‘private’ that resolves to the following 4 IP addresses:

  • 199.36.153.8
  • 199.36.153.9
  • 199.36.153.10
  • 199.36.153.11

A wildcard record ‘*’ that points to hostname ‘private’

The zone will look like this once created.

Private Google Access should now be working. To test it, ping something.googleapis.com and it should resolve to one of those 4 IP addresses

ping www.googleapis.com
PING private.googleapis.com (199.36.153.9) 56(84) bytes of data.

Disabling IPv6 and DNSSEC in Bind9 / Ubuntu 16.04

We recently migrated an internal bastion host from Ubuntu 14 to 16.04.  I was able to pull secondary zones, but getting recursion working was a real problem.  The previous one would forward certain zones to other internal servers, and even thought the configuration was the same I was having zero luck:

root@linux:/etc/bind# host test.mydomain.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

Host test.mydomain.com not found: 2(SERVFAIL)

I did a tcpdump and discovered the queries were being sent to the intended forwarder just fine and valid IPs being returned:

19:11:24.180854 IP dns.cache-only.ip.46214 > dns.forwarder.ip.domain: 18136+% [1au] A? test.mydomain.com. (77)
19:11:24.181880 IP dns.forwarder.ip.domain > dns.cache-only.ip.46214: 18136 3/0/1 A 10.10.1.2, A 10.10.1.3 (125)

Grasping at straws, I theorized the two culprits could be IPv6 and DNSSec, some Googling indicated it’s a bit confusing on how to actually disable these, but I did find the answer.

Disabling IPv6 and DNSSEC

There were two steps to do this:

In /etc/default/bind9, add -4 to the OPTIONS variable

OPTIONS="-u bind -4"

In /etc/bind/named.conf.options do this

// Disable DNSSEC 
//dnssec-validation auto
dnssec-enable no;

// Disable IPv6
//listen-on-v6 { any; };
filter-aaaa-on-v4 yes;

After restarting BIND with sudo /etc/init.d/bind9 restart now we’re good:

root@linux:/etc/bind# host test.mydomain 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

test.mydomain.com has address 10.10.1.2
test.mydomain.com has address 10.10.1.3

Improving DNS performance for recursive/cache-only queries to Internet

how_dns_works.pngBIND servers will typically ship with a factory-default hint zone like this:

zone "." {
 type hint;
 file "db.root";
};

You’ll see this db.root file contains a static list of the 13 root servers.  It gets the job done, but since recursive queries always go out to the root servers, it’s not ideal.

dns_to_root_servers

A better solution: download the complete database from the root servers themselves:

zone "." {
 type slave;
 masters {
  198.41.0.4;
  192.228.79.201;
  192.33.4.12;
  199.7.91.13;
 };
 file "root.cache";
};

This file is roughly 2 MB and will take a few seconds to transfer, but helps deliver much more consistent lookup times since it hits the TLD servers directly without first bouncing off the root servers.  Note the significantly lower standard deviation below:

dns_to_tld_servers

As an added bonus, it will be resilient should the root servers ever come under DDoS.

 

 

GoDaddy Servers for Secondary DNS

If using GoDaddy as a Master, configure your secondaries to pull from these IPs:

  • xfr03.domaincontrol.com (72.167.238.111)
  • xfr04.domaincontrol.com (72.167.238.110)

Note that the DNS server list should be the two default servers (pdnsXX.domaincontrol.com) plus your secondaries.

As far as using GoDaddy for secondary DNS, good luck with that.