extranet.aro.army.mil - not resolving

agreed but why would my server not resolve it while others do?

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

terrible slow and insane config - fix it
https://intodns.com/aro.army.mil
;; Query time: 1175 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Do Mai 31 21:12:26 CEST 2018
;; MSG SIZE rcvd: 247
;; Query time: 1109 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Do Mai 31 21:12:52 CEST 2018
;; MSG SIZE rcvd: 191
aro.army.mil. 2022 IN NS ns03.army.mil.
aro.army.mil. 2022 IN NS ns02.army.mil.
aro.army.mil. 2022 IN NS ns01.army.mil.
;; Query time: 163 msec
;; SERVER: 192.82.113.7#53(192.82.113.7)
;; WHEN: Do Mai 31 21:15:37 CEST 2018
;; MSG SIZE rcvd: 98
Warn SOA REFRESH WARNING: Your SOA REFRESH interval is: 900. That is
not so ok
Warn SOA RETRY Your SOA RETRY value is: 90. That is NOT OK

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

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

Sten Carlsen

2018-05-31 20:09:09 UTC

Post by Con Wieland
agreed but why would my server not resolve it while others do?

For what its worth.
My server has never seen this request before and resolves it:

silver4-2:~ carlsen$ dig extranet.aro.army.mil

; <<>> DiG 9.10.6 <<>> extranet.aro.army.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29942
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;extranet.aro.army.mil.Â Â Â Â Â Â INÂ Â Â A

;; ANSWER SECTION:
extranet.aro.army.mil.Â Â Â 487Â Â Â INÂ Â Â CNAMEÂ Â Â
aro.army.mil.apps.gcds.disa.mil.
aro.army.mil.apps.gcds.disa.mil. 969 INÂ Â Â CNAMEÂ Â Â
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil.
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil. 100 IN CNAME
e1008.d.akamaiedge.akamai.csd.disa.mil.
e1008.d.akamaiedge.akamai.csd.disa.mil.Â Â Â 19 IN AÂ Â Â 214.48.244.31

;; AUTHORITY SECTION:
disa.mil.Â Â Â Â Â Â 21597Â Â Â INÂ Â Â NSÂ Â Â NS1.csd.disa.mil.
disa.mil.Â Â Â Â Â Â 21597Â Â Â INÂ Â Â NSÂ Â Â NS.JTFGNO.mil.
disa.mil.Â Â Â Â Â Â 21597Â Â Â INÂ Â Â NSÂ Â Â NS.CYBERCOM.mil.

;; ADDITIONAL SECTION:
NS1.csd.disa.mil.Â Â Â 21597Â Â Â INÂ Â Â AÂ Â Â 152.229.110.235
NS.JTFGNO.mil.Â Â Â Â Â Â 21597Â Â Â INÂ Â Â AÂ Â Â 214.3.125.231
NS.CYBERCOM.mil.Â Â Â 21597Â Â Â INÂ Â Â AÂ Â Â 131.77.60.235

;; Query time: 4576 msec
;; SERVER: 192.168.16.20#53(192.168.16.20)
;; WHEN: Thu May 31 21:59:28 CEST 2018
;; MSG SIZEÂ rcvd: 307

--
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!"

Con Wieland

2018-05-31 21:31:21 UTC

Also for what it’s worth you get a different set of nameservers if you "dig any"

dig any extranet.aro.army.mil

; <<>> DiG 9.3.6-P1 <<>> any extranet.aro.army.mil
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1002
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2

;; QUESTION SECTION:
;extranet.aro.army.mil. IN ANY

