I have an Azure AO AG which consists of three servers (all WS-2019 & SQL-2019 CU8):

  • A - Subnet 1 - Principal Server (Sync)
  • B - Subnet 1 - Secondary Server (Sync)
  • C - Subnet 2 - Secondary Server (Async)

I have created a DNN Listener on the resource which looks to be up an running but when I connect to the Listener it resolves to server C. I have confirmed that in the cluster and AG, server A is the principal. I have tried failing over to server B which seems to work fine but the listener still only resolves to Server C.

I pulled out the Cluster Logs and I have a warning that jumped out to me that does not seem to appear on google:

2020/11/12-15:27:48.720 WARN [RES] Distributed Network Name <6789>: Configuration: Obtaining exclude networks failed with error 2.


4 Answers 4


Default 1433 SQL port is not supported by DNN listener if SQL server uses this port.
Additionally, In case there are multiple AGs with DNN listeners in scope of single cluster, every DNN listener should be configured using unique custom port. The custom port should be added to firewall exceptions on all AG nodes. When connecting using SSMS, it is necessary to specify custom port that was configured for DNN listener in format: DNSName,port. It is also better to explicitly specify AG database in SSMS connection properties and MultiSubnetFailover=True in Additional Connection parameters. That worked for me.



A Distributed Network Name is like an AG Listener in a Multi-Subnet Failover cluster. It's registered in DNS with multiple IP addresses.

Clients resolving the name from DNS will receive a list of IP addresses, and it requires client-side logic to select the correct one. The SQL Server client drivers do this with the MultiSubnetFailover connection string and the Transparent Network IP Resolution Feature as a fallback. And the logic is simple. The client will connect to one of the IP addresses that has the target port open. And so the DNN must use a port that no SQL Server (or other process) in the cluster is listening on.

If you test with something like ping.exe, or telnet, or test-netconnection it will just connect to the first IP address returned from DNS, which may not be the primary node.

  • I have configured the DDN listener using the script provided form the microsoft documentation link I ran this script on the principal server and that server is now listening on port 6789 however the other two server are not listening on that port. However SSMS still resolves to the incorrect server (one not listening on that port)
    – Lickrob
    Commented Nov 30, 2020 at 9:10

Availability Group DNN listeners aren't supported until CU8 so you may need to upgrade?



  • can you please quote the relevant parts, as link age.
    – nbk
    Commented Nov 24, 2020 at 10:51
  • Apologies, that is a typo, i'm running SQL 15.0.4073.23
    – Lickrob
    Commented Nov 25, 2020 at 16:13

I am putting this here for anyone being silly like me.

In the SSMS Connect to Server dialog, make sure you separate the dnn listener name & the port with a comma, not a colon.

That & adding the MultiSubnetFailover=True in the Additional Connection parameters worked for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.