> On 1 Jun 2018, at 11:03 am, cwiel...@uci.edu wrote:
> 
> 
>> On May 31, 2018, at 5:29 PM, Mark Andrews <ma...@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: ma...@isc.org
>> 
>> 
> 

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

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to