# dig

A finding over DNS. Artist, title, BPM, key, all in a TXT record.



A finding is a point of light in the Galaxy, and `dig.fluncle.com` is the one you can reach with `dig`. Point a DNS query at a finding's coordinate and the answer comes back as a TXT record: artist, title, BPM, key, the day Fluncle found it, and the link home. No browser, no API client, just the resolver every machine already has.

```
$ dig random.dig.fluncle.com TXT +short
"v=fluncle1; id=012.1.0A; artist=GLXY; title=It's Whatever; album=Pinnacle; bpm=173.48; key=A minor; found=2026-06-11; url=https://www.fluncle.com/log/012.1.0A; spotify=https://open.spotify.com/track/5c1h0scE7Ck8gdRfLvMISZ"
```

## Names you can query [#names-you-can-query]

All names live under `dig.fluncle.com`. DNS is case-insensitive, so the coordinate's trailing letter can be upper or lower case.

| Name                          | Answers with                                  |
| ----------------------------- | --------------------------------------------- |
| `<coord>.dig.fluncle.com TXT` | That finding, e.g. `004.7.2I.dig.fluncle.com` |
| `random.dig.fluncle.com TXT`  | A random finding                              |
| `latest.dig.fluncle.com TXT`  | The newest finding                            |
| `dig.fluncle.com SOA` / `NS`  | Zone metadata                                 |

An unknown coordinate returns `NXDOMAIN`. A known name queried for a type other than TXT returns `NOERROR` with no answer (NODATA). Anything outside the zone is `REFUSED`; this is authoritative for one zone, not a recursive resolver.

## The TXT format [#the-txt-format]

One logical TXT record per finding. The payload is a single line of `key=value` pairs joined by `"; "`, built to read cleanly in a terminal and parse cleanly in a script.

```
v=fluncle1; id=011.1.6E; artist=Netsky; title=I See The Future In Your Eyes; album=Second Nature; bpm=171.09; key=C minor; found=2026-06-10; url=https://www.fluncle.com/log/011.1.6E; spotify=https://open.spotify.com/track/1rgIJkGSUqB3EgidQbEbxy
```

The grammar:

* **Version first.** `v=fluncle1` always leads. A parser that doesn't recognise the version should stop.
* **Keys** are stable and lowercase: `v`, `id`, `artist`, `title`, `album`, `bpm`, `key`, `found`, `url`, `spotify`. Optional fields (`album`, `bpm`, `key`, `spotify`) are omitted when absent; `v`, `id`, `artist`, `title` are always present.
* **`id`** is the finding's [Log ID](/docs/log-id&#x29; coordinate. &#x2A;*`found`** is the day Fluncle found it, `YYYY-MM-DD&#x60;. &#x2A;*`url`** is the canonical log page.
* **Separator safety.** Values are single-line; a literal `;` inside a value is downgraded to `,` so the `"; "` field separator stays unambiguous.
* **Multiple strings.** A TXT string maxes out at 255 bytes (RFC 1035). A longer payload is split across several strings on a `"; "` boundary; concatenate them (no separator) to get the payload back, then split on `"; "`.

Parse it in one line:

```bash
dig +short latest.dig.fluncle.com TXT \
  | tr -d '"' | sed 's/" "//g' \
  | tr ';' '\n' | sed 's/^ *//'
```

## How it works [#how-it-works]

`fluncle-dns` keeps no database. On each query it reads the public [API](/docs/api-overview) and renders the result as TXT, with a short in-memory cache so a hot coordinate or a `dig` retry storm doesn't hammer the API.

* A coordinate or `random` reads the finding from `/api/v1/tracks/<id>`.
* `latest` reads `/api/v1/findings?limit=1`; the list is newest-first, so the head is the latest finding.

Same archive as every other surface, this time spoken in DNS.