DNS behavior and resolution logic

The Domain Name System (DNS) underpins the web, working transparently in the background to convert human-readable website names into computer-readable numerical IP addresses. These addresses follow the internet's RFC 1918 guidelines for IPv4 and RFC 4193 for IPv6. In short, DNS servers match domain names, such as ibm.com, to their corresponding IP addresses, which most people never need to know.

To perform this translation, the DNS system queries a network of interconnected DNS servers across the internet. This process is similar to using a phone book or a map to find a specific location.

Name servers

A name server provides services that respond to queries against a directory, translating meaningful, text-based web or hostnames into IP addresses.

Name server delegation occurs when a domain's name server gets a request for a subdomain's records and responds by referring the requester to the delegated name server that manages the subdomain. This process allows decentralized management of large domains, such as ibm.com.

With a custom domain name server, you can use the DNS provider's servers with the customized reference name of your own domain. For example, you can define your name server as ns1.cloud.ibm.com instead of the provider's default like ns1.acme.com.

Proxying DNS records and global load balancers

CIS supports proxying for global load balancers and DNS records. When a record or load balancer is proxied, its traffic runs directly through CIS.

Currently, DNS records of type A, AAAA, or CNAME can be proxied. For more information, see DNS record types.

Setting proxy modes

Load balancers and DNS records support both DNS-only and HTTP proxy modes. You can have HTTP proxy and DNS-only domains in the same CIS instance, but the traffic routing behavior differs: traffic for records that are proxied flows through CIS, while traffic for records that are nonproxied (DNS-only mode) flows directly from the client to the origin.

HTTP proxy mode

In HTTP proxy mode, CIS announces IBM IP addresses externally, but protects (masks) your origin server IP addresses. The announced IP address records have an automatic TTL. Traffic flows through CIS, where all the security, performance, and reliability features, such as firewall rules and caching, are applied. The "automatic" TTL (five minutes) also reduces the number of authoritative queries that are made against CIS.

DNS-only mode

In DNS-only mode, the records are resolved to the origin IP, and you can customize the TTL for your records. For global load balancers, CIS serves the addresses of the healthy origin servers directly, but relies on DNS resolvers, which respect the short TTL, to requery CIS DNS for an updated list of healthy addresses.

In DNS-only mode, none of the CIS security, reliability, and performance features are applied.

Root record CNAME flattening

The "CNAME flattening" feature in CIS makes it possible for the root records to bypass the IETF RFC restriction. This restriction states that if a root record is a CNAME, it can't have any other records for that domain. CIS authoritative servers bypass this restriction by returning the A records corresponding to the CNAME target instead of returning the CNAME itself, effectively hiding the CNAME. This technique allows other records, such as MX records, to be added to the domain even though the root record is a CNAME.

Secure DNS

DNSSEC is a technology that digitally "signs" DNS data so you can be confident that it is valid. To eliminate vulnerability from the internet, DNSSEC must be deployed at each step in the lookup process, from the root zone to the final domain name (for example, www.icann.org).

Batch DNS record changes

CIS supports batch DNS record changes, allowing you to update multiple zone records in a single action. This approach reduces manual effort and simplifies domain management tasks, such as migrations, environment setups, or automation workflows. While the CIS console supports individual changes, batch operations are best performed by using API.

The Batch DNS records API endpoint allows you to perform multiple DELETES, PATCHES, PUTS, and POSTS in a single request.

Operations that are included in the /batch request body are always processed in the following order:

Deletes
Patches
Puts
Posts

Within each operation type, individual record changes are applied in the order in which they are processed. If any of the operations fail, no changes are applied, and the API returns the first error that it encounters.

Key considerations for batch DNS records

When specifying each operation in the /batch request body, follow these guidelines for required fields and how unspecified fields are handled:

Deletes: Only the id field is required for each record object. You can include additional fields, such as name for clarity, but all other fields are ignored.
Patches: Apart from each record id, specify the fields that you want to update. All unspecified fields remain the same.
Puts: Specify the id, content, name, and type of each record. Also specify any other fields that you want to set to non-default values. Any unspecified fields assume the default value for each Record type. This operation works as an overwrite, so all fields in a record are always affected.
Posts: Used to create new records. The id field is not required. For field definitions, see the Create DNS Record endpoint and select the appropriate record type from the request body specification.

Example request

In this example, the proxied field for the first record that is listed in the puts assumes the default value false.

{
  "deletes": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353"
    }
  ],
  "patches": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ],
  "posts": [
    {
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ],
  "puts": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ]
}