[dns-operations] Sierra Leone (.sl) TLD

[Petr Špaček]

On 24. 02. 25 12:58, Meir Kraushar wrote:
> On Mon, Feb 24, 2025 at 11:32 AM Petr Špaček <pspacek at isc.org 
> <mailto:pspacek at 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