Re: Preventing a particular type of nameserver abuse

[Julien Salort]

Le 13/04/2021 à 07:12, Ondřej Surý a écrit :

BIND 9.11 has minimal-any option that’s helpful to reduce the attack 
impact: https://www.isc.org/blogs/bind-release-911/ 



RRL should also help to limit the responses: 
https://kb.isc.org/docs/aa-01000 


Usually the source IP is spoofed, so blocking it might be causing 
collateral damage in case the target of the attack is a resolver, but 
again in general case fail2ban that parses named log files might be a 
good option to add a temporary ban on the ip. Just bear in mind you 
are not blocking the attacker, but the victim.


I also have a lot of these (sl) queries in my logs.

Would it not be possible to have an option to tell bind to refrain from 
answering to all unauthorized queries over UDP?


Is there really a usefulness to reply with code 5, instead of silently 
ignoring the request?


A built-in option would be much easier than to require every server to 
have a dedicated fancy firewall rule.


But I have no idea how much work it would be to add this feature in bind.


Cheers,


Julien

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[Ondřej Surý]

Yes, the legitimate client would be susceptible to spoofing. No answer means 
larger time windows to guess the port+msgid combination.

--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 13. 4. 2021, at 11:31, Julien Salort  wrote:
> 
> Is there really a usefulness to reply with code 5, instead of silently 
> ignoring the request?

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[Borja Marcos]

> On 13 Apr 2021, at 11:31, Julien Salort  wrote:
> 
> Is there really a usefulness to reply with code 5, instead of silently 
> ignoring the request?

Yes, we do it.

imagine a customer who uses to connect from different locations (hence 
different ISPs) and for whatever
reason keeps a static list of resolvers in resolv.conf.

If the customer queries your DNS servers from a non authorized location and 
they ignore the request you
will force the resolver to time out. If, however, the query is refused, the 
resolver will send it to the next
server in the list.

Being short messages means they are useless for a DDoS. Anyway we keep an eye 
on it.





Borja.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[Anand Buddhdev]

Hi Ondrej, and others,

A legitimate client, following a normal chain of referrals, has *no*
reason to query a server for zones it is not authoritative for. Most of
the time, such a query would only arrive at a name server from a naughty
client. And then, replying with any response, even REFUSED, is
satisfying this client's naughtiness.

I think it's quite okay for an authoritative name server to simply DROP
UDP queries for zones that it's not authoritative for. It's better to
ignore naughty clients, and give them the cold shoulder, and not
participate in reflection attacks using REFUSED responses.

Regards,
Anand

On 13/04/2021 11:47, Ondřej Surý wrote:

> Yes, the legitimate client would be susceptible to spoofing. No
> answer means larger time windows to guess the port+msgid combination.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[Tony Finch]

Peter Coghlan  wrote:
>
> I have a nameserver which is authoritative for three or four domain names.
> It receives around 1000 queries per day that could be regarded as plausably
> legitimate.  It receives around ten times that number of absive queries per
> day from presumably spoofed ip addresses, the vast majority of them IN ANY
> queries for the "sl" domain or for the root nameservers all of which my
> nameserver responds to with return code 5 ie refused.

There have been several helpful replies, but to be honest I wouldn't spend
too much effort on low levels of abuse unless you want to use it as a
learning exercise. (I would care if it was multiple abusive queries per
second...)

> I have tried "errors-per-second 1" and this seems to reduce the abuse
> by about four fifths but one fifth of it still manages to get through
> and I don't find this acceptable.

RRL is designed to avoid interfering with legitimate traffic, but that
does mean that some abuse traffic leaks through. Its aim is to stop
amplification, so that the attackers don't get any benefit from abusing
your server.

But it sounds to me like your problem traffic is more like background
radiation (e.g. probes) than active abuse; if so it's likely that RRL will
not deter them.

> Instead, when I notice particularly heavy abuse of my nameserver,
> I apply packet filtering to prevent the abusive queries from reaching
> my nameserver and therefore to prevent it responding to them.

