Fortinet black logo

Administration Guide

DNS server configuration

Copy Link
Copy Doc ID 2cb222d1-3405-11ea-9384-00505692583a:319081
Download PDF

DNS server configuration

FortiNAC has its own DNS server used to manage page resolution in the captive portal. For secure communications between the agent and the server, this DNS server must contain specific SRV records used by the agent to locate the server while in isolation. Adding these SRV records is handled for you by FortiNAC.

On upgrade to FortiNAC V6.0 or higher, SRV records indicating the port and FQDN of the FortiNAC appliance where the portal is located are automatically added to the domain.zone.* files for named. If this is a new installation, the domain.zone.* files are created by the Configuration Wizard. The Configuration Wizard also adds the SRV records to the domain.zone.* files during the initial appliance configuration. Manual edits to files are not needed and should not be attempted.

If you use agents for macOS and some Linux systems, using a .local suffix in Domain fields in the Configuration Wizard may cause communications issues.

Example:

Incorrect DNS suffix for reg: tech-reg.megatech.local

Correct DNS suffix for reg: tech.megatech-reg.edu

If you are unable to configure the agent through Agent Configuration, the same SRV records may be added to the corporate production DNS servers. These are particularly important in a high availability environment because the SRV records provide the agent with a prioritized list of servers with which it can communicate. In a facility were multiple FortiNAC appliances are being managed by a FortiNAC Control Manager, SRV records make it easier for the agent to locate a FortiNAC server.

When using the FortiNAC Control Manager to manage multiple FortiNAC servers, enabling the Require Connected Adapter check box in Security Management eliminates the need to use ACLs to block access to the FortiNAC Application server when the host is connecting on a device managed by a different FortiNAC Control Server/Application Server pair. This setting will require a host reported by the agent to be connected to a device managed by FortiNAC in order to communicate.

To enable the Require Connected Adapter check box, go to Settings > Persistent Agent > Security Management.

The agent must be configured with security enabled.

When Require Connected Adapter is disabled, you must use ACLs to block access to a FortiNAC Application server when the host is connecting on a device managed by a different FortiNAC Control Server/Application Server pair. For example, assume the host initially connects to the network on Device A which is managed by Server A. When the host later connects to the network on Device B which is managed by Server B, the agent continues to communicate with Server A. If access to Server A is denied, the agent will go through the server discovery process to locate another server.

Entries in DNS are different for each agent. Currently, the DNS mechanism used for the agent to discover the server is used by the Mobile Agent, Dissolvable Agent, and Persistent Agent. As new types of agents are added to FortiNAC you may be required to update DNS SRV records to accommodate them. See Agent server discovery.

Verify the SRV records

  1. Log into the CLI of the FortiNAC appliance that is running the captive portal, typically this is a FortiNAC Application Server.
  2. Navigate to the following directory: /var/named/chroot/etc
  3. There is a special zone file for the Mobile Agent labeled
    discovery.portal.bradfordnetworks.com.zone. Type ls *.zone and verify that this file is in the list of files.
  4. Type ls domain.zone.* to display a list of all of the domain.zone files.
  5. Display the contents of one of the files by typing cat <file name>, for example, cat domain.zone.reg .
  6. Within the contents displayed look for the lines beginning with _bradfordagent.

    If those lines are included in the file, then the SRV records have been added to the domain.zone.* files. You should see records similar to the following:

    $TTL 15s
    example.com.              IN SOA reg.example.com. root.reg.example.com. (
                              1
                              10800
                              3600
                              604800
                              86400
                              )
                    IN NS      reg.example.com.
                    IN TXT     "Registration Domain"
    $ORIGIN example.com.
     
    b._dns-sd._udp  PTR @
    lb._dns-sd._udp  PTR  @
    _networksentry._tcp  PTR AgentConfig._networksentry._tcp
     
    ;Insert agent line here
    ; Needs to be here for BN_OTHER_HOSTNAME
    AgentConfig._networksentry._tcp SRV 0 0 443 servername.domainname.com.
                                    TXT path=/registration/agent/config
    _networksentry._tcp             SRV 0 0 443 servername.domainname.com.
                                    TXT path=/registration/agent/config
     
    _bradfordagent._udp             SRV 0 0 4567 servername.domainname.com.
    _bradfordagent._tcp             SRV 0 0 4568 servername.domainname.com.
    *.example.com.            IN      A   172.16.28.1

Adding a DNS SRV record

DNS servers will vary based on the operating system of the computer used to house them. The example below is for a DNS server running on a Windows operating system with the SRV records added from a command prompt. You may prefer to use another method to add records to your DNS Server.

  1. On the Windows Desktop click Start > Run.
  2. On the Run dialog in the Open field, type command and click OK.
  3. At the command prompt type the following:

    > dnscmd /RecordAdd yourdomain.com _bradfordagent._udp.yourdomain.com. SRV 0 0 4567 servername.domainname.com.

  4. To add the next record type the following:

    > dnscmd /RecordAdd yourdomain.com _bradfordagent._tcp.yourdomain.com. SRV 0 0 4568 servername.domainname.com.

In the commands above yourdomain.com is the zone supplied via DHCP (Connection-specific DNS Suffix on a Windows station in "ipconfig /all" output). servername.domainname.com is the FQDN of the FortiNAC Application Server or server that is running the captive portal. Note that there is a period (.) after .com at the end of the FQDNs and node names.

The two zeros (0) in the example indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment.

DNS server examples

From the DNS example in the section above you must include specific entries in your production DNS server. The examples below list each entry and provide notes about its function and the agents affected.

Entry 1

This entry is used only by the Dissolvable Agent. It is always required.

_networksentry._tcp  PTR AgentConfig._networksentry._tcp
 
AgentConfig._networksentry._tcp SRV 0 0 443 servername.domainname.com.
                                TXT path=/registration/agent/config

These lines work together to define the AgentConfig service. The first line indicates the name of the service and sets the type (_networksentry._tcp).

The second and third lines are the SRV record and indicate the FQDN of the server to which the agent will connect. The two zeros (0) in the example indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment. 443 is the port and should not be changed. In the example, the name of the server is servername.domainname.com. This must match the name in the valid certificate used to secure the portal. Note that the period (.) at the end of servername.domainname.com. is required. The TXT line contains the path.

The agent uses the information contained in these entries to construct a URL for the server to which it should connect. Using the records shown above the agent would construct the following:

https://servername.domainname.com:443/registration/agent/config
Entry 2

This entry is used by the Mobile Agent and is always required.

_networksentry._tcp.discovery.portal.bradfordnetworks.com             SRV 0 0 443 servername.domainname.com.
_networksentry._tcp.discovery.portal.bradfordnetworks.com             TXT path=/registration/agent/config

These lines are SRV record and indicate the FQDN of the server to which the agent will connect. They are the detailed version of the lines below that are included in the domain.zone.reg file shown above. It is recommended that you use the detailed entry when editing your production DNS, however, either entry is acceptable.

_networksentry._tcp             SRV 0 0 443 servername.domainname.com.
                                TXT path=/registration/agent/config

The two zeros (0) in the examples indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment. 443 is the port and should not be changed. In the example, the name of the server is servername.domainname.com. This must match the name in the valid certificate used to secure the portal. Note that the period (.) at the end of servername.domainname.com. is required. The TXT line contains the path.

The agent uses the information contained in these entries to construct a URL for the server to which it should connect. Using the records shown above the agent would construct the following:

https://servername.domainname.com:443/registration/agent/config
Entry 3

This entry must be done on each site that uses the Persistent Agent.

_bradfordagent._udp             SRV 0 0 4567 servername.domainname.com.
 
_bradfordagent._tcp             SRV 0 0 4568 servername.domainname.com.

These SRV records indicate the FQDN of the server to which the agent will connect. The two zeros (0) in the example indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment. 4567 and 4568 are the ports on which the server listens and should not be changed. In the example, the name of the server is servername.domainname. Note that the period (.) at the end of servername.domainname.com. is required.

This entry is used by the Persistent Agent and is required. The Persistent Agent has other mechanisms for determining where its server is such as registry entries on the host or information contained in Persistent Agent Properties on the server. However, if those options are not available, the Persistent Agent does use DNS to locate a server.

See Agent server discovery.

Entry 4

These records are used by the Persistent Agent.

In a high availability environment where redundant servers are not on the same sub-net and there is no shared IP address, you must add SRV records for all of the servers in order by priority. Priority is the first number after SRV in the example. If your high availability servers share an IP address you do not need to provide these entries. Use the entries for the stand-alone server as shown in the examples above for Entry 1 through Entry 4.

_bradfordagent._tcp.example.com   SRV  0 0 4568 primaryas.example.com.
_bradfordagent._udp.example.com   SRV  0 0 4567 primaryas.example.com.
_bradfordagent._tcp.example.com   SRV  1 0 4568 secondaryas.example.com.
_bradfordagent._udp.example.com   SRV  1 0 4567 secondaryas.example.com.
Entry 5

These records are used by the Persistent Agent.

In an environment where multiple FortiNAC servers are managed by a FortiNAC Control Manager, the best practice is to set the registry keys via software push. If this is not possible, there should be an entry in DNS for each FortiNAC appliance that runs a captive portal. If all servers are reachable across all segments of the network, you may need to create ACLs that block access for the Persistent Agent from one segment to another. When a host with the Persistent Agent installed moves from one location to another on the network the Persistent Agent will continue to connect to its original FortiNAC server. The agent will not connect to the server that is managing the port to which it is connected. If an ACL denies the Persistent Agent access to a FortiNAC server based on the hosts location on the network, the Persistent Agent will search for a different server.

The following shows DNS configuration entries for two FortiNAC configurations.

_bradfordagent._tcp.example.com   SRV   0 0 4568 appserver1.example.com.
_bradfordagent._udp.example.com   SRV   0 0 4567 appserver1.example.com.
_bradfordagent._tcp.example.com   SRV   0 0 4568 appserver2.example.com.
_bradfordagent._udp.example.com   SRV   0 0 4567 appserver2.example.com.

In the commands above example.com is the zone. appserver1.example.com and appserver2.example.com are the FQDNs of the FortiNAC Application Servers or servers that are running the captive portal. Note that there is a period (.) after .com. at the end of the FQDNs and node names.

DNS server configuration

FortiNAC has its own DNS server used to manage page resolution in the captive portal. For secure communications between the agent and the server, this DNS server must contain specific SRV records used by the agent to locate the server while in isolation. Adding these SRV records is handled for you by FortiNAC.

On upgrade to FortiNAC V6.0 or higher, SRV records indicating the port and FQDN of the FortiNAC appliance where the portal is located are automatically added to the domain.zone.* files for named. If this is a new installation, the domain.zone.* files are created by the Configuration Wizard. The Configuration Wizard also adds the SRV records to the domain.zone.* files during the initial appliance configuration. Manual edits to files are not needed and should not be attempted.

If you use agents for macOS and some Linux systems, using a .local suffix in Domain fields in the Configuration Wizard may cause communications issues.

Example:

Incorrect DNS suffix for reg: tech-reg.megatech.local

Correct DNS suffix for reg: tech.megatech-reg.edu

If you are unable to configure the agent through Agent Configuration, the same SRV records may be added to the corporate production DNS servers. These are particularly important in a high availability environment because the SRV records provide the agent with a prioritized list of servers with which it can communicate. In a facility were multiple FortiNAC appliances are being managed by a FortiNAC Control Manager, SRV records make it easier for the agent to locate a FortiNAC server.

When using the FortiNAC Control Manager to manage multiple FortiNAC servers, enabling the Require Connected Adapter check box in Security Management eliminates the need to use ACLs to block access to the FortiNAC Application server when the host is connecting on a device managed by a different FortiNAC Control Server/Application Server pair. This setting will require a host reported by the agent to be connected to a device managed by FortiNAC in order to communicate.

To enable the Require Connected Adapter check box, go to Settings > Persistent Agent > Security Management.

The agent must be configured with security enabled.

When Require Connected Adapter is disabled, you must use ACLs to block access to a FortiNAC Application server when the host is connecting on a device managed by a different FortiNAC Control Server/Application Server pair. For example, assume the host initially connects to the network on Device A which is managed by Server A. When the host later connects to the network on Device B which is managed by Server B, the agent continues to communicate with Server A. If access to Server A is denied, the agent will go through the server discovery process to locate another server.

