BIND 9

Search for BIND 9 in the Marketplace, select the SecureAnyCloud publisher, and select Create.

Configure the Network Security Group to allow UDP 53 and TCP 53 (DNS) from your client networks, and TCP 22 for administration. DNS uses UDP 53 for most queries and falls back to TCP 53 for large responses and zone transfers, so open both.

RG="dns-prod"; LOCATION="eastus"; VM_NAME="ns1" IMAGE_URN="sac1647283583153:bind9-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:bind9-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard

Open the DNS and administration ports on the VM's NSG:

az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 53 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

On first boot, the image resolves the VM public IP and generates a fresh per-instance rndc control key. It verifies the responsible defaults, starts named, and proves that the example zone answers and that the server is not an open resolver. It then writes /root/bind-credentials.txt. This completes within a minute.

SSH in as azureuser and read the details:

sudo cat /root/bind-credentials.txt

Confirm that named.service (the BIND daemon) and nginx.service (the health probe) are both active. rndc status reports the server as up, using the per-instance control key. ss confirms that DNS is listening on :53 and that the rndc control channel is bound to 127.0.0.1:953 only.

systemctl is-active named.service nginx.service
sudo rndc status

The image ships one example authoritative zone, example.internal, so a DNS round trip works immediately. Query it against the loopback address, or against the VM public IP from a client. The aa flag in the header confirms an authoritative answer.

dig @127.0.0.1 www.example.internal dig @127.0.0.1 example.internal SOA +short dig @127.0.0.1 example.internal MX +short dig @127.0.0.1 example.internal TXT +short

The configuration lives in /etc/bind. named-checkconf validates the whole configuration, and no output means it is valid. The options file locks the server down so that it is not an open resolver.

named -v sudo named-checkconf grep -E 'recursion|allow-recursion|version|allow-transfer|responses-per-second' /etc/bind/named.conf.options

This is the key security property: a recursive query for an external name must be REFUSED. Also confirm that the per-instance rndc key file is present with 0640 root:bind permissions and that the zone data lives on the dedicated data disk.

dig @127.0.0.1 google.com
sudo stat -c '%n %a %U:%G' /etc/bind/rndc.key findmnt /var/lib/bind

Create a zone file on the data disk and register it in /etc/bind/named.conf.local. For example, create the zone file to serve mycompany.example:

sudo tee /var/lib/bind/db.mycompany.example >/dev/null <<'ZONE' $TTL 3600 @ IN SOA ns1.mycompany.example. admin.mycompany.example. ( 2026071001 3600 900 604800 3600 ) @ IN NS ns1.mycompany.example. ns1 IN A 203.0.113.10 www IN A 203.0.113.20 ZONE
sudo chown bind:bind /var/lib/bind/db.mycompany.example

Add the zone to /etc/bind/named.conf.local, where a commented template is already in place. Then check the configuration and reload:

sudo named-checkconf
sudo named-checkzone mycompany.example /var/lib/bind/db.mycompany.example
sudo rndc reload

If you want this server to also act as a resolving (caching) DNS server for your own trusted clients, edit /etc/bind/named.conf.options and set the following:

recursion yes; allow-recursion { localhost; localnets; 10.0.0.0/8; };

Replace 10.0.0.0/8 with your own trusted client ranges. Never use allow-recursion { any; };, because it turns the server back into an open resolver. Apply the change with sudo named-checkconf && sudo rndc reload.

The rndc control channel uses the per-instance key and is bound to loopback. Common operations:

sudo rndc status
sudo rndc reload
sudo rndc reconfig

Restrict the NSG. Allow UDP and TCP 53 only from the client networks that need to query the server, and TCP 22 for administration only.

Keep recursion off unless you need it. If you enable it, scope allow-recursion to your own networks (Step 9), and never to any.

Add DNSSEC signing to production authoritative zones (dnssec-policy) so that resolvers can validate your answers. Keys are stored on the data disk under /var/lib/bind.

Add secondary servers. For resilience, configure secondaries and scope allow-transfer to their addresses instead of { none; }.

Keep the OS and BIND patched. Unattended security upgrades remain enabled on the running VM, including the ISC repository for the 9.20 branch.

Back up /var/lib/bind (the data disk) to preserve your zone files and DNSSEC keys.

BIND 9 is developed by Internet Systems Consortium (ISC) and distributed under the Mozilla Public License 2.0 (MPL-2.0). This SecureAnyCloud image bundles the unmodified official ISC packages.

SecureAnyCloud provides the packaging, the non-open-resolver hardening, the per-instance rndc key automation, the example zone, and 24/7 support with a guaranteed 24-hour response SLA.

SecureAnyCloud is not affiliated with or endorsed by Internet Systems Consortium (ISC). BIND is a mark of its respective owner and is used here only to identify the software.

Deploy on Azure

Find BIND 9 on Ubuntu 24.04 LTS on the Azure Marketplace, published by SecureAnyCloud. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions or licensing inquiries.

Deploy on Azure

Launch BIND 9 (ISC BIND) 9.20 on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com