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 <anandb at ripe.net> 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.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210414/415a50f6/attachment.htm>