Oracle Net Service Name Resolution Options

Oracle database name resolution is provided by Oracle Net Services.  Oracle Net Services connect string (a.k.a. connect descriptor) resolution is to Oracle database clients what Domain Name Services (DNS) is to TCP/IP clients for host name to IP address resolution. For example, with DNS a TCP/IP client would resolve a hostname like hrdb.dbauthdemo.com to an IP address like 10.10.0.1.  In the same way, an Oracle database client would resolve through Oracle Net services a service name alias like pdb1 to a connect string like the following:

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hrdb.dbauthdemo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=pdb1)))

In the above sample connect string, the pdb1 service name resolves to a connect string for enabling a database client to connect to the pdb1 service name via TCP to host hrdb.dbauthdemo.com on port 1521.

As customers expand their Oracle database estate and transition Oracle databases from on premises to one or more  clouds and strengthen their security posture through enabling TLS encryption or enabling multi-factor authentication, the number and complexity of connect strings will increase dramatically over time.  Therefore, it is important to ensure accurate and up-to-date name resolution through centralizing Oracle database server name resolution.

Net Service Name Resolution Options

The most common net service naming resolution configuration approaches include the following.

1. Independent Client Configs

Every database client independently specifies a connect string or maintains name service entry it's own  local tnsnames.ora file.  Using previous example, here is a sample connect string for the service name alias pdb1:

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hrdb.dbauthdemo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=pdb1))) 

Here is an equivalent net service connect descriptor entry from a tnsnames.ora file: 

PDB1 = 
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=hrdb.dbauthdemo.com)(PORT=1521))
    (CONNECT_DATA=
      (SERVICE_NAME= pdb1)
    )
  )

2. Unified tnsnames.ora File

With this option, the database administrative team creates and maintains a single tnsnames.ora file that is either published for internal reference or distributed to all database clients.  This method is better than independently managed connect strings and tnsnames.ora files but is also fraught with possible data inconsistency over time because the clients don't necessarily have to refresh their tnsnames.ora files with the most current version. There can also be security concerns with method used to propagate the tnsnames.ora file to database clients.

3. Centralized Directory Naming

This is one of the most common options employed by customers with a large number of database servers and clients that need to be kept up-to-date.  In this solution, you setup one or more LDAP-based directory service instances according to your high availability requirements and load the directory service with your TNS entries using either dbca tool that comes with the Oracle database or create your own custom TNS entries.

The main directory service products employed for this architecture include Oracle Unified Directory (OUD) and Oracle Internet Directory (OID) though others could be used as well.  One important note on directory server product selection is that Active Directory (AD) can technically be used for this purpose but Microsoft strongly discourages extending AD schema or loading non-Microsoft data in AD because it can put AD upgrades at risk.  I've worked with hundreds of customers on this use case and I've yet to meet a single large customer that allows this data to be loaded into their production AD service.

 Regarding high availability, the recommended maximum high availability architecture includes use local and geographic load balancers that support proper LDAP service tests.  From a security perspective, note that exclusive use of encrypted LDAPS connections is accomplished by not including non-encrypted port in the DIRECTORY_SERVERS ldap.ora.  Further, authenticated lookups is available as well using additional properties for basic authentication are supported for LDAP-based name resolution as well.

An example configuration using OUD 12cPS4 is covered at the following blog post:https://www.braddiggs.com/2023/10/oud-12cps4-use-case-oracle-database.html

The equivalent net service connect descriptor entry for the pdb1 alias from a directory services looks like the following: 

dn: cn=pdb1,cn=OracleContext,dc=hrdb.dbauthdemo,dc=com
objectclass: orclApplicationEntity
objectclass: orclDBServer_92
objectclass: orclService
objectclass: orclDBServer
objectclass: top
orclNetDescString: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hrdb.dbauthdemo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=pdb1))

 

4. Centralized Configuration Provider [New with 23ai] 

This is a new option was introduced with Oracle database version 23ai that enables connect descriptors to be loaded into HTTPS based object storage in JSON format. 

 There are several restrictions namely that it only works with 23ai and newer version clients and that the WALLET_LOCATION only supports SYSTEM.  Only supporting SYSTEM for the WALLET_LOCATION means that all certificates must be signed by a public certificate authority or your private certificate authority chain must be loaded into the host trust store where the database client is run.  This new feature along with the full set of restrictions is covered at the following link: https://docs.oracle.com/en/database/oracle/oracle-database/23/netrf/centralized-configuration-provider-naming-parameters.html 

The equivalent net service connect descriptor entry of the pdb1 alias in JSON format for centralized configuration provider looks like the following: 

{
 "connect_descriptor": "(DESCRIPTION=
                           (ADDRESS=
                              (PROTOCOL=TCP)
                              (HOST=hrdb.dbauthdemo.com)
                              (PORT=1521))
                           (CONNECT_DATA=
                              (SERVICE_NAME=pdb1))
                        )"
}

A JDBC reference to the above entry might look like:

jdbc:oracle:thin:@config-https://objectstorage.us-phoenix-1.oraclecloud.com/n/orasenatdpltintegration03/b/azure/o/pdb1.json

A more robust list of examples of the available configuration providers are available at the following blog post: https://blogs.oracle.com/developers/post/jdbc-config-providers

I hope you find this information helpful.

Blessings!

Braed