;; ANSWER SECTION:
extranet.aro.ARMY.mil. 5 IN RRSIG CNAME 8 4 3600 20180603234628 20180530232344 17853 aro.army.mil. FWADxA2KjVZGnMJMrqCeQaaIhYdyf/pgu5OkBkCk/BAVyRnRaksGbNhx WP15FIQpfXHZXpuV7ChQoGxGXbmpFZc6khlBgOHxhhOSykiJeVB53QR6 8uvu1cRQ6gy7yeaGHvVUFsYyPlSyitY4kWS1v5RS70RhNVviVaSmaEBu JAkACgMdQs8FG6y8E5Uhsazsl3fX6p2b5wX8ohwCYaFygHoIZqq+TBJX HxcX6MOdPfyyP0UeM+aC1x/58HQXekRlpY8VXujBSjDbVIWZKI/EdA0o Z6eXuGBExkzl4IctnwGSGTyQgtWRovDoJEiRi/jyss/Z4BlMBvpbDBJi AC0b9g==
extranet.aro.ARMY.mil. 5 IN CNAME aro.army.mil.apps.gcds.disa.mil.

;; AUTHORITY SECTION:
aro.ARMY.mil. 2461 IN NS ns03.army.mil.
aro.ARMY.mil. 2461 IN NS ns01.army.mil.
aro.ARMY.mil. 2461 IN NS ns02.army.mil.

;; ADDITIONAL SECTION:
NS01.ARMY.mil. 2391 IN A 140.153.43.44
NS02.ARMY.mil. 2089 IN A 192.82.113.7

;; Query time: 42 msec
;; SERVER: 128.200.1.201#53(128.200.1.201)
;; WHEN: Thu May 31 14:30:30 2018
;; MSG SIZE rcvd: 498

Post by Sten Carlsen

Post by Con Wieland
agreed but why would my server not resolve it while others do?

For what its worth.
silver4-2:~ carlsen$ dig extranet.aro.army.mil
; <<>> DiG 9.10.6 <<>> extranet.aro.army.mil
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29942
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 4
; EDNS: version: 0, flags:; udp: 4096
;extranet.aro.army.mil. IN A
extranet.aro.army.mil. 487 IN CNAME aro.army.mil.apps.gcds.disa.mil.
aro.army.mil.apps.gcds.disa.mil. 969 IN CNAME aro.army.mil.edgekey.dmz.akamai.csd.disa.mil.
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil. 100 IN CNAME e1008.d.akamaiedge.akamai.csd.disa.mil.
e1008.d.akamaiedge.akamai.csd.disa.mil. 19 IN A 214.48.244.31
disa.mil. 21597 IN NS NS1.csd.disa.mil.
disa.mil. 21597 IN NS NS.JTFGNO.mil.
disa.mil. 21597 IN NS NS.CYBERCOM.mil.
NS1.csd.disa.mil. 21597 IN A 152.229.110.235
NS.JTFGNO.mil. 21597 IN A 214.3.125.231
NS.CYBERCOM.mil. 21597 IN A 131.77.60.235
;; Query time: 4576 msec
;; SERVER: 192.168.16.20#53(192.168.16.20)
;; WHEN: Thu May 31 21:59:28 CEST 2018
;; MSG SIZE rcvd: 307
--
Best regards
Sten Carlsen
"MALE BOVINE MANURE!!!"
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

Con Wieland

2018-05-31 21:29:58 UTC

and here they are but I don’t see anything indicating what the problem might be

31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.1.201)
31-May-2018 13:56:01.151 resolver: debug 1: createfetch: aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.1.201)
31-May-2018 13:56:06.153 resolver: debug 1: createfetch: aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.1.201)
31-May-2018 13:56:11.158 query-errors: debug 1: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
31-May-2018 13:56:11.158 resolver: debug 1: createfetch: aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
31-May-2018 13:56:21.168 query-errors: debug 1: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215

Post by Con Wieland
agreed but why would my server not resolve it while others do?

ask the logs of 128.200.1.201
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; SERVER: 128.200.1.201#53(128.200.1.201)

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

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

bind-users mailing list
bind-***@lists.isc.org

John Miller

2018-05-31 21:45:14 UTC

Hi Con,

May I suggest running dig +trace extranet.aro.army.mil from your
nameserver? That'll make the delegation process explicit and help you
troubleshoot a little better. It could be that one of the three main
army.mil nameservers is unreachable by your ns for some reason
(routing being a likely culprit).

John

Post by Con Wieland
and here they are but I don’t see anything indicating what the problem might be
31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.1.201)
31-May-2018 13:56:01.151 resolver: debug 1: createfetch: aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.1.201)
31-May-2018 13:56:06.153 resolver: debug 1: createfetch: aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A +E (128.200.1.201)
31-May-2018 13:56:11.158 query-errors: debug 1: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
31-May-2018 13:56:11.158 resolver: debug 1: createfetch: aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
31-May-2018 13:56:21.168 query-errors: debug 1: client 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215

Post by Con Wieland
agreed but why would my server not resolve it while others do?

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

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

--
John Miller
Senior Systems Engineer
Brandeis University ITS
***@brandeis.edu
(781) 736-4619
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

Warren Kumari

2018-05-31 21:51:26 UTC

Try it with +cd and see if that fixes it.

The DNSSEC stuff for this domain is all borked up -- sufficiently that
I felt like I was playing snakes and ladders while looking at:
http://dnsviz.net/d/extranet.aro.army.mil/dnssec/

Post by John Miller
Hi Con,
May I suggest running dig +trace extranet.aro.army.mil from your
nameserver? That'll make the delegation process explicit and help you
troubleshoot a little better. It could be that one of the three main
army.mil nameservers is unreachable by your ns for some reason
(routing being a likely culprit).
John

Post by Con Wieland
agreed but why would my server not resolve it while others do?

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

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

--
John Miller
Senior Systems Engineer
Brandeis University ITS
(781) 736-4619
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.o

Peter DeVries

2018-05-31 22:08:58 UTC

