The Address as Identity

An allocation hands out one routable IPv6 /128 from 2a04:2a01::/32, announced by AS219419 and covered by an RPKI route origin authorisation. The upper half of the address carries routing and account topology. The lower half is the identity itself, and every name and record below is a function of it.

The name is derived from the address

Take the last four hextets of the address, zero-pad each one to four hex digits, concatenate them, and prefix the result with a. That string is the handle. The fully qualified name is the handle, then the account handle, then the identity zone.

address        2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478
last hextets   e3b0  51ff  3bf7  f478
handle         ae3b051ff3bf7f478
name           ae3b051ff3bf7f478.t<tenant>.agents.whisper.online

Because the derivation runs one way only, there is nothing to look up and nothing to trust. Anyone holding the address can compute the name it must answer to, then check that the DNS agrees.

The account handle

The middle label is an opaque account handle of the form t<tenant>: the letter t followed by a fixed run of hex. It is the same label in DNS, in the registry and in the verdict endpoint. A raw account identifier never appears in any of them, so publishing an identity does not publish who owns it, only that one owner owns all of them.

The friendly name

An allocation can also carry a short label as a CNAME beside the canonical name, at <label>.t<tenant>.agents.whisper.online. It is convenient and it is guessable, which is why publication is a choice made when the identity is minted. Read the member_published field rather than an empty member field to know whether a label went into public DNS.

The two-way lock

The reverse record and the forward record live in separate delegations and are populated independently. PTR under ip6.arpa names the identity; AAAA under the forward zone names the address. Forward-confirmed reverse DNS is the pair agreeing, and a mismatch is the signal that someone is claiming a name they were not given.

dig -x 2a04:2a01:b69a:6717:e3b0:51ff:3bf7:f478 +short
dig +short AAAA ae3b051ff3bf7f478.t<tenant>.agents.whisper.online

Both zones are signed with DNSSEC, so a validating resolver returns the AD bit on each answer. Read that bit. Without it you have two strings that agree, and no evidence that either came from the zone it claims.

What hangs off the address

The same lower half seeds the rest of the record set. The TLSA record pins the identity to its own key, and the public registry answers for the allocation. Issuing the address also writes a leaf into the transparency log. The proof chain walks each one in order. If you would rather the names sat under a name your customers already recognise, delegate your own apex and the derivation runs unchanged underneath it.