Stopping name server abuse

[Alex]

Hi,
We had a former customer who parked about 300 domains with his
registry on our server but is no longer a customer and hasn't moved
his domains. There aren't any hosts behind the domains.

Is there anything more I can do to block/prevent them from continually
querying my system outside of just redirecting them to localhost or
something?

It's not a terrible amount of traffic, but it's pretty substantial.

Unfortunately asking him nicely didn't work.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Warren Kumari]

Unfortunately I don’t think that there is, other than the nuclear option of
becoming authoritative and pointing them elsewhere.

That would be a jackass move though.

W

On Sun, Jun 24, 2018 at 3:30 PM Alex <***@gmail.com> wrote:

> Hi,
> We had a former customer who parked about 300 domains with his
> registry on our server but is no longer a customer and hasn't moved
> his domains. There aren't any hosts behind the domains.
>
> Is there anything more I can do to block/prevent them from continually
> querying my system outside of just redirecting them to localhost or
> something?
>
> It's not a terrible amount of traffic, but it's pretty substantial.
>
> Unfortunately asking him nicely didn't work.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf

[j***@hasig.de]

hi,
why dont you just delete the zones?
j.

Am 24.06.2018 um 22:35 schrieb Warren Kumari:
> Unfortunately I don’t think that there is, other than the nuclear option of
> becoming authoritative and pointing them elsewhere.
>
> That would be a jackass move though.
>
> W
>
> On Sun, Jun 24, 2018 at 3:30 PM Alex <***@gmail.com> wrote:
>
>> Hi,
>> We had a former customer who parked about 300 domains with his
>> registry on our server but is no longer a customer and hasn't moved
>> his domains. There aren't any hosts behind the domains.
>>
>> Is there anything more I can do to block/prevent them from continually
>> querying my system outside of just redirecting them to localhost or
>> something?
>>
>> It's not a terrible amount of traffic, but it's pretty substantial.
>>
>> Unfortunately asking him nicely didn't work.
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-***@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-***@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-***@lists.isc.org
https://lists.isc.org/mailman/listinf

[Barry Margolin]

In article <mailman.70.1529876093.803.bind-***@lists.isc.org>,
***@hasig.de wrote:

> hi,
> why dont you just delete the zones?

That won't stop the queries from coming to the server.

--
Barry Margolin
Arlington, MA
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[j***@hasig.de]

yes, but it minimizes the use of resources because the only answer is nxdomain.
j.

Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> In article <mailman.70.1529876093.803.bind-***@lists.isc.org>,
> ***@hasig.de wrote:
>
>> hi,
>> why dont you just delete the zones?
>
> That won't stop the queries from coming to the server.
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Paul Kosinski]

Is it possible to get BIND not to respond at all, thereby causing
a timeout on the query? That would perhaps reduce load more than
NXDOMAIN or deleting the sone(s) would.


On Mon, 25 Jun 2018 00:03:09 +0200
***@hasig.de wrote:

> yes, but it minimizes the use of resources because the only answer is
> nxdomain. j.
>
> Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> > In article <mailman.70.1529876093.803.bind-***@lists.isc.org>,
> > ***@hasig.de wrote:
> >
> >> hi,
> >> why dont you just delete the zones?
> >
> > That won't stop the queries from coming to the server.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Browne, Stuart via bind-users]

If the incoming query has already been parsed and it BIND instance now knows it doesn't need to respond, it's already done all the work, so there's no point not sending the response. To introduce something before the BIND instance in userspace, then for every legitimate query you are double-processing; more wasted resources.

In either case, by 'not responding', you're tying up even more resources (open sockets or other connection tracking mechanisms if you haven't disabled them) until the connections all time out.

If you're filtering on an upstream device that can do that level of analysis without hurting your network, then maybe, but once again, you're double-processing every legitimate query; you're only moving the cost to a different device.

It's best to respond nicely and move on.

Unless the DNS server is massively under-resourced or the query load is in the many-thousands-per-second range, there shouldn't be that much of an issue with the server coping with the load; but from what I can tell on this thread, it's more about "The customer is no longer paying so I want to stop spending money or resources for them".

Stuart

