[dnsdist] pool selection without implicit accept

[Klaus Darilion]

Hi Peter!

My current config is:

-- Send requests for zones without dynamic features to pool "static" (NSD)
-- For other zones forwarded to default pool (PDNS)
addAction({ 'aaaaa.aa' }, PoolAction("static"))


-- Rate limiting for domains
addAction(QNameRule("rate1.com"), AllowAction())
addAction(QNameRule("www.rate1.com"), AllowAction())
addAction(AndRule({makeRule("rate1.com"),NotRule(MaxQPSRule(10))}),
DropAction())

addAction(QNameRule("rate2.com"), AllowAction())
addAction(QNameRule("www.rate2.com"), AllowAction())
addAction(AndRule({makeRule("rate2.com"),NotRule(MaxQPSRule(10))}),
DropAction())




Now I need to add rate1.com to the "static" pool. I would like to have
my rate filtering logic independent of my pool logic and just use:
addAction({ 'rate1.com','aaaaa.aa' }, PoolAction("static"))

That does not work. At the moment, if I want to add another domain (ie
rate1.com) to the "static" pool I have to check first, if the domain is
rate limited or not, and if yes, use a andAction construct to achieve my
goal. So, yes it would be possible, the complex to manage.

regards
Klaus

PS: This is not a high priority thing, but I think it might be useful
also for other functions to not imply a final action but continue with
the rules




Am 12.07.2019 um 12:58 schrieb Pieter Lexis:
> Hi Klaus,
> 
> On 7/12/19 10:34 AM, Klaus Darilion wrote:
>> I have a ruleset with severals whitelist (AllowAction) and ratelimit
>> (MaxQPSRule+DropAction).
>>
>> Now, independent of these rules I would like to use different backend
>> pools. But now I have a problem as PoolAction() immediately forwards the
>> request and my blacklist/whitelist rules are not handled anymore.
>>
>> Moving the pool selection after the black/whitelist also does not work
>> as the whiteliste sends immediately to the default pool.
>>
>> Hence, I suggest a PoolAction() without implicit AllowAction, for
>> example PoolActionSetOnly() or PoolActionContinue() to set the pool for
>> a request but continue in the rules processing.
> 
> Perhaps the AndRule[1] operator could help here?
> 
> ```
> rule1 = MaxQPSRule(...)
> rule2 = SomeOtherRule()
> 
> addAction(AndRule{rule1, rule2}, PoolAction(...))
> ```
> 
> We use this in our own setups:
> 
> ```
> allowed_axfr_addresses_rule = makeRule({'192.0.2.1', '2001:DB8::1'})
> -- Deny AXFR from anything but the allowed addresses
> addAction(
>   AndRule({
>     OrRule({
>       QTypeRule(DNSQType.AXFR),
>       QTypeRule(DNSQType.IXFR),
>     }),
>     NotRule(allowed_axfr_addresses_rule)
>   }),
>   RCodeAction(DNSRCode.REFUSED)
> )
> 
> ```
> 
> This way, with the rules correctly ordered, you should be able to
> achieve your goal. If you could provide the mailinglist with your
> current config and a description of what exactly you're trying to do, we
> could be able to judge if what you're asking for is indeed a new feature
> that could be implemented.
> 
> Cheers,
> 
> Pieter
> 
> 1 - https://dnsdist.org/rules-actions.html#AndRule
>