extranet.aro.army.mil - not resolving

Fri Jun 1 00:31:23 UTC 2018

+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?

On Thu, May 31, 2018 at 8:18 PM, cwieland at uci.edu <cwieland at uci.edu> wrote:

> Hi
>
> Can you elaborate on +cd? a dig option, I am not finding it as an option.
>
> thanks
> con
>
> > On May 31, 2018, at 2:51 PM, Warren Kumari <warren at kumari.net> wrote:
> >
> > 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/
> > On Thu, May 31, 2018 at 5:45 PM John Miller <johnmill at brandeis.edu>
> wrote:
> >>
> >> 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
> >>
> >> On Thu, May 31, 2018 at 5:29 PM, Con Wieland <cwieland at uci.edu> wrote:
> >>> 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
> >>>
> >>>> On May 31, 2018, at 12:51 PM, Reindl Harald <h.reindl at thelounge.net>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Am 31.05.2018 um 21:42 schrieb 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
> >>>> ;; Got answer:
> >>>> ;; ->>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)
> >>>>
> >>>>>> On May 31, 2018, at 12:16 PM, Reindl Harald <h.reindl at thelounge.net>
> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Am 31.05.2018 um 21:09 schrieb 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
> >>>>>>
> >>>>>> ;; ANSWER SECTION:
> >>>>>> 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-users at lists.isc.org
> >>> https://lists.isc.org/mailman/listinfo/bind-users
> >>
> >>
> >>
> >> --
> >> John Miller
> >> Senior Systems Engineer
> >> Brandeis University ITS
> >> johnmill at 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-users at lists.isc.org
> >> 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-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180531/552381f5/attachment.html>