Re: NS ROOT queries to root servers

[Tony Finch]

Medina, Antonio  wrote:
>
> We have noticed that each query forwarded towards root servers creates
> an extra NS ROOT query.

This is due to a long-standing bug which was recently fixed. You need
change number 4770 - see
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=CHANGES;hb=v9_9#l169

Complain to your vendor if it isn't present in their mystery meat version.

> In addition, we are going to configure a second provider that has warned
> us on they do not reply to NS ROOT queries. Could this pose a problem
> for our DNS servers? Is it possible to instruct our DNS servers not to
> perform root priming?

Jeez, are they deliberately trying to break things? :-)

You should find that it works as they require if you configure the root
zone on your server as a static-stub zone, with the server-addresses
clause pointing at your upstreams. From a brief test I think this
suppresses the priming queries, but I'm running bleeding edge BIND, so
your milage may vary.

I have a crazy setup on my test server, with a local mirror of the root
zone (which feeds https://twitter.com/diffroot). Because BIND does not
normally validate authoritative data, I have separate views for
authoritative service and recursive service. The rec view is configured
with static-stub versions of all the auth zones, pointing at localhost.
When I remove the static-stub root zone and restart the server, it logs
about sending priming queries; when I restart with my usual configuration
it does not.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Westerly 5 to 7, occasionally gale 8 at first, becoming variable 3
or 4. Moderate or rough, becoming slight. Wintry showers, rain later in south.
Good, occasionally poor.
___
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

Update ACLs dynamically

[Anvar Kuchkartaev via bind-users]

 Hello I would like to know if it is possible to add or remove IP addresses to bind acl list without service restart?Anvar Kuchkartaev an...@aegisnet.eu 
___
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

Re: Update ACLs dynamically

[Anand Buddhdev]

Hi Anvar,

Yes, you can change ACLs in named.conf, and then run "rndc reconfig"
which will pick up the changes. You don't need to restart BIND.

Regards,
Anand

On 19/01/2018 14:48, Anvar Kuchkartaev via bind-users wrote:

> Hello I would like to know if it is possible to add or remove IP addresses to 
> bind acl list without service restart?
___
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

Re: intermittent SERVFAIL for high visible domains such as *.google.com

[Brian J. Murrell]

On Thu, 2018-01-18 at 17:46 +, Tony Finch wrote:
> Brian J. Murrell  wrote:
> > On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote:
> > >
> > > The default is 10 minutes - try reducing it and see if the outage
> > > becomes shorter.
> >
> > If it does, what is that telling me?
> 
> My hypothesis here is that `named` has marked all the nameservers for
> the
> domain that is failing as lame, so it no longer has anywhere to send
> queries for the domain, so it returns a SERVFAIL.

Seems this might be the case.  Using a trace level of 11, when a
failure starts this seems to be the trail...

19-Jan-2018 09:06:18.893 resquery 0x7f1010f3bd90 (fctx 
0x7f1010f23d90(www.google.com/A)): response
19-Jan-2018 09:06:18.893 received packet:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  25156
;; flags: qr; QUESTION: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1472
;; QUESTION SECTION:
;www.google.com.IN  A

;; AUTHORITY SECTION:
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.86400   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.86400   IN  RRSIG   DS 8 1 86400 2018020105 
2018011904 41824 . IwT0e9jOKKgASgCQXGsryxFFeN5R0e/HPGCzQuD7rhtCYg4UywLcJ9A1 
Ftn0drh2mggBE5wWX90dc5u26P8Gt1jkJ8XbxyjNHA5uTmakjVnGGOZ+ 
9N/6JMtDApT4F6q/3EN8dkctxWvEe9uph8dFR1Uj0aqCNS3aQ0ge4LkS 
JPfRQ2FIQCQxsh+Ts2hdiC6mThpWoFmwmfBxGPu/NsS92/iA5EaP4ZOK 
oIRqrvgyV4PrTDJM8StJJk9qw7z78RC+3/RfEsnwICXKptIGE4AekqIa 
RiVhkTrXhCZAibab5gtqkCkWZ6kF1/6Xbcjexj4VHL+FxqlQCec6CUcz Wpt/DA==

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800  IN  A   192.5.6.30
a.gtld-servers.net. 172800  IN  2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
b.gtld-servers.net. 172800  IN  2001:503:231d::2:30
c.gtld-servers.net. 172800  IN  A   192.26.92.30
c.gtld-servers.net. 172800  IN  2001:503:83eb::30
d.gtld-servers.net. 172800  IN  A   192.31.80.30
d.gtld-servers.net. 172800  IN  2001:500:856e::30
e.gtld-servers.net. 172800  IN  A   192.12.94.30
e.gtld-servers.net. 172800  IN  2001:502:1ca1::30
f.gtld-servers.net. 172800  IN  A   192.35.51.30
f.gtld-servers.net. 172800  IN  2001:503:d414::30
g.gtld-servers.net. 172800  IN  A   192.42.93.30
g.gtld-servers.net. 172800  IN  2001:503:eea3::30
h.gtld-servers.net. 172800  IN  A   192.54.112.30
h.gtld-servers.net. 172800  IN  2001:502:8cc::30
i.gtld-servers.net. 172800  IN  A   192.43.172.30
i.gtld-servers.net. 172800  IN  2001:503:39c1::30
j.gtld-servers.net. 172800  IN  A   192.48.79.30
j.gtld-servers.net. 172800  IN  2001:502:7094::30
k.gtld-servers.net. 172800  IN  A   192.52.178.30
k.gtld-servers.net. 172800  IN  2001:503:d2d::30
l.gtld-servers.net. 172800  IN  A   192.41.162.30
l.gtld-servers.net. 172800  IN  2001:500:d937::30
m.gtld-servers.net. 172800  IN  A   192.55.83.30
m.gtld-servers.net. 172800  IN  2001:501:b1f9::30


19-Jan-2018 09:06:18.894 fctx 0x7f1010f23d90(www.google.com/A): 
noanswer_response
19-Jan-2018 09:06:18.894 log_ns_ttl: fctx 0x7f1010f23d90: noanswer_response: 
www.google.com (in '.'?): 1 518400
19-Jan-2018 09:06:18.894 log_ns_ttl: fctx 0x7f1010f23d90: DELEGATION: 
www.google.com (in 'com'?): 0 518400
19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): cache_message
19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): cancelquery
19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): nameservers now 
above QDOMAIN
19-Jan-2018 09:06:18.895 fctx 0x7f1010f23d90(www.google.com/A): done
19-Jan-2018 09:06:18.896 fctx 0x7f1010f23d90(www.google.com/A): stopeverything
19-Jan-2018 09:06:18.896 fctx 0x7f1010f23d90(www.google.com/A): cancelqueries

Is that reporting that an attempt to resolve www

Re: intermittent SERVFAIL for high visible domains such as *.google.com

[Tony Finch]

Brian J. Murrell  wrote:
>
> Am I interpreting this correctly?  If so, why would these queries come
> back with responses with no answers?

Those responses look like referrals from the root servers to the .com
servers; I would expect you to see `named` repeating the queries as it
follows the iterative resolution algorithm.

If it thinks it is talking to Google's nameservers when it gets that
response, then something VERY screwy is happening.

(Another advantage of the 9.11 packet tracing change I mentioned
previously is that it logs the remote IP address of upstream queries and
responses, handy for working out what `named` thinks it is talking to.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Northerly or northeasterly 5 or 6, becoming variable 3 or 4 except
in southwest. Rough or very rough, but slight or moderate in southeast. Fair.
Good.
___
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

Re: intermittent SERVFAIL for high visible domains such as *.google.com

[Brian J. Murrell]

On Fri, 2018-01-19 at 14:54 +, Tony Finch wrote:
> 
> Those responses look like referrals from the root servers to the .com
> servers;

Ahhh.  Right.  That makes sense.

> I would expect you to see `named` repeating the queries as it
> follows the iterative resolution algorithm.

Indeed.  I will looking further down the log then...

So, between that initial:

19-Jan-2018 09:06:18.893 resquery 0x7f1010f3bd90 (fctx 
0x7f1010f23d90(www.google.com/A)): response

is just the referrals to .com for that query and the referrals to .com
for the subsequent ns[1-4].google.com queries before we get to:

19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): query 
failed (SERVFAIL) for www.google.com/IN/A at query.c:7007
19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): error
19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): send
19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): sendto
19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): senddone
19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): next
19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): 
ns_client_detach: ref = 0
19-Jan-2018 09:06:18.967 client 10.75.22.32#21585 (www.google.com): endrequest
19-Jan-2018 09:06:18.967 fetch completed at resolver.c:7415 for 
www.google.com/A in 0.547099: SERVFAIL/success 
[domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
19-Jan-2018 09:06:18.967 fetch 0x7f1012541cd0 (fctx 
0x7f1010f23d90(www.google.com/A)): destroyfetch
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): query failed 
(SERVFAIL) for www.google.com/IN/A at query.c:7007
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): error
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): send
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): sendto
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): senddone
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): next
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): 
ns_client_detach: ref = 0
19-Jan-2018 09:06:18.967 client 10.75.22.32#1145 (www.google.com): endrequest
19-Jan-2018 09:06:18.968 fetch 0x7f102c5def88 (fctx 
0x7f1010f23d90(www.google.com/A)): destroyfetch
19-Jan-2018 09:06:18.968 fctx 0x7f1010f23d90(www.google.com/A): shutdown
19-Jan-2018 09:06:18.968 fetch 0x7f10125423f0 (fctx 
0x7f1010d86e80(ns1.google.com/A)): destroyfetch
19-Jan-2018 09:06:18.968 fctx 0x7f1010d86e80(ns1.google.com/A): shutdown
19-Jan-2018 09:06:18.968 adb: fetch of 'ns1.google.com' A failed: SERVFAIL
19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES
19-Jan-2018 09:06:18.968 cfan: skipping find 0x7f10228d7630
19-Jan-2018 09:06:18.968 fetch 0x7f10191e91e8 (fctx 
0x7f1010d88a40(ns1.google.com/)): destroyfetch
19-Jan-2018 09:06:18.968 fctx 0x7f1010d88a40(ns1.google.com/): shutdown
19-Jan-2018 09:06:18.968 adb: fetch of 'ns1.google.com'  failed: SERVFAIL
19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES
19-Jan-2018 09:06:18.968 cfan: processing find 0x7f10228d7630
19-Jan-2018 09:06:18.968 sending event 0x7f10228d76b8 to task 0x7f10247a2f10 
for find 0x7f10228d7630
19-Jan-2018 09:06:18.968 fetch 0x7f102069a2d0 (fctx 
0x7f1010a83a60(ns2.google.com/A)): destroyfetch
19-Jan-2018 09:06:18.968 fctx 0x7f1010a83a60(ns2.google.com/A): shutdown
19-Jan-2018 09:06:18.968 adb: fetch of 'ns2.google.com' A failed: SERVFAIL
19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES
19-Jan-2018 09:06:18.968 cfan: skipping find 0x7f10208679e0
19-Jan-2018 09:06:18.968 fetch 0x7f10206998b0 (fctx 
0x7f1010a83ea0(ns2.google.com/)): destroyfetch
19-Jan-2018 09:06:18.968 fctx 0x7f1010a83ea0(ns2.google.com/): shutdown
19-Jan-2018 09:06:18.968 adb: fetch of 'ns2.google.com'  failed: SERVFAIL
19-Jan-2018 09:06:18.968 DNS_EVENT_ADBNOMOREADDRESSES
19-Jan-2018 09:06:18.968 cfan: processing find 0x7f10208679e0
19-Jan-2018 09:06:18.968 sending event 0x7f1020867a68 to task 0x7f10247a2f10 
for find 0x7f10208679e0
19-Jan-2018 09:06:18.968 fetch 0x7f102112d400 (fctx 
0x7f1010b6bee0(ns3.google.com/)): destroyfetch
19-Jan-2018 09:06:18.970 fctx 0x7f1010b6bee0(ns3.google.com/): shutdown
19-Jan-2018 09:06:18.970 adb: fetch of 'ns3.google.com'  failed: SERVFAIL
19-Jan-2018 09:06:18.970 DNS_EVENT_ADBNOMOREADDRESSES
19-Jan-2018 09:06:18.970 cfan: skipping find 0x7f102309fc10
19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 
(wifi-test.mobidia.com): query failed (SERVFAIL) for wifi-test.mobidia.com/IN/A 
at query.c:7007
19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 
(wifi-test.mobidia.com): error
19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 
(wifi-test.mobidia.com): send
19-Jan-2018 09:06:18.971 client fd31:aeb1:48df:0:e5f4:253a:6c1f:b73d#16975 
(wifi-test.mobidia.com): sendto
19-J

Re: intermittent SERVFAIL for high visible domains such as *.google.com

[Tony Finch]

Brian J. Murrell  wrote:
>
> So, between that initial:
>
> 19-Jan-2018 09:06:18.893 resquery 0x7f1010f3bd90 (fctx 
> 0x7f1010f23d90(www.google.com/A)): response
>
> is just the referrals to .com for that query and the referrals to .com
> for the subsequent ns[1-4].google.com queries before we get to:
>
> [ snip servfail logs ]
>
> Shouldn't I have seen at least some referrals from a .com NS to the
> google.com NSes similar to the referrals from the root server to the
> .com NSes?

That's what I would expect, yes.

You don't have any weird middleboxes between your resolver and the
Internet, do you?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Westerly 5 to 7, occasionally gale 8 at first, becoming variable 3
or 4. Moderate or rough, becoming slight. Wintry showers, rain later in south.
Good, occasionally poor.
___
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

Re: intermittent SERVFAIL for high visible domains such as *.google.com

[Brian J. Murrell]

On Fri, 2018-01-19 at 15:22 +, Tony Finch wrote:
> 
> You don't have any weird middleboxes between your resolver and the
> Internet, do you?

I don't believe so.  Not entirely sure what "weird middleboxes" refers
to in this context though.  And by resolver are you referring to my
BIND9 server or the resolvers on the clients of that server?

I've added packet capturing to the debug collection so that I can see
what my BIND9 server is sending and receiving in the way of queries and
responses when this happens again.

Cheers,
b.


signature.asc
Description: This is a digitally signed message part
___
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

9.11 can't validate sss.gov

[Timothy A. Holtzen]

I've run into an odd problem.  On the same host with nearly identical
configurations.  Bind 9.10.6 can resolve and DNSSEC validate sss.gov but
Bind 9.11.2 cannot.  If I turn off DNSSEC validation 9.11.2 resolves it
just fine.  According to http://dnsviz.net/d/sss.gov/dnssec/ it looks
like the the domain is properly signed and valid.  I get the following
in the log when validation fails.

Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: starting
Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: attempting insecurity proof
Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: checking existence of DS at 'gov'
Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: checking existence of DS at 'sss.gov'
Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: insecurity proof failed
Jan 19 09:26:20 stout named[11872]: validating sss.gov/A: got insecure
response; parent indicates it should be secure
Jan 19 09:26:20 stout named[11872]: dnssec: info: validating sss.gov/A:
got insecure response; parent indicates it should be secure
Jan 19 09:26:20 stout named[11872]: insecurity proof failed resolving
'sss.gov/A/IN': 2001:428::7#53
Jan 19 09:26:20 stout named[11872]: client @0x7fa6ec5ef6d0
10.9.2.18#39295 (sss.gov): view internal: query: sss.gov IN A +E(0)
(10.1.1.5)
Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: starting
Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: attempting insecurity proof
Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: checking existence of DS at 'gov'
Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: checking existence of DS at 'sss.gov'
Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating
sss.gov/A: insecurity proof failed
Jan 19 09:26:21 stout named[11872]: validating sss.gov/A: got insecure
response; parent indicates it should be secure
Jan 19 09:26:21 stout named[11872]: dnssec: info: validating sss.gov/A:
got insecure response; parent indicates it should be secure
Jan 19 09:26:21 stout named[11872]: insecurity proof failed resolving
'sss.gov/A/IN': 63.150.72.5#53
Jan 19 09:26:23 stout named[11872]: client @0x7fa725012090
2606:1c00:2802:9::6#40869 (sss.gov): view internal: query failed
(SERVFAIL) for sss.gov/IN/A at query.c:8302
Jan 19 09:26:23 stout named[11872]: client @0x7fa728a30e50
10.9.2.18#39295 (sss.gov): view internal: query failed (SERVFAIL) for
sss.gov/IN/A at query.c:8302

Oddly enough other signed domains seem to validate correctly.  What
might have changed between 9.10 and 9.11?  I'm guessing that 9.11 is
probably more closely requiring some kind of standard conformance and
sss.gov is maybe not conforming completely.

Any thoughts?

It is kind of important for us.  As a University we are required to
verify that our students are properly registered with the selective
service(sss.gov).

-- 

Timothy A. Holtzen
Campus Network Administrator
Nebraska Wesleyan University
Public PGP key CFB4 3AE8 B726 DEBF 00D9  CCFC 426E 76AF DABC B3D7





signature.asc
Description: OpenPGP digital signature
___
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

Re: 9.11 can't validate sss.gov

[Tony Finch]

Timothy A. Holtzen  wrote:

> I've run into an odd problem.  On the same host with nearly identical
> configurations.  Bind 9.10.6 can resolve and DNSSEC validate sss.gov but
> Bind 9.11.2 cannot.

Ah, this is because sss.gov is hosted on Qwest's DNS servers that have
broken EDNS logic which is incompatible with DNS cookies.

I have a short script (quoted below) which generates a blacklist of broken
servers which is included in my `named.conf`.

The number of problem reports I've received is mercifully small - Qwest
are the worst cookie offenders.



#!/bin/sh

set -eu

noedns=roles/named/files/named.conf.noedns

: >$noedns

# qwest - bea.gov
# barclays - myapplication.international.barclays.com

for s insauthns1.qwest.net. \
sauthns2.qwest.net. \
ns21.barclays.com. \
ns22.barclays.net. \
ns23.barclays.com. \
ns24.barclays.net.
do
dig +noall +nottl +noclass +answer $s a $s 
done |
sort |
while   read s t a
do  echo "server $a { send-cookie no; }; # $s"
done>>$noedns



Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Cyclonic 4 or 5,
occasionally 6 in Hebrides, Bailey and Southeast Iceland. Moderate or rough,
occasionally very rough in Hebrides and Bailey. Wintry showers. Good,
occasionally poor.___
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

Re: Update ACLs dynamically

[Anvar Kuchkartaev via bind-users]

But if you have more than 1000 client ip addresses which dynamically added and 
removed to acl will rndc reconfig not take too much performance?

Anvar Kuchkartaev 
an...@aegisnet.eu 
  Original Message  
From: Anand Buddhdev
Sent: viernes, 19 de enero de 2018 14:53
To: Anvar Kuchkartaev; bind-users@lists.isc.org
Subject: Re: Update ACLs dynamically

Hi Anvar,

Yes, you can change ACLs in named.conf, and then run "rndc reconfig"
which will pick up the changes. You don't need to restart BIND.

Regards,
Anand

On 19/01/2018 14:48, Anvar Kuchkartaev via bind-users wrote:

> Hello I would like to know if it is possible to add or remove IP addresses to 
> bind acl list without service restart?
___
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

Re: Update ACLs dynamically

[Matus UHLAR - fantomas]

On 19.01.18 19:26, Anvar Kuchkartaev via bind-users wrote:

But if you have more than 1000 client ip addresses which dynamically added and 
removed to acl will rndc reconfig not take too much performance?


yes, it will. If you have that much clients, either authentize them via TSIG
or let them use VPN

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Chernobyl was an Windows 95 beta test site.
___
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

Re: [ASK] Block Malware Generate Random Subdomain, Domain and TLD

[Syaifudin]

Hi Daniel

thank you very much for your answer.  i want ask much more but my english
not good so once again thank you very much.



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
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

Re: 9.11 can't validate sss.gov

[Mark Andrews]

Yes, qwest were informed years ago that there severs are broken. Report this to 
the .gov site operators.  The servers return BADVERS to the queries which was 
never part of the EDNS spec and is a invention of the servers developers. 
FORMERR was permissible by STD13  but this was tightened when the EDNS spec was 
revised to say ignore unknown EDNS options. 

-- 
Mark Andrews

> On 20 Jan 2018, at 03:39, Tony Finch  wrote:
> 
> Timothy A. Holtzen  wrote:
> 
>> I've run into an odd problem.  On the same host with nearly identical
>> configurations.  Bind 9.10.6 can resolve and DNSSEC validate sss.gov but
>> Bind 9.11.2 cannot.
> 
> Ah, this is because sss.gov is hosted on Qwest's DNS servers that have
> broken EDNS logic which is incompatible with DNS cookies.
> 
> I have a short script (quoted below) which generates a blacklist of broken
> servers which is included in my `named.conf`.
> 
> The number of problem reports I've received is mercifully small - Qwest
> are the worst cookie offenders.
> 
> 
> 
> #!/bin/sh
> 
> set -eu
> 
> noedns=roles/named/files/named.conf.noedns
> 
> : >$noedns
> 
> # qwest - bea.gov
> # barclays - myapplication.international.barclays.com
> 
> for s insauthns1.qwest.net. \
>sauthns2.qwest.net. \
>ns21.barclays.com. \
>ns22.barclays.net. \
>ns23.barclays.com. \
>ns24.barclays.net.
> do
>dig +noall +nottl +noclass +answer $s a $s 
> done |
> sort |
> while   read s t a
> do  echo "server $a { send-cookie no; }; # $s"
> done>>$noedns
> 
> 
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
> Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Cyclonic 4 or 5,
> occasionally 6 in Hebrides, Bailey and Southeast Iceland. Moderate or rough,
> occasionally very rough in Hebrides and Bailey. Wintry showers. Good,
> occasionally poor.
> ___
> 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

___
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

Re: [ASK] Block Malware Generate Random Subdomain, Domain and TLD

[Josh Kuo]

You might want to check out the free service offered by Quad Nine
(9.9.9.9), they use RPZ in the backend to filter out known malicious domain
names. I do not know if they can filter out malware-related names.

On Sat, Jan 20, 2018 at 7:02 AM Syaifudin  wrote:

> Hi Daniel
>
> thank you very much for your answer.  i want ask much more but my english
> not good so once again thank you very much.
>
>
>
> --
> Sent from: http://bind-users-forum.2342410.n4.nabble.com/
> ___
> 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
>
___
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

Re: [ASK] Block Malware Generate Random Subdomain, Domain and TLD

[Syaifudin JW]

As i know RPZ is usefull for random subdomain. So we can respon it localy. But if request with random sub domain, random domain and random tld its imposible to use RPZ. Dns server will check to root server. For now i still use iptables with regex to block that request so request not to dns but droped by iptablesOn Jan 20, 2018 08:29, Josh Kuo  wrote:You might want to check out the free service offered by Quad Nine (9.9.9.9), they use RPZ in the backend to filter out known malicious domain names. I do not know if they can filter out malware-related names.On Sat, Jan 20, 2018 at 7:02 AM Syaifudin  wrote:Hi Daniel

thank you very much for your answer.  i want ask much more but my english
not good so once again thank you very much.



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
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

___
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

No more idea about loging...?

[Pierre Couderc]

On 01/18/2018 05:48 PM, Pierre Couderc wrote:



On 01/18/2018 01:01 PM, Anand Buddhdev wrote:


I don't know what the function "isc_file_isplainfile" checks for, but
perhaps the executable bits on the file are causing the failure. Log
files shouldn't be executable, so you normally need mode 0644 for them.
Try changing the mode, and seeing if that helps.


Thnk you I have tried all possible combiations without success
___

No more idea about loging?

___
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