On 24. 02. 25 12:58, Meir Kraushar wrote:
On Mon, Feb 24, 2025 at 11:32 AM Petr Špaček <pspa...@isc.org <mailto:pspa...@isc.org>> wrote:

    On 23. 02. 25 13:25, Meir Kraushar via dns-operations wrote:
     > Hi
     > The .sl ccTLD (Sierra Leone) is being used as an amplifier for
     > reflection attacks.
     > It looks like the domain is horribly misconfigured:
     >
     > 1) It has 4 keys:
     >      - Two KSK's each one *4096* in size
     >      - Two ZSK each 2048
     > 2) *ALL* keys are used to sign DNSKEY records, resulting in 4
    DNSKEY RRSIG
     > 3) All other records are signed twice
     > 4) All algos are 7
     > 5) There is no DS in the root, this TLD is not DNSSEC validated
     >
     > As a result,
     > The reply size of "dig sl any" is 5814 (!)
     > Again, this is being used as an amplifier for reflection attacks
     > (victims referred to us for help).
     > If anyone knows someone there who can fix this?

    I agree sl TLD has _very_ unusual configuration, but their servers
    don't
    send ANY responses over UDP, so it should not be a problem by itself. I
    would think the problem is someone else's servers which are willing to
    send oversized UDP answers, ignoring not only
    https://www.dnsflagday.net/2020/ <https://www.dnsflagday.net/2020/>
    but also the very old 4096 byte
    'default' buffer size for EDNS0.

-- Petr Špaček
    Internet Systems Consortium


Hi Petr, I suspect the same. If so, it seems like there is nothing to do? (combined with the fact that they do not respond)

Hmm no, that's not what I wanted to say. What I meant:

I would try to contact source of the _packets_, not sl TLD. Presumably the source IP points to an IP address of a resolver which has a very exotic EDNS buffer size configuration and and no response rate limits.

Lowering EDNS buffer size is sensible, and RRL for a public resolver is a must nowadays. Or perhaps the resolver responds to queries from the public Internet by accident ...

--
Petr Špaček
Internet Systems Consortium

_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Reply via email to