By Navya Ramanjulu and Nelsonia Worsley
DoT is a security protocol for encrypting and wrapping DNS queries and answers via the Transport Layer Security (TLS) protocol. It increases user privacy and security by preventing eavesdropping and manipulation of DNS data via man-in-the-middle attacks.
By default, a DNS server that supports DNS over TLS listens on a well-known port 853. In order for resolver to implement TLS security when a TCP connection is established with the DNS server on port 853, we will leverage Application Transparent TLS provided by the IBM z/OS Communications Server. AT-TLS invokes System SSL on behalf of the application (the z/OS System Resolver, in this case) for its actual TLS protocol processing and is configured using policy rules that are processed and installed into the TCP/IP stack by the z/OS Communications Server Policy Agent.
After TLS negotiation completes, resolver has a secure communication path to the DNS server.
High level steps to establish DoT in the z/OS System Resolver:
Resolver configuration:
-
Understanding the resolver search orders used in native MVS™ and z/OS® UNIX environments is key to setting up your system properly. To determine what TCPIP.DATA values are being used by resolver and where they are read from, see ‘Resolver configuration files’ in the z/OS Communications Server IP Configuration Guide.
-
Once you have determined the TCPIP.DATA file used by resolver:
a. Specify the protocol to be used by resolver to TCP on the RESOLVEVIA statement
b. Specify the DNS over TLS name servers on the NAMESERVER or NSINTERADDR statement
c. Specify the name server port number for TLS on the NSPORTADDR statement. By default, the DNS server that supports DNS over TLS listens on a well-known port 853
3. Optionally, specify the TCP port number with the service information for socket calls in the services file. See ‘Resolver configuration’ to determine which service file is used by resolver. An example of the service information would be like:
-
- domain 853/tcp nameserver
- domain 53/udp nameserver
4. Use the MODIFY RESOLVER,REFRESH command for resolver to the new TCPIP.DATA values. For more information see ‘Dynamically changing TCPIP.DATA statements’ in the z/OS Communications Server IP Configuration Reference
AT-TLS configuration:
-
Ensure that AT-TLS is enabled for the TCPIP stack. To do this, specify TTLS on the TCPCONFIG statement. For more information, see ‘TCPCONFIG statement’ in the z/OS Communications Server IP Configuration Reference
-
In order for AT-TLS to negotiate TLS protection transparently when resolver makes a TCP connection to the DNS on port 853, setup an AT-TLS rule for outbound resolver connections to the DNS servers
a. Set the REMOTEPORTRANGE parameter to 853 and Direction parameter to Outbound on the TTLSRule statement
b. Set the HandshakeRole parameter to Client on the TTLSEnvironmentAction statement
3. The DNS server always sends its server certificate during the TLS handshake to prove its identity to the connecting clients. The clients must validate that the server is what it says it is in order to complete the TLS handshake and send a DNS request. If the identity cannot be validated, DNS name resolution fails and the resolver returns an error to the application. In order for resolver to validate the certificate, the root Certificate Authority (CA) certificate of the name server’s trust chain needs to be added to the trusted certificates list.
a. Obtain the DNS server’s root certificate and store it in a data set. For example: USER1.DIGICERT.DER
b. Add the certificate as TRUSTED CERTAUTH in your SAF database. For example: RACDCERT CERTAUTH add('USER1.DIGICERT.DER’) withlabel('DIGICERT') TRUST
4. Assuming you are using SAF keyring to hold your TLS certificates, and your DNS server does not require TLS mutual authentication (the most common scenario), use the CERTAUTH virtual key ring within your AT-TLS rule. To do this, specify “Keyring *AUTH*/*” on the TLSKeyringParms statement. For example:
#Client rule
TTLSRule Resolver_Client_Rule
{
. . .
REMOTEPORTRANGE 853
Direction Outbound
. . .
TTLSEnvironmentActionRef ClientEnvironment
}
TTLSEnvironmentAction ClientEnvironment
{
HandshakeRole Client
TTLSKeyringParmsRef ClientKeyring
TTLSEnvironmentAdvancedParms
{
ApplicationControlled Off
SecondaryMap off
. . .
}
}
TLSKeyringParms ClientKeyring
{
Keyring *AUTH*/*
}
Use the pasearch -t to verify that your policy has been installed correctly in the TCP/IP stack.
-
If your DNS server requires TLS mutual authentication, or if you use gskkyman key databases instead of SAF key rings, see the z/OS Communications Server IP Configuration guide chapter on Application Transparent TLS for additional guidance.
-
Refresh pagent to install the new rule within the TCP/IP stack
-
Verify the resolver connection to the DNS is using TLS with the following netstat commands:
a. netstat -a to obtain the connection id between resolver and the DNS server
b. netstat -x CONN connid DETAIL to get the AT-TLS information for the specified connection and the associated action details
See the following references for more details on the resolver and AT-TLS setup and configuration:
Disclaimer: Chris Meyer also contributed to this article.