Depending on the DHCP assignment group, clients in the house get one of 3 DNS configurations:

• Normal clients get Surfrock66 Bind DNS, then upstream requests go to Surfrock66 PiHole, then upstream to Google DNS
• Kids clients get Surfrock66 Bind DNS, then upstream to OpenDNS FamilyShield
• Some guest clients get DNS directly from Google

This is a bind server running on sr66-ipam-01 at 10.2.2.213 on port 53. It should be the primary DNS responder to the house. It has 3 categories of DNS zones:

• Zones for defining internal access to sites with the same URL as external sites, for example, “nextcloud.surfrock66.com”. These are defined in /etc/bind/named.conf and the zonefiles are in /etc/bind/zones/ under canonical names. These have to be looked up internally, as an external resolver like google would point to the WAN home IP and NOT the LAN IP of the web server.
• A single zone for all home clients on the domain hda.surfrock66.com; This is defined in /etc/bind/named.conf and the zone is /etc/bind/zones/hda.surfrock66.com.zone. This file groups clients into logical partitions based on subnet and "subNot" logical partition.
• Reverse lookup zones to resolve host names to IPs. These are defined in /etc/bind/named.conf and the zonefiles are in /etc/bind/zones/ under names in reverse order of octet (so for IP subnet 10.4.3.0/24, the zonefile would be 3.4.10.in-addr-arpa-zone).

Bind responds based on “ACLs” or Access Control Lists which are just subnets/IP blocks. 3 are defined but we only use 2 actively:

• internal-all-acl - This is every defined subnet/"subnot" in the house but is unused
• internal-default-acl - This every defined subnet/"subnot" in the house EXCEPT the kids devices. It is tied to a view that will forward unknown requests to pihole on 127.0.0.1:5354.
• internal-kids-acl - This is the kids devices. It is tied to a view that will forward unknown requests to OpenDNS FamilyShield.

PiHole is running as an ad and tracking blocking service on sr66-ipam-01 on port 5354. Once pihole was set up, it was not intuitive to move it to listen on another port (understanding Bind is listening on the normal DNS port). PiHole uses DNSMasq under the hood, and to change the port add “port=5354” to “/etc/dnsmasq.d/02-changeport.conf” and restart the service.

If you want to add a new DNS Alias which works both externally and internally, open cPanel, go to “Zone Manager”, select the domain (usually surfrock66) and click the “manage” button, then add an A record with a 300s (5m) TTL with the IP set to the current IP of the house.

We then need to edit the script which keeps the DNS records dynamically pointed at the house. On sr66-ipam-01 edit /home/surfrock66/.scripts/cpanel/cpanel-dynamic-dns-all.sh and add a new code block for the new DNS alias.

Now we need to define the zone in bind. Edit /etc/bind/named.conf and find the records for local zonefiles, and copy a syntax block with the new domain name. You will need to do this within each “view” of the config file. You will see that you will be pointing to a new zone file which doesn't exist yet.

Lastly, you will need to create said zone file in /etc/bind/zones/. I recommend copying an existing zone, then modifying it with the new domain name. Make sure to update the date timestamp at the top, then when done, make sure the “bind” user owns the file. Restart bind9 for this to take effect.

The Chromecasts have very complex networking requirements as they constantly ping google and will fail if they cannot get to google, and by default they do not like being behind VLANS and having their DNS captured by pihole. For this reason, we have a complex configuration to support the Chromecasts:

1. On sr66-opnsense-1, in Firewall → NAT → Port Forward, there are redirect rules for all DNS requests to be sent to sr66-ipam-01.
2. On sr66-opnsense-1, in Services, there is a UDP Broadcast Relay to help redirect multicast DNS as needed.

Back to Tech Documentation