I'm having problems resolving DNS for some of my delivery paths - AppNeta
search cancel

I'm having problems resolving DNS for some of my delivery paths - AppNeta

book

Article ID: 264435

calendar_today

Updated On:

Products

AppNeta AppNeta

Issue/Introduction

My Monitoring Points DNS is not resolving correctly, and Delivery & Experience seem to fail.  
How can I test DNS ?

Cause

As mentioned in the Documentation portal for DNS that DNS can be configured by DHCP or Statically assigned. 

When a DNS request is required, the monitoring point may check all servers from the list of available DNS servers, depending on the how the path has been created.  From the monitoring point's perspective, all name servers equal.

If a path is created using the 'auto' interface: then the monitoring point will check all available DNS servers across any interface, VLAN or otherwise:


If a path is created from a specific interface or VLAN Interface: then only the DNS servers on the listed interface are used:

 

~~~~~

You can identify paths with specific interfaces by examining the path name:

 

~~~~

Its important to note that when the DNS request is sent to the name servers, the fastest response received by the monitoring point will be used.  This can be important if lookup responses for internal targets are responded with unknown from external DNS services, such as Google DNS, as this can result in a DNS error.

 

Resolution

For in-product DNS lookups and ping tools, please use PathPlus:

 

*Please note that Path Plus will use the auto interface and leverage all available DNS servers

For individual server DNS lookups, you can use dig from the the monitoring points CLI, see below.

Additional Information

For individual server DNS lookups, you can use dig from the the monitoring points CLI, and specify the taget.  

You can also force the use of a specific DNS server by using the @ symbol:


admin@V35-xxx:~$ dig @8.8.8.8 support.broadcom.com

; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> @8.8.8.8 support.broadcom.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51955
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;support.broadcom.com.		IN	A

;; ANSWER SECTION:
support.broadcom.com.	300	IN	CNAME	casupport.broadcom.com.
casupport.broadcom.com.	300	IN	A	141.202.0.1

;; Query time: 53 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Apr 25 18:22:33 UTC 2023
;; MSG SIZE  rcvd: 89

We can see above the response time was 53 msec

Using a different server below:

admin@V35-Gmaccy:~$ dig @4.2.2.2 support.broadcom.com

; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> @4.2.2.2 support.broadcom.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2134
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;support.broadcom.com.		IN	A

;; ANSWER SECTION:
support.broadcom.com.	300	IN	CNAME	casupport.broadcom.com.
casupport.broadcom.com.	300	IN	A	141.202.0.1

;; Query time: 34 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Tue Apr 25 18:24:19 UTC 2023
;; MSG SIZE  rcvd: 89

 

We can see the resolution was faster in the second query (34 msec), and as the monitoring point performs these lookups in parallel, the fastest response would be used.