Re: Ask for automated KSK roll with DS checking

[Matthijs Mekking]

On 14-04-2021 22:30, Greg Rivers via bind-users wrote:

On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote:

Does anyone have an automated KSK roll process, that checks for the DS
record at the parent, that they can share?

As far as I can tell, the automated signing in BIND will roll the KSK if I
set the timing in the policy file, but it won't check the DS record, so it
will happily break DNSSEC if some other process does not update the DS
record at the right time.  That's too big a risk for me, the process needs
to check the DS record before completing the KSK roll.  Surely someone has
done this.  I would rather not reinvent the wheel.  But I have searched and
not found anything yet.


As I understand it, the way it works now is that the actual KSK rollover won't 
occur until you execute `rndc dnssec -checkds ...` [1].


That is correct.


I'm hopeful that named will fully automate this check at some point soon.


It is on the roadmap:

https://gitlab.isc.org/isc-projects/bind9/-/issues/1126

- Matthijs



[1] 



___
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

[Mark Andrews]

> On 15 Apr 2021, at 11:35, @lbutlr  wrote:
> 
> On 14 Apr 2021, at 01:48, Anand Buddhdev  wrote:
>> This is a short-sighted opinion. If just one authoritative server sends
>> out REFUSED responses towards an innocent, it won't matter. But if 1000
>> authoritative servers all send out REFUSED responses towards an innocent
>> IP address, their combined volume and packet rate *is* significant.
> 
> Is it?
> 
> How big is a REFUSED response?

Approximately the same size as the request.  It depends on the request and
the server’s capabilities.

> Even if it is 100 bytes (and I think it is not that large, but I cannot find 
> it), 1000 refused would be 100K.
> 
> How many thoudanss of servers do you need in this "DDoS" to overwhelm a 
> pretty average connection? (My home connection is only 200Mbps down).
> 
> Granted, a million machines would be generating a 100MB of data, which is 
> insignificantes, but the number of pockets at that scale would probably be an 
> issue. But is a million servers realistic?
> 
> I don't think calling this a DDoS is accurate. It is more likely;y there is a 
> known exploit for some servers and they are probing or it is some script 
> kiddie just blasting out packets hoping to get lucky.

If you really want to do something, talk to your local politician and get laws 
written up that require ISPs to deploy BCP38.  This is completely fixable if 
ISPs deploy BCP38 filters on themselves and all of their customers.  There is 
some CAPEX and OPEX to deploying BCP38 filters and making it a requirement 
under law levels the playing field between ISPs.

> -- 
> "Are you pondering what I'm pondering?"
> "I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
>   it doing right now?"
> 
> ___
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
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

On 14 Apr 2021, at 01:48, Anand Buddhdev  wrote:
> This is a short-sighted opinion. If just one authoritative server sends
> out REFUSED responses towards an innocent, it won't matter. But if 1000
> authoritative servers all send out REFUSED responses towards an innocent
> IP address, their combined volume and packet rate *is* significant.

Is it?

How big is a REFUSED response?

Even if it is 100 bytes (and I think it is not that large, but I cannot find 
it), 1000 refused would be 100K.

How many thoudanss of servers do you need in this "DDoS" to overwhelm a pretty 
average connection? (My home connection is only 200Mbps down).

Granted, a million machines would be generating a 100MB of data, which is 
insignificantes, but the number of pockets at that scale would probably be an 
issue. But is a million servers realistic?

I don't think calling this a DDoS is accurate. It is more likely;y there is a 
known exploit for some servers and they are probing or it is some script kiddie 
just blasting out packets hoping to get lucky.

-- 
"Are you pondering what I'm pondering?"
"I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
it doing right now?"

___
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

[Peter Coghlan]

Tony Finch wrote:
>Peter Coghlan  wrote:
>> Instead, isn't it the case that bind knows what domains it is authoritative
>> for (or which ones it is supposed to be authoritative for) and bind is
>> therefore in the ideal position to know which queries are abusive and which
>> are not rather than wrapping kludgy filtering mechanisms around it?
>
> Not always, sadly, because of misconfigured (lame) delegations. See the
> earlier messages from me and Ondřej -
>
> https://lists.isc.org/pipermail/bind-users/2021-April/104408.html
> 
> https://lists.isc.org/pipermail/bind-users/2021-April/104423.html
>

