How do I check which IP address TR7 resolves a domain name to?

Short answer

TR7 resolves domain names with the Virtual Hosts records and the DNS Servers list defined per route table on the Device DNS screen. The check is done in WEB-CLI after the route table in which the name is used is selected with sys-cmd route-table set. The result TR7 arrives at is seen with sys-cmd ping: the first line of the sys-cmd ping -c 1 <domain-name> output shows the IP address the name was resolved to. To see the response of each DNS server separately, sys-cmd dig is used (sys-cmd dig @<dns-server> <domain-name> +short); since dig asks only the DNS server, the Virtual Hosts records do not appear in its response.

Problem: Name Resolution Does Not Give the Expected Address

When a Backend Service address is defined with a domain name, or when a target such as a notification, log forwarding or update server is written with a name, it must be known which IP TR7 resolves this name to. A query made on the client's computer goes to another DNS server; the result may not be the same as what TR7 sees. When DNS resolution error is seen in the vService preview, it is also checked whether the name is resolved from TR7.

Solution: Two Methods

The two methods complement each other: ping shows the result TR7 arrives at, and dig shows the response given by each DNS server. If the result is unexpected, ping is used first, and then dig is used to find the cause.

Your situation	Suitable method
I want to see which IP TR7 finally resolves the name to	Method 1: sys-cmd ping
I want to see what each server in Device DNS responds, and the type and status of the record	Method 2: sys-cmd dig

Method 1: sys-cmd ping Recommended

• How it workssys-cmd ping resolves the target name with the Device DNS setting of the selected route table (first Virtual Hosts, then the DNS Servers list) and writes the resolved address in the first line of the output. The method is the same as the DNS change check on the Device DNS screen.
• Where it is openedWEB-CLI
• Requirement A user whose User Type is Admin.
• Scope Device-wide; not bound to a vService. ping resolves to an IPv4 address.

Step-by-Step Configuration

1

Adım 1 Select the route table

The route table in which the name is used is selected (for a Backend Service, the Route Table value of the Backend Service); for the device itself, Host is written in the v-device field, and the route table name is taken from the Tab list:

sys-cmd route-table set v-device Host route-table <route-table>

2

Adım 2 Have the name resolved

The name is resolved with a single echo request:

sys-cmd ping -c 1 app.example.com

The first line of the output is in the PING app.example.com (192.0.2.21) format; the address in parentheses is the result TR7 arrives at in this route table. The first line is written even if the target does not respond to ICMP. If the name cannot be resolved, a name resolution error such as Name or service not known is written in the output.

Verification

1Resolved addressTR7 side

The address in parentheses in the first line of the output is checked.

Command: sys-cmd ping -c 1 app.example.com

ExpectedPING app.example.com (192.0.2.21)

Method 2: sys-cmd dig

• How it workssys-cmd dig sends the query from the selected route table to the DNS server written with @, and shows the returned records, their TTL durations and the duration of the query. If @ is not written, the query goes to the default resolver of the device; so that it is certain which server responds, the server is written with @.
• Where it is openedWEB-CLI
• Requirement A user whose User Type is Admin; access to the DNS server from the selected route table.
• Scope Device-wide; not bound to a vService.

Step-by-Step Configuration

1

Adım 1 Find out the Device DNS servers

The Settings → General Settings → Device DNS screen is opened; the related route table is selected in the Route Table selector at the top left, and the addresses in the DNS Servers list are noted. If the name is mapped with a row in the Virtual Hosts table, TR7 uses the IP in that row; in this case, the dig query is not needed.

2

Adım 2 Select the route table

In WEB-CLI, the same route table is selected with sys-cmd route-table set v-device Host route-table <route-table>, as in step 1 of Method 1.

3

Adım 3 Ask each DNS server

The query is repeated for each server in Device DNS; in the example, the server with the address 192.0.2.53 is asked for the A record of app.example.com:

sys-cmd dig @192.0.2.53 app.example.com A +short

+short writes only the values in the response. If the record is a CNAME, first the target name and then the IP addresses are listed. For an IPv6 address, the record type AAAA is written.

4

Adım 4 Examine the detailed response (if needed)

If +short returns empty, the query is repeated without this option; the status: value in the response header and the flags: line are read:

sys-cmd dig @192.0.2.53 app.example.com A

Seen	Meaning
status: NOERROR and a record in the ANSWER section	The name is resolved; the returned address is in the response
status: NXDOMAIN	The DNS server does not know this name
connection timed out	The DNS server cannot be reached from the selected route table (dig · Things to Know)
aa in the flags: line	The response came directly from the authoritative server; otherwise, it may have come from a cache

Verification

1Server responsesTR7 side

sys-cmd dig is run for each server in Device DNS and the results are compared.

Command: sys-cmd dig @192.0.2.53 app.example.com A +short

ExpectedThe expected IP address on all servers

Name resolution is tried starting from the first server in the DNS Servers list; if the servers return different addresses, the DNS records are made consistent.

Common Mistakes

• Making the query from the client's computer. The client may be using another DNS server; for the result TR7 sees, the query is made from TR7's WEB-CLI to the servers in Device DNS.
• Asking from the wrong route table. Device DNS settings are per route table and are not inherited from the default table; if no DNS server is defined in a route table, name resolution cannot be done in that table (Route Table).
• Assuming that the name is not resolved because the target does not respond to ICMP. The first line of the ping output is written without waiting for a response; the address the name was resolved to is read from there.
• Looking for the Virtual Hosts record in the dig output. dig asks only the DNS server; the Virtual Hosts rows are not reflected in the query. The result TR7 arrives at with this record is seen with ping.
• Correcting the DNS record and expecting the Backend Service to go to the new address immediately. The domain name in the Backend Service address is resolved while the vService configuration is loaded; after the correction, the vService is reloaded (Can I enter a domain name (FQDN) instead of an IP as the Backend Service address?).
• Taking the +trace result for the response TR7 uses. +trace follows the resolution step by step from the root servers; for the response returned by the server in Device DNS, the query is sent to that server with @.

How it is done in the documentation

• Device DNS · Verifying the DNS Change
• sys-cmd dig · Frequently Used Parameters
• sys-cmd dig · Things to Know
• Device DNS · DNS Servers
• Device DNS · Virtual Hosts

Related questions

• Can I enter a domain name (FQDN) instead of an IP as the Backend Service address?
• What does the configuration error(s) warning in the vService preview (DNS Resolution Error, Port binding error) mean; where does Port Collision appear?
• How do I test from TR7 whether a server's port is reachable?