Re: [dnsdist] How get ECS in DnsDist logs ?
david n via dnsdist writes: > I’m trying to log the client subnet with DnsDist, actually I only have the IP > of the DNS > server requesting : > > [1727699139.669387387] Packet from 192.29.141.4:38506 for foo.bar. A with id > 51444 > > cat /etc/systemd/system/pdns.service.d/02_service_extra_options.conf It seems that you only included configuration for pdns/PowerDNS, and not for dnsdist which is a separate service developed by the same team that develops PowerDNS. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Enabling cache for certain sources?
Fredrik Pettai via dnsdist writes:
>> addAction(NetmaskGroupRule(no_cache_ips, true), SetSkipCacheAction())
>
> Slightly OT, I wonder if it would be possible to reverse the suggested
> solution,
> to cache only queries from specific IPs and skip the caching "for the rest” ?
You can just do something like this:
cache_ips = newNMG()
-- IPs of clients that should use the cache
cache_ips:addMask('192.0.2.1/32')
cache_ips:addMask('192.0.2.8/32')
addAction(NotRule(NetmaskGroupRule(cache_ips, true)), SetSkipCacheAction())
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Disable cache for certain sources
Andreas Wili via dnsdist writes:
> Now, there are two servers on the network for which all DNS queries must
> not be cached.
Ahh, then you just do:
no_cache_ips = newNMG()
-- IPs of servers that shouldn't use the cache
no_cache_ips:addMask('192.0.2.1/32')
no_cache_ips:addMask('192.0.2.8/32')
addAction(NetmaskGroupRule(no_cache_ips, true), SetSkipCacheAction())
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Disable cache for certain sources
Hi
Andreas Wili via dnsdist writes:
> I have dnsdist deployed centrally to route DNS queries to various backends:
> [...]
> In this setup, I use caching as follows:
> cache_all_queries = newPacketCache(200, {maxTTL=86400, minTTL=0,
> temporaryFailureTTL=60, staleTTL=60})
> getPool(""):setCache(cache_all_queries)
>
> I would now need to disable caching for certain servers that issue a DNS
> query. Is there a
> rule for this or any other option?
Do you mean that you do not want to cache responses from e.g.
"backend2"? Then you can try something like:
-- Configure backends in separate pools
newServer({
address='192.168.100.10',
name='backend1',
pool='use_cache_pool'
})
newServer({
address='192.168.100.20',
name='backend2',
pool='no_cache_pool'
})
-- Create cache
cache_all_queries = newPacketCache(200,
{maxTTL=86400,
minTTL=0,
temporaryFailureTTL=60,
staleTTL=60})
-- Set cache for the "use_cache_pool"
getPool('use_cache_pool'):setCache(cache_all_queries)
-- route requests to your two pools, this will route ~50% to the pool
-- using cache and the remaining queries to your no_cache_pool.
-- You probably want something else, but I can't guess what.
AddAction(ProbaRule(0.5), PoolAction('use_cache_pool'))
AddAction(AllRule(), PoolAction('no_cache_pool'))
If it's something else you wish to achieve, then please describe in more
words, e.g. with an example.
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] automatically forward query from the problematic domain
Affan Basalamah via dnsdist writes: > May I add that it's not the authoritative DNS, but it's the ccTLD DNS server > (example like > server for .com.country_names, .co.country_names, or .net.country_names) It sounds like you might be hitting some rate limits towards those servers from your resolvers. Do you know how many queries you send their way during normal operation. Have you tried to reach out to the operators of those servers to discuss if they could change the rate limits? It often helps to ask nicely. It's hard to give you any specific advice when you are not sharing which servers that are not always responding properly. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Multiple API Keys
Lars Weinrich via dnsdist writes: > I would like to create different API accounts with individual API keys. > > Is this possible? If so, how do I enter this in dnsdist.conf? Not as far as I know. The easier way is probably to put up an nginx or similar in front and have that do the authentication. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] setDynBlocksWarningAction(action) or something equal?
Hi Fredrik Pettai via dnsdist writes: > Now, https://dnsdist.org/guides/dynblocks.html is the simples way of > configuring such rules in DNSdist, > but it seems to be only one “global” Action that can be set (defaults > to Drop) by the setDynBlocksAction(action) function. There's a feature request for being able to do something more advanced here: https://github.com/PowerDNS/pdns/issues/13374 Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] two upstreams linked with OR?
Hi RyB via dnsdist writes: > I got a problem concerning having two upstream servers that do not have the > same data. So I am looking for a solution to query always both of them but > linked logically with an OR. > > for example: > - query for one.example.com > - NS1 - NXDOMAIN > - NS2 - 10.0.0.10 > - send 10.0.0.10 to the client This issue is that NXDOMAIN is a perfectly valid response to a DNS query, so what you want is not supported out of the box as far as I know. I guess you need to venture into writing your own custom logic in Lua if you want this particular functionality. Wouldn't it simply be easier to merge the zone into a single backend? Or alternatively use separate zones on separate backends? Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Suggestions for rules to block abusive traffic
Dan McCombs via dnsdist writes: > We've had on and off attacks recently targeting legitimate domains delegated > to our authoritative service flooding > queries for random subdomains of varying length and characters/words. i.e. > 12345.example.com, fred.example.com, > abc178371jd.example.com, where example.com is a different domain we're > authoritative for each attack. That's usually called a pseudo random sub domain attack. It happens to all of us. > We have thousands of domains, so it doesn't seem reasonable to apply > individual rate limits to them all, but if > there is a straight forward way to do something like that I'd be happy to > hear it. The source addresses are well > known public resolvers that we shouldn't rate limit either. dnsdist doesn't really know which queries belongs to which zones, so it would be hard to implement a per domain rate limit. > I'm wondering if there's any way to detect and apply a rule dynamically to > respond to queries for one of these > domains without affecting the source IP address entirely, and not require us > to manually add a rule for each domain > as it occurs. Have you looked at https://dnsdist.org/guides/dynblocks.html ? It can dynamically block clients misbehaving, where you define what it means to be misbehaving. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Dnsdist in front of AD DNS stops several times a day.
Søren Dam via dnsdist writes: > Hello, i have set up dnsdist in front of our AD DNS servers to provide > failover and flexibility. They run dnsdist 1.81 on RHEL 8 in front of four AD > servers. and > run a modest load of 1500-3000 QPS That should work just fine - we run much more than that through some of our dnsdist instances. > But they somehow saturate several times a day, they pattern is this, suddenly > outgoing sessions starts to pile up ( i guess that's what the "Out" column i > the > web interface is saying) , and then it soon becomes unresponsive. Is there anything in the log about what happened? Does all servers look healthy when it happens? Are you perhaps running out of available file descriptors? Check out the fd_usage metric. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Matching corrupt DNS queries?
Hi Remi Remi Gacogne via dnsdist writes: > On 13/08/2023 13:07, Jacob Bunk Nielsen via dnsdist wrote: > >> :setTC() function, but not a :getTC() function. > > Right, it was indeed missing. [1] adds it, and will likely be > backported to 1.8.x. Very quick expedition. Thank you, now I can shortly look into doing something with a LuaAction(). >> Also, it would be great >> to have a generic way to match on header flags like you can do on e.g. >> query types. >> Something like: >> HeaderRule(DNSFlags.TC, true) >> or similar, but I don't find anything like this in the docs. > > I don't think we have such a rule yet, and I would gladly add it to > dnsdist. Would you mind opening a feature request so it doesn't get > forgotten? There you go: https://github.com/PowerDNS/pdns/issues/13137 Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
[dnsdist] Matching corrupt DNS queries?
Hi We are sometimes seeing UDP DNS queries that come in with the TC flag set to true. That doesn't make sense to send such queries as the client should of course just make that query over TCP. But how do I match those queries in dnsdist? The DNSHeader class has a :setTC() function, but not a :getTC() function. Also, it would be great to have a generic way to match on header flags like you can do on e.g. query types. Something like: HeaderRule(DNSFlags.TC, true) or similar, but I don't find anything like this in the docs. Do any of you do any sort of filtering based on header flags? Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist[]: While reading a TCP question: accepting new connection on socket: Too many open files
Fredrik Pettai writes: >> On 26 Jul 2023, at 13:50, Jacob Bunk Nielsen via dnsdist >> wrote: >> Fredrik Pettai via dnsdist writes: >> >> Have you checked out dynamic blocks? If not, have a look at >> https://dnsdist.org/guides/dynblocks.html > > Yes, and we already have that in place. > Still, the descriptors ran out, so I guess dnsdist didn’t manage block all > the incoming bogus packets in time… dnsdist still have to accept the query and decide to drop it, so it will still use file descriptors for that. > How many packets/s is dnsdist able to handle? Should dnsdist be able to > handle 100K packets/s at peaks with the proper settings? We have handled significantly much more than 100k QPS with a single dnsdist instance in the past, so yes, that should definitely be possible, depending on the hardware you run it on. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist[]: While reading a TCP question: accepting new connection on socket: Too many open files
Fredrik Pettai via dnsdist writes: > One dnsdist instance recently got overloaded, and the message (subject + > below) appeared a lot in the logs: > > “dnsdist[]: While reading a TCP question: accepting new connection on > socket: Too many open files" > > Is this only related to too much DNS-traffic over TCP, or could lots > of DNS traffic over UDP also potentially lead to slowdown/locking > issues for dnsdist TCP handling? It's not just TCP, but also UDP. There's a good chance that you got hit by a DDOS attack and those tend to often be UDP based because it's much harder to spoof the source address of a TCP connection. > I’ve increased the amount of addLocal() + newServer() workers to be able to > handle more traffic. This probably wasn't your problem since you managed to run out of available file descriptors just fine with the current number of addLocal() and newServer(). > Dnsdist currently gets 16k fd’s (via systemctl's dnsdist.service > configuration) > > # grep -E '^Max open files' /proc/$(pidof dnsdist)/limits > Max open files1638416384files > > Would it be okay to increase this 4x or so? That depends on your specific hardware, but probably, yes. > What other things could one do to increase dnsdist ability to handle large > bursts of DNS traffic better? Have you checked out dynamic blocks? If not, have a look at https://dnsdist.org/guides/dynblocks.html Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist 1.8, change of behavior for dynamic blocks
On 11/05/2023 11.58, Remi Gacogne via dnsdist wrote: On 14/04/2023 08:25, Jacob Bunk Nielsen via dnsdist wrote: Just a heads up, we run an auth DNS service and I noticed after we upgraded to dnsdist 1.8 that we have started blocking a lot more based on a dynamic block rule defined as: dbr:setRCodeRate(DNSRCode.REFUSED, N, X, 'Exceeded REFUSED response rate', Y) This is what the metrics look like from around the upgrade time: https://allg.one/bvLn - I suspect that the rule above have now started working as intended. Thanks a lot for the heads-up! I don't remember any recent change in the related code, so I'm a bit surprised. Just to be sure, was dnsdist upgraded from 1.7.x? I'm asking because I remember fixing an issue that could be related in 1.6, but that doesn't match if you upgraded from 1.7.x, of course. We upgraded from 1.7.3 to 1.8.0. I suspect many of the REFUSED responses to be answered from cache, since most of them will (in our case) be a result of a lame delegation and lame delegations seems to retried very eagerly by some resolvers. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
[dnsdist] dnsdist 1.8, change of behavior for dynamic blocks
Hi Just a heads up, we run an auth DNS service and I noticed after we upgraded to dnsdist 1.8 that we have started blocking a lot more based on a dynamic block rule defined as: dbr:setRCodeRate(DNSRCode.REFUSED, N, X, 'Exceeded REFUSED response rate', Y) This is what the metrics look like from around the upgrade time: https://allg.one/bvLn - I suspect that the rule above have now started working as intended. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] rule to limit the QPS for each zone in absolute terms
Hi On 02/04/2023 09.35, Marco Mangione via dnsdist wrote: Have you ever had an area under flood attack? Well, it is identified (even automatically) and a specific rule is applied to the area under attack. Do you think it is possible to create a dynamic rule that does this automatically? That is, if a single zone exceeds X qps --> action. The problem is that dnsdist usually doesn't know what is a zone and what is not. E.g. is www.example.com a zone? You would need to check for a SOA record and delegation records to know for sure. That is likely more expensive than just answering the query you got. What about foo.bar.example.com? Or a.b.c.d.example.com? Those random subdomain attacks can go quite deep in some cases. I completely understand why you have this idea, but it's not entirely trivial to implement in a sufficiently generic way. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist 1.7 : allow only A request
Please keep the discussion on this list.
On 17/03/2023 16.37, david.n...@orange.com wrote:
Hi Jacob,
Here :
[root@UAVARRDIJ01 ~]# cat /etc/dnsdist/dnsdist.conf
-- DNSdist configuration file
-- disable security status polling via DNS
setSecurityPollSuffix("")
-- world reachable
setACL({'0.0.0.0/0', '::/0'})
-- listen on
setLocal('X.X.X.X')
-- control socket on localhost
controlSocket('127.0.0.1:5199')
setConsoleACL('127.0.0.1/32')
setKey('vr1zmw7JwKBN0hzk7n9vD69/SLkT+pl+Rb+crkiHYIM=')
webserver("X.X.X.X:8081")
-- webserver ("127.0.0.1:8081")
setWebserverConfig({password="", apiKey="x", acl="0.0.0.0/0"})
includeDirectory("/etc/dnsdist/conf.d")
==
cat /etc/dnsdist/conf.d/myconf_dnsdit.conf
setServerPolicy(wrandom)
newServer({address="127.0.0.1:853", name="my_server", pool="local", qps=1000,
order=1, weight=10, useClientSubnet=true})
newServer({address="180.112.144.96", name="remote-server" , pool="remote", checkType="A",
checkName="my_domain.fr" , qps=1500, order=1, weight=10 , useClientSubnet=true})
addAction(
NotRule (
OrRule {QTypeRule(DNSQType.A), QTypeRule(DNSQType.)}
),
AllowAction()
)
addAction({'toto.com'}, PoolAction("local"))
addAction({'titi.com'}, PoolAction("remote-server"))
I suggest you look into my previous suggestion, that I made in this
thread on the 13th of March. I think that would work better for you.
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist 1.7 : allow only A request
Hi On 17/03/2023 16.23, david.n...@orange.com wrote: Hello all After some tests I see a potential issue, tell me if I m right please : It works for A request : [root@node ~]# dig a www.toto.com @X.X.X.X +short 2.2.2.2 It stays mute more most of the requests ( expected behavior ), ^C is needed to get the prompt back. Please provide the full configuration of dnsdist in your setup, otherwise it will be close to impossible to help you figure out why things work the way they do. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist 1.7 : allow only A request
On 10/03/2023 09.21, david n via dnsdist wrote:
I tried to explicitly deny the most current DNS requests like for ex :
-- refused query type :
addAction(QTypeRule(dnsdist.ANY), DropAction())
addAction(QTypeRule(dnsdist.SOA), DropAction())
With dnsdist 1.4 (as far as I remember) those names for the various
query types changed, so dnsdist.ANY became DNSQType.ANY.
For your particular case of only wanting to serve A and records I
would probably just do (untested):
addAction(
NotRule(OrRule({QTypeRule(DNSQType.A),QTypeRule(DNSQType.)})),
RCodeAction(DNSRCode.REFUSED))
With all the warnings that Stephane already gave you about why this is a
bad idea.
You can replace RCodeAction(DNSRCode.REFUSED) with DropAction() if you
don't even want to reply with a REFUSED response.
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Handling lack of caching of TC responses
Hi On 18/11/2022 17.52, Dan McCombs via dnsdist wrote: Jacob - the downstreams are pdns-recursor resolvers. I mainly work with authoritative servers, but my tricks are mainly caching and rate limiting, I guess you can use similar tricks to ease the load on your recursor downstreams. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Publishing DNS NS records for dnsdist DNS load balancers
On 18/11/2022 15.07, Turritopsis Dohrnii Teo En Ming via dnsdist wrote: If I deploy 2 dnsdist DNS load balancers, one as primary and the other as secondary, I would only need to publish DNS NS records for these 2 DNS load balancers? I do not need to publish DNS NS records for the backend DNS servers, which are not DNS load balancers. Am I right? If you run authoritative servers for one or more DNS zones, you are right. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Handling lack of caching of TC responses
On 18/11/2022 02.51, Dan McCombs via dnsdist wrote: Anyone have any clever tricks to ease the load on the downstreams? What do you have downstream? Resolvers or authoritative servers? Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Dnsdist not reading from the cache
On 22/07/2022 12.11, SAMI RAHAL via dnsdist wrote:
Hello dnsdist community,
The dnsdist cache does not work Version: dnsdist 1.7.0 (Lua 5.1.4
[LuaJIT 2.0.4]) here is my configuration:
setPoolServerPolicy(leastOutstanding, "cacheTestiong")
test_pc = newPacketCache(200, {maxTTL=43200,
minTTL=0,temporaryFailureTTL=60, staleTTL=60, dontAge=false})
getPool("cacheTestiong"):setCache(test_pc)
addAction(AllRule(), PoolAction("cacheTestiong"))
Are you certain that this is your entire configuration? I'm guessing
it's not.
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] wrandom with downed servers?
On 03/06/2022 01.41, Aaron de Bruyn via dnsdist wrote:
The goal was to make sure we can serve 'somecustomer.local' (the
blasted Windows domain) should the local Windows Server go down and
also continue to serve external domains without accidentally sending
them queries for somecustomer.local.
[...]
# The local DC has the highest priority in the somecustomer pool
because the VPN is slow.
newServer ({address='ip.of.local.windows.dns',
name='local-windows-dns', pool='somecustomer', qps=500,
weight=2147483647})
It sounds to me like you really want to use the firstAvailable policy
rather than wrandom, especially when you set a local QPS limit.
See also https://dnsdist.org/guides/serverselection.html
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Latency and backend down issue
On 23/03/2022 13.20, Rais Ahmed via dnsdist wrote: We are seeing backend down issue and latency increase as well. Load traffic tested with 50K as well as 30K. same behavior. Implemented different configuration to diagnose this issue. Please help. What does your configuration look like? How does load on your backends look like, the increase in latency *could* indicate that they are unable to keep up. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] what do you think of our dns concept?
Hi On 12/03/2021 11.29, Jochen Demmer via dnsdist wrote: we're a small local provider and we're trying to renew our DNS infrastructure. I humbly ask you to take a look at it and tell me what you think of it. Every black box is a VM. There are supposed to be three authoritative PowerDNS that use postgresql in the back, while there is a logical replication originating from siteA. SiteA and SiteB are within our own IP adress range, while site C ist a very different site outside of our AS. Every dnsdist instance is getting its own dedicated IP. There are dnsdist for recursive requests and dnsdists for authoritative queries. Recursive dnsdist balances over three pdns recursors. If you run a separate dnsdist for recursive DNS, why not run it together with the PowerDNS resolvers instead of mixing it with the authoritative DNS setup? You don't have to run multiple dnsdist instances if you want to mix, you can split the queries based on their destination IPs, but I'd probably configure dnsdist to only talk to the local backends so you have instances that can operate independently. What's not in the graphic is an autoritative powerdns with no Domain configured. We plan to redirect requests from IPs that are not authorized querying some of our internal zones that we try to protect and also abusive requests for example when a customer is under DDoS. Why not answer directly from dnsdist in such cases? E.g. with a refused response or similar? Or simply drop the query and avoid participating in a reflection attack. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] cache dnsdist not working for my setup
Hi On 07/02/2021 20.19, SAMI RAHAL via dnsdist wrote: Thank you Jacob I installed version 1.5 when I try to access the console with the sudo dnsdist command I have the following error: Fatal error: binding socket to Server_IP: 53: Address already in use. Did you remember to stop dnsdist 1.3 before upgrading? What's listening on port 53? "sudo netstat -nlp | grep ':53'" can probably give you a good hint. It's been a long time since I ran 1.3, and I don't remember if there were any caveats of the 1.3->1.4 upgrade except many types getting new names. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] cache dnsdist not working for my setup
Hi Sami On 06/02/2021 19.35, SAMI RAHAL via dnsdist wrote: Hi Remi can I use version 1.6 in production? You can, but it's not recommended unless you want to run an alpha version. The latest released version is 1.5.1: https://blog.powerdns.com/2020/10/01/dnsdist-1-5-1-released/ Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] cache dnsdist not working for my setup
Hi Sami On 05/02/2021 09.59, SAMI RAHAL via dnsdist wrote: dnsdist packet cache is not working form my setup How do you know that it's not working? Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist Digest, Vol 65, Issue 11
Hi Sami
On 30/01/2021 19.11, SAMI RAHAL via dnsdist wrote:
thank you Jacob for your reply ,
I want to know the normal response from a dns resolver server in general (the
value in ms)
here is the setup
As Stephane pointed out that very much depends on a lot of variables
that are hard to predict. Are you asking because you are dissatisfied
with the performance of your setup?
-- listen for console connection with the given secret key
controlSocket("0.0.0.0")
addLocal('@IP-serverdnsdist:53',{doTCP=true, reusePort=true, tcpFastOpenSize=0})
setACL('@IP/24')
-- fix up possibly badly truncated answers from pdns 2.9.22
truncateTC(true)
warnlog(string.format("Script starting %s", "up!"))
newServer({name="unbound", address="@IP", qps=1000, order=1})
newServer({name="pdns-recursor", address="@IP", order=2})
--newServer({address="8.8.8.8", pool="abuse"})
-- set the TC-bit (truncate) on ANY queries received over UDP, forcing a retry
over TCP.
addAction(AndRule({QTypeRule(dnsdist.ANY), TCPRule(false)}), TCAction())
This (dnsdist.ANY) indicates that you are running a fairly old version
of dnsdist (prior to 1.4, I think). There are performance improvements
done in every release. Consider upgrading.
-- DDos protection, block for 5 minutes.
https://dnsdist.org/guides/dynblocks.html
local dbr = dynBlockRulesGroup()
dbr:setQueryRate(30, 10, "Exceeded query rate", 3000)
dbr:setRCodeRate(dnsdist.NXDOMAIN, 20, 10, "Exceeded NXD rate", 3000)
dbr:setRCodeRate(dnsdist.SERVFAIL, 20, 10, "Exceeded ServFail rate", 300)
dbr:setQTypeRate(dnsdist.ANY, 5, 10, "Exceeded ANY rate", 300)
dbr:setResponseByteRate(1, 10, "Exceeded resp BW rate", 300)
-- send the queries for selected domain suffixes to the server
-- in the 'abuse' pool
addAction({"ezdns.it.", "xxx."}, PoolAction("abuse"))
-- send the queries from a selected subnet to the
-- abuse pool
addAction("192.168.1.0/24", PoolAction("abuse"))
-- send only queries from the selected subnet to
-- the luarule function
addLuaAction("192.168.1.0/24", luarule)
-- drop queries exceeding 5 qps, grouped by /24 for IPv4
-- and /64 for IPv6
addAction(MaxQPSIPRule(5, 24, 64), DropAction())
5 queries per second is not a lot. Loading some websites will generate
much more than 5 queries within a very short time. Consider increasing
this significantly. I'd be surprised if you don't see this rule being
hit frequently. Check it with 'showRules()' in the dnsdist console.
Also if you have multiple clients in your /24 network this is very low.
-- move the last rule to the first position
topRule()
Why not just add it to the top of your config?
-- drop queries for the following suffixes:
addAction("powerdns.org.", DropAction())
Why?
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Average response latency
On 29/01/2021 17.41, SAMI RAHAL via dnsdist wrote: hello please is the following result from my dnsdist server within standards? and at the same time I want to know the optimal response time of a dns resolver server What's your setup? The ~1 ms response times are probably cached responses. The ~50-500ms response times are probably from backends. You tell us if that's reasonable for your setup? Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] DNScrypt with DNSDist
Hi
I read the list, so no need to write me in person.
On 15/12/2020 06.27, Sayan Bhattacharyya wrote:
[root@t2 ~]# dnsdist -e
'generateDNSCryptProviderKeys("/etc/dnsdist/ssl/pub.key",
"/etc/dnsdist/ssl/t2.xolentum.net.key")' --verbose
Read configuration from '/etc/dnsdist/dnsdist.conf'
Adding server to default pool
Connecting to 127.0.0.1:5199
Provider fingerprint is:
6BEA:CDAB:114C:E2E5:DA96:743F:A6FB:4941:CEF6:B434:9C8B:CA5F:FE44:A9B3:7F23:70C0
And tried searching the entire /, no resolver.key or similar file found.
So you generated a key and put it in a file called t2.xolentum.net.key
and then expect to find a file called resolver.key? How should that work?
What ended up in /etc/dnsdist/ssl/ ?
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] DNScrypt with DNSDist
Hi
On 13/12/2020 06.10, Sayan Bhattacharyya via dnsdist wrote:
Hello,
I'm trying to generate the resolver key using my certificate's public
and private keys, the command that I'm using on the DNSDist console is:
/generateDNSCryptProviderKeys("/etc/pki/tls/certs/public.key",
"/etc/pki/tls/private/private.key")/
/
/
I can see that my fingerprint is printed to the screen, however, I do
not get where is the key being save? It's neither in the CWD nor in
the//etc/dnsdist/directory. Where is the location?
Did you check the paths that you entered in the dnsdist console? I.e.
/etc/pki/tls/certs/ and /etc/pki/tls/private/ ? That's where I'd expect
to find them when I read https://dnsdist.org/guides/dnscrypt.html
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist metrics
Hi On 05/05/2020 16.41, Simone Beccato via dnsdist wrote: I setup in dnsdist.conf the carbon export and configured Grafana to query data from Graphite but as I see, from dnsdist are coming only “totals”, total queries, totals rdqueries etc. Is there a way to get QPS and/or metrics per seconds? Or I have to manipulate data (how?)? As others have already pointed out you'll want the derivative to find a rate rather than just the growing gauge value. E.g. by using the perSecond function like perSecond(dnsdist.name.main.queries) Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Question about the use of the method :addMask(masks)
On 27/02/2020 18.47, Ambauen Daniel (ID NET) via dnsdist wrote: I try to understand the NetmaskGroup feature. https://dnsdist.org/reference/netmaskgroup.html?highlight=mask :addMask(mask) works fine. internal_NMG = newNMG() internal_NMG:addMask(‘192.168.1.0/24’) internal_NMG:addMask(‘192.168.2.0/24’) addAction(NetmaskGroupRule(internal_NMG), NoneAction()) What exactly are you trying to do? This will do nothing because that's what NoneAction() does. The above config will invoke NoneAction() for all queries from your two internal /24 networks. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist Action dependant on source IP and queried domain
On 27/02/2020 10.58, Jochen Demmer via dnsdist wrote:
In your example queries from internal network are being redirected to
the pool that can answer those.
Exactly.
addAction(AndRule({NetmaskGroupRule(internal_dns_ips, false),
NetmaskGroupRule(internal_network)}), PoolAction('internal_auth_pool'))
But queries from internal network do not neccessarily ask only for
internal zones, they might as well need recursion or maybe even the
public pool.
But those queries should go to different IPs. So you give out a set of
IPs for recursion, another set of IPs for public auth zones and a third
set of IPs for internal zones.
How can I handle that? Should the DNS server that the clients of the
internal network use make the distinction between where normal recursive
queries shall be sent to and where to send those who are private domains?
The clients should only talk to the recursive resolver, I guess?
Best regards,
Jacob
P.S. Jochen, sorry for writing to you directly - I wanted to answer on-list.
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist Action dependant on source IP and queried domain
On 27/02/2020 10.15, Jochen Demmer via dnsdist wrote: this makes it very much clear so far where to go, just one more question. What if I want to have only ONE cluster of powerdns auth servers who answer both private and public domains? How can dnsdist distinguish between those, can it? That was what I was trying to help you achieve with the config example. Only my example would not prevent you from asking the public auth server about things that should only be served for internal use if those two frontends end up asking the same backend. I'd run two PowerDNS instances in your situation, one for public zones and one for private zones. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist Action dependant on source IP and queried domain
On 27/02/2020 09.13, Jochen Demmer via dnsdist wrote:
you're saying I can use one dnsdist instance bound to different IPs for
all DNS traffic no matter if it's recursive or authoritative and even at
the same time for my protected authoritative domains?
Yes, you can do stuff like:
addLocal('1.1.1.1',{})
addLocal('2.2.2.2',{})
addLocal('3.3.3.3',{})
external_auth_dns_ips = newNMG()
external_auth_dns_ips:addMask('1.1.1.1/32')
external_recursive_dns_ips = newNMG()
external_recursive_dns_ips:addMask('2.2.2.2/32')
internal_dns_ips = newNMG()
internal_dns_ips:addMask('3.3.3.3/32')
internal_network = newNMG()
internal_network:addMask('10.0.0.0/8')
internal_network:addMask('192.168.0.0/16')
addAction(NetmaskGroupRule(external_auth_dns_ips, false),
PoolAction('auth_pool'))
addAction(NetmaskGroupRule(external_recursive_dns_ips, false),
PoolAction('recursive_pool'))
addAction(AndRule({NetmaskGroupRule(internal_dns_ips, false),
NetmaskGroupRule(internal_network)}), PoolAction('internal_auth_pool'))
Then you of course want to create relevant backends using newServer()
and probably add a bit of caching as well.
But as always, there's more than one way to do it :-)
Since there are several thousand domains we host for our customers and a
few protected ones I would have to keep dnsdinst informed about all of
those, right? This is not something I would like to do manually of
course. Without the dnsdist knowing how could it decide where to
redirect the query or even to deny the request in the first place?
Can someone please give a short example of how such an Action could look
like?
I've tried something like this but this is obviously not enough.
addAction(RegexRule(".internal\\.domain\\.net$"), PoolAction("privatezone"))
That's why I suggest setting it up on a separate IP. You can even put it
in a separate dnsdist instance if you prefer to keep things completely
separate, but the above (untested) config would also just solve this for
you.
But this would need a second selector which would be this NMG thing. How
can I combine that?
I also made a small matrix on what shall be done which which requests.
See attached image.
You can make explicit rules to return REFUSED replies in the cases where
you want that.
Best regards,
Jacob
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist Action dependant on source IP and queried domain
Hi On 25/02/2020 17.37, Jochen Demmer via dnsdist wrote: we're trying to make our DNS infrastructure great again. Currently we use Bind as recursive servers for our clients (we're a small ISP) and nsd for authoritative domains. This is what I'm heading to do: - run 2+ powerdns servers as authoritative for public domains as well as our internal domains - run 2+ dnsdist servers as load balancer with regex and ip dependant rules - run xyz as recursive nameserver for our dialup / fibre clients Consider running recursive DNS and authoritative DNS on separate IPs. You can still run it through the same dnsdist instance, but by splitting it on IPs you can just look at the destination IP to determine which backend to send queries to or whether to deny the query or not. We have domains hosted for ourselves but also customers. We would like to host those with powerdns with replicated postgres. As powerdns does not have ACL we plan to run dnsdist in front of the powerdns in order to make better decisions what to do with requests: requests from the www, recursive: REFUSE requests from the www, authoritative public domain: forward to powerdns requests from the www, authoritative private domain: REFUSE Take a look at creating network mask group: https://dnsdist.org/reference/netmaskgroup.html to match specific source or destination addresses and take actions based on that. requests from our internal network, recursive: won't happen requests from our internal network, authoritative public domain: forward to powerdns requests from our internal network, authoritative private domain: forward to powerdns The plan is to protect our private domains from being resolved from any public IP. Will such kind of filter have big performance implications? What is best practice to do so? It won't, but consider putting them on a separate IP that is not internet reachable if you want to be sure to keep it private. Best regards, Jacob ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