But I don't have any misconfigured (lame) delegations and even if I had,
I think I would rather put up with the consequences of the lame delegations
on rare occasions than having my nameserver foisting abuse on others all
the time.

Those that are more worried about having lame delegations don't have to
use any option that would cause error responses to be dropped.

(I've been there and done that with the lame delegations years ago.  When
I fouled up the master, the slaves toiled on regardless, presumably because
the master returned "non-authoritative" or "refused" and nobody noticed there
was any problem.  Meanwhile, the slaves were unable to get zone transfers
from the fouled up master and much much later, they hit whatever the relevant
timeout was and the zone failed completely.  There then followed lots of head
scratching as to why the domain had failed when nothing had changed recently.
I think I would have preferred if it had failed immediately I made the
incorrect change (and I probably failed to notice bind trying to tell me about
it too) because I would have known exactly where to look for the problem.)

>> If there is a resistance to having bind ignore the abusive queries
>> altogether, could we at least have something like "errors-per-minute 1"
>> which would reduce the problem by a factor of 60 compared with
>> "errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)
>
> There is probably something that might improve things, but I'm not sure
> what it is. I think the minimum RRL rate of 1 per second might be intended
> to work with resolver retry times. I'm wary of suppressing error responses
> without thinking through the possible consequences.
>

But isn't this what the filtering that has been suggested is going to do?
Except isn't the filtering marginally more likely to get fouled up because
of the danger of not keeping the filtering configuration and the bind
configuration in sync with each other?

Regards,
Peter Coghlan.

> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Viking, North Utsire, South Utsire, Forties: Northerly or
> northwesterly 3 to 5, becoming variable 3 or less later. Moderate
> becoming slight. Showers. 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]

Peter Coghlan  wrote:
>
> I wouldn't describe it as background radiation or probes.  It doesn't seem
> to be caused by misconfigured or faulty resolvers or anything of that nature.

Hmm, maybe air pollution would be a better metaphor? What I mean is the
kind of continuous low levels of abuse that's definitely harmful in
aggregate, but it's not clear who is responsible or what can be done about
it. These sl/IN/ANY queries are exactly the kind of thing I had in mind.

> It is possible for me to apply filtering that catches most or maybe all of
> this but this only fixes the problem on my server and does nothing to prevent
> the abuse of lots of other servers out there.

Yeah, it's a wicked problem. There's very little one can do as a server
operator except for relatively limited mitigations. The real fix is to
trace back the traffic and do malware analysis of the sources and all that
fun forensic blue team stuff that is a very long way away from my job or
abilities :-) Before DNS I did anti-spam stuff for several years so I have
had to make peace with protecting my systems and users from the worst of
the abuse, without being in a position to do much about the causes, other
than helping to keep our networks clean.

> Instead, isn't it the case that bind knows what domains it is authoritative
> for (or which ones it is supposed to be authoritative for) and bind is
> therefore in the ideal position to know which queries are abusive and which
> are not rather than wrapping kludgy filtering mechanisms around it?

Not always, sadly, because of misconfigured (lame) delegations. See the
earlier messages from me and Ondřej -

https://lists.isc.org/pipermail/bind-users/2021-April/104408.html

https://lists.isc.org/pipermail/bind-users/2021-April/104423.html

> If there is a resistance to having bind ignore the abusive queries
> altogether, could we at least have something like "errors-per-minute 1"
> which would reduce the problem by a factor of 60 compared with
> "errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)

There is probably something that might improve things, but I'm not sure
what it is. I think the minimum RRL rate of 1 per second might be intended
to work with resolver retry times. I'm wary of suppressing error responses
without thinking through the possible consequences.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Viking, North Utsire, South Utsire, Forties: Northerly or
northwesterly 3 to 5, becoming variable 3 or less later. Moderate
becoming slight. Showers. 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: Ask for automated KSK roll with DS checking