If all the problem traffic is sl. IN ANY, then I suggest permanently
leaving in place a filter to drop those queries. Use a string match rule,
like Grant Taylor suggested, but match the queries instead of the
responses, so they don't clutter your query logs.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate
becoming rough. Fair. Good.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[Tony Finch]

Anand Buddhdev  wrote:
>
> A legitimate client, following a normal chain of referrals, has *no*
> reason to query a server for zones it is not authoritative for.

That's true for cases like .sl and other domains whose delegations are set
up correctly, but if a server is accidentally lame then it's helpful to
return REFUSED so that resolvers don't have to wait for a timeout before
trying other servers. A quick REFUSED will also avoid messing up the
resolver's per-server statistics that might interfere with queries for
authoritative zones.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Fitzroy: Southeasterly 5 to 7, becoming variable 2 to 4 at
times in south. Moderate or rough, occasionally slight in south.
Thundery showers, fog patches. Moderate, occasionally very poor.

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

No logging of failed queries

[Sachchidanand Upadhyay via bind-users]

Hi, 

I am using bind's geoip feature, created one ACL to allow country IN. I am not 
getting logs of a failed query if the client IP is other than than country IN. 
Rest all is working fine, getting logs of successful queries. Below find the 
config details: 

BIND 9.16.13 (Stable Release)  
running on Linux x86_64 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Apr 8 19:51:47 
UTC 2021 
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' 
'--mandir=/usr/share/man' '--with-libtool=/usr/lib64' '--disable-static' 
'--with-maxminddb' 
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44) 
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017 
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017 
compiled with libuv version: 1.41.0 
linked to libuv version: 1.41.0 
compiled with zlib version: 1.2.7 
linked to zlib version: 1.2.7 
linked to maxminddb version: 1.2.0 
threads support is enabled 

default paths: 
named configuration: /etc/named.conf 
rndc configuration: /etc/rndc.conf 
DNSSEC root key: /etc/bind.keys 
nsupdate session key: /var/run/named/session.key 
named PID file: /var/run/named/named.pid 
named lock file: /var/run/named/named.lock 
geoip-directory: /usr/share/GeoIP 


acl "test" { 
geoip country IN; 
}; 

