[dns-operations] bind-9.9.3rc2 ANY+TCP patch

Matthäus Wander matthaeus.wander at uni-due.de
Wed May 15 21:09:18 UTC 2013


* Vernon Schryver [2013-05-15 21:40]:
>> From: Jared Mauch <jared at puck.nether.net>
>> This is a crude but effective hack.  It doesn't stop the system from recursing to find the response.
> 
> 
> I can understand simplistic DNS reflection mitigation in firewalls,
> especially when response rate limiting is not available in the DNS
> server implementation or when local policies forbid the use of patches.
> I don't understand why would one use a patch like that with its
> limitations and drawbacks (e.g. usable only on recent versions of
> BIND9, affects only ANY, affects all ANY, doesn't limit the flood of
> reflected truncated responses during attacks, no whitelisting for local
> clients, not view-specific) instead of the full blown RRL patch for
> 9.9.3rc2, 9.9.2, 9.9.2-P1, 9.9.2-P2, 9.8.4-P2, 9.8.4-P1, or 9.8.5rc2.
> 
> 
> By the way, why use "qtype == 255" instead of "qtype == dns_rdatatype_any" ? 
> 
> Why #define TCP_CLIENT() and use the macro exactly once instead
> something like
>     if (qtype == dns_rdatatype_any &&
>         (client->attributes & NS_CLIENTATTR_TCP) != 0) {
> If TCP_CLIENT() is used in query.c, then its definition should be moved
> from client.c to bin/named/include/named/client.h and the several uses
> of "client->attributes & NS_CLIENTATTR_TCP" in query.c replaced with
> TCP_CLIENT().   It's bad form to define macros (or much of anything)
> more than once, because you can be sure that eventually the definitions
> will differ.

I think the keyword here is "hack". I wouldn't invest too much time in
an analysis.

Regards,
Matt

-- 
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5156 bytes
Desc: S/MIME Kryptografische Unterschrift
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130515/7d398e40/attachment.bin>


More information about the dns-operations mailing list