[Greg Rivers via bind-users]

On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote:
> Does anyone have an automated KSK roll process, that checks for the DS
> record at the parent, that they can share?
> 
> As far as I can tell, the automated signing in BIND will roll the KSK if I
> set the timing in the policy file, but it won't check the DS record, so it
> will happily break DNSSEC if some other process does not update the DS
> record at the right time.  That's too big a risk for me, the process needs
> to check the DS record before completing the KSK roll.  Surely someone has
> done this.  I would rather not reinvent the wheel.  But I have searched and
> not found anything yet.
> 
As I understand it, the way it works now is that the actual KSK rollover won't 
occur until you execute `rndc dnssec -checkds ...` [1].

I'm hopeful that named will fully automate this check at some point soon.


[1] 


-- 
Greg


___
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

Ask for automated KSK roll with DS checking

[Bob Harold]

Does anyone have an automated KSK roll process, that checks for the DS
record at the parent, that they can share?


As far as I can tell, the automated signing in BIND will roll the KSK if I
set the timing in the policy file, but it won't check the DS record, so it
will happily break DNSSEC if some other process does not update the DS
record at the right time.  That's too big a risk for me, the process needs
to check the DS record before completing the KSK roll.  Surely someone has
done this.  I would rather not reinvent the wheel.  But I have searched and
not found anything yet.


-- 
Bob Harold
DNS and DHCP Hostmaster - UMNet
Information and Technology Services (ITS)
rharo...@umich.edu
___
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

[Sten Carlsen]

Thanks

Sten

> On 14 Apr 2021, at 19.47, Carl Byington via bind-users 
>  wrote:
> 
> Signed PGP part
> On Wed, 2021-04-14 at 12:58 -0400, Paul Kosinski via bind-users wrote:
> > Interesting, although we host different domains, in and from different
> > geographic areas, we got the same queries as yours on the same day,
> > with some at about the same time (we're EDT).
> > 13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074
> > (sl): query (cache) 'sl/ANY/IN' denied
> > 13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074
> > (sl): query (cache) 'sl/ANY/IN' denied
> 
> These times are PDT (-0700)
> 
> Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> 
> Apr 12 23:19:15 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
> (sl): view normal: query (cache) 'sl/ANY/IN' denied
> 
> So either 76.20.145.58, or someone forging that source ip, made queries
> to servers in (+), (-0400), and (-0700) at the same time. Malware
> running on 76.20.145.58 is one explanation. Would the REFUSED replies
> carry enough information from the original query to be used as a covert
> communication channel into something listening on 76.20.145.58?
> 
> vpn over dns query-refused replies? That seems a bit far-fetched.

I wonder if it may be an attempt to keep track of the Internet speed across the 
world?
If you send off these queries at the same time to different locations what 
would the round trip time tell you?
It would probably be a fair assessment of the speed of the net - might be a 
replacement for pings.

> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
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

[Chuck Aurora]

On 2021-04-14 04:38, Gaurav Kansal wrote:

Is there a way, by which we can log denied statement w.r.t. view
somewhere in logging ?


The thing is, your view did not deny anything.  Your non-.IN client
simply does not match the match-clients list for that view.


On 14/04/21 1:48 am, ma...@isc.org wrote:


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


And that's what Mark is suggesting here.  If you follow your view
with another view:

view "any" {
match-clients { any; };
allow-recursion no;
allow-query { none; };
};

... then you get your denied query.


On 13 Apr 2021, at 22:41, Sachchidanand Upadhyay via bind-users
 wrote:

snip
___
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

[Peter Coghlan]

Tony Finch wrote:
> 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 think a learning exercise would be very useful as there seems to be very
little awareness of this issue and I found it very difficult to find any
discussion or analysis of it anywhere.  From the replies to my posting here,
it seems apparant that my nameserver is definately not the only one which is
experiencing this abuse.

I am seeing abusive query rates of 5 per second for sustained periods of the
day.  As far as I can see this is specially designed to get in under the
widely suggested "errors-per-second 5" rate limiting.

>
>> 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.
>

Sure but something is clearly benefitting from the abuse because it is
going on day in, day out for months now and it it is apparantly happening
on servers other than mine too.

Also, my nameserver doesn't receive any legitimate traffic at all which my
nameserver replies to with "refused" responses.

>
> 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.
>

I wouldn't describe it as background radiation or probes.  It doesn't seem
to be caused by misconfigured or faulty resolvers or anything of that nature.
Exactly the same queries (including the same source port and query id) are
repeated over and over again whether a "refused" reply is provided or not.
It seems pretty clearly abusive to me even if the exact purpose of the abuse
is not so obvious yet.

>
>> 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.
>

>From what I can see, roughly half of the problem traffic is sl/IN/ANY and the
other half is ./IN/ANY.  Some of the problem traffic has source ports less
than 1024 and some doesn't. ([tos 0x8] is often thrown in for good measure
too. I wonder what that's about?)

It is possible for me to apply filtering that catches most or maybe all of
this but this only fixes the problem on my server and does nothing to prevent
the abuse of lots of other servers out there.

Besides, I'm not really that concerned about the effect on my nameserver, I am
more concerned about the effect of the abusive traffic being reflected by
my nameserver and various other nameservers onto innocent third parties
with little or no awareness that this is happening.

Also, I don't believe a sufficiently portable filtering mechanism exists
which can be deployed across all the platforms that bind can be deployed
on.

Even if everybody could start filtering queries for "sl" and the root
nameservers, what's to stop the abusers moving on to using a different
domain name when they discover this filtering being applied?

Instead, isn't it the case that bind knows what domains it is authoritative
for (or which ones it is supposed to be authoritative for) and bind is
therefore in the ideal position to know which queries are abusive and which
are not rather than wrapping kludgy filtering mechanisms around it?

If there is a resistance to having bind ignore the abusive queries
altogether, could we at least have something like "errors-per-minute 1"
which would reduce the problem by a factor of 60 compared with
"errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)

Regards,
Peter Coghlan.

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

Re: Preventing a particular type of nameserver abuse

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2021-04-14 at 12:58 -0400, Paul Kosinski via bind-users wrote:
> Interesting, although we host different domains, in and from different
> geographic areas, we got the same queries as yours on the same day,
> with some at about the same time (we're EDT).
> 13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074
> (sl): query (cache) 'sl/ANY/IN' denied
> 13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074
> (sl): query (cache) 'sl/ANY/IN' denied

These times are PDT (-0700)

Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied
Apr 12 23:18:13 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied

Apr 12 23:19:15 ns named[5091]: client @0x7fda540105b8 76.20.145.58#3074
(sl): view normal: query (cache) 'sl/ANY/IN' denied

So either 76.20.145.58, or someone forging that source ip, made queries
to servers in (+), (-0400), and (-0700) at the same time. Malware
running on 76.20.145.58 is one explanation. Would the REFUSED replies
carry enough information from the original query to be used as a covert
communication channel into something listening on 76.20.145.58?

vpn over dns query-refused replies? That seems a bit far-fetched.



-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHcqsRUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsEvgACgh6muAlNI6qk99Rd9sLaSp29IESQA
njJo7E3ajD0Yw/ja7VOStNhgkxDd
=tlQQ
-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

[Paul Kosinski via bind-users]

Interesting, although we host different domains, in and from different 
geographic areas, we got the same queries as yours on the same day, with some 
at about the same time (we're EDT).

13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.365 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.366 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.568 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.820 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied


13-Apr-2021 03:04:25.379 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:25.553 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied

This is not a complete list, but they all were on Apr 13 (and near your times).

==

On Tue, 13 Apr 2021 15:23:20 +0100 (WET-DST)
Peter Coghlan  wrote:

> Hi Paul,
> 
> Many thanks for your reply.  Yours is exactly the sort of reply I was hoping
> for because I feel like I have been banging my head on a brick wall for months
> now looking for someone else who cares whether their nameserver is an engine
> for this sort of abuse.  I was beginning to wonder if I was the only person
> in the world seeing this kind of abuse and regarding it as a problem.
> 
> I will leave another while to see if more clueful replies like yours arrive
> and then I will reply back to the list again myself to try to move the thread
> in the direction of requesting a solution which can easily be implemented by
> anyone and does not involve packet filters, firewalls, IPtables and so on.
> 
> In the meantime, I thought it would be interesting to see if I also got
> the same abusive queries you logged below.  Unfortunately (or fortunately)
> I am packet filtering incoming queries with source port 80 so they did not
> make it as far as the logs in my case.  Here are a few that did make it to
> my logs.  Maybe they are in yours too?
> 
> Regards,
> Peter Coghlan.
> 
> 13-Apr-2021 06:20:10.867 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.396 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.743 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.804 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.746 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.935 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:33.993 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:34.047 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
___
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]

sth...@nethelp.no  wrote:
>
> Agree that you should be able to ignore them. But as a practical matter,
> ignoring them *may* result in the question being asked again and again,
> while REFUSED *may* stop the client from asking more.

REFUSED leads to retries too: if the client is a legit resolver it will
retry using the other authoritative servers. For example, when I changed
private.cam.ac.uk from refusing external queries to replying with an empty
answer, the load on our auth servers dropped by half.

Retries following REFUSED are also one reason why the RFC 8482 minimal-any
option is not refuse-any: when an ANY attack is bouncing off a recursive
server, the authoritative server can reduce the power of the attack by
returning a small cacheable answer. This reduces the load on the
authoritative servers (no retries), and on the recursive servers (no need
to recurse and retry), and reduces the volume of the attack traffic.

Probe traffic like these sl/IN/ANY queries is a very different matter. I
wouldn't expect any kind of reasonable behaviour, so it makes sense to
drop the queries as early as possible.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Fitzroy, Sole: Easterly or southeasterly 4 to 6. Moderate or
rough. Showers at first in northwest Fitzroy, otherwise 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: FW: Preventing a particular type of nameserver abuse

[Alessandro Vesely]

On Wed 14/Apr/2021 00:37:22 +0200 Richard T.A. Neal wrote:

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.


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.



That behavior might expose the victim to some kind of spear DoS.  If the 
attackers know the victim is going to seek services from .myzone, they can 
spray the authoritative servers of .myzone with illegal requests apparently 
coming from the victim's resolvers.  That way, when the victim tries to resolve 
needed.service.myzone it will be DoSsed.



Best
Ale
--



















___
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

[Jim Popovitch via bind-users]

On Wed, 2021-04-14 at 08:07 +, Richard T.A. Neal wrote:
> 
> Just out of interest, because I run some services on OVH, I know what
> that term means. When you rent a dedicated server from OVH you are
> assigned a single IPv4 address. Let's assume that you then want to use
> VMware or Hyper-V on that dedicated server to run some VMs - for many
> of those VMs you'll obviously want a distinct public IPv4 address. So
> OVH assign you what they term a "failover" block of IPv4 addresses. I
> don't know why they use that term, I just know that they do! So really
> it's just confirmation that it's an OVH customer (running a VM on a
> dedicated server) that is either the source IP or the spoofed target.


Additional IP address are one thing, Failover IPs are something else. 
In OVH land they unfortunately lease additional IPs using the same
french-to-english translated text form.  OVH "Failover IPs" are probably
used more for adding an additional IP to a leased server
(VPS/Cloud/Physical), but the true purpose and benefit of OVH (and other
provider's) Failover IP is that the customer can have one or more
reserved IPs and quickly transfer them from server to server using the
OVH API.  This is great for database resiliency/failover, etc.

-Jim P.

___
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

[Gaurav Kansal]

Hi Mark,

Is there a way, by which we can log denied statement w.r.t. view 
somewhere in logging ?


Regards,
Gaurav

On 14/04/21 1:48 am, ma...@isc.org wrote:
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


--
Thanks and Regards,
Gaurav Kansal
+91-9910118448





Disclaimer:

This e-mail and its attachments may contain official Indian Government information. If you are not the intended recipient, please notify the sender immediately and delete this e-mail. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. The responsibility lies with the recipient to check this email and any attachment for the presence of viruses.   
___
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

[sthaug]

> I'm not talking of DNS *resolvers* here. I'm talking of authoritative
> servers. If my authoritative server is authoritative for zones A, B and
> C, then I should only get queries for those zones from legitimate
> resolvers and clients. Queries for any other zones should *not* be
> coming to my server. I shouldn't even be obliged to answer with REFUSED.
> I should just be able to ignore those queries completely as junk.

Agree that you should be able to ignore them. But as a practical matter,
ignoring them *may* result in the question being asked again and again,
while REFUSED *may* stop the client from asking more.

I run one of the authoritative name servers for no (Norway). That name
server receives its share of completely irrelevant queries, e.g. (25
queries from just now):

NS? .
ANY? sl.
ANY? sl.
A? d2cnv2pop2xy4v.cloudfront.net.
NS? .
A? www.google.li.
A? tussilagobarnehage-no02c.mail.protection.outlook.com.
A? handball-havdur-no.mail.protection.outlook.com.
A? tronica-no.mail.protection.outlook.com.
A? storage-support.glb.itcs.hpe.com.
A? msgr-latest.c10r.facebook.com.
NS? .
A? mqtt.c10r.facebook.com.
A? inappcheck.itunes.apple.com.edgekey.net.
Type65? inappcheck.itunes.apple.com.edgekey.net.
Type65? e69896.dscapi6.akamaiedge.net.
A? e69896.dscapi6.akamaiedge.net.
A? javvs-no.mail.protection.outlook.com.
A? clients4.google.com.
A? clients.l.google.com.
A? storage-support.glb.itcs.hpe.com.
A? au-bg-shim.trafficmanager.net.
NS? .
ANY? sl.
ANY? sl.

And here again we see the queries for .sl. In any case, the volume of
these queries is so low (on the order of 0.1% of the total) that I
don't really care. I'm not going to spend any time worrying about the
resource usage of these queries.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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ý]

Anand,

I understand that this topic is something you feel passionate about, but alas, 
it’s more complicated than just dropping REFUSED answers. Any lame delegation 
would be then susceptible to cache poisoning. Also it would be a protocol 
violation.

A small well-maintained authoritative server might be able to safely disable 
such answers, but it’s not cure-all, and it could quickly bite you back even in 
case of small authoritative servers. Imagine admin of example.org botches up 
delegation of vpn.example.org and would be able to poison the cache somewhere. 
There too many possible scenarios where things might go wrong and shifting the 
blame from lack of BCP38 implementation to well-behaved DNS servers isn’t 
particularly helpful.

I think dropping such answers would be very similar to: 
https://www.cvedetails.com/cve/CVE-2008-3337/ and 
https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2008-02.html

Ondřej 
--
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 14. 4. 2021, at 9:49, Anand Buddhdev  wrote:
> 
> On 14/04/2021 00:29, @lbutlr 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.
> 
> I'm not talking of DNS *resolvers* here. I'm talking of authoritative
> servers. If my authoritative server is authoritative for zones A, B and
> C, then I should only get queries for those zones from legitimate
> resolvers and clients. Queries for any other zones should *not* be
> coming to my server. I shouldn't even be obliged to answer with REFUSED.
> I should just be able to ignore those queries completely as junk.
> 
>> 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.
> 
> This is a misbelief. When a resolver fails to get an answer from an
> authoritative server (whether explicitly with a REFUSED response, or
> just a timeout), it may lower the preference for that name server, but
> will eventually retry, in case that server is able to answer for that
> zone again.
> 
>>> 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.
> 
> Amplification isn't necessary for causing a DDoS towards an innocent
> client. Even a high-enough packet rate (with small packets), can
> overwhelm the upstream router of the client, or use up a significant
> portion of the bandwidth. It can also cause problems for the client
> whose networking stack has to deal with the packets. Whether an unwanted
> packet is of 100 bytes or 1000 bytes, the network stack has to deal with
> it somehow.
> 
>>> And then, replying with any response, even REFUSED, is
>>> satisfying this client's naughtiness.
>> 
>> How?
> 
> A spoofer gets to generate responses, however, small, towards an
> innocent client.
> 
>>> I think it's quite okay for an authoritative name server to simply DROP
>>> UDP queries for zones
>> 
>> It's not.
> 
> If you try to SSH to a server that you're not supposed to connect to,
> and it drops your packets, you won't complain right? So why are you so
> bothered about a DNS server that drops queries it's not supposed to be
> receiving? The DNS resolution protocol is clear. A resolver is supposed
> to follow a chain of referrals, and not query any random server on the
> Internet. So a legitimate resolver has no business querying random
> authoritative servers for zones they're not supposed to serve.
> 
>>> 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.
> 
> This is a short-sighted opinion. If just one authoritative server sends
> out REFUSED responses towards an innocent, it won't matter. But if 1000
> authoritative servers all send out REFUSED responses towards an innocent
> IP address, their combined volume and packet rate *is* significant.
> 
> Regards,
> Anand
> ___
> 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.

FW: Preventing a particular type of nameserver abuse

[Richard T.A. Neal]

Paul Kosinksi wrote:

> Interesting observation. I just did lookups on 4 recent (< 24 hrs ago) 
> 'sl/ANY/IN' queries logged by our BIND and got:
> ...1 OVH Hosting IP (Montreal)
> The whois info for the OVH IP contains the line:
>  Comment:   Failover IPs

Just out of interest, because I run some services on OVH, I know what that term 
means. When you rent a dedicated server from OVH you are assigned a single IPv4 
address. Let's assume that you then want to use VMware or Hyper-V on that 
dedicated server to run some VMs - for many of those VMs you'll obviously want 
a distinct public IPv4 address. So OVH assign you what they term a "failover" 
block of IPv4 addresses. I don't know why they use that term, I just know that 
they do! So really it's just confirmation that it's an OVH customer (running a 
VM on a dedicated server) that is either the source IP or the spoofed target.

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: Preventing a particular type of nameserver abuse

[Anand Buddhdev]

On 14/04/2021 00:29, @lbutlr 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.

I'm not talking of DNS *resolvers* here. I'm talking of authoritative
servers. If my authoritative server is authoritative for zones A, B and
C, then I should only get queries for those zones from legitimate
resolvers and clients. Queries for any other zones should *not* be
coming to my server. I shouldn't even be obliged to answer with REFUSED.
I should just be able to ignore those queries completely as junk.

> 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.

This is a misbelief. When a resolver fails to get an answer from an
authoritative server (whether explicitly with a REFUSED response, or
just a timeout), it may lower the preference for that name server, but
will eventually retry, in case that server is able to answer for that
zone again.

>> 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.

Amplification isn't necessary for causing a DDoS towards an innocent
client. Even a high-enough packet rate (with small packets), can
overwhelm the upstream router of the client, or use up a significant
portion of the bandwidth. It can also cause problems for the client
whose networking stack has to deal with the packets. Whether an unwanted
packet is of 100 bytes or 1000 bytes, the network stack has to deal with
it somehow.

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

A spoofer gets to generate responses, however, small, towards an
innocent client.

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

If you try to SSH to a server that you're not supposed to connect to,
and it drops your packets, you won't complain right? So why are you so
bothered about a DNS server that drops queries it's not supposed to be
receiving? The DNS resolution protocol is clear. A resolver is supposed
to follow a chain of referrals, and not query any random server on the
Internet. So a legitimate resolver has no business querying random
authoritative servers for zones they're not supposed to serve.

>> 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.

This is a short-sighted opinion. If just one authoritative server sends
out REFUSED responses towards an innocent, it won't matter. But if 1000
authoritative servers all send out REFUSED responses towards an innocent
IP address, their combined volume and packet rate *is* significant.

Regards,
Anand
___
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