<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Anand,<div><br></div><div>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.</div><div><br></div><div>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.<br><br>I think dropping such answers would be very similar to: <a href="https://www.cvedetails.com/cve/CVE-2008-3337/">https://www.cvedetails.com/cve/CVE-2008-3337/</a> and <a href="https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2008-02.html">https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2008-02.html</a><br><br>Ondřej <br><div dir="ltr"><div>--</div>Ondřej Surý — ISC (He/Him)<div><br></div><div>My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.</div></div><div dir="ltr"><br><blockquote type="cite">On 14. 4. 2021, at 9:49, Anand Buddhdev <anandb@ripe.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On 14/04/2021 00:29, @lbutlr wrote:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>A legitimate client, following a normal chain of referrals, has *no*</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>reason to query a server for zones it is not authoritative for.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Well, that's not really true. A mobile user might have their device</span><br></blockquote><blockquote type="cite"><span>configured to always check their corporate DNS server first, for</span><br></blockquote><blockquote type="cite"><span>example, then fall back if that fails.</span><br></blockquote><span></span><br><span>I'm not talking of DNS *resolvers* here. I'm talking of authoritative</span><br><span>servers. If my authoritative server is authoritative for zones A, B and</span><br><span>C, then I should only get queries for those zones from legitimate</span><br><span>resolvers and clients. Queries for any other zones should *not* be</span><br><span>coming to my server. I shouldn't even be obliged to answer with REFUSED.</span><br><span>I should just be able to ignore those queries completely as junk.</span><br><span></span><br><blockquote type="cite"><span>Refusing makes everything faster, ignoring breaks things and makes things slower.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>When a DNS host refuses a query, it will not be queried again, wen</span><br></blockquote><blockquote type="cite"><span>it times out, is is still in the rotation.</span><br></blockquote><span></span><br><span>This is a misbelief. When a resolver fails to get an answer from an</span><br><span>authoritative server (whether explicitly with a REFUSED response, or</span><br><span>just a timeout), it may lower the preference for that name server, but</span><br><span>will eventually retry, in case that server is able to answer for that</span><br><span>zone again.</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>Most of the time, such a query would only arrive at a name server from a naughty</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>client.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Unlikely as there is no benefit to the "naughty" client. This is not</span><br></blockquote><blockquote type="cite"><span>a</span><br></blockquote><blockquote type="cite"><span>amplification attack, the refusal is a short packet, meaning the query</span><br></blockquote><blockquote type="cite"><span>from the client is probably larger than the response. Very inefficient</span><br></blockquote><blockquote type="cite"><span>for naughty clients.</span><br></blockquote><span></span><br><span>Amplification isn't necessary for causing a DDoS towards an innocent</span><br><span>client. Even a high-enough packet rate (with small packets), can</span><br><span>overwhelm the upstream router of the client, or use up a significant</span><br><span>portion of the bandwidth. It can also cause problems for the client</span><br><span>whose networking stack has to deal with the packets. Whether an unwanted</span><br><span>packet is of 100 bytes or 1000 bytes, the network stack has to deal with</span><br><span>it somehow.</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>And then, replying with any response, even REFUSED, is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>satisfying this client's naughtiness.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>How?</span><br></blockquote><span></span><br><span>A spoofer gets to generate responses, however, small, towards an</span><br><span>innocent client.</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>I think it's quite okay for an authoritative name server to simply DROP</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>UDP queries for zones</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It's not.</span><br></blockquote><span></span><br><span>If you try to SSH to a server that you're not supposed to connect to,</span><br><span>and it drops your packets, you won't complain right? So why are you so</span><br><span>bothered about a DNS server that drops queries it's not supposed to be</span><br><span>receiving? The DNS resolution protocol is clear. A resolver is supposed</span><br><span>to follow a chain of referrals, and not query any random server on the</span><br><span>Internet. So a legitimate resolver has no business querying random</span><br><span>authoritative servers for zones they're not supposed to serve.</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>that it's not authoritative for. It's better to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>ignore naughty clients, and give them the cold shoulder, and not</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>participate in reflection attacks using REFUSED responses.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>How do you imagine this is a reflection attack? It is far too small</span><br></blockquote><blockquote type="cite"><span>to be an effective attack for anything.</span><br></blockquote><span></span><br><span>This is a short-sighted opinion. If just one authoritative server sends</span><br><span>out REFUSED responses towards an innocent, it won't matter. But if 1000</span><br><span>authoritative servers all send out REFUSED responses towards an innocent</span><br><span>IP address, their combined volume and packet rate *is* significant.</span><br><span></span><br><span>Regards,</span><br><span>Anand</span><br><span>_______________________________________________</span><br><span>Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list</span><br><span></span><br><span>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.</span><br><span></span><br><span></span><br><span>bind-users mailing list</span><br><span>bind-users@lists.isc.org</span><br><span>https://lists.isc.org/mailman/listinfo/bind-users</span><br></div></blockquote></div></body></html>