Hi Victoria,
On Wed, 30 May 2018, Victoria Risk wrote:
... would it be useful if we included the GeoLite2 database with the
BIND distribution? Since we update at least twice a year, we could
keep it fairly well up to date, and it would save users having to go
get and update the db themselves. I
Hi Michael,
On Wed, 30 May 2018, Michael McNally wrote:
We have had reports that posts to bind-users are (in at least some
cases) triggering unwelcome direct-to-the-submitter messages from
spammers.
Please disregard this message while I try to gather some information
in the hopes of stopping t
On Wed, 30 May 2018, Michael McNally wrote:
We have had reports that posts to bind-users are (in at least some
cases) triggering unwelcome direct-to-the-submitter messages from
spammers.
it was about time ;-)
On 31.05.18 08:28, G.W. Haywood via bind-users wrote:
I'm not sure that there's much
Timothe Litt wrote:
>
> Rather than bundling the database, you might want to bundle a script to
> automate the update process... preferably one that you don't have to
> maintain.
I'm not a geoip user so feel free to ignore me. I think it makes sense to
integrate with the OS geoip package, and it
On Thu, May 31, 2018 at 3:48 AM Matus UHLAR - fantomas
wrote:
>
> >On Wed, 30 May 2018, Michael McNally wrote:
> >>We have had reports that posts to bind-users are (in at least some
> >>cases) triggering unwelcome direct-to-the-submitter messages from
> >>spammers.
>
> it was about time ;-)
>
> On
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
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
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
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:
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
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
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
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
> 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
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
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
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
+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
> 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
> 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
>
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 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
22 matches
Mail list logo
