Subject: Feature: Use DNS SRV records for connecting

From: Feike Steenbergen <[email-masked]>
Date: Tue, 13 Aug 2019 11:50:18 +0200

Hi all,

I'd like to get some feedback on whether or not implementing a DNS SRV feature
for connecting to PostgreSQL would be desirable/useful.

The main use case is to have a DNS SRV record that lists all the possible
primaries of a given replicated PostgreSQL cluster. With auto failover
solutions like patroni, pg_auto_failover, stolon, etc. any of these endpoints
could be serving the primary server at any point in time.

Combined with target_session_attrs a connection string to a highly-available
cluster could be something like:

   psql "dnssrv=mydb.prod.example.com target_session_attr=read_write"

Which would then resolve the SRV record _postgresql._tcp.mydb.prod.example.com
and using the method described in RFC 2782 connect to the host/port combination
one by one until it finds the primary.

A benefit of using SRV records would be that the port is also part of the DNS
record and therefore a single IP could be used to serve many databases on
separate ports. When working with a cloud environment or containerized setup
(or both) this would open up some good possibilities.

Note: We currently can already do this somehow by specifying multiple
hosts/ports in the connection string, however it would be useful if we could
refer to a single SRV record instead, as that would have a list of hosts
and ports to connect to.

DNS SRV is described in detail here:
https://tools.ietf.org/html/rfc2782

I'd love to hear some support/dissent,

regards,

Feike

---

From: Graham Leggett <[email-masked]>
Date: Tue, 13 Aug 2019 12:21:37 +0200

> for connecting to PostgreSQL would be desirable/useful.

A big +1.

We currently use SRV records to tell postgresql what kind of server it is. This way all of our postgresql servers have an identical configuration, they just tailor themselves on startup as appropriate:

_postgresql-master._tcp.sql.example.com.

The above record in our case declares who the master is. If the postgresql startup says “hey, that’s me” it configures itself as a master. If the postgresql startup says “hey, that’s not me” it configures itself as a slave of the master.

We also use TXT records to define the databases we want (with protection against DNS security issues, we never remove a database based on a TXT record, but signed DNS records will help here).

_postgresql.sql.example.com TXT "v=PGSQL1;d=mydb;u=myuser"

We use a series of systemd “daemons” that are configured to run before and after postgresql to do the actual configuration on bootup, but it would be great if postgresql could just do this out the box.

Regards,
Graham
—

---

From: Tom Lane <[email-masked]>
Date: Tue, 13 Aug 2019 10:43:07 -0400

> for connecting to PostgreSQL would be desirable/useful.

How would we get at that data without writing our own DNS client?
(AFAIK, our existing DNS interactions are all handled by getnameinfo()
or other library-supplied functions.)

Maybe that'd be worth doing, but it sounds like a lot of work and a
lot of new code to maintain, relative to the value of the feature.

			regards, tom lane

---

From: Andres Freund <[email-masked]>
Date: Wed, 14 Aug 2019 11:01:43 -0700

Hi,

> lot of new code to maintain, relative to the value of the feature.

It might have enough independent advantages to make it worthwhile
though.

Right now our non-blocking interfaces aren't actually in a number of
cases, due to name resolution being blocking. While that's documented,
it imo means that our users need to use a non-blocking DNS library, if
they need non-blocking PQconnectPoll() - it's imo not that practical to
just use IPs in most cases.

We also don't have particularly good control over the order of hostnames
returned by getaddrinfo, which makes it harder to implement reliable
round-robin etc.

Greetings,

Andres Freund

---

From: Andrey Borodin <[email-masked]>
Date: Wed, 22 Apr 2026 14:48:50 +0500

> On 14 Aug 2019, at 23:01, Andres Freund <[email-masked]> wrote:
> 

Here is a patch prototyping SRV-based discovery for libpq, reviving
the idea from the 2019 thread.

Tom asked how we'd get SRV data without writing our own DNS client.
On POSIX, res_query(3) from libresolv does the lookup and
dn_expand(3) decompresses names in the response - the same library
that Kerberos and LDAP support already depend on. On Windows,
DnsQuery() from windns.h returns a typed linked list with no wire-format
parsing needed. The resolver is about 200 lines and uses no DNS logic
of our own.

Regarding non-blocking resolution raised by Andres: res_query() is
blocking, as is the existing getaddrinfo() call for regular hosts.
This patch does not make things worse, but does not improve them
either. Async DNS resolution is a separate, larger problem.

A new connection parameter "srvhost" (env: "PGSRVHOST") causes libpq
to query "_postgresql._tcp.<srvhost>" before connecting. I chose
"srvhost" over the original "dnssrv" suggestion to align with the
existing "host" parameter naming. Two URI schemes are supported as
shorthand:

    psql "postgresql+srv://cluster.example.com/mydb?target_session_attrs=read-write"
    psql "postgres+srv://cluster.example.com/mydb?target_session_attrs=read-write"

Given the DNS records:

    _postgresql._tcp.cluster.example.com. SRV 10 50 5432 primary.example.com.
    _postgresql._tcp.cluster.example.com. SRV 20 50 5432 standby1.example.com.
    _postgresql._tcp.cluster.example.com. SRV 20 50 5432 standby2.example.com.

The resolved host list is sorted per RFC 2782 and injected into the
existing multi-host machinery before connhost[] is built, so
target_session_attrs, load_balance_hosts, and failover work on the
expanded list without any changes to PQconnectPoll.

"srvhost" is mutually exclusive with "host" and "hostaddr".  Multiple
hosts in a "+srv" URI are rejected - expansion is DNS's responsibility.

I'm proposing this across the PostgreSQL driver ecosystem (pgx, pgjdbc,
npgsql, and now libpq). I would be happy to hear a feedback.

Best regards, Andrey Borodin.

---

From: Andrey Borodin <[email-masked]>
Date: Tue, 12 May 2026 14:46:38 +0500

Hi hackers!

> On 22 Apr 2026, at 14:48, Andrey Borodin <[email-masked]> wrote:
> 
> I'm proposing this across the PostgreSQL driver ecosystem

While preparing equivalent patches for pgx, pgjdbc and npgsql, Jack
Christensen (pgx maintainer) raised a concern [0] about the
postgres+srv:// URI scheme I proposed here.

The issue is specific to Go's net/url package [1]. In Go 1.26 the URL
parser was tightened and broke parsing of HA connection strings of
the form postgresql://user@h1:1,h2:2/db (colons inside the authority
after a comma). The Go team addressed this by relaxing validation,
but only for the "postgres" and "postgresql" schemes - any new
scheme, including "postgres+srv", gets the strict modern parser. For
a single SRV name in the authority this is probably fine in practice,
but Jack reasonably points out that deviating from postgresql:// is
a compatibility bet without much upside. [2]

Per RFC 3986 §3.1 the "+" in a scheme name is syntactically legal.
Per RFC 7595 / BCP 35, schemes can be registered with IANA, but
neither "postgresql" nor "mongodb+srv" is in the IANA registry today,
so there is no formal gate to pass - just our own consensus on what
to ship.

On a related note, "mongodb", "redis" and "rediss" (Redis over TLS) are
both registered with IANA as provisional schemes, while "mongodb+srv" is
not - so there is no consistent precedent either way.

Given the above, I see three options:

1. Drop the +srv URI scheme entirely. Keep only the srvhost= keyword
   parameter. Smallest API surface, no compatibility concerns for
   any driver. No URI form to use DNS SRV at all.

     srvhost=cluster.example.com dbname=mydb target_session_attrs=read-write

2. Keep postgresql+srv:// / postgres+srv:// as proposed. Aligns with
   the mongodb+srv:// precedent and reads naturally; a single cluster
   name in the authority is unaffected by Go's stricter parser, but
   driver authors take on a small risk for any future tightening.

     postgresql+srv://[email-masked]/mydb?target_session_attrs=read-write
     postgres+srv://[email-masked]/mydb