> -----Original Message-----
> From: bind-users [mailto:bind-users-***@lists.isc.org] On Behalf Of
> Paul Kosinski
> Sent: Monday, 25 June 2018 1:40 PM
> To: bind-***@lists.isc.org
> Subject: Re: Stopping name server abuse
>
> Is it possible to get BIND not to respond at all, thereby causing
> a timeout on the query? That would perhaps reduce load more than
> NXDOMAIN or deleting the sone(s) would.
>
>
> On Mon, 25 Jun 2018 00:03:09 +0200
> ***@hasig.de wrote:
>
> > yes, but it minimizes the use of resources because the only answer is
> > nxdomain. j.
> >
> > Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> > > In article <mailman.70.1529876093.803.bind-***@lists.isc.org>,
> > > ***@hasig.de wrote:
> > >
> > >> hi,
> > >> why dont you just delete the zones?
> > >
> > > That won't stop the queries from coming to the server.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Barry Margolin]

In article <mailman.79.1529899821.803.bind-***@lists.isc.org>,
"Browne, Stuart" <***@team.neustar> wrote:

> If you're filtering on an upstream device that can do that level of analysis
> without hurting your network, then maybe, but once again, you're
> double-processing every legitimate query; you're only moving the cost to a
> different device.

An upstream firewall might already be parsing it, so telling it not to
pass some of them through could be relatively cheap.

--
Barry Margolin
Arlington, MA
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Paul Kosinski]

How does *not* responding to a UDP query take longer for the *server*
than responding to UDP a query? Both responding and (deliberately) not
responding require identifying the query, but not responding bypasses
the time the server would need to construct the response, plus time
spent in the network stack. (I'm assuming we don't care about client
side "expense".)

Of course, if not responding to a UDP query provokes a TCP query, that
might increase the total server time needed, since TCP is inherently
more expensive for short transactions like DNS.

P.S. If you have something like iptables (with its string matching) in
front of your DNS server, you could just drop UDP queries for bogus
domains rather than letting them in at all. Or you could even route
them to a special lightweight server that just yields canned responses.
(This wouldn't work for TCP, because the query doesn't come until after
the connection is established.)



On Mon, 25 Jun 2018 15:32:44 +0200
Reindl Harald <***@thelounge.net> wrote:

>
>
> Am 25.06.2018 um 05:39 schrieb Paul Kosinski:
> > Is it possible to get BIND not to respond at all, thereby causing
> > a timeout on the query? That would perhaps reduce load more than
> > NXDOMAIN or deleting the sone(s) would.
>
> timeouts are expensive for both sides by definition
>
> > On Mon, 25 Jun 2018 00:03:09 +0200
> > ***@hasig.de wrote:
> >
> >> yes, but it minimizes the use of resources because the only answer
> >> is nxdomain. j.
> >>
> >> Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> >>> In article <mailman.70.1529876093.803.bind-***@lists.isc.org>,
> >>> ***@hasig.de wrote:
> >>>
> >>>> hi,
> >>>> why dont you just delete the zones?
> >>>
> >>> That won't stop the queries from coming to the server
>
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Matus UHLAR - fantomas]

>> Am 25.06.2018 um 05:39 schrieb Paul Kosinski:
>> > Is it possible to get BIND not to respond at all, thereby causing
>> > a timeout on the query? That would perhaps reduce load more than
>> > NXDOMAIN or deleting the sone(s) would.

>On Mon, 25 Jun 2018 15:32:44 +0200
>Reindl Harald <***@thelounge.net> wrote:
>> timeouts are expensive for both sides by definition

On 25.06.18 11:04, Paul Kosinski wrote:
>How does *not* responding to a UDP query take longer for the *server*
>than responding to UDP a query? Both responding and (deliberately) not
>responding require identifying the query, but not responding bypasses
>the time the server would need to construct the response, plus time
>spent in the network stack. (I'm assuming we don't care about client
>side "expense".)

not responding server will usually receive more queries.

--
Matus UHLAR - fantomas, ***@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.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson. -- Daffy Duck & Porky Pig
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Barry Margolin]

In article <mailman.82.1529939079.803.bind-***@lists.isc.org>,
Paul Kosinski <***@iment.com> wrote:

> How does *not* responding to a UDP query take longer for the *server*
> than responding to UDP a query? Both responding and (deliberately) not
> responding require identifying the query, but not responding bypasses
> the time the server would need to construct the response, plus time
> spent in the network stack. (I'm assuming we don't care about client
> side "expense".)

If there's no response, the client retries several times. It will try
all the servers that the zone is delegated to, so you'll put more load
on multiple servers.

NXDOMAIN responses are cached, it's one hit and then nothing for a while.

--
Barry Margolin
Arlington, MA
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Paul Kosinski]

Somebody who has irresponsibly (and apparently wantonly, given his
refusal to fix it) delegated his domain(s) to your DNS server is
essentially causing a (modest bandwidth) distributed denial of service
attack on your server. I don't think that the "responsible" thing to do
is to sit there and suffer from a significantly increased load.

What should be done is to get the domain(s) revoked if the owner
continues to refuse to remedy the problem: it is *he*, not you, who is
being irresponsible. And if the queries are coming via an innocent
ISP's resolver, then they are inadvertently assisting in the attack,
and should be contacted and asked to help in the remediation. (Note
that *their* resources, as well as yours, are being wasted.)


On Mon, 25 Jun 2018 17:47:23 +0200
Reindl Harald <***@thelounge.net> wrote:

> Am 25.06.2018 um 17:37 schrieb Barry Margolin:
> > In article <mailman.82.1529939079.803.bind-***@lists.isc.org>,
> > Paul Kosinski <***@iment.com> wrote:
> >
> >> How does *not* responding to a UDP query take longer for the
> >> *server* than responding to UDP a query? Both responding and
> >> (deliberately) not responding require identifying the query, but
> >> not responding bypasses the time the server would need to
> >> construct the response, plus time spent in the network stack. (I'm
> >> assuming we don't care about client side "expense".)
> >
> > If there's no response, the client retries several times. It will
> > try all the servers that the zone is delegated to, so you'll put
> > more load on multiple servers.
> >
> > NXDOMAIN responses are cached, it's one hit and then nothing for a
> > while
>
> and additionally "I'm assuming we don't care about client side
> "expense" is nonsense because the client in question is typically a
> *innocent* ISP resolver or something like 8.8.8.8 and the attitude "i
> don't care about them" is irresponsible because as sysadmin you are
> expected to think what your actions mean for the whole ecosystem
>
>
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Barry Margolin]

In article <mailman.87.1529956879.803.bind-***@lists.isc.org>,
Paul Kosinski <***@iment.com> wrote:

> Somebody who has irresponsibly (and apparently wantonly, given his
> refusal to fix it) delegated his domain(s) to your DNS server is
> essentially causing a (modest bandwidth) distributed denial of service
> attack on your server. I don't think that the "responsible" thing to do
> is to sit there and suffer from a significantly increased load.

Good luck getting him prosecuted under any kind of computer abuse law.
That would be like calling the cops on a sibling who is poking you,
claiming that it's assault.

> What should be done is to get the domain(s) revoked if the owner
> continues to refuse to remedy the problem: it is *he*, not you, who is
> being irresponsible. And if the queries are coming via an innocent
> ISP's resolver, then they are inadvertently assisting in the attack,
> and should be contacted and asked to help in the remediation. (Note
> that *their* resources, as well as yours, are being wasted.)

I doubt any ISPs will do anything about it. It's probably negligible
relative to their total DNS volume, and would be more trouble than it's
worth to add filters to block it.

The domain registrar is the place to go, I expect most of them have
standard procedures for exactly this problem.

--
Barry Margolin
Arlington, MA
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Darcy Kevin (FCA)]

IANAL, but even if one considers this scenario to constitute a DDoS attack, and there is plenty of case law supporting prosecution under CFAA (Computer Fraud and Abuse Act) for DDoS attacks, CFAA generally requires *intent*, and this appears to be simple negligence.

"Trespass to chattel" might be another possibility, but only as a civil (not criminal) complaint. And one would have to prove damages, which might be difficult to assess, or simply _de_minimis_.

- Kevin