Entries in DNS are different for each agent. Currently, the DNS mechanism used for the agent to discover the server is used by the Mobile Agent, Dissolvable Agent, and Persistent Agent. As new types of agents are added to FortiNAC you may be required to update DNS SRV records to accommodate them. See Agent server discovery.

Verify the SRV records

  1. Log into the CLI of the FortiNAC appliance that is running the captive portal, typically this is a FortiNAC Application Server.
  2. Navigate to the following directory: /var/named/chroot/etc
  3. There is a special zone file for the Mobile Agent labeled
    discovery.portal.bradfordnetworks.com.zone. Type ls *.zone and verify that this file is in the list of files.
  4. Type ls domain.zone.* to display a list of all of the domain.zone files.
  5. Display the contents of one of the files by typing cat <file name>, for example, cat domain.zone.reg .
  6. Within the contents displayed look for the lines beginning with _bradfordagent.

    If those lines are included in the file, then the SRV records have been added to the domain.zone.* files. You should see records similar to the following:

    $TTL 15s
    example.com.              IN SOA reg.example.com. root.reg.example.com. (
                              1
                              10800
                              3600
                              604800
                              86400
                              )
                    IN NS      reg.example.com.
                    IN TXT     "Registration Domain"
    $ORIGIN example.com.
     
    b._dns-sd._udp  PTR @
    lb._dns-sd._udp  PTR  @
    _networksentry._tcp  PTR AgentConfig._networksentry._tcp
     
    ;Insert agent line here
    ; Needs to be here for BN_OTHER_HOSTNAME
    AgentConfig._networksentry._tcp SRV 0 0 443 servername.domainname.com.
                                    TXT path=/registration/agent/config
    _networksentry._tcp             SRV 0 0 443 servername.domainname.com.
                                    TXT path=/registration/agent/config
     
    _bradfordagent._udp             SRV 0 0 4567 servername.domainname.com.
    _bradfordagent._tcp             SRV 0 0 4568 servername.domainname.com.
    *.example.com.            IN      A   172.16.28.1

Adding a DNS SRV record

DNS servers will vary based on the operating system of the computer used to house them. The example below is for a DNS server running on a Windows operating system with the SRV records added from a command prompt. You may prefer to use another method to add records to your DNS Server.

  1. On the Windows Desktop click Start > Run.
  2. On the Run dialog in the Open field, type command and click OK.
  3. At the command prompt type the following:

    > dnscmd /RecordAdd yourdomain.com _bradfordagent._udp.yourdomain.com. SRV 0 0 4567 servername.domainname.com.

  4. To add the next record type the following:

    > dnscmd /RecordAdd yourdomain.com _bradfordagent._tcp.yourdomain.com. SRV 0 0 4568 servername.domainname.com.

In the commands above yourdomain.com is the zone supplied via DHCP (Connection-specific DNS Suffix on a Windows station in "ipconfig /all" output). servername.domainname.com is the FQDN of the FortiNAC Application Server or server that is running the captive portal. Note that there is a period (.) after .com at the end of the FQDNs and node names.

The two zeros (0) in the example indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment.

DNS server examples

From the DNS example in the section above you must include specific entries in your production DNS server. The examples below list each entry and provide notes about its function and the agents affected.

Entry 1

This entry is used only by the Dissolvable Agent. It is always required.

_networksentry._tcp  PTR AgentConfig._networksentry._tcp
 
AgentConfig._networksentry._tcp SRV 0 0 443 servername.domainname.com.
                                TXT path=/registration/agent/config

These lines work together to define the AgentConfig service. The first line indicates the name of the service and sets the type (_networksentry._tcp).

The second and third lines are the SRV record and indicate the FQDN of the server to which the agent will connect. The two zeros (0) in the example indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment. 443 is the port and should not be changed. In the example, the name of the server is servername.domainname.com. This must match the name in the valid certificate used to secure the portal. Note that the period (.) at the end of servername.domainname.com. is required. The TXT line contains the path.

The agent uses the information contained in these entries to construct a URL for the server to which it should connect. Using the records shown above the agent would construct the following:

https://servername.domainname.com:443/registration/agent/config
Entry 2

This entry is used by the Mobile Agent and is always required.

_networksentry._tcp.discovery.portal.bradfordnetworks.com             SRV 0 0 443 servername.domainname.com.
_networksentry._tcp.discovery.portal.bradfordnetworks.com             TXT path=/registration/agent/config

These lines are SRV record and indicate the FQDN of the server to which the agent will connect. They are the detailed version of the lines below that are included in the domain.zone.reg file shown above. It is recommended that you use the detailed entry when editing your production DNS, however, either entry is acceptable.

_networksentry._tcp             SRV 0 0 443 servername.domainname.com.
                                TXT path=/registration/agent/config

The two zeros (0) in the examples indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment. 443 is the port and should not be changed. In the example, the name of the server is servername.domainname.com. This must match the name in the valid certificate used to secure the portal. Note that the period (.) at the end of servername.domainname.com. is required. The TXT line contains the path.

The agent uses the information contained in these entries to construct a URL for the server to which it should connect. Using the records shown above the agent would construct the following:

https://servername.domainname.com:443/registration/agent/config
Entry 3

This entry must be done on each site that uses the Persistent Agent.

_bradfordagent._udp             SRV 0 0 4567 servername.domainname.com.
 
_bradfordagent._tcp             SRV 0 0 4568 servername.domainname.com.

These SRV records indicate the FQDN of the server to which the agent will connect. The two zeros (0) in the example indicate priority and weight of this record. Priority is used when there are multiple servers to which the agent can connect, such as in a high availability environment. 4567 and 4568 are the ports on which the server listens and should not be changed. In the example, the name of the server is servername.domainname. Note that the period (.) at the end of servername.domainname.com. is required.

This entry is used by the Persistent Agent and is required. The Persistent Agent has other mechanisms for determining where its server is such as registry entries on the host or information contained in Persistent Agent Properties on the server. However, if those options are not available, the Persistent Agent does use DNS to locate a server.

See Agent server discovery.

Entry 4

These records are used by the Persistent Agent.

In a high availability environment where redundant servers are not on the same sub-net and there is no shared IP address, you must add SRV records for all of the servers in order by priority. Priority is the first number after SRV in the example. If your high availability servers share an IP address you do not need to provide these entries. Use the entries for the stand-alone server as shown in the examples above for Entry 1 through Entry 4.

_bradfordagent._tcp.example.com   SRV  0 0 4568 primaryas.example.com.
_bradfordagent._udp.example.com   SRV  0 0 4567 primaryas.example.com.
_bradfordagent._tcp.example.com   SRV  1 0 4568 secondaryas.example.com.
_bradfordagent._udp.example.com   SRV  1 0 4567 secondaryas.example.com.
Entry 5

These records are used by the Persistent Agent.

In an environment where multiple FortiNAC servers are managed by a FortiNAC Control Manager, the best practice is to set the registry keys via software push. If this is not possible, there should be an entry in DNS for each FortiNAC appliance that runs a captive portal. If all servers are reachable across all segments of the network, you may need to create ACLs that block access for the Persistent Agent from one segment to another. When a host with the Persistent Agent installed moves from one location to another on the network the Persistent Agent will continue to connect to its original FortiNAC server. The agent will not connect to the server that is managing the port to which it is connected. If an ACL denies the Persistent Agent access to a FortiNAC server based on the hosts location on the network, the Persistent Agent will search for a different server.

The following shows DNS configuration entries for two FortiNAC configurations.

_bradfordagent._tcp.example.com   SRV   0 0 4568 appserver1.example.com.
_bradfordagent._udp.example.com   SRV   0 0 4567 appserver1.example.com.
_bradfordagent._tcp.example.com   SRV   0 0 4568 appserver2.example.com.
_bradfordagent._udp.example.com   SRV   0 0 4567 appserver2.example.com.

In the commands above example.com is the zone. appserver1.example.com and appserver2.example.com are the FQDNs of the FortiNAC Application Servers or servers that are running the captive portal. Note that there is a period (.) after .com. at the end of the FQDNs and node names.