SYNTHRECORD(8)

💅 synthrecord — the manual, but make it cute

okay bestie, welcome to synthrecord(8), a page from the BIND 9 set of manuals. it's about a lil plugin that makes up PTR records on the fly. yes, literally conjures them out of thin air. iconic behavior honestly. 🦋

---

✨ NAME ✨

synthrecord — dynamically synthesize PTR records

like. it synthesizes them. dynamically. the name is not playing games. 💅

---

🌸 SYNOPSIS 🌸

plugin query "synthrecord.so" [{ parameters }];

that's it. that's the whole vibe. drop it in, add your lil { parameters } if you want, go off. ✨

---

💖 DESCRIPTION 💖

so synthrecord.so is a query plugin module for named, and what it does is enable named to synthesize forward and reverse responses for non-existent names in a zone. like. the name doesn't exist but the plugin says "and what about it" and answers anyway. main character energy fr fr. 👑

okay important part — this plugin can only be configured inside a zone clause. it does not go anywhere else. it knows its lane.

and here's the tea: the name of the zone decides which mode the plugin runs in. 🫖

• if the zone name ends with ip6.arpa or in-addr.arpa → the plugin operates in "reverse" mode
• for any other zone name → it operates in "forward" mode

🔄 reverse mode

in "reverse" mode, the module intercepts queries of type PTR.

if no authoritative answer can be found in the zone database, and if the IP address encoded in the query name matches one of the prefixes or addresses specified in allow-synth, then the module dynamically generates a response, and that response is constructed by concatenating:

1. the configured prefix
2. the IP address encoded in the query reverse name
3. the configured origin

boom. built different. 🎀

➡️ forward mode

in forward mode, the module intercepts queries of type A or AAAA.

if no authoritative answer can be found in the zone, and the query begins and ends with the configured prefix and origin, and an IP address can be parsed from the part in between, then that IP address will be returned to the client. slay. 🌈

⚠️ note: synthesized responses are not signed, so the use of this module is incompatible with DNSSEC. do NOT try to make them hold hands, it will not work bestie. 💀

---

🧚 EXAMPLE 🧚

zone "1.168.192.in-addr.arpa." {
    type primary;
    file "1.168.192.in-addr.arpa.db";
    plugin query "synthrecord" {
        prefix "dynamic-";
        origin "example.";
    };
};

zone "e.f.a.c.ip6.arpa." {
    type primary;
    file "e.f.a.c.ip6.arpa.db";
    plugin query "synthrecord" {
        prefix "dynamic-";
        origin "example.";
    };
};

zone "example." {
    type primary;
    file "example.db";
    plugin query "synthrecord" {
        prefix "dynamic-";
        origin "example.";
        allow-synth { 192.168.1/24; cafe::/16; };
        ttl 3600;
    };
};

okay so in the above configuration, let's walk through it 👇

a PTR query for the name 5.1.168.192.in-addr.arpa (which represents the IPv4 address 192.168.1.5) receives the synthesized response dynamic-192-168-1-5.example.. hyphens replace dots in this address representation. noted. 📝

similarly, a PTR query for the name e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.e.f.a.c.ip6.arpa (which represents the IPv6 address cafe::cafe) receives the synthesized response "dynamic-cafe--cafe.example." in this format, hyphens replace colons; two consecutive hyphens are the same as two consecutive colons.

but — and this is the plot twist 😭 — a DNS label cannot begin or end with a hyphen. so an address like ::1 would be represented as 0--1, and 2001:db8:: would be 2001-db8--0.

finally, an AAAA query for dynamic-cafe--cafe.example would receive a synthesized response with the IPv6 address cafe::cafe, and and an A query for dynamic-192-168-1-5.example would receive 192.168.1.5. (yes, the original says "and and". we keep it. it's part of the lore. 🙈)

---

🌟 PARAMETERS 🌟

• prefix — specifies the prefix of the synthesized name. it must be a single-label name. this parameter is mandatory. no prefix, no deal, bestie. 🎀
• origin — specifies the origin of the synthesized name. this may be the same as the zone origin, or a descendent. it cannot be below a delegation point. this parameter is mandatory for reverse zones, but when configured in forward mode, it defaults to the zone name. convenient much? ✨
• allow-synth — this option is an address-match list, which can be used to restrict response synthesis to certain addresses. the default is any, meaning that in reverse mode, any address within the zone can receive a synthesized answer, and in forward mode, any name with a parseable address encoded in it will return that address in an A or AAAA answer. note that in reverse mode, at least some of the addresses within the zone's namespace must be allowed; otherwise the plugin will be unable to synthesize any responses. so like. don't lock yourself out of your own house 💀
• ttl — specifies the TTL of the synthesized resource record in the answer section. the default is 300. 🕒

---

👀 SEE ALSO 👀

BIND 9 Administrator Reference Manual. that's the one, that's the required reading, iykyk 📚

---

✍️ Author

Internet Systems Consortium

©️ Copyright

2026, Internet Systems Consortium

---

okay that's the whole page, you ate it, no crumbs left 🫶 now go synthesize some records responsibly. and remember: not signed, not DNSSEC compatible, don't come for me when your validator cries. 💜

this was BIND 9.21.26, dated 2026-09-03. bye bestie, mwah 💅✨🌸