Con Wieland wrote:
> I have a nameserver that can not resolve extranet.aro.army.mil.
The end of the CNAME chain is e1008.d.akamaiedge.akamai.csd.disa.mil. The
authoritative servers for this name really like to drop queries if they
don't like the qtype. This is very bad, because it makes it easy
> On 1 Jun 2018, at 11:03 am, cwiel...@uci.edu wrote:
>
>
>> On May 31, 2018, at 5:29 PM, Mark Andrews 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.uc
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)
[cwieland@ns2 ~]$ dig -v
DiG 9.9.4-RedHat-9.9.4-61.el7
Neither dig +cd +cdflag produce anything different
[root@ns2 ~]#
> On May 31, 2018, at 5:29 PM, Mark Andrews 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
>
> On 1 Jun 2018, at 10:18 am, cwiel...@uci.edu wrote:
>
> 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
+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 P
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 o
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 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 snak
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 na
> On 1 Jun 2018, at 5:09 am, Con Wieland wrote:
>
> 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
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, st
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?
On Thu, May 31, 2018 at 5:51 PM, Warren
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 wrote:
>
> Hi Con,
>
> May
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 like
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, AN
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:
On 31/05/2018 21:42, Con Wieland wrote:
> 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 option
agreed but why would my server not resolve it while others do?
> On May 31, 2018, at 12:16 PM, Reindl Harald 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
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
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AU
18 matches
Mail list logo
