Re: [dnsdist] pool selection without implicit accept
* Remi Gacogne [190712 16:08]: > That would make it possible to do something like that in a generic way: > > addAction({ 'rate1.com','a.aa' }, ContinueAction(PoolAction("static"))) > > I don't think it would be too complicated to implement and since it > would be self-contained we could even consider it for 1.4.0. > > Any thoughts? Sounds good to me. At a future time maybe all currently terminating actions could be reviewed and possibly be turned into SetXxxAction (ex SetPoolAction) which then would imply "Continue". Personally I like the iptables design where there are only very few terminating actions ("targets" in iptables lingo), and almost everything else implicitly continues. Writing this in a very vague way as I haven't even done a preliminary analysis what this would entail... -- Chris Hofstaedtler / Deduktiva GmbH (FN 418592 b, HG Wien) www.deduktiva.com / +43 1 353 1707 ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] pool selection without implicit accept
Am 12.07.2019 um 16:08 schrieb Remi Gacogne: > > > On 7/12/19 2:52 PM, Klaus Darilion wrote: >> 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. > > You are right, while Pieter's solution would work it increases the > complexity a bit. Since it's not the first time I would like to be able > to apply an existing action without stopping the processing, I'm > considering implementing a ContinueAction() action that would accept an > existing action as parameter, execute it and return None, regardless of > the value returned by the existing action. > > That would make it possible to do something like that in a generic way: > > addAction({ 'rate1.com','a.aa' }, ContinueAction(PoolAction("static"))) > > I don't think it would be too complicated to implement and since it > would be self-contained we could even consider it for 1.4.0. > > Any thoughts? Sounds like a useful hack. Although I think the otherway round would be better, ie: addAction({ 'rate1.com','a.aa' }, PoolAction("static") && AllowAction()) with default "continue" for PoolAction, but I guess for such changes it it a few years to late. Thanks Klaus ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] pool selection without implicit accept
On 7/12/19 2:52 PM, Klaus Darilion wrote: > 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. You are right, while Pieter's solution would work it increases the complexity a bit. Since it's not the first time I would like to be able to apply an existing action without stopping the processing, I'm considering implementing a ContinueAction() action that would accept an existing action as parameter, execute it and return None, regardless of the value returned by the existing action. That would make it possible to do something like that in a generic way: addAction({ 'rate1.com','a.aa' }, ContinueAction(PoolAction("static"))) I don't think it would be too complicated to implement and since it would be self-contained we could even consider it for 1.4.0. Any thoughts? Best regards, -- Remi Gacogne PowerDNS.COM BV - https://www.powerdns.com/ signature.asc Description: OpenPGP digital signature ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] pool selection without implicit accept
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({ 'a.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','a.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 > ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] pool selection without implicit accept
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 -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist