Feature: Use DNS SRV records for connecting

On 13 Aug 2019, at 11:50, Feike Steenbergen <feikesteenbergen@gmail.com> wrote:

I'd like to get some feedback on whether or not implementing a DNS SRV feature
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
—

Feike Steenbergen <feikesteenbergen@gmail.com> writes:

I'd like to get some feedback on whether or not implementing a DNS SRV feature
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

Hi,

On 2019-08-13 10:43:07 -0400, Tom Lane wrote:

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.

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

On 14 Aug 2019, at 23:01, Andres Freund <andres@anarazel.de> wrote:

On 2019-08-13 10:43:07 -0400, Tom Lane wrote:

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.

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

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.

Hi hackers!

On 22 Apr 2026, at 14:48, Andrey Borodin <x4mmm@yandex-team.ru> 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]https://github.com/jackc/pgx/pull/2538 about the
postgres+srv:// URI scheme I proposed here.

The issue is specific to Go's net/url package [1]https://github.com/golang/go/issues/75859. 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]https://github.com/jackc/pgx/issues/2404

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://user@cluster.example.com/mydb?target_session_attrs=read-write
postgres+srv://user@cluster.example.com/mydb

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

pgsrv://user@cluster.example.com/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

Hello!

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

On Tue, May 12, 2026 at 2:47 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:

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]

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.

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.

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).

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.

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.)

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.

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.

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

pgsrv://user@cluster.example.com/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

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.

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.

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.