I'm having problems resolving DNS for some of my delivery paths - AppNeta
Article ID: 264435
Updated On:
Products
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.
Feedback