3. Some other shorthand (pgsrv://). Avoids "+" entirely but invents
   yet another name with no clear advantage.

     pgsrv://[email-masked]/mydb?target_session_attrs=read-write

My slight preference is (1). The srvhost= parameter alone expresses
intent unambiguously and avoids opening a second scheme namespace
that every driver in the ecosystem would need to replicate.

If we go with option (2), registering "postgresql+srv" as a
provisional scheme with IANA (First Come First Served per RFC 7595
§7.1) would take minimal effort and give the scheme a stable
reference. Interestingly, even "postgresql" itself is not in the
IANA registry despite being in use for over 20 years, so registration
is not a prerequisite — but it would be a nice step toward treating
SRV as a first-class URI scheme on par with mongodb+srv.

On the other note "redis" and "rediss" are both provisioned with IANA.

WDYT?

Best regards,
Andrey Borodin.

[0] https://github.com/jackc/pgx/pull/2538
[1] https://github.com/golang/go/issues/75859
[2] https://github.com/jackc/pgx/issues/2404

---

From: Jacob Champion <[email-masked]>
Date: Tue, 12 May 2026 09:07:59 -0700

Hello!

I'm speaking only on the design questions here; I have not looked at
the patch implementation yet.

> a compatibility bet without much upside. [2]

So this doesn't answer your broader question, really, but I consider
it a Very Good Thing that Go is enforcing stricter validation. If we
choose to introduce a brand-new scheme, I think we should do it by the
book and not carry over our oddities from 2012.

> not - so there is no consistent precedent either way.

As a continuation of the above, I think it'd be good to ask for IETF
review on any new scheme. The [scheme]+[variant]: form has some
uptake, but there are also expert reviewer notes saying that some
attempts might make things difficult for implementers (or others in
the ecosystem).

>    any driver. No URI form to use DNS SRV at all.

Either way, we'll need to define the semantics of mixing this new mode
with the existing parameters. I think that's likely to introduce its
own subtle compatibility concerns if we don't design it up front.

(Your proposal doesn't introduce this problem, but we never should
have allowed query parameters to modify the prior components --
scheme, authority, path -- of the URI. I am strongly motivated to fix
that, though I don't really want to derail SRV conversations too much
with it.)

>    driver authors take on a small risk for any future tightening.

Can you elaborate on the additional risk?

IMO, if a URI identifies a single resource (the cluster), it doesn't
seem like anyone needs to support our comma pseudo-syntax anymore.
Drivers that want to connect to multiple clusters can take multiple
fully formed URIs, and define how to configure that in a way that
makes sense for them.

>      pgsrv://[email-masked]/mydb?target_session_attrs=read-write

I guess I don't see what this accomplishes. The `+` is not the problem, right?

--

I would additionally propose options 4 and 5 (which you don't need to
feel obligated to give any thought to):

4. Use the new behavior opportunistically somehow, similar to how
https: has continued to evolve the underlying protocol and DNS lookup
without any scheme changes at all. Whether this is technically
feasible without usability and security concerns... I don't know at
this point.

5. Moonshot: break compatibility outright, and design a scheme that
does exactly what we want in 2026. Strong URI semantics, enforcement
of TLS, useful DNS semantics, etc., etc. Represents complete
derailment of the thread. :)

Thanks,
--Jacob

---

From: Zsolt Parragi <[email-masked]>
Date: Tue, 12 May 2026 22:05:45 +0100

Hello!

Shouldn't srvhost be freed in freePGconn?

+ /*
+ * If srvhost is set, validate mutual exclusivity with host/hostaddr and
+ * then resolve _postgresql._tcp.<srvhost> SRV records, populating
+ * conn->pghost and conn->pgport from the sorted results.  This must
+ * happen before the host-array allocation below.
+ */
+ if (conn->srvhost != NULL && conn->srvhost[0] != '\0')

Shouldn't this also cover port? The current behavior with it seems inconsistent.

> expanded list without any changes to PQconnectPoll.

Doesn't RFC 2782 specifies a weighted random selection? The current
code seems to be deterministically sorted by weight.
RFC also says that weight=0 should be specially handled, it provides a
detailed algorithm about the random selection method.