ASD ISM 2017 Encrypt DNS traffic between clients and servers
What it says
DNS traffic is encrypted by clients and servers using ASD-approved cryptography.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDNS lookups sent between your devices and DNS servers must be encrypted using cryptography approved by the Australian Signals Directorate (ASD).
Every time a device on your network looks up a website address, it sends a request to a DNS (Domain Name System) server, which acts like the internet's phone book by turning a name such as example.com into a numeric address. By default these lookups travel in plain text, so anyone watching the network can see and even tamper with which sites your people are visiting. This control requires that DNS traffic between your devices (clients) and your DNS servers is scrambled (encrypted) using cryptography that the Australian Signals Directorate (ASD) has approved, so the lookups cannot be read or altered in transit.
Free. Save your status, tasks and notes.
Why it matters
If DNS lookups are sent in plain text, attackers can spy on which sites your staff visit and redirect them to fake websites to steal credentials or deliver malware.
How to implement
The IT administrator should turn on encrypted DNS on the organisation's DNS servers by enabling DNS over Transport Layer Security (DoT) or DNS over HTTPS (DoH), which are the two standard ways of scrambling DNS lookups.
The IT administrator should configure all client devices (laptops, desktops, phones) to send their DNS lookups only to the approved encrypted DNS servers, blocking plain-text DNS so devices cannot quietly fall back to the unencrypted method.
When setting up encryption, the person configuring the servers must select only the cipher suites and protocol versions listed as approved in the Australian Signals Directorate (ASD) Information Security Manual, rather than leaving the default settings in place.
The network or firewall administrator should block outbound plain-text DNS (traffic on UDP and TCP port 53) at the firewall, forcing every lookup through the encrypted DNS service so no device can bypass it.
The IT team should record which DNS servers, protocols (DoT or DoH), and ASD-approved cryptographic settings are in use in a short configuration document, and review it whenever ASD updates its approved algorithms.
Keep it running
Recheck the DNS encryption settings whenever the Australian Signals Directorate updates its approved cryptography, and confirm new or rebuilt devices use the encrypted servers rather than plain-text DNS.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the IT team to show the DNS server configuration.
Look at
whether DNS over TLS (DoT) or DNS over HTTPS (DoH) is enabled and which cipher suites are set.
Good evidence
demonstrates encryption is switched on and limited to ASD-approved algorithms, not left on defaults.
- Check 2 of 5What an auditor asks for
Ask for
which cryptographic algorithms and protocol versions are used for DNS encryption.
Look at
the configured settings against the current Australian Signals Directorate (ASD) approved list in the Information Security Manual.
Good evidence
matches the approved list exactly with no deprecated ciphers.
- Check 3 of 5What an auditor asks for
Ask for
how client devices are pointed at the encrypted DNS service.
Look at
the device or group policy settings that set the DNS server.
Good evidence
shows all clients are centrally configured to use only the encrypted servers.
- Check 4 of 5What an auditor asks for
Ask for
how plain-text DNS is prevented.
Look at
firewall rules that block outbound port 53 and any fallback paths.
Good evidence
shows unencrypted DNS is blocked so devices cannot silently revert to it.
- Check 5 of 5What an auditor asks for
Ask for
proof that the encryption is actually working in practice.
Look at
packet captures, server logs, or a connection test showing DNS traffic is encrypted.
Good evidence
provides recent evidence that real lookups were encrypted end to end.
Mappings
Closest match in ISO/IEC 27001: A.8.20, Network and network devices security, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.20.
ISM-2017 requires DNS traffic to be encrypted between clients and servers wherever supported to protect DNS queries and responses from interception and manipulation. Annex A 8.20 requires networks and network devices to be secured, managed and controlled, which includes implementing secure network services and protocols such as encrypted DNS (e.g. DoT/DoH) where appropriate. Annex A 8.20 is broader because it covers overall network/device security beyond DNS, while ISM-2017 is a specific requirement focused on DNS encryption.
This control partially meets A.8.24.
ISM-2017 requires organisations to encrypt DNS traffic where supported, typically via cryptographic protections at the transport or application layer. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management, which underpins the selection, configuration and governance of encrypted DNS mechanisms. Annex A 8.24 is broader because it applies to all cryptographic use cases, whereas ISM-2017 applies cryptography specifically to DNS traffic.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.