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

> Discover how is-a.dev manages special DNS record types like CAA, DS, SRV, TLSA, and URL using JSON config and Cloudflare API. Learn about schema validation.

- Repository: [is-a.dev/register](https://github.com/is-a-dev/register)
- Tags: deep-dive
- Published: 2026-03-09

---

**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`](https://github.com/is-a-dev/register/blob/main/dnsconfig.js), with strict schema validation enforced by [`tests/records.test.js`](https://github.com/is-a-dev/register/blob/main/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`](https://github.com/is-a-dev/register/blob/main/dnsconfig.js) (lines 45-48), the system iterates over CAA record arrays and constructs Cloudflare `CAA()` objects:

```javascript
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:

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

```

According to [`tests/records.test.js`](https://github.com/is-a-dev/register/blob/main/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`](https://github.com/is-a-dev/register/blob/main/dnsconfig.js) (lines 58-63) maps JSON fields directly to the Cloudflare `DS()` constructor:

```javascript
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:

```json
{
  "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`](https://github.com/is-a-dev/register/blob/main/dnsconfig.js) (lines 96-100), the system appends a trailing dot to the target hostname to ensure proper DNS root resolution:

```javascript
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`](https://github.com/is-a-dev/register/blob/main/tests/records.test.js) (lines 1002-1014), these fields must conform to RFC 2782 standards.

Example SRV configuration:

```json
{
  "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`](https://github.com/is-a-dev/register/blob/main/dnsconfig.js) implementation (lines 105-117) passes usage, selector, and matching type parameters to Cloudflare:

```javascript
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`](https://github.com/is-a-dev/register/blob/main/tests/records.test.js) lines 1016-1028) and a `certificate` field containing hexadecimal certificate data.

Example:

```json
{
  "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`](https://github.com/is-a-dev/register/blob/main/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:

```javascript
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:

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

```

Validation in [`tests/records.test.js`](https://github.com/is-a-dev/register/blob/main/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`](https://github.com/is-a-dev/register/blob/main/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`](https://github.com/is-a-dev/register/blob/main/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`](https://github.com/is-a-dev/register/blob/main/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`](https://github.com/is-a-dev/register/blob/main/tests/records.test.js) (lines 887-900) and must pass before the CI pipeline executes [`dnsconfig.js`](https://github.com/is-a-dev/register/blob/main/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`](https://github.com/is-a-dev/register/blob/main/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.