How is-a.dev Handles Special DNS Record Types: CAA, DS, SRV, TLSA, and URL

is-a.dev handles special record types by parsing JSON configuration files in the domains/ directory and converting them into Cloudflare DNS API calls through dnsconfig.js, with strict schema validation enforced by tests/records.test.js before deployment.

The is-a-dev/register repository provides free subdomains under is-a.dev through an automated, infrastructure-as-code workflow. When users request advanced DNS features like CAA, DS, SRV, TLSA, or URL redirects, the platform processes these through a specialized pipeline that translates JSON domain definitions into specific Cloudflare record types. This article examines the exact implementation details of how is-a.dev handles these special record types according to the source code.

CAA Records: Certification Authority Authorization

CAA records specify which Certificate Authorities (CAs) are permitted to issue certificates for a domain. In dnsconfig.js (lines 45-48), the system iterates over CAA record arrays and constructs Cloudflare CAA() objects:

if (data.records.CAA) {
  for (var caa in data.records.CAA) {
    var caaRecord = data.records.CAA[caa];
    records.push(CAA(subdomainName, caaRecord.tag, caaRecord.value));
  }
}

The JSON structure requires an array of objects, each containing a tag field (limited to issue, issuewild, or iodef) and a value field. For example:

{
  "records": {
    "CAA": [
      { "tag": "issue", "value": "letsencrypt.org" },
      { "tag": "issuewild", "value": ";" },
      { "tag": "iodef", "value": "mailto:security@example.com" }
    ]
  }
}

According to tests/records.test.js (lines 777-785), validation ensures that each CAA record contains a valid tag from the allowed set and that the value follows hostname or contact URI formatting rules.

DS Records: DNSSEC Delegation Signer

DS records enable DNSSEC by storing hashes of DNSKEY records to establish chain of trust. The implementation in dnsconfig.js (lines 58-63) maps JSON fields directly to the Cloudflare DS() constructor:

if (data.records.DS) {
  for (var ds in data.records.DS) {
    var dsRecord = data.records.DS[ds];
    records.push(
      DS(
        subdomainName,
        dsRecord.key_tag,
        dsRecord.algorithm,
        dsRecord.digest_type,
        dsRecord.digest
      )
    );
  }
}

Each DS record requires four integer fields—key_tag, algorithm, digest_type—and a hexadecimal digest string. The validation suite (lines 887-900) verifies that these integers fall within DNSSEC standard ranges and that the digest represents valid hexadecimal encoding.

Example configuration:

{
  "records": {
    "DS": [
      {
        "key_tag": 12345,
        "algorithm": 8,
        "digest_type": 2,
        "digest": "ABCD1234EF567890..."
      }
    ]
  }
}

SRV Records: Service Location

SRV records define the hostname and port for specific services like SIP, XMPP, or Minecraft servers. In dnsconfig.js (lines 96-100), the system appends a trailing dot to the target hostname to ensure proper DNS root resolution:

if (data.records.SRV) {
  for (var srv in data.records.SRV) {
    var srvRecord = data.records.SRV[srv];
    records.push(
      SRV(
        subdomainName,
        srvRecord.priority,
        srvRecord.weight,
        srvRecord.port,
        srvRecord.target + "."
      )
    );
  }
}

The JSON schema requires priority, weight, and port as integers between 0 and 65535, plus a target hostname. As validated in tests/records.test.js (lines 1002-1014), these fields must conform to RFC 2782 standards.

Example SRV configuration:

{
  "records": {
    "SRV": [
      {
        "priority": 10,
        "weight": 5,
        "port": 5060,
        "target": "sip.example.com"
      }
    ]
  }
}

TLSA Records: DANE TLS Authentication

TLSA records support DNS-based Authentication of Named Entities (DANE) by associating TLS certificates with domain names. The dnsconfig.js implementation (lines 105-117) passes usage, selector, and matching type parameters to Cloudflare:

if (data.records.TLSA) {
  for (var tlsa in data.records.TLSA) {
    var tlsaRecord = data.records.TLSA[tlsa];
    records.push(
      TLSA(
        subdomainName,
        tlsaRecord.usage,
        tlsaRecord.selector,
        tlsaRecord.matching_type,
        tlsaRecord.certificate
      )
    );
  }
}