It's messy to be sure but it's not failing validation on any of the systems
I'm testing on (no AD bit because the CNAMEs aren't signed but no SERVFAIL
either)(. I see a bunch of dig versions in your posting (9.3?). What
version BIND is the server running?

Post by Warren Kumari
Try it with +cd and see if that fixes it.
The DNSSEC stuff for this domain is all borked up -- sufficiently that
http://dnsviz.net/d/extranet.aro.army.mil/dnssec/

and here they are but I donât see anything indicating what the problem

might be

31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (

extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
+E (128.200.1.201)
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A

31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (

extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
+E (128.200.1.201)
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A

31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (

extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
+E (128.200.1.201)

31-May-2018 13:56:11.158 query-errors: debug 1: client

128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
(SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A

31-May-2018 13:56:21.168 query-errors: debug 1: client

128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
(SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215

Post by Con Wieland
agreed but why would my server not resolve it while others do?

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

900. That is

not so ok
Warn SOA RETRY Your SOA RETRY value is: 90. That is

NOT OK

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

unsubscribe from this list

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

--
John Miller
Senior Systems Engineer
Brandeis University ITS
(781) 736-4619
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to

unsubscribe from this list

Post by John Miller
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

c***@uci.edu

2018-06-01 00:18:56 UTC

Hi

Can you elaborate on +cd? a dig option, I am not finding it as an option.

thanks
con

Post by Warren Kumari
Try it with +cd and see if that fixes it.
The DNSSEC stuff for this domain is all borked up -- sufficiently that
http://dnsviz.net/d/extranet.aro.army.mil/dnssec/

Post by Con Wieland
agreed but why would my server not resolve it while others do?

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

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

Peter DeVries

2018-06-01 00:31:23 UTC

+cd disables DNSSEC validation. You are running some very old versions of
dig in some cases which don't have dnssec support. The 9.9 version of dig
you have on at least one server should work.

What version of BIND server are you running on the problematic system?

Post by c***@uci.edu
Hi
Can you elaborate on +cd? a dig option, I am not finding it as an option.
thanks
con

Post by Warren Kumari
Try it with +cd and see if that fixes it.
The DNSSEC stuff for this domain is all borked up -- sufficiently that
http://dnsviz.net/d/extranet.aro.army.mil/dnssec/

and here they are but I donât see anything indicating what the problem

might be

31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (

extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
+E (128.200.1.201)
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A

31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (

extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
+E (128.200.1.201)
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A

31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (

extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
+E (128.200.1.201)

31-May-2018 13:56:11.158 query-errors: debug 1: client

128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
(SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A

31-May-2018 13:56:21.168 query-errors: debug 1: client

128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
(SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215

Post by Con Wieland
agreed but why would my server not resolve it while others do?

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

900. That is

not so ok
Warn SOA RETRY Your SOA RETRY value is: 90. That is

NOT OK

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

unsubscribe from this list

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

--
John Miller
Senior Systems Engineer
Brandeis University ITS
(781) 736-4619
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to

unsubscribe from this list

Post by John Miller
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

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

c***@uci.edu

2018-06-01 01:26:43 UTC

I will keep queries on the server as Mark explaned the dig +trace

The versions on the porblem server are:

named -v
BIND 9.9.4-RedHat-9.9.4-61.el7 (Extended Support Version)
[***@ns2 ~]$ dig -v
DiG 9.9.4-RedHat-9.9.4-61.el7

Neither dig +cd +cdflag produce anything different

[***@ns2 ~]# dig +cd extranet.aro.army.mil

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> +cd extranet.aro.army.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60621
;; flags: qr rd ra cd; 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: 4539 msec
;; SERVER: 128.200.192.202#53(128.200.192.202)
;; WHEN: Thu May 31 18:25:50 PDT 2018
;; MSG SIZE rcvd: 50

[***@ns2 ~]# dig +cdflag extranet.aro.army.mil

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> +cdflag extranet.aro.army.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11925
;; flags: qr rd ra cd; 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: 4000 msec
;; SERVER: 128.200.192.202#53(128.200.192.202)
;; WHEN: Thu May 31 18:26:17 PDT 2018
;; MSG SIZE rcvd: 50

+cd disables DNSSEC validation. You are running some very old versions of dig in some cases which don't have dnssec support. The 9.9 version of dig you have on at least one server should work.
What version of BIND server are you running on the problematic system?
Hi
Can you elaborate on +cd? a dig option, I am not finding it as an option.
thanks
con

Post by Warren Kumari
Try it with +cd and see if that fixes it.
The DNSSEC stuff for this domain is all borked up -- sufficiently that
http://dnsviz.net/d/extranet.aro.army.mil/dnssec/

Post by Con Wieland
agreed but why would my server not resolve it while others do?

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.

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

Mark Andrews

2018-06-01 00:38:13 UTC

Post by c***@uci.edu
Hi
Can you elaborate on +cd? a dig option, I am not finding it as an option.
thanks
con

Prior to BIND 9.7.0 it was +cdflag. BIND 9.7 was EOL’d in 2012.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org

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

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

Mark Andrews

2018-05-31 23:29:37 UTC

Post by Con Wieland
I have a nameserver that can not resolve extranet.aro.army.mil.
dig extranet.aro.army.mil
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;extranet.aro.army.mil. IN A
;; Query time: 4004 msec
;; SERVER: 128.200.1.201#53(128.200.1.201)
;; WHEN: Thu May 31 11:58:23 PDT 2018
;; MSG SIZE rcvd: 50
dig any works though
dig any extranet.aro.army.mil
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> any extranet.aro.army.mil
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36259
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4
; EDNS: version: 0, flags:; udp: 4096
;extranet.aro.army.mil. IN ANY
extranet.aro.ARMY.mil. 5 IN CNAME aro.army.mil.apps.gcds.disa.mil.
extranet.aro.ARMY.mil. 5 IN RRSIG CNAME 8 4 3600 20180603234628 20180530232344 17853 aro.army.mil. FWADxA2KjVZGnMJMrqCeQaaIhYdyf/pgu5OkBkCk/BAVyRnRaksGbNhx WP15FIQpfXHZXpuV7ChQoGxGXbmpFZc6khlBgOHxhhOSykiJeVB53QR6 8uvu1cRQ6gy7yeaGHvVUFsYyPlSyitY4kWS1v5RS70RhNVviVaSmaEBu JAkACgMdQs8FG6y8E5Uhsazsl3fX6p2b5wX8ohwCYaFygHoIZqq+TBJX HxcX6MOdPfyyP0UeM+aC1x/58HQXekRlpY8VXujBSjDbVIWZKI/EdA0o Z6eXuGBExkzl4IctnwGSGTyQgtWRovDoJEiRi/jyss/Z4BlMBvpbDBJi AC0b9g==
aro.ARMY.mil. 2921 IN NS ns03.army.mil.
aro.ARMY.mil. 2921 IN NS ns02.army.mil.
aro.ARMY.mil. 2921 IN NS ns01.army.mil.
NS01.ARMY.mil. 582 IN A 140.153.43.44
NS02.ARMY.mil. 20920 IN A 192.82.113.7
NS03.ARMY.mil. 279 IN A 130.114.200.6
;; Query time: 0 msec
;; SERVER: 128.200.1.201#53(128.200.1.201)
;; WHEN: Thu May 31 12:00:39 PDT 2018
;; MSG SIZE rcvd: 530

ANY (*) queries DO NOT FOLLOW CNAMEs. This is why this query resolved.

Your problem is with one of the targets in the CNAME chain. You now need to workout if the server can resolve aro.army.mil.apps.gcds.disa.mil. Then you need to workout if it can resolve aro.army.mil.edgekey.dmz.akamai.csd.disa.mil. Then you need to workout if it can resolve e1008.d.akamaiedge.akamai.csd.disa.mil.

Don’t forget to check the firewall settings for the new server. Firewall vendors have STUPID defaults for DNS.

Post by Con Wieland
and to further confuse the issue, resolution from a nameserver that does resolve this shows different nameservers listed for the default query and the “any” query
dig extranet.aro.army.mil
; <<>> DiG 9.3.4-P1 <<>> extranet.aro.army.mil
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 359
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 3
;extranet.aro.army.mil. IN A
extranet.aro.ARMY.mil. 801 IN CNAME aro.army.mil.apps.gcds.disa.mil.
aro.army.mil.apps.gcds.DISA.mil. 247 IN CNAME aro.army.mil.edgekey.dmz.akamai.csd.disa.mil.
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil. 180 IN CNAME e1008.d.akamaiedge.akamai.csd.disa.mil.
e1008.d.akamaiedge.akamai.csd.disa.mil. 20 IN A 214.48.248.31
DISA.mil. 17124 IN NS NS1.CSD.DISA.MIL.
DISA.mil. 17124 IN NS NS.CYBERCOM.MIL.
DISA.mil. 17124 IN NS NS.JTFGNO.MIL.
NS.JTFGNO.mil. 17124 IN A 214.3.125.231
NS.CYBERCOM.mil. 17124 IN A 131.77.60.235
NS1.CSD.DISA.mil. 17124 IN A 152.229.110.235
;; Query time: 161 msec
;; SERVER: 128.200.192.203#53(128.200.192.203)
;; WHEN: Thu May 31 12:03:21 2018
;; MSG SIZE rcvd: 384
and “any” include the RRSIG record and different nameservers
dig any extranet.aro.army.mil
; <<>> DiG 9.3.4-P1 <<>> any extranet.aro.army.mil
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 763
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2
;extranet.aro.army.mil. IN ANY
extranet.aro.ARMY.mil. 732 IN RRSIG CNAME 8 4 3600 20180603234628 20180530232344 17853 aro.army.mil. FWADxA2KjVZGnMJMrqCeQaaIhYdyf/pgu5OkBkCk/BAVyRnRaksGbNhx WP15FIQpfXHZXpuV7ChQoGxGXbmpFZc6khlBgOHxhhOSykiJeVB53QR6 8uvu1cRQ6gy7yeaGHvVUFsYyPlSyitY4kWS1v5RS70RhNVviVaSmaEBu JAkACgMdQs8FG6y8E5Uhsazsl3fX6p2b5wX8ohwCYaFygHoIZqq+TBJX HxcX6MOdPfyyP0UeM+aC1x/58HQXekRlpY8VXujBSjDbVIWZKI/EdA0o Z6eXuGBExkzl4IctnwGSGTyQgtWRovDoJEiRi/jyss/Z4BlMBvpbDBJi AC0b9g==
extranet.aro.ARMY.mil. 732 IN CNAME aro.army.mil.apps.gcds.disa.mil.
ARMY.mil. 17055 IN NS NS01.ARMY.MIL.
ARMY.mil. 17055 IN NS NS02.ARMY.MIL.
ARMY.mil. 17055 IN NS NS03.ARMY.MIL.
NS01.ARMY.mil. 17055 IN A 140.153.43.44
NS02.ARMY.mil. 17055 IN A 192.82.113.7
;; Query time: 2 msec
;; SERVER: 128.200.192.203#53(128.200.192.203)
;; WHEN: Thu May 31 12:04:29 2018
;; MSG SIZE rcvd: 506
To further confuse this, this server worked until it’s IP address changed when it replace an existing server. There were no configuration changes only the ip address and it is otherwise fully functioning..
any leads on where to start looking or further trouble shooting ideas would really be appreciated.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

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

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

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

c***@uci.edu

2018-06-01 00:14:59 UTC

Thanks for the explanation of “ANY”

The strange thing is this server previously answered this correctly. We changed the ip address ( on the same network segment) of it to replace one of our existing servers. That is when it no longer resolved extranet.aro.army.mil. It otherwise is resolving names without issue.

So following your suggestion I tried to resolve the first cname in the chain and it failed. But dig +trace resolved. How does dig +trace work when dig doesn’t?

dig +trace aro.army.mil.apps.gcds.disa.mil @ns2.service.uci.edu

; <<>> DiG 9.10.6 <<>> +trace aro.army.mil.apps.gcds.disa.mil @ns2.service.uci.edu
;; global options: +cmd
. 495781 IN NS i.root-servers.net.
. 495781 IN NS e.root-servers.net.
. 495781 IN NS b.root-servers.net.
. 495781 IN NS m.root-servers.net.
. 495781 IN NS f.root-servers.net.
. 495781 IN NS a.root-servers.net.
. 495781 IN NS h.root-servers.net.
. 495781 IN NS l.root-servers.net.
. 495781 IN NS j.root-servers.net.
. 495781 IN NS d.root-servers.net.
. 495781 IN NS c.root-servers.net.
. 495781 IN NS g.root-servers.net.
. 495781 IN NS k.root-servers.net.
. 495781 IN RRSIG NS 8 0 518400 20180613140000 20180531130000 39570 . KymbweT83qDcnulFtNOnem4Lg3jHaFAXmN3CKLgD6ixycW1zxPrt64JX vbeIsRAnthemN6rO2buqRzEJhyOcUyHSEmlRzoLEx/vDVuARJ7uFyVEW ChQAYiWzY3t+5rPIQK+10v9pvvYaQ/yu1oiPcbYydln32L4vwblkeO2A K3zbhTsTkzW++01lU5nhL3Kq7koxTenGMoFuAjsA7cEF4NyrOdDPDCjJ 2G8DRFd4xDaBvrLtP17EphnKl0+txlKnHyC6ggc0jCNa6kioEJHQejR6 mrugHkN3BEVnk6REv2mI0kIa2OGWf76J9zjG6L9X3YkZdESbyOs7Y6JN gfKayw==
;; Received 1097 bytes from 128.200.192.202#53(ns2.service.uci.edu) in 0 ms

mil. 172800 IN NS con1.nipr.mil.
mil. 172800 IN NS con2.nipr.mil.
mil. 172800 IN NS eur1.nipr.mil.
mil. 172800 IN NS eur2.nipr.mil.
mil. 172800 IN NS pac1.nipr.mil.
mil. 172800 IN NS pac2.nipr.mil.
mil. 86400 IN DS 27319 8 2 98332FC2B22D453BD47ACDF73C0150A4DAB54751450ED679411EC972 577CAD47
mil. 86400 IN DS 27319 8 1 B090CA5F985BE47393497300F887EF8466E86C8C
mil. 86400 IN RRSIG DS 8 1 86400 20180613170000 20180531160000 39570 . evM0FK22HOjAFlyL+ZNutDiVquVpmB6X2f7z3rXxKJqB7t2/zXKxWK5S Hitt7Yqu70iqSPyL1mpJBI9eAfsZ7Jo9E77hGxM27AZLGQC1Ph+v52IY rVWu2/l/uygtTKO+jjd1s1KkiKbmyLxU170Zu6xXUxLoy3bGhPy8dpCh A+VLqH3OzhzbITVcFpvIGqDt/hVZ0bTaIY5bdk3v5lBPsACLQ2OFpoWw 5iRMIPAS5rAMARpSaK1ShIN+w5ITa1Sg/iWIr59wCEcsqGsCdcmqauSx 9QWU4PlCSJOgHmG/BGhksjwIAxn06kuoY9K0t9Vh1gxH+DXAJ+IMu4SI FUykUw==
;; Received 646 bytes from 193.0.14.129#53(k.root-servers.net) in 150 ms

DISA.mil. 21600 IN NS NS.JTFGNO.MIL.
DISA.mil. 21600 IN NS NS1.CSD.DISA.MIL.
DISA.mil. 21600 IN NS NS.CYBERCOM.MIL.
DISA.mil. 10800 IN DS 8665 8 1 2C75259E1FEE495705846DB5326486A82BF8BA0F
DISA.mil. 10800 IN DS 8665 8 2 7052D1A8F7862D35616BF5B0B53BB8CBDB87FBF54AC4C7954CB1BA88 A84FF32D
DISA.mil. 10800 IN RRSIG DS 8 2 10800 20180607161146 20180531161146 14394 mil. SCwIsUwwx7D3Xopiig4ZEXhvImsID4rLUe3c75ZNx4kCOd1aAyGGbin7 yVHqh6+Dul4moh53xZiywt7dqN/EXSBiub4X6MwDSrh+W4jbnUU7OVBN 24aurdj32KPGHwcaAGy/TCwtMr35lh/2A/PwZ6h4lRQY/ACqGiIAQRZS Pn8=
;; Received 470 bytes from 199.252.143.234#53(eur2.nipr.mil) in 164 ms

aro.army.mil.apps.gcds.disa.mil. 893 IN CNAME aro.army.mil.edgekey.dmz.akamai.csd.disa.mil.
aro.army.mil.apps.gcds.disa.mil. 893 IN RRSIG CNAME 8 7 3600 20180621160052 20180522160052 57303 apps.gcds.disa.mil. IIM8AqFASfo56yYWBoA1MX4M8zUEQdSuULGmymruFbzajcHkdHBv1FnV 1IHtC6DHZQwVYsfYKpf0XcTrldWdpC5V70hcBrHrEId3yhun74RG5D9t DMUIWAxJuxVGY9e0FAjJ7e8W82udQwJ1AwXACYto1qlTEpsU0mdBNjfR qm4=
aro.army.mil.edgekey.dmz.akamai.csd.disa.mil. 96 IN CNAME e1008.d.akamaiedge.akamai.csd.disa.mil.
e1008.d.akamaiedge.akamai.csd.disa.mil. 20 IN A 214.48.248.31
;; Received 337 bytes from 152.229.110.235#53(NS1.CSD.DISA.MIL) in 65 ms

Con Wieland
Office of Information Technology
University of California at Irvine

Post by Mark Andrews

ANY (*) queries DO NOT FOLLOW CNAMEs. This is why this query resolved.
Your problem is with one of the targets in the CNAME chain. You now need to workout if the server can resolve aro.army.mil.apps.gcds.disa.mil. Then you need to workout if it can resolve aro.army.mil.edgekey.dmz.akamai.csd.disa.mil. Then you need to workout if it can resolve e1008.d.akamaiedge.akamai.csd.disa.mil.
Don’t forget to check the firewall settings for the new server. Firewall vendors have STUPID defaults for DNS.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia

Mark Andrews

2018-06-01 00:29:10 UTC

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?
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ***@isc.org

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

bind-users mailing list
bind-***@lists.isc.org
https://lists.i

c***@uci.edu

2018-06-01 01:03:35 UTC

Post by Mark Andrews
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?

Post by Mark Andrews
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia

Mark Andrews

2018-06-01 01:28:32 UTC

Post by c***@uci.edu

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
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54757
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
;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

Post by c***@uci.edu

Post by Mark Andrews
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia

Tony Finch

2018-06-01 11:07:50 UTC