Bulk inputs
Services
Protocols
Port mode
Shared targets
One list applied to every selected combo. Same priority / weight semantics as the single tool.
Tools /
Engineering & scale
/ Vol III
Bulk DNS SRV Builder
For when one set of targets serves many services. Pick the
services and protocols you need, drop in the shared targets
once, and the tool emits every _service._proto
combo's SRV records with conventional ports filled in.
Single-combo edits? See the
standard SRV builder instead.
Output
0×0
No combos selected
Tick at least one service + one protocol above.
Per-combo summary
| Owner | Port | Targets | Note |
|---|
Combined BIND zone-file
Each combo gets a comment header so the file stays scannable.
Test commands
One dig per combo so you can spot the missing one when something doesn't resolve.
Downloads
.zone wraps the records in a BIND-style file with placeholder
$TTL, $ORIGIN, and commented SOA / NS templates.
.json is structured for Terraform, Pulumi, or any IaC tool
that consumes record arrays.
Findings
Reading the matrix
Why bulk?
A typical SIP edge needs at least three records: _sip._udp, _sip._tcp, and _sips._tcp — all pointing at the same pool of SBCs. The bulk tool lets you describe the pool once and emit all three. Add XMPP, STUN, or TURN to the mix and you'd otherwise be filling in seven forms by hand.
Conventional ports
sip rides 5060 over UDP or TCP; sips and sip-over-TLS ride 5061. xmpp-client uses 5222; xmpp-server uses 5269; xmpps-client uses 5223. stun / turn use 3478; stuns / turns use 5349. H.323 call signaling is 1720 (TCP); RAS is 1719 (UDP). kerberos is 88, ldap is 389. The convention table fills these in for every combo unless you switch to override mode.
Unusual combos get flagged
Some pairs don't make sense: _sips._udp (SIPS only over TCP), _xmpp-client._udp (XMPP is TCP-only), _h323rs._tcp (RAS is UDP), etc. The per-combo summary table flags them. Records still emit if you really want them — sometimes legacy gear demands them.
Shared priority / weight
The targets list is shared across every combo, so the same priority and weight ladder applies everywhere. That's almost always what you want: if sip1.example.com is the primary for SIP, it's also the primary for SIPS and XMPP on that pool. If you need different ladders per combo, use the single SRV builder.
NAPTR scope
The NAPTR record sits at the owner-domain root and points at one SRV owner — the one matching the service-tag you pick. RFC 3263 says the SIP UA walks the NAPTR set; you can publish multiple NAPTRs for the same owner with different priorities. This tool emits one; run it twice with different tags if you need both, or use the single builder for finer NAPTR control.
.zone file structure
The downloaded zone file includes a commented SOA and NS block as placeholders — fill them in (serial, NS targets) before publishing. The $TTL and $ORIGIN directives are set from your inputs. Records use the short owner form so the file is portable across $ORIGIN changes.
.json output
JSON is one array of records, each carrying the full owner, type (SRV / NAPTR), TTL, and a structured data field. Drop straight into a Terraform for_each over cloudflare_record or aws_route53_record; the data shape mirrors what those providers expect.
TTL guidance
3600 (1h) is the steady-state default. During a cutover, drop TTL to 60–300 at least TTL × 2 ahead of the switch so caches drain; restore once the new records stabilize. The bulk tool applies one TTL across every combo — split into two runs if some records need different TTLs during a staged rollout.