The record requires usage, selector, and matching_type as integers (0-255 per tests/records.test.js lines 1016-1028) and a certificate field containing hexadecimal certificate data.

Example:

{
  "records": {
    "TLSA": [
      {
        "usage": 3,
        "selector": 1,
        "matching_type": 1,
        "certificate": "2A3B4C5D..."
      }
    ]
  }
}

URL Records: HTTP Redirects via Cloudflare Workers

Unlike standard DNS records, URL records in is-a.dev implement HTTP redirects through a two-part system. The dnsconfig.js script (lines 132-135) creates a placeholder A record pointing to 192.0.2.1 (a reserved TEST-NET-1 address) with Cloudflare proxying enabled:

if (data.records.URL) {
  records.push(A(subdomainName, IP("192.0.2.1"), CF_PROXY_ON));
}

The actual redirect logic executes in a Cloudflare Worker that intercepts requests to this IP and issues 301/302 redirects to the target URL specified in the JSON. This approach allows HTTPS redirects and custom path mappings without exposing origin IP addresses.

Example configuration with custom paths:

{
  "records": {
    "URL": "https://my-portfolio.dev"
  },
  "proxied": true,
  "redirect_config": {
    "custom_paths": {
      "/blog": "https://blog.my-portfolio.dev"
    }
  }
}

Validation in tests/records.test.js (lines 553-564) requires URLs to use http:// or https:// schemes, parse correctly via new URL(), and not reference the same *.is-a.dev subdomain to prevent redirect loops.

Validation and CI Enforcement

Before any DNS changes deploy, tests/records.test.js validates every domain JSON file against strict schemas. The test suite checks that:

• Record keys belong to the allowed set: A, AAAA, CAA, CNAME, DS, MX, NS, SRV, TLSA, TXT, URL
• CAA, DS, SRV, and TLSA records contain arrays of properly typed objects with valid integer ranges and hexadecimal formats (lines 777-1028)
• URL records contain valid external URLs without self-references (lines 553-564)

Any validation failure blocks the CI pipeline, preventing malformed DNS configurations from reaching Cloudflare.

Summary

• is-a.dev stores domain configurations as JSON files in the domains/ directory, processed by dnsconfig.js during deployment.
• CAA records control certificate issuance through CAA() API calls with validated tag and value fields.
• DS records enable DNSSEC via DS() calls requiring key_tag, algorithm, digest_type, and hexadecimal digest parameters.
• SRV records map services to hosts using SRV() with automatic root dot appending to target hostnames.
• TLSA records implement DANE through TLSA() calls with usage, selector, and matching type integers.
• URL records create proxied A records to 192.0.2.1, with actual redirect logic handled by Cloudflare Workers.
• All record types undergo strict validation in tests/records.test.js before deployment.

Frequently Asked Questions

What is the difference between URL and CNAME records in is-a.dev?

CNAME records map your subdomain to another domain name at the DNS level, requiring the target to provide valid DNS resolution. URL records create an HTTP redirect through a Cloudflare Worker, allowing you to redirect to any URL including external domains, specific paths, or HTTPS destinations, while the DNS layer simply points to a dummy IP (192.0.2.1) with proxying enabled.

How does is-a.dev validate DNSSEC DS record parameters?

The validation suite checks that key_tag, algorithm, and digest_type are integers within valid DNSSEC ranges, and verifies that the digest field contains only valid hexadecimal characters. These checks occur in tests/records.test.js (lines 887-900) and must pass before the CI pipeline executes dnsconfig.js to publish the records.

Can I combine multiple special record types in a single domain?

Yes. A single JSON file in domains/ can include any combination of A, AAAA, CAA, CNAME, DS, MX, NS, SRV, TLSA, TXT, and URL records simultaneously. The dnsconfig.js script processes each record type independently and aggregates them into a single Cloudflare zone update.

Why does is-a.dev use 192.0.2.1 for URL redirects?

The IP address 192.0.2.1 belongs to RFC 5737's TEST-NET-1 block and is guaranteed not to route on the public internet. By creating an A record to this address with CF_PROXY_ON, is-a.dev ensures all HTTP traffic is intercepted by Cloudflare's edge network, where a Cloudflare Worker executes the actual redirect logic without exposing any origin server infrastructure.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}