options { 
geoip-directory "path to geo db"; 

view "local" { 
match-clients { test; }; 
recursion yes; 

channel queries { 
file "/var/log/queries"; 
print-time yes; 
print-category yes; 
print-severity yes; 
}; 
category queries { 
queries; 
}; 
channel security { 
file "/var/log/security"; 
print-time yes; 
print-category yes; 
print-severity yes; 
}; 
category security { 
queries; 
}; 
channel query-errors { 
file "/var/log/query-errors"; 
print-time yes; 
print-category yes; 
print-severity yes; 
}; 
category query-errors { 
query-errors; 
}; 


BR, 
Sachchidanand 



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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: No logging of failed queries

[Mark Andrews]

Real world configurations would have a catch all view after the more specific 
views. Add one. 

-- 
Mark Andrews

> On 13 Apr 2021, at 22:41, Sachchidanand Upadhyay via bind-users 
>  wrote:
> 
> 
> Hi,
> 
>I am using bind's geoip feature, created one ACL to allow country IN. I am 
> not getting logs of a failed query if the client IP is other than than 
> country IN.
>Rest all is working fine, getting logs of successful queries. Below find 
> the config details:
> 
> BIND 9.16.13 (Stable Release) 
> running on Linux x86_64 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Apr 8 19:51:47 
> UTC 2021
> built by make with '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' 
> '--mandir=/usr/share/man' '--with-libtool=/usr/lib64' '--disable-static' 
> '--with-maxminddb'
> compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
> compiled with OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
> linked to OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
> compiled with libuv version: 1.41.0
> linked to libuv version: 1.41.0
> compiled with zlib version: 1.2.7
> linked to zlib version: 1.2.7
> linked to maxminddb version: 1.2.0
> threads support is enabled
> 
> default paths:
>   named configuration:  /etc/named.conf
>   rndc configuration:   /etc/rndc.conf
>   DNSSEC root key:  /etc/bind.keys
>   nsupdate session key: /var/run/named/session.key
>   named PID file:   /var/run/named/named.pid
>   named lock file:  /var/run/named/named.lock
>   geoip-directory:  /usr/share/GeoIP
> 
> 
> acl "test" {
>  geoip country IN;
> };
> 
> options {
>   geoip-directory  "path to geo db";
> 
> view "local" {
> match-clients {  test; };
> recursion yes;
> 
> channel queries {
> file "/var/log/queries";
> print-time yes;
> print-category yes;
> print-severity yes;
> };
> category queries {
> queries;
> };
> channel security {
> file "/var/log/security";
> print-time yes;
> print-category yes;
> print-severity yes;
> };
> category security {
> queries;
> };
> channel query-errors {
> file "/var/log/query-errors";
> print-time yes;
> print-category yes;
> print-severity yes;
> };
> category query-errors {
> query-errors;
> };
> 
> 
> BR,
> Sachchidanand 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> 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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[Julien Salort]

Le 13/04/2021 à 00:55, Richard T.A. Neal a écrit :


That's exactly what I do - I have some code that's watching for a frequent occurrence of these 
sorts of queries and then adds a firewall rule for a predetermined amount of time to simply drop 
the incoming packets at the firewall - this prevents them from reaching BIND in the first place and 
thus consuming system resource on the BIND server. And I say "predetermined amount of 
time" because that rule is then removed after a period of time in case the abuse was 
"unintentional" (ahem), or in case it came from a system using a non-static IP (i.e. a 
different user may be using that IP now, so I don't want to block them).


Do you block specifically the dns queries in the firewall, or straight 
out block the IP?


Reading this thread, I considered simply enabling the fail2ban 
named-refused jail, but they advise against it because it would end up 
blocking the victim rather than the attacker.


I understand that always ignoring these request may be bad if it causes 
some timeout somewhere (though I still do not quite fully understand 
what legitimate requests those may be for a server which only does 
authoritative answers). Couldn't bind then have a built-in option to 
ignore repeated attempts from a given host, and cap the number of error 
codes sent to a given host per day?


Julien

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2021-04-13 at 22:32 +0200, Julien Salort wrote:
> Reading this thread, I considered simply enabling the fail2ban
> named-refused jail, but they advise against it because it would end
> up
> blocking the victim rather than the attacker.

In the particular case of the .sl denied queries, I don't think these
are forged queries from the attack victim. Something else is going on
here. We see queries from systems like these, almost exclusively
consumer endpoints:

142-197-133-231.res.spectrum.com.
mta-162-154-195-235.kya.rr.com.
mobile-166-173-63-176.mycingular.net.
prg03s05-in-f193.1e100.net.
prg03s05-in-f1.1e100.net.
pool-173-79-59-79.washdc.fios.verizon.net.
174-30-51-96.wrbg.centurylink.net.
c-174-53-75-253.hsd1.va.comcast.net.
174-081-062-250.res.spectrum.com.
cpe-174-106-58-62.ec.res.rr.com.
192.sub-174-214-12.myvzw.com.
stop-looking-at-drifteds-ip.gov.
252.243.53.179.d.dyn.claro.net.do.
ip184-186-26-40.no.no.cox.net.
dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
customer-189-216-112-75.cablevision.net.mx.
189.223.57.66.dsl.dyn.telnor.net.
212-149-157-12.rev.dnaip.fi.

It seems unlikely that someone is trying to attack those specific
endpoints. Unless the attack is *very* widely distributed and they are
actually attacking the ISP infrastructure. But in that case, this seems
to be a simultaneous attack on almost every major ISP, which I find
unlikely.


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
n0zp1wmsrlc9yeDc/wXJCy8xBToC
=Ir5g
-END PGP SIGNATURE-


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Preventing a particular type of nameserver abuse

[@lbutlr]

On 13 Apr 2021, at 04:02, Anand Buddhdev  wrote:
> A legitimate client, following a normal chain of referrals, has *no*
> reason to query a server for zones it is not authoritative for.

Well, that's not really true. A mobile user might have their device configured 
to always check their corporate DNS server first, for example, then fall back 
if that fails.

Refusing makes everything faster, ignoring breaks things and makes things 
slower.

When a DNS host refuses a query, it will not be queried again, wen it times 
out, is is still in the rotation.

> Most of the time, such a query would only arrive at a name server from a 
> naughty
> client.

Unlikely as there is no benefit to the "naughty" client. This is not a 
amplification attack, the refusal is a short packet, meaning the query from the 
client is probably larger than the response. Very inefficient for naughty 
clients.

> And then, replying with any response, even REFUSED, is
> satisfying this client's naughtiness.

How?

> I think it's quite okay for an authoritative name server to simply DROP
> UDP queries for zones

It's not.

> that it's not authoritative for. It's better to
> ignore naughty clients, and give them the cold shoulder, and not
> participate in reflection attacks using REFUSED responses.

How do you imagine this is a reflection attack? It is far too small to be an 
effective attack for anything.


-- 
'Today Is A Good Day For Someone Else To Die!' --Feet of Clay

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

FW: Preventing a particular type of nameserver abuse

[Richard T.A. Neal]

Julien Salort wrote:

> Do you block specifically the dns queries in the firewall, or straight out 
> block the IP?

I specifically block both UDP 53 and TCP 53, but that's essentially a full 
block because these servers are only running BIND, nothing else.

> Reading this thread, I considered simply enabling the fail2ban named-refused 
> jail, but they advise against it because it would end up blocking the victim 
> rather than the attacker.

I'm happy to be corrected by more knowledgeable people than me, but I don't 
necessarily agree with fail2ban's recommendation. By blocking traffic to the 
victim (which is what I'm doing by blocking traffic from the spoofed Source IP, 
because no inbound traffic means no outgoing replies) then I'm helping to 
protect the victim, or at least prevent my server being used in the reflection 
attack against that victim.


Best,
Richard.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

FW: Preventing a particular type of nameserver abuse

[Richard T.A. Neal]

> In the particular case of the .sl denied queries, I don't think these are 
> forged queries from the attack victim. Something else is going on here. We 
> see queries from systems like these, almost exclusively consumer endpoints:

[snipped]

> It seems unlikely that someone is trying to attack those specific endpoints. 
> Unless the attack is *very* widely distributed and they are actually 
> attacking the ISP infrastructure. But in that case, this seems to be a 
> simultaneous attack on almost every major ISP, which I find unlikely.

Yes, another individual & I were discussing this off-list today. We wonder if 
those queries are from malware on infected hosts that are trying to determine 
whether a given nameserver can be used in a distributed reflection attack? The 
source IP is not spoofed (because it wants to get the answer), so if it gets 
either "refused" or a timeout then it knows that nameserver can't be used in 
the reflection attack. But if it gets a response with data then it knows it 
*can* be used in the reflection attack.

A lot of the "bad clients" that I block are also domestic IP addresses, and 
I've yet to come up with any other explanation so am always open to any 
plausible causes.

Best,
Richard.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: forwarding zone setup from a BIND slave (without recursion?)

[Sebby, Brian A. via bind-users]

I have been banging my head against the wall regarding this very topic and then 
found this thread from last week.  I’m also looking for a solution to this 
problem, and wondered if anyone may have some suggestions (including potential 
alternatives).

My situation is due to a security requirement.  We have DNS servers at our site 
running BIND that allow recursion, but I’ve been requested to set up some 
additional DNS servers for another project that is expected to *only* access 
the data that we’re authoritative for.  And of course …. there’s a chance that 
it might need to look up one or two external zones.  Essentially, what I really 
need is a recursive whitelist that doesn’t tell BIND what clients are allowed 
to do recursive lookups, but to limit BIND to only allow recursive lookups on a 
very small list of allowed domains.

I was trying to set up a forwarding zone to forward queries to our DNS servers 
that do allow recursion, but as I discovered (and as was discussed earlier in 
the thread), if recursion is not allowed, then forwarding is also not allowed.  
I had tried setting the “allow-recursion” field to “localhost” and setting up a 
forward zone to forward to 127.0.0.1, but that didn’t work either.

Is there any potential workaround for this, or do I just need to tell the 
person who requested this that they can only get all or nothing for recursive 
queries?  We’re still running BIND 9.11, but I was wondering if there may be 
new features in BIND 9.16 or 17 that I’m not aware of.


Thanks,

Brian

--
Brian Sebby (he/him/his)  |  Lead Systems Engineer
Email: se...@anl.gov  |  Information Technology 
Infrastructure
Phone: +1 630.252.9935|  Business Information Services
Cell:  +1 630.921.4305|  Argonne National Laboratory

From: bind-users  on behalf of RK K 

Date: Wednesday, April 7, 2021 at 7:40 PM
To: "bind-users@lists.isc.org" 
Subject: Re: forwarding zone setup from a BIND slave (without recursion?)

Hello Marki, Matus,

Thank you for the insights on this topic.

Answering Marki's question about why the secondary-authoritative (slaves) are 
used for lookups is some-what history and there was no need to be recursive 
(until now) as all the  queries are authoritatively answered or refused. May be 
security is another reason.

Much appreciated your ideas

Thank you
Kind Regards
RK

On Wed, Apr 7, 2021 at 8:01 AM 
mailto:bind-users-requ...@lists.isc.org>> 
wrote:
Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to

bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."


Today's Topics:

   1. forwarding zone setup from a BIND slave (without recursion?)
  (RK K)
   2. Re: forwarding zone setup from a BIND slave (without
  recursion?) (Matus UHLAR - fantomas)
   3. Re: forwarding zone setup from a BIND slave (without
  recursion?) (Marki)


--

Message: 1
Date: Tue, 6 Apr 2021 22:47:23 -0400
From: RK K mailto:rvk...@gmail.com>>
To: bind-users@lists.isc.org
Subject: forwarding zone setup from a BIND slave (without recursion?)
Message-ID:

mailto:caotbjrubejlxc6-uff5kgkd_ignoytg_ku2pkdxbhpovyzs...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

All,

We have a set of BIND primary servers (MASTERs) and a set of secondary
servers (slaves to the MASTERs).
The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *)
in the global options.
All the applications/systems do use secondary DNS servers for name
resolution.

Now there is a need to configure a forwarding zone in the "secondary DNS
servers" to an external DNS server.

In this scenario, in-order for the secondary server to forward the DNS
query to an external DNS server, is it required to enable the recursion in
the global options on the secondary servers?
Based on reference material, I did not see such a requirement. But my
observation is the query is not getting forwarded ( tried to check using
the packet trace)
When recursion is enabled, the query is getting forwarded.

The BIND version I am using is 9.11.2.x.

Appreciate your ideas and help.

Thank you
Kind Regards,
Ravi Kota
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Wed, 7 Apr 2021 10:35:12 +0200
From: Matus UHLAR - fant

Re: Preventing a particular type of nameserver abuse

[Paul Kosinski via bind-users]

Interesting observation. I just did lookups on 4 recent (< 24 hrs ago) 
'sl/ANY/IN' queries logged by our BIND and got:

2 Comcast cable IPs (hsd1.tx.comcast.net and hsd1.ma.comcast.net)
1 OVH Hosting IP (Montreal)
1 Afranet IP (Tehran!)

The whois info for the OVH IP contains the line:

  Comment:   Failover IPs


On Tue, 13 Apr 2021 14:04:14 -0700
Carl Byington via bind-users  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Tue, 2021-04-13 at 22:32 +0200, Julien Salort wrote:
> > Reading this thread, I considered simply enabling the fail2ban
> > named-refused jail, but they advise against it because it would end
> > up
> > blocking the victim rather than the attacker.  
> 
> In the particular case of the .sl denied queries, I don't think these
> are forged queries from the attack victim. Something else is going on
> here. We see queries from systems like these, almost exclusively
> consumer endpoints:
> 
> 142-197-133-231.res.spectrum.com.
> mta-162-154-195-235.kya.rr.com.
> mobile-166-173-63-176.mycingular.net.
> prg03s05-in-f193.1e100.net.
> prg03s05-in-f1.1e100.net.
> pool-173-79-59-79.washdc.fios.verizon.net.
> 174-30-51-96.wrbg.centurylink.net.
> c-174-53-75-253.hsd1.va.comcast.net.
> 174-081-062-250.res.spectrum.com.
> cpe-174-106-58-62.ec.res.rr.com.
> 192.sub-174-214-12.myvzw.com.
> stop-looking-at-drifteds-ip.gov.
> 252.243.53.179.d.dyn.claro.net.do.
> ip184-186-26-40.no.no.cox.net.
> dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
> dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
> customer-189-216-112-75.cablevision.net.mx.
> 189.223.57.66.dsl.dyn.telnor.net.
> 212-149-157-12.rev.dnaip.fi.
> 
> It seems unlikely that someone is trying to attack those specific
> endpoints. Unless the attack is *very* widely distributed and they are
> actually attacking the ISP infrastructure. But in that case, this seems
> to be a simultaneous attack on almost every major ISP, which I find
> unlikely.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
> LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
> n0zp1wmsrlc9yeDc/wXJCy8xBToC
> =Ir5g
> -END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: FW: Preventing a particular type of nameserver abuse

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2021-04-13 at 22:42 +, Richard T.A. Neal wrote:
> Yes, another individual & I were discussing this off-list today. We
> wonder if those queries are from malware on infected hosts that are
> trying to determine whether a given nameserver can be used in a
> distributed reflection attack? The source IP is not spoofed (because
> it wants to get the answer), so if it gets either "refused" or a
> timeout then it knows that nameserver can't be used in the reflection
> attack. But if it gets a response with data then it knows it *can* be
> used in the reflection attack.

That makes sense, but in that case the malware is badly written (what a
surprise). In 28 hours a single dns server here saw 1182 such queries
from 80.2.150.110 = cpc99574-brnt1-2-0-cust621.4-2.cable.virginm.net.

I am now using the equivalent of fail2ban to firewall those clients.

-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHY0yhUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsEkYwCfT3lTQO8NIdgSkMvAS03QmrnixiUA
n0IYWwS3qImFMByQzfUbWhK1v850
=D55z
-END PGP SIGNATURE-


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: FW: Preventing a particular type of nameserver abuse

[Brett Cooper]

Of the small amount of name servers I run, each and every name server 
has had persistent attacks (I guess) in the form of "(sl): query (cache) 
'sl/ANY/IN' denied". These attacks appear to be originating from 
legitimate ISP resolvers, but the majority of the attacks appear to be 
drones/malware of sorts. I am assuming the majority of these IP's are 
spoofed. These attacks appeared to begin in Dec 2020 / Jan 2021, and 
have persisted up to this writing. The worst of it was in Jan 2021 for 
me.
Prior to me crafting a firewall rule, log monitoring and triggers, and 
adding some loose rate limiting (The various *-per-second options), I 
would see well more than 2500 queries an hour for the sl query from 
copious amounts of IP's. It probably was much more than that, as it was 
pegging a VPS single vCPU that I have to 100% - bad on me for not 
hardening that particular virtual machine in the first place months ago. 
 The other name servers had similar attacks, but not to the same 
magnitude by a long shot.
Today, and so far, the VPS above that was originally taking in such a 
huge amount of sl queries, has temporarily blocked 78 unique IPv4 
addresses. Every query from each of the IP's has been in the form of:
Apr 13 22:08:55 ns02 named[432]: client @0x7f98c063d430 50.99.83.201#80 
(sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:08:55 ns02 named[432]: client @0x7f98c063d430 50.99.83.201#80 
(sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:08:56 ns02 named[432]: client @0x7f98c063d430 50.99.83.201#80 
(sl): query (cache) 'sl/ANY/IN' denied

[...]
Apr 13 22:44:02 ns02 named[9487]: client @0x7fc8740c7310 
46.102.130.246#80 (sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:44:02 ns02 named[9487]: client @0x7fc8740c7310 
46.102.130.246#80 (sl): query (cache) 'sl/ANY/IN' denied
Apr 13 22:44:04 ns02 named[9487]: client @0x7fc8740c7310 
46.102.130.246#80 (sl): query (cache) 'sl/ANY/IN' denied


--Brett

-- Original Message --
From: "Richard T.A. Neal" 
To: "bind-users@lists.isc.org" 
Sent: Apr 13, 2021 17:42:28 PM
Subject: FW: Preventing a particular type of nameserver abuse


 In the particular case of the .sl denied queries, I don't think these are 
forged queries from the attack victim. Something else is going on here. We see 
queries from systems like these, almost exclusively consumer endpoints:


[snipped]


 It seems unlikely that someone is trying to attack those specific endpoints. 
Unless the attack is *very* widely distributed and they are actually attacking 
the ISP infrastructure. But in that case, this seems to be a simultaneous 
attack on almost every major ISP, which I find unlikely.


Yes, another individual & I were discussing this off-list today. We wonder if those 
queries are from malware on infected hosts that are trying to determine whether a given 
nameserver can be used in a distributed reflection attack? The source IP is not spoofed 
(because it wants to get the answer), so if it gets either "refused" or a timeout 
then it knows that nameserver can't be used in the reflection attack. But if it gets a 
response with data then it knows it *can* be used in the reflection attack.

A lot of the "bad clients" that I block are also domestic IP addresses, and 
I've yet to come up with any other explanation so am always open to any plausible causes.

Best,
Richard.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: forwarding zone setup from a BIND slave (without recursion?)

[Marki]

On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote:


My situation is due to a security requirement.  We have DNS servers at 
our site running BIND that allow recursion, but I’ve been requested to 
set up some additional DNS servers for another project that is 
expected to **only** access the data that we’re authoritative for.  
And of course …. there’s a chance that it might need to look up one or 
two external zones.  Essentially, what I really need is a recursive 
whitelist that doesn’t tell BIND what clients are allowed to do 
recursive lookups, but to limit BIND to only allow recursive lookups 
on a very small list of allowed domains.


I was trying to set up a forwarding zone to forward queries to our DNS 
servers that do allow recursion, but as I discovered (and as was 
discussed earlier in the thread), if recursion is not allowed, then 
forwarding is also not allowed. I had tried setting the 
“allow-recursion” field to “localhost” and setting up a forward zone 
to forward to 127.0.0.1, but that didn’t work either.




Hello,

So they do _not_ only look up internal/authoritative zones, but external 
ones as well. (It's always the exceptions that kill you.)


I think we have previously established that there is not a good way to 
do whitelisting using Bind, see the thread "Authority and forwarding, 
but not recursion/iteration".


If you can live with non-allowed zones returning SERVFAIL (instead of 
NXDOMAIN for example), then using a recursive service with a bogus 
global forwarder and static stubs pointing to the 
authoritative/non-recursive service might do the trick.


You might also be able to leverage RPZ if there are no complex 
conditions associated to your rules (everyone will have the same 
white/blacklists). You configure passthrough for the allowed zones and 
deny the rest.


Alternatively, there is dnsdist which, while being a load-balancer, 
could be considered the swiss army knife of DNS filtering.


Finally, some firewalls like Fortigates provide a "DNS filter" that lets 
you define custom white and blacklists. Palo Altos currently are not 
able to whitelist AFAIK.


Best regards,

Marki

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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