-----Original Message-----
From: bind-users <bind-users-***@lists.isc.org> On Behalf Of Barry Margolin
Sent: Tuesday, June 26, 2018 10:42 AM
To: comp-protocols-dns-***@isc.org
Subject: Re: Stopping name server abuse

In article <mailman.87.1529956879.803.bind-***@lists.isc.org>,
Paul Kosinski <***@iment.com> wrote:

> Somebody who has irresponsibly (and apparently wantonly, given his
> refusal to fix it) delegated his domain(s) to your DNS server is
> essentially causing a (modest bandwidth) distributed denial of service
> attack on your server. I don't think that the "responsible" thing to
> do is to sit there and suffer from a significantly increased load.

Good luck getting him prosecuted under any kind of computer abuse law.
That would be like calling the cops on a sibling who is poking you, claiming that it's assault.

> What should be done is to get the domain(s) revoked if the owner
> continues to refuse to remedy the problem: it is *he*, not you, who is
> being irresponsible. And if the queries are coming via an innocent
> ISP's resolver, then they are inadvertently assisting in the attack,
> and should be contacted and asked to help in the remediation. (Note
> that *their* resources, as well as yours, are being wasted.)

I doubt any ISPs will do anything about it. It's probably negligible relative to their total DNS volume, and would be more trouble than it's worth to add filters to block it.

The domain registrar is the place to go, I expect most of them have standard procedures for exactly this problem.

--
Barry Margolin
Arlington, MA
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Paul Kosinski]

Most of your replies seem not to address the (immediately
preceding) paragraph they appear to be responding to.


On Mon, 25 Jun 2018 22:15:07 +0200
Reindl Harald <***@thelounge.net> wrote:

>
>
> Am 25.06.2018 um 22:01 schrieb Paul Kosinski:
> > Somebody who has irresponsibly (and apparently wantonly, given his
> > refusal to fix it) delegated his domain(s) to your DNS server is
> > essentially causing a (modest bandwidth) distributed denial of
> > service attack on your server. I don't think that the "responsible"
> > thing to do is to sit there and suffer from a significantly
> > increased load.
>
> no, but you proposed timeout don't change that anyways
> it makes things only worser
>
> if you have noticeable increased load in real life becuase of some
> domains you no longer want to host on a nameserver you are lost
> anyways and calling that a distributed denial of service is a joke
>
> > What should be done is to get the domain(s) revoked if the owner
> > continues to refuse to remedy the problem: it is *he*, not you, who
> > is being irresponsible.
>
> if you make things worser for everyone without any gain *you are*
> irresponsible because you don't understand the outcome of your actions
> like funny timeouts
>
> > And if the queries are coming via an innocent
> > ISP's resolver, then they are inadvertently assisting in the attack,
> > and should be contacted and asked to help in the remediation. (Note
> > that *their* resources, as well as yours, are being wasted.)
>
> you will contact every ISP and resolver admin out there?
> seriously?
> and ask them to do what exactly?
>
> if you call me and tell me your story about domains pointing to your
> nameserver and why we as ISP don#t stop asking the response you
> deserve is not allowed legally
>
> the question was how to reduce the load and your answers where how to
> increase load and make things worser for everybody and things much
> complexer - the only correct way to get this *finally* resolved is
> force the registry of the domain to remove your nameservers and
> that's it instead of calling innocent parties or playing technical
> games with no gain
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Tony Finch]

***@hasig.de <***@hasig.de> wrote:
> Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> > ***@hasig.de wrote:
> > >
> > > why dont you just delete the zones?
> >
> > That won't stop the queries from coming to the server.
>
> yes, but it minimizes the use of resources because the only answer is
> nxdomain.

If you delete the zones, the nameserver will return REFUSED not NXDOMAIN,
and the resolver that is making the query will retry.

We used to refuse external queries for private.cam.ac.uk, but for reasons
related to X.509 CAA checks we now use views to return NXDOMAIN instead.
This change unexpectedly reduced the query load on our authoritative
servers by half. (Obvious in retrospect, but...)

I suggest empty place-holder zones with long TTLs, possibly with a www
entry pointing to a page saying the account has been closed.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
oppose all forms of entrenched privilege and inequality
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[John W. Blue]

I disagree. Put up classy default page that is smart but funny while pointing out that owners of the domains are morons.

So many options here!

John

Sent from Nine<http://www.9folders.com/>
________________________________
From: Warren Kumari <***@kumari.net>
Sent: Jun 24, 2018 3:36 PM
To: Alex
Cc: bind-***@lists.isc.org
Subject: Re: Stopping name server abuse

Unfortunately I don't think that there is, other than the nuclear option of becoming authoritative and pointing them elsewhere.

That would be a jackass move though.

W

On Sun, Jun 24, 2018 at 3:30 PM Alex <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi,
We had a former customer who parked about 300 domains with his
registry on our server but is no longer a customer and hasn't moved
his domains. There aren't any hosts behind the domains.

Is there anything more I can do to block/prevent them from continually
querying my system outside of just redirecting them to localhost or
something?

It's not a terrible amount of traffic, but it's pretty substantial.

Unfortunately asking him nicely didn't work.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org<mailto:bind-***@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
---maf

[Mukund Sivaraman]

On Sun, Jun 24, 2018 at 04:30:08PM -0400, Alex wrote:
> Hi,
> We had a former customer who parked about 300 domains with his
> registry on our server but is no longer a customer and hasn't moved
> his domains. There aren't any hosts behind the domains.
>
> Is there anything more I can do to block/prevent them from continually
> querying my system outside of just redirecting them to localhost or
> something?
>
> It's not a terrible amount of traffic, but it's pretty substantial.
>
> Unfortunately asking him nicely didn't work.

Serve the customer an invoice. They're his domains after all, and he's
using up your resources. You can identify him and show that your
resources are being used because he has not moved the delegations.

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

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

[Dave Warren]

On Sun, Jun 24, 2018, at 15:48, Mukund Sivaraman wrote:
> On Sun, Jun 24, 2018 at 04:30:08PM -0400, Alex wrote:
> > Hi,
> > We had a former customer who parked about 300 domains with his
> > registry on our server but is no longer a customer and hasn't moved
> > his domains. There aren't any hosts behind the domains.
> >
> > Is there anything more I can do to block/prevent them from continually
> > querying my system outside of just redirecting them to localhost or
> > something?
> >
> > It's not a terrible amount of traffic, but it's pretty substantial.
> >
> > Unfortunately asking him nicely didn't work.
>
> Serve the customer an invoice. They're his domains after all, and he's
> using up your resources. You can identify him and show that your
> resources are being used because he has not moved the delegations.

Absent a situation where the customer has agreed to purchase this service, the only result sending an invoice would have is that you have increased your loss by adding wasted time, toner, paper, an envelope and the cost of postage.

You might flag the customer's attention, but since "Unfortunately asking him nicely didn't work." it seems unlikely that repeatedly annoying the individual repeatedly will be productive.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Matus UHLAR - fantomas]

>> On Sun, Jun 24, 2018 at 04:30:08PM -0400, Alex wrote:
>> > We had a former customer who parked about 300 domains with his
>> > registry on our server but is no longer a customer and hasn't moved
>> > his domains. There aren't any hosts behind the domains.
>> >
>> > Is there anything more I can do to block/prevent them from continually
>> > querying my system outside of just redirecting them to localhost or
>> > something?
>> >
>> > It's not a terrible amount of traffic, but it's pretty substantial.
>> >
>> > Unfortunately asking him nicely didn't work.

>On Sun, Jun 24, 2018, at 15:48, Mukund Sivaraman wrote:
>> Serve the customer an invoice. They're his domains after all, and he's
>> using up your resources. You can identify him and show that your
>> resources are being used because he has not moved the delegations.

On 25.06.18 09:06, Dave Warren wrote:
>Absent a situation where the customer has agreed to purchase this service,
> the only result sending an invoice would have is that you have increased
> your loss by adding wasted time, toner, paper, an envelope and the cost of
> postage.
>
>You might flag the customer's attention, but since "Unfortunately asking
> him nicely didn't work." it seems unlikely that repeatedly annoying the
> individual repeatedly will be productive.

I believe this can eb the same situation as putting images owned by getty to
your website. They will send you invoice with higher price than if you had a
contract...

--
Matus UHLAR - fantomas, ***@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.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Dave Warren]

On Tue, Jun 26, 2018, at 01:28, Matus UHLAR - fantomas wrote:
> On 25.06.18 09:06, Dave Warren wrote:
> >Absent a situation where the customer has agreed to purchase this service,
> > the only result sending an invoice would have is that you have increased
> > your loss by adding wasted time, toner, paper, an envelope and the cost of
> > postage.
> >
> >You might flag the customer's attention, but since "Unfortunately asking
> > him nicely didn't work." it seems unlikely that repeatedly annoying the
> > individual repeatedly will be productive.
>
> I believe this can eb the same situation as putting images owned by getty to
> your website. They will send you invoice with higher price than if you had a
> contract...

Assuming the user ignores the invoice (from you or Getty), your remedy would be the same as Getty: Take the user to court.

But Getty has copyright law behind them and therefore has a relatively easy win with well understood penalties. A DNS server operator could try small claims could, but would probably need to show actual damages to get a judgement.

Getty also has lawyers on payroll who do this stuff all day, every day, and therefore have minimal overhead due to the copy/paste nature of their filings. A random DNS server operator likely does not have a lawyer who can copy/paste this type of claim, the cost of research and filing would probably exceed the (mostly non-existent) cost of just ignoring the unwanted traffic. My money says that win or lose, you've already lost by using the legal system even assuming you manage to collect on a judgement.

At the end of the day, I doubt there is much you can do legally, the only real solutions are technical by returning answers that will discourage resolvers from asking as frequently (probably meaning responses carrying a high TTL).

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

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

[Dave Warren]

On Tue, Jun 26, 2018, at 11:27, Reindl Harald wrote:
>
>
> Am 26.06.2018 um 20:18 schrieb Dave Warren:
> > At the end of the day, I doubt there is much you can do legally, the only real solutions are technical by returning answers that will discourage resolvers from asking as frequently (probably meaning responses carrying a high TTL)
>
> nonsense - the onbly real solution is non-tchnical by get the registry
> to remove your nameservers - it's that easy

Have you had success in accomplishing such? I've tried in the past and universally been ignored or had the request rejected by registrars and registries.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Dave Warren]

On Tue, Jun 26, 2018, at 11:47, Reindl Harald wrote:
>
> Am 26.06.2018 um 20:36 schrieb Dave Warren:
> > On Tue, Jun 26, 2018, at 11:27, Reindl Harald wrote:
> >>
> >>
> >> Am 26.06.2018 um 20:18 schrieb Dave Warren:
> >>> At the end of the day, I doubt there is much you can do legally, the only real solutions are technical by returning answers that will discourage resolvers from asking as frequently (probably meaning responses carrying a high TTL)
> >>
> >> nonsense - the onbly real solution is non-tchnical by get the registry
> >> to remove your nameservers - it's that easy
> >
> > Have you had success in accomplishing such? I've tried in the past and universally been ignored or had the request rejected by registrars and registries
>
> yes
>
> if i can prove that i am the zone-owner of the nameservers and that i
> don't have any contract with the domain owner where should be the problem?
>
> just use the abuse-contacts instead support monkeys

Where have you had success? With a registrar (which one?) or a registry (which one?)?

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

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

[Dave Warren]

On Tue, Jun 26, 2018, at 11:54, Reindl Harald wrote:
>
>
> Am 26.06.2018 um 20:50 schrieb Dave Warren:
> > On Tue, Jun 26, 2018, at 11:47, Reindl Harald wrote:
> >>
> >> Am 26.06.2018 um 20:36 schrieb Dave Warren:
> >>> On Tue, Jun 26, 2018, at 11:27, Reindl Harald wrote:
> >>>>
> >>>>
> >>>> Am 26.06.2018 um 20:18 schrieb Dave Warren:
> >>>>> At the end of the day, I doubt there is much you can do legally, the only real solutions are technical by returning answers that will discourage resolvers from asking as frequently (probably meaning responses carrying a high TTL)
> >>>>
> >>>> nonsense - the onbly real solution is non-tchnical by get the registry
> >>>> to remove your nameservers - it's that easy
> >>>
> >>> Have you had success in accomplishing such? I've tried in the past and universally been ignored or had the request rejected by registrars and registries
> >>
> >> yes
> >>
> >> if i can prove that i am the zone-owner of the nameservers and that i
> >> don't have any contract with the domain owner where should be the problem?
> >>
> >> just use the abuse-contacts instead support monkeys
> >
> > Where have you had success? With a registrar (which one?) or a registry (which one?)?
>
> where did you *not* have success?

The last time I tried was some years ago, at Network Solutions, with a .COM. The owner of the domain was a company that had ceased operations and contact information was at the domain itself (therefore they were unreachable by email).

The load wasn't enormous but I was curious if they would be responsive, the only answers I received were to contact the owner of the domain, silence, or a ticket-closed type response.

Mark Jeftovic from easyDNS has commented on similar situations back in 2015: "It's not that rare. It's happened to us (more than once) and it happened to DNSimple not too long ago. In those cases we've had problems getting the registrar to yank the delegation. In cases like that the registry often won't even talk to us."

Maybe the situations has improved over the last few years?
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[Hika van den Hoven]

Hi All,

I doubt any legal action would have any chance, of cause depending on
the country's law your using. The server is publicly accessible.
It's like prosecuting somebody for knocking on your public front door
to ask the way. (or for that matter salespeople) You only might have a
chance to put it on harassment if he is doing it all the time.

Hika

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

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

[Mark Andrews]

You should just be able to ask the registries to remove the delegations
in a sane world as per RFC 1033.

COMPLAINTS

These are the suggested steps you should take if you are having
problems that you believe are caused by someone else's name server:


1. Complain privately to the responsible person for the domain. You
can find their mailing address in the SOA record for the domain.

2. Complain publicly to the responsible person for the domain.

3. Ask the NIC for the administrative person responsible for the
domain. Complain. You can also find domain contacts on the NIC in
the file NETINFO:DOMAIN-CONTACTS.TXT

4. Complain to the parent domain authorities.

5. Ask the parent authorities to excommunicate the domain.

If that doesn’t work go to the local magistrate an seek a court order for the
delegating records that point to you to be removed. Then serve the court order
on the registries.

You are NOT required to follow whatever dispute resolution process that
has been worked out between the Registries, Registrars and Registrant as
you are NOT party to that contract.

Your lawyer should be able to workout exactly how to to this.

> On 25 Jun 2018, at 6:30 am, Alex <***@gmail.com> wrote:
>
> Hi,
> We had a former customer who parked about 300 domains with his
> registry on our server but is no longer a customer and hasn't moved
> his domains. There aren't any hosts behind the domains.
>
> Is there anything more I can do to block/prevent them from continually
> querying my system outside of just redirecting them to localhost or
> something?
>
> It's not a terrible amount of traffic, but it's pretty substantial.
>
> Unfortunately asking him nicely didn't work.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone] INTERNET: ***@isc.org

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

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.o

[m***@isc.org]

Sorry for the noise
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

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

[A]

You could ask the registrar/root domain admins to point those domains
somewhere other than your server; or just delete them from the root
servers at their perogative.  You might want to give your ex-customer a
final warning beforehand as to your intent.  It might spur them into
actionand maybe help deter any potential legal action after the fact. 
I'm not a lawyer.  This is not legal advice.

- A

On 06/24/2018 01:30 PM, Alex wrote:
> Hi,
> We had a former customer who parked about 300 domains with his
> registry on our server but is no longer a customer and hasn't moved
> his domains. There aren't any hosts behind the domains.
>
> Is there anything more I can do to block/prevent them from continually
> querying my system outside of just redirecting them to localhost or
> something?
>
> It's not a terrible amount of traffic, but it's pretty substantial.
>
> Unfortunately asking him nicely didn't work.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

[Noel Butler]

On 25/06/2018 10:09, ***@isc.org wrote:

> Sorry for the noise

What noise?

Your post is to the point and appropriate, lots of members of this list
may be in this situation and ignore it because they have NFI on what to
do, so you've helped them.

Though personally I have done a few times what John Blue suggested,
might not stop my resources being abused, but it gets the point across
:)

--
Kind Regards,

Noel Butler

This Email, including any attachments, may contain legally privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents



Links:
------
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument