Tools / Engineering & scale / Vol III

DNS SRV Record Builder

Build RFC 2782 SRV records (and the optional NAPTR that sits above them for RFC 3263 SIP discovery) without misplacing a dot, transposing a priority, or guessing how BIND wants $ORIGIN to look. Add as many targets as you need — the tool emits all of them with the right priority / weight semantics for load-balancing and failover — and gives you the dig commands to verify the records once they're published. Need records for many service+protocol combos at once? Use the bulk SRV builder instead.

Record details

The base domain. The full owner is service.protocol.domain.

3600 (1h) is typical; drop to 60–300 during a failover cutover.

Targets

Each target row becomes one SRV record. Equal priorities load-balance via weight; different priorities define primary / secondary failover.

NAPTR (optional)

Service-tag controls what kind of SRV the NAPTR points at. The matching SRV owner is computed for you below.

Output

SRV
_sip._tcp.example.com
1 target · TTL 3600

BIND zone-file ($ORIGIN form)

 
 
 
 
 
BIND zone-file (full owner)
 
  
 
 
Self-contained — paste anywhere without worrying about $ORIGIN.
 
 
 
NAPTR (RFC 3263 chain)
 
  
 
 
A SIP client following RFC 3263 hits NAPTR first to pick the protocol family, then the matching SRV, then A/AAAA.
 
 
 
Test commands
 
  
 
 
Run after publishing to verify the resolver returns what you expect.
 
  
 
 
 
Reading SRV semantics
 
 
 
The five fields
 

RFC 2782: priority weight port target. The owner
              name is _service._proto.name. Everything else in the
              record line is BIND meta (TTL, CLASS, RR type).

 
 
 
Priority = failover ladder
 

Clients try targets in priority order, lowest first.
              Different priorities give you primary / secondary / tertiary
              failover. A target only gets traffic if everything below
              its priority is unreachable.

 
 
 
Weight = load distribution
 

Within the same priority, weight controls the
              probability a client picks one target over another. Weight
              0 means "use only if nothing else is available."
              Two targets at 10 / 90 split 10% / 90% of new sessions.

 
 
 
RFC 3263 — SIP discovery chain
 

A SIP UA resolving sip:alice@example.com walks
              the chain: NAPTR (pick protocol family) → SRV (pick target
              + port + balance) → A/AAAA (resolve host). The NAPTR is
              optional; without it the UA tries
_sips._tcp then _sip._tcp then
_sip._udp in that preference order.

 
 
 
Port conventions
 
 5060 for _sip._udp and _sip._tcp.
5061 for _sips._tcp (SIP-over-TLS).
              Non-standard ports work but every UA / firewall / SBC config has
              to know — the tool warns when the port doesn't match the
              service.

 
 
 
Trailing dot — or $ORIGIN
 

A fully-qualified domain in a BIND zone file
              ends in a dot (sip1.example.com.). Without the
              trailing dot, BIND appends the current
$ORIGIN — so sip1 in a zone for
example.com resolves to sip1.example.com.
              The tool emits both forms so you can paste whichever your
              zone style uses.

 
 
 
TTL during a cutover
 

The TTL caps how long a stale answer can linger in
              resolvers. The standard playbook for an SRV cutover:
(1) 48 hours ahead, drop TTL to 60–300;
(2) at cutover, publish the new records;
(3) after stabilization, restore TTL to 3600+ to
              cut resolver load.

 
 
 
DNS provider syntax differs
 

BIND zone format is the lingua franca but DNS providers
              (Route 53, Cloudflare, Google Cloud DNS, etc.) usually want
              the four SRV fields as separate inputs in their UI: priority,
              weight, port, target. The tool shows the BIND form; you
              transcribe the fields by hand.