The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36

The communication channel that between Exchange client and Exchange server is based on a simple concept, in which Exchange client address the Exchange server by using the Exchange host name or, if we want to be more accurate – the Exchange server FQDN.

The variety of the services that are offered by Exchange server to his Exchange client begging for Exchange web services and, ending with services for the webmail client such as OWA, are implemented by the Exchange client that access this Exchange service by using a URL address.

Regarding the relationships that exist between an Exchange server and Outlook client, all of this information is packaged and shipped to an Outlook client via the Autodiscover response that is provided by the Exchange server.

As mentioned in a previous article, each public-facing Exchange server has two identities – the private vs. the public identifies.

When Exchange provides information about the available Exchange web services, the information is provided in two different “formats”:

• Information relevant to internal Outlook client
• Information relevant to external Outlook client

The main difference in the information that is provided for internal vs. the external Outlook client is the Exchange web services URL address.

• The Information relevant for the internal Outlook client includes Exchange web services URL address that uses the internal Exchange FQDN.
• The Information relevant for external Outlook clients includes Exchange web services URL address that uses the external Exchange FQDN.

URL address concept and Exchange web services

Although apparently, we are familiar with the concept of using a web address (URL), I would like to devote the following section, to the subject the Autodiscover and URL address because this subject is not as simple as it seems.

In our journey to become an “Autodiscover professional”, we need to be familiar with

1. The structure of the Exchange web services URL address
2. The different part which consists the address web services URL address
3. The different URL address that Exchange provides for an internal mail client vs. external mail client.

Additionally, question that can appear could be:

1. How does the Exchange CAS server set the URL address for the web services?
2. Should we “Intervene” with the default settings of the Exchange web services URL address?
3. What are the scenarios in which we need to implement this “Intervene”?
4. Are there any best practice for the URL address of the Exchange web services?

And as usual, there is no one simple answer to this question.
In the current article, we will focus on the “physical structure” of the Exchange web services URL address

The structure of URL address | High-level view

Let’s start with a very simple question:
Q. Do you know what URL stand for?

A: Well… I’m not going to bore you with academic discussions, but, for those of you that did not know the answer, URL stand for -uniform resource locator.

Most of us, associatively link the term -” URL” with terms such as – browser, website and so on.

A “browser” is just one example of a “client” that can consume web-based services.

In reality, there are many types of “clients” that can consume web-based services.
For example, Outlook is a client that heavily depends on the Exchange web services.

The structure of URL address

A URL address is like a puzzle, made up of many parts.

The “begging” of the URL address will “declare” the protocol (the language) in which the client and the server will use. In Exchange based environment, the web services are provided by using the HTTP protocol and the HTTPS protocol (the encrypted version of the HTTP protocol).

The “middle part” of the URL address, include information about the host or the “element” name that will provide the web service.

Most of the time, the naming conventions that we use for “pointing at” the host who provide the specific web services based on the FQDN (fully qualified domain name) naming convention.

The “last part” or the “right part” of the URL address includes the path for the particular web services. The “path” is not a mandatory part of the URL address.

We use the option of “way” in case that the particular host provided a couple of web services, or we want to point the client to a specific folder or file.

For example, Exchange CAS server provides many types of web services. When Exchange clients need a particular web service from the Exchange CAS server, the Exchange clients will have to address the Exchange CAS server by using a URL that includes the Exchange CAS server name + the path of the specific web service.

In this article, we will focus only in the “middle part” (the hostname or the FQDN name) of the Exchange web services URL address because, in case that we need to configure or adjust the URL address of a particular Exchange web service, we will update or set the part that relates to the Exchange host name.

The scenario in which we update the “path” part of the Exchange web services URL address is very rare and not recommended.

Hostname vs. FQDN name

A host name is a logical name whom we use to address a specific network “element”.
We can define the term host name as a “single name” or a “one-word name”.

The term FQDN stands for – Fully Qualified Domain Name.
For me, the word FQDN always sounds strange.

The term – “Fully Qualified Domain Name” defines naming convention, but the term FQDN relates to a “Full host name” vs. the term -” Host” that rates with a single hostname.

An FQDN is created by using the following formula:

To be able to understand better the difference between the term host name and the term FQDN name, we can relate to a standard “human address.”

When we refer to somebody using the name – John, this is the equivalent of the term host name. The name “John” couldn’t consider as a unique identifier.

In case that we need to send a package to John, we will need to use an address that will be a unique identifier and will enable us to be sure that the package sent to the required destination recipient.

In this case, we will use the “Full” or “complete” address of John that includes his family name, street address, city and so on.

We can say that the “Full address” of John is identical to the scenario in which we address a particular host by using his FQDN in the network environment.

Technically, in an internal network, we can address a specific “host” by using only the hostname but, most of the time, the preferred method to address “servers” or hosts who provide services, is by using the FQDN of the host.

In a public network environment, the only way to address hosts is by using their FQDN.

Domain name

A domain name is also a naming convention that based on a specific structure.
An official domain name is built from an organization name and the domain name suffix.

Domain suffix

Every domain name has a suffix (like every bullet has an address). The domain name could be classified as private or as public.

Private domain name suffix

A private domain name suffix based on non-public suffix (and yes, I know that the sentence is not so clear).
In other words – a private domain name suffix cannot be published on the public network. In case that we want to use a private domain name suffix, technically we can invent any name whom we would like to.

For example, an available option for a private domain name suffix could be blab la, and the full domain name could be – o365info.blabla

Public domain names suffix.

Public domain names suffix based on a public suffix.
In a case that we want to use a public domain name suffix, we will need to purchase the domain name from a public provider and, there is a limited amount of public domain name suffix that we can choose from.

Host with the public domain name suffix can publish and accessible by hosts on an external network (and also by hosts from the internal\private network).

In the following diagram, we can see an example of a domain name with a private domain name suffix – o365info.lcoal

And additional example of a public domain name such as – o365info.com

Active Directory domain name

Every Active Directory must have a domain name.

The Active Directory domain name defended by the person that installs the first DC server. Active Directory administrators can decide what type of domain to choose as the Active Directory domain name suffix.

In case that the administrator prefers to use a private domain name for the Active Directory, the common domain name suffix is – local

The domain name suffix “local” is not published on the public network.

In the following diagram, we can see an example of the options that are available for the Active Directory Administrator.

The Active Directory administrator, can choose to use an “internal namespace” for the Active Directory such as – o365info.lcoal or, “external namespace” such as – o365info.com .
The “com” suffix is a public domain name suffix.

Active Directory domain name and Exchange infrastructure

Exchange infrastructure is “Integrated” or “interwoven” into the Active Directory infrastructure.

The exchange infrastructure cannot “live” outside the Active Directory or in other words; the Active Directory serves as a platform for the Exchange infrastructure, and Exchange infrastructure is “bound” to the boundary of the Active Directory forest.

Default FQDN of each Exchange server

The default FQDN of each Exchange server built from the Exchange hostname + the local Active Directory domain name.

In case that we use a private domain name suffix for the Active Directory domain, Exchange will “inherit” the Active Directory domain name and the result are that all the Exchange servers FQDN’s will have the Active Directory private domain name suffix.

Theoretically, there is no “harm” in this scenario, but the problem realized because of the different nature of the Active Directory infrastructure vs. the Exchange infrastructure.

When we relate to the Active Directory infrastructure, the underlying assumption is that we will never want\need to expose the Active Directory infrastructure to the public network or enable the external host to access the internal Active Directory.

When relating to the Exchange infrastructure, the concept of “hiding” internal host or prevent from external hosts accessing private hosts, cannot be realized. Most of the time, we will need to “expose” some of the Exchange Server (Public facing Exchange server) so external hosts such as external Exchange client will be able to communicate with the Exchange server.

To be able to fulfill the requirement of – “publishing Exchange resources”, we will need to use the public domain name for publishing the required host.

For example, external Exchange clients will address the Public facing Exchange CAS server by using an FQDN such as – mail.o365info.com

The two identities of Public facing Exchange CAS server

In case that Exchange CAS server is a “Public-facing Exchange server” and the Active Directory based on a private domain name the outcome is-
The Exchange CAS server will have two different “identities”.

1. Internal – “Active Directory” identity
2. Public identity

The term “identity” describes the FQDN that the Exchange CAS server will use.

• When an Exchange client needs to address an Exchange CAS server, the Exchange client will address the Exchange CAS server private or public identity (FQDN).
• When Exchange clients need to use a particular Exchange web service, the Exchange client will use a URL address that includes the private or public identity (FQDN) of the Exchange server which provides the specific Exchange web service.

Exchange web service and URL address

Exchange server, provide a variety of web services to his Exchange clients.

The way that the Exchange CAS server “expose” a particular Exchange web service is, by using a URL address. In other words – Exchange clients access the Exchange web service by using a URL address.

In this section, I would like to focus on a very specific part of the URL address that we use for Exchange web services -the FQDN.

In the previous section, we discuss a scenario in which the Active Directory based on a private domain name, and we also discuss the need for using an additional domain name: a public domain name, which used by Public facing Exchange server who needs to communicate with external Exchange clients.

In this scenario, we will need to implement a scenario that I describe as “two different identities” that will assign to the Public facing Exchange server. The external identity and internal identity.

Example 1 – Outlook client looking for Exchange CAS server

When the Outlook client tries to locate available Exchange CAS server, the following process will be implemented.

• An internal Outlook client (Outlook client located on the internal company network), will address the Exchange CAS server by using his “private FQDN”.
• An external Outlook client (Outlook client located on the internal company network), will address the Exchange CAS server by using his “public FQDN”.

Example 2 – publishing information about the Exchange web service

When the Exchange CAS server replies to an Autodiscover request, the Autodiscover response will include two types of information about Exchange web services:

• Information for internal Autodiscover clients, which based on URL address that includes the private FQDN of the Exchange server which provides the particular Exchange web service.
• Information for external Autodiscover clients, which based on URL address that includes the public FQDN of the Exchange server which provides the particular Exchange web service.

Exchange web services and URL address structure

Exchange server, provide a variety of web-based services. Each of the different Exchange web services is “represented” by a dedicated URL address.

Despite that we use a dedicated URL of the different Exchange web services, the URL address that we use is based on a basic structure that used in all the Exchange web services URL addresses.

A “standard” Exchange web service URL address will include four parts:

1. Protocol name

The first part of the URL address is the protocol name.
Exchange web services implemented by using the HTTP or the HTTPS protocol.
Most of the time, the communication between Exchange server and his clients will be performed by using the HTTPS protocol.

2. FQDN name

The FQDN name is the “Full host name” that includes the host name + the domain name.

In case that the Exchange server not exposed to a public network, the Exchange CAS server FQDN is built from the “correct server name” (the server NetBIOS name) + the internal Active Directory domain name.

In case that the Exchange CAS server configured as a “Public-facing Exchange server”, the Exchange CAS server “exposed” himself by using a public FQDN and additionally, can and will most of the time have a couple of FQDN names.

The need for more than one “public FQDN” depends on the services that the “Public-facing Exchange server” provides.

3. Folder name

For each of the web services that Exchange provides, there is a “dedicated virtual folder.”

For example, the Autodiscover service of Exchange server is implemented by using a dedicated folder named – Autodiscover.

When Exchange clients need to get a particular service, the Exchange client will need to know and to use the URL address that includes a specific “folder name” that represents the specific services that he needs.

4. The file name

The last part of the URL address can include a file name. For example, In the scenario of Autodiscover services, the URL address that the Autodiscover client use, contain the name of the particular file that the client requests from the server.
Autodiscover client will request a file named – autodiscover.xml

Internal vs. external Autodiscover URL address example

To be able to demonstrate the concept of “dual identity” of Exchange CAS server” let’s review the Autodiscover URL address that is used by internal Exchange clients vs. the Autodiscover URL address that is used by external Exchange clients.

Scenario charters:

An organization uses a private domain name as the Active Directory domain name.
The Active Directory domain name is – o365info.local

The organizing public domain name is – o365info.com

The Exchange CAS server name is – exo1

In a scenario, the Exchange CAS server serves internal Exchange clients and also helps public or external Exchange clients.

In the following diagram, we can see the base structure of the Autodiscover web service URL address.

Autodiscover URL Address | internal Exchange clients

In our example, the Exchange CAS server will automatically register himself at the SCP of the Active Directory, by using the following hostname – ex01.o365info.local

If we want to be more accurate, the Exchange CAS server registers the Autodiscover URL address in the SCP of the Active Directory by using the following URL:
https://ex01.o365info.local/autodiscover/autodiscover.xml

When the internal Outlook client starts the Autodiscover process, the Outlook client will get from the On-Premise Active Directory the URL address of the Exchange Autodiscover service and “extract” from the URL address the Exchange CAS server hostname – ex01.o365info.local and, query the internal DNS for this hostname.
The DNS “answer” will include the internal\private IP address of the Exchange CAS server.

Autodiscover URL Address | external Exchange clients

In our example, when an external mail client such as Outlook need to create a new Outlook mail profile for John@o365info.com , Outlook “assume” that the Autodiscover URL address is as follow: https://autodiscover.o365info.com/autodiscover/autodiscover.xml

To be able to connect the Public facing Exchange server, Outlook will “extract” the FQDN name of the Exchange server from the public Autodiscover address.

In our scenario – autodiscover.o365info.com

Outlook client will address public DNS server and send a query looking for information about the public IP address of this host.

Exchange dual identity | using identical or different FQDN?

One of the most basic and important decision that we have as an Exchange administrator is the decision about the Exchange namespace infrastructure.

Our underlying assumption is that part of the Exchange infrastructure will be configured as a Public facing and for this reason, the Exchange will need to serve internal + external Exchange clients.

In other words, Public facing Exchange server will have two different interfaces.

Option 1 – using a separated namespace

In this case, each of the Public facing Exchange servers will use a different namespace for each of his “identities”.

To demonstrate this concept let’s use the following scenario:

• The internal Active Directory domain name is – o365info.local
• The organization public domain name is – o365info.com

For example

• The “internal identity” of the Exchange server, will be represented by the host name – ex01.o365info.local
• The “external identity” of the Exchange server, will be represented by the host name – mail.o365info.com and, autodiscover.o365info.com

An internal Exchange client that will need to address the Exchange server, looking for Autodiscover infrastructure will address the Exchange server by using the host name – ex01.o365info.local

An external Exchange client that will need to address the Exchange server, looking for Autodiscover infrastructure will address the Exchange server by using the hostname – autodiscover.o365info.com

Option 2 – using a unified namespace

In this case, we will use the identical namespace for each of the Exchange server “identities”.

To demonstrate this concept let’s use the following scenario:

• The internal Active Directory domain name is – o365info.local
• The organization public domain name is – o365info.com

The main difference is that in this scenario we will not use, the local Active Directory domain name as part of the Exchange host name.

In the scenario which I describe as a unified namespace, the Exchange server will be “published” for internal + external Exchange client by using the public domain namespace.

• The “internal identity” of the Exchange server, will be represented by the host names – mail.o365info.com and, autodiscover.o365info.com
• The “external identity” of the Exchange server, will be represented by the host names – mail.o365info.com and, autodiscover.o365info.com

An internal Exchange client that will need to address the Exchange server, looking for Autodiscover infrastructure will address the Exchange server by using the host name – autodiscover.o365info.com

An external Exchange client that will need to address the Exchange server, looking for Autodiscover infrastructure will address the Exchange server by using the hostname – autodiscover.o365info.com

In the past, the “trend” was to emphasize the difference that exists between the “internal Exchange environments” vs. the “external Exchange environment.”

The reason for this trend based on the assumption that using a separated namespace is more secured because the “separation” protects the internal Exchange infrastructure from unwanted access by external hosts.

My opinion is that the “logical separation” doesn’t actually protect the internal Exchange infrastructure because, in reality, the protection and the separation will be implemented by different solutions.

Using the concept of separated namespace will make the life of the Exchange administrator more complicated and confuse users.