extranet.aro.army.mil - not resolving

[Mark Andrews]

> On 1 Jun 2018, at 11:03 am, cwieland at uci.edu wrote:
> 
> 
>> On May 31, 2018, at 5:29 PM, Mark Andrews <marka at isc.org> wrote:
>> 
>> Well the first thing is that dig +trace is making queries from the machine it is running on and not the name server unless they are one and the same.  The @ns2.service.uci.edu is only used to lookup the root nameservers.  Dig +trace is also not performing DNSSEC validation on the answers.
>> 
>> Dig on a CNAME chain requires the entire lookup chain to complete unless you ask for ANY or CNAME both of which don’t follow the CNAME target as per STD 13.
>> 
>> Named also logs errors it detects. Have you looked at the logs?
> 
> Yes I have. Here is the query 
> 
> dig extranet.aro.army.mil
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54757
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;extranet.aro.army.mil.		IN	A
> 
> ;; Query time: 4249 msec
> ;; SERVER: 128.200.192.202#53(128.200.192.202)
> ;; WHEN: Thu May 31 18:01:15 PDT 2018
> ;; MSG SIZE  rcvd: 50

> and heres the log
> 
> 31-May-2018 18:01:04.838 queries: info: client 128.200.192.202#36469 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.192.202)
> 31-May-2018 18:01:10.838 queries: info: client 128.200.192.202#36469 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.192.202)
> 
> is there more I can get?

Have you tries looking up ALL the names in the CNAME chain with A, CNAME and ANY queries?  Which ones of them failed? Show the list the results of ALL those lookups.

You also haven’t answered which version of named you are running.

Working out why that query failed is a matter of working out which subcomponent failed.

This is basic problem solving.  The DNS really isn’t that hard to diagnose once you break it down into its individual steps.  That is what "dig +trace” does for one name but you need to
run it from the nameserver.  If you get a CNAME at the end you need to run it again for that name.  Once you find what part is actually failing you may need to run a packet sniffer.

You know that the lookup of extranet.aro.army.mil gets to the CNAME.  You said that the target of the CNAME failed which was expected if you didn’t query for CNAME or ANY.  I would have thought that you would have made a ANY query given that you had already seen that the ANY query for extranet.aro.army.mil showed a CNAME when the A query returned SERVFAIL.

Mark

>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
>> 
>> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org