Re: [dnsdist] DoH issues after 1.8.3 -> 1.9.0 upgrade

2024-03-17 Thread Otto Moerbeek via dnsdist 
On Sun, Mar 17, 2024 at 06:41:13PM +0100, Christoph via dnsdist wrote:

> Hi,
> 
> in February we upgraded our test DoH/DoT server from 1.8.3 to 1.9.0
> but we did not notice any problems so we upgraded our production server
> from 1.8.3 to 1.9.0 yesterday.
> 
> Immediately after upgrading our monitoring claimed our DoH service is
> unavailable (HTTP 400) but we were unable to reproduce it using firefox.
> 
> A closer look confirmed that there is some issue because we see about 50%
> less DoH requests in our grafana graphs showing DoH request rates.
> 
> Having a look at the request rates per HTTP method suggests that we "loose"
> almost all GET requests but also a significant fraction of POST DoH
> requests.
> 
> sum by (method) 
> (irate(dnsdist_frontend_doh_http_method_queries{job="$job"}[$__rate_interval]))
> 
> After looking at the TLS versions graph I noticed a clear correlation
> but then I realized that all our DoH requests are TLS version 1.3
> because we set minTLSVersion='tls1.3' - so this might be irrelevant.
> 
> irate(dnsdist_frontend_tlsqueries{job="$job"}[$__rate_interval])
> 
> 2024-03-16 20:57:59 dnsdist upgraded: 1.8.3_1 -> 1.9.0
> 2024-03-16 20:59 monitoring says DoH is down (HTTP 400 - Bad Request)
> monitoring requests this: 
> https://doh.applied-privacy.net/query?dns=l1sBAAABA3d3dw1rbm90LXJlc29sdmVyAmN6AAAcAAE
> Mar 17 02:40:45 bender-dpriv1 kernel: pid 77544 (dnsdist), jid 0, uid 208:
> exited on signal 11 -> also interesting put likely unrelated?
> 
> Today we downgraded to 1.8.3, and everything went back to normal.
> 
> Is anyone else observing similar issues on dnsdist 1.9.0?
> 
> DoT does not appear to be affected.
> 
> best regards,
> Christoph
> 
> OS: FreeBSD 13.2
> dnsdist installed via pkg
> 
> our dnsdist config:
> 
> newServer({address="109.70.100.136", maxInFlight=1000, sockets=32,
> name="clamps"})
> newServer({address="109.70.100.140", maxInFlight=1000, sockets=32,
> name="roberto"})
> --newServer({address="109.70.100.133", sockets=4, name="titanius-dpriv1"})
> setServerPolicy(leastOutstanding)
> 
> addTLSLocal("0.0.0.0",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.crt",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.key", 
> {ciphers='ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256',
> minTLSVersion='tls1.2', tcpFastOpenQueueSize=1000, maxInFlight=1000 })
> addTLSLocal("[::]",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.crt",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.key", 
> {ciphers='ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256',
> minTLSVersion='tls1.2', tcpFastOpenQueueSize=1000, maxInFlight=1000 })
> 
> addDOHLocal("0.0.0.0:444",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.crt",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.key",
> "/query", {minTLSVersion='tls1.3', serverTokens='doh',
> tcpFastOpenQueueSize=1000, tcpListenQueueSize=4096 })
> addDOHLocal("[::]:444",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.crt",
> "/usr/local/etc/ssl/lego/certificates/doh.applied-privacy.net.key",
> "/query", {minTLSVersion='tls1.3', serverTokens='doh',
> tcpFastOpenQueueSize=1000, tcpListenQueueSize=4096 })
> 
> setACL({'0.0.0.0/0', '::/0'})
> controlSocket('127.0.0.1:5199')
> setConsoleACL('127.0.0.1/8')
> 
> setKey()
> 
> pc = newPacketCache(5, {maxTTL=86400, minTTL=3, temporaryFailureTTL=60,
> staleTTL=60, dontAge=false})
> getPool(""):setCache(pc)
> 
> webserver("127.0.0.1:8083")
> setWebserverConfig({...})
> setVerboseHealthChecks(true)
> addAction(QTypeRule(65535), RCodeAction(DNSRCode.NOTIMP))


This might be related: https://github.com/PowerDNS/pdns/issues/13850,
not backported yet

-Otto

___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] dnsdist 1.8.0 thread spinning

2023-07-15 Thread Otto Moerbeek via dnsdist 
On Fri, Jul 14, 2023 at 03:06:12PM -0500, Dustin Marquess via dnsdist wrote:

> So far we've had instances with dnsdist 1.8.0 having a thread in a tight 
> loop. OS versions seem to vary widely, so I don't believe it's a glibc bug.
> 
> Config on both is the same plain config:
> 
> setLocal("127.0.0.1:53", {reusePort=true})
> addLocal("127.0.0.1:53", {reusePort=true})
> addLocal("127.0.0.1:53", {reusePort=true})
> addLocal("127.0.0.1:53", {reusePort=true})
> addACL('10.0.0.0/8')
> newServer({address="10.112.104.116", checkType="A", checkClass=DNSClass.IN, 
> checkName="hc.xxx.local", mustResolve=true, checkInterval=30})
> newServer({address="10.112.106.177", checkType="A", checkClass=DNSClass.IN, 
> checkName="hc.xxx.local", mustResolve=true, checkInterval=30})
> newServer({address="10.9.41.68", checkType="A", checkClass=DNSClass.IN, 
> checkName="hc.xxx.local", mustResolve=true, checkInterval=30})
> setServerPolicy(firstAvailable)
> 
> -- Tuning
> setRingBuffersSize(100, 100)
> setMaxTCPClientThreads(20)
> 
> -- Caching
> -- We should make these tunables configurable
> pc = newPacketCache(10, {maxTTL=86400, minTTL=0, temporaryFailureTTL=60, 
> staleTTL=60, dontAge=false})
> getPool(""):setCache(pc)
> 
> -- Don't try and hit the internet
> setSecurityPollSuffix("")
> 
> [pid  2990] recvfrom(-1, 0x7f3d9c0008c0, 4368, 0, NULL, NULL) = -1 EBADF (Bad 
> file descriptor)
> [pid  2990] recvfrom(-1, 0x7f3d9c0008c0, 4368, 0, NULL, NULL) = -1 EBADF (Bad 
> file descriptor)
> [pid  2990] recvfrom(-1, 0x7f3d9c0008c0, 4368, 0, NULL, NULL) = -1 EBADF (Bad 
> file descriptor)
> [pid  2990] recvfrom(-1, 0x7f3d9c0008c0, 4368, 0, NULL, NULL) = -1 EBADF (Bad 
> file descriptor)
> 
> In each case, a strace shows a bad recvfrom() call in a tight loop:
> 
> Obviously -1 is a bad fd! Restarting dnsdist seems to resolve it. The only 
> idea I can come up with is that when dnsdist first starts, it's unable to 
> contact the upstream DNS servers and that somehow causes the issue. When we 
> restart it, it IS able to contact them, and so works fine.
> 
> Any ideas?
> 
> Thanks!
> -Dustin

This is likely https://github.com/PowerDNS/pdns/pull/12726

ATM this is not marked for backporting to 1.8.x. Don't know if that is
an omission.

-Otto
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] dnsdist latency bucket metric still broken in 1.8.0?

2023-04-14 Thread Otto Moerbeek via dnsdist 
On Thu, Apr 13, 2023 at 10:00:25PM +0200, Christoph via dnsdist wrote:

> Remi Gacogne via dnsdist:
> > The fix not being backported is an oversight, I added the "backport to
> > 1.7.x" flag so we include it in an upcoming 1.7.x release.
> 
> Great to hear that this was unexptected.
> 
> > > Recently we upgraded our dnsdist instances to 1.8.0
> > > but the upgrade did not improve the values in dnsdist_latency_bucket.
> > > Now after the upgrade, the graph show basically a flat line.
> > > This only affects our FreeBSD servers, not our Debian based dnsdist
> > > instances.
> > 
> > That's weird. Would you be able to share the prometheus output, or the
> > dumpStats() one, so we know if this is the same bug or a related one?
> 
> I added it here because I wanted to add the graph as well but github upload
> is failing me, so just prometheus:
> https://github.com/PowerDNS/pdns/issues/11239#issuecomment-1507536007

Did you compile dnsdist yourself? If I try to install dnsdist on
13.1-RELEASE-p6 I only get 1.7.3:

# pkg install dnsdist
New packages to be INSTALLED:
dnsdist: 1.7.3

# pkg install dnsdist-1.8.0

pkg: No packages available to install matching 'dnsdist-1.8.0' have
been found in the repositories

A quick test with a self-compiled 1.8.0 dnsdist shows a non-zero sum
for me, so I'm confused what's goiong on.

prometheus  output after a few queries to a UDP upstream:

# HELP dnsdist_latency Histogram of responses by latency (in milliseconds)
# TYPE dnsdist_latency histogram
dnsdist_latency_bucket{le="1"} 0
dnsdist_latency_bucket{le="10"} 4
dnsdist_latency_bucket{le="50"} 6
dnsdist_latency_bucket{le="100"} 6
dnsdist_latency_bucket{le="1000"} 6
dnsdist_latency_bucket{le="+Inf"} 6
dnsdist_latency_sum 74
dnsdist_latency_count 6

-Otto


___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] DNSDIST 1.8.0 With Cache Enabled Unknown key 'dontAGE'

2023-03-30 Thread Otto Moerbeek via dnsdist 
On Thu, Mar 30, 2023 at 11:15:10PM +, Bradley Minamoto via dnsdist wrote:

> Much thanks to Christof who pointed out the upper-case.
> 
> My original configuration contained dontAGE=false. After correcting it to 
> dontAge=false the error cleared. Oddly I did not have this issue with 
> previous versions.

Matching of key names has always been case-sensitive. 1.8.0. added
checking of keys names to discover typos: 
https://github.com/PowerDNS/pdns/pull/10115

Before that, unknown keys were silently ignored. For dontAge that did
not matter as it default value is false.

-Otto

> 
> 
> 
> -Brad
> 
> 
> From: dnsdist  on behalf of Bradley 
> Minamoto via dnsdist 
> Sent: Thursday, March 30, 2023 12:11 PM
> To: dnsdist@mailman.powerdns.com 
> Subject: [dnsdist] DNSDIST 1.8.0 With Cache Enabled Unknown key 'dontAGE'
> 
> Has anyone noticed this error when accessing the DNSDIST console (it's also 
> shows up in /var/log/messages) on Red Hat 8?
> 
>  newPacketCache: Unknown key 'dontAGE' given - ignored
> 
> 
> It seems the dontAGE parameter is not recognized in 1.8.0. This parameter is 
> listed in the example on 
> https://dnsdist.org/guides/cache.html
>  and I did not see any references to it being removed/renamed in the change 
> notes.
> 
> 
> As a workaround, I removed "dontAge=false" from my configuration. Is this 
> option no longer supported in 1.8.0 or is this a bug?
> 
> 
> 
> Thanks,
> 
> Brad

> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist

___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] DOH configuration issue

2023-03-19 Thread Otto Moerbeek via dnsdist 


Oops, ignore this. My mistake.

-Otto

On Sun, Mar 19, 2023 at 09:14:40PM +0100, Otto Moerbeek via dnsdist wrote:

> On Sun, Mar 19, 2023 at 09:09:47PM +0100, Chandra wrote:
> 
> > Thank you.  It seems I missed that one. :) 
> 
> It's good form to reply to the list.
> 
>   -Otto
> 
> > 
> > On Sun, Mar 19, 2023, at 21:06, Otto Moerbeek wrote:
> > > On Sun, Mar 19, 2023 at 04:54:19PM +0100, Chandra via dnsdist wrote:
> > > 
> > > > Hello all,
> > > > 
> > > > I am trying to configure DOH over HTTP and I can't seem to figure out 
> > > > what I'm doing wrong. I have a nginx proxying the incoming request and 
> > > > don't need it on HTTPS.  Here's my config
> > > > 
> > > > *--- doh over http*
> > > > setACL({"0.0.0.0/0", "::/0"})
> > > > addLocal('0.0.0.0:7070')
> > > > webserver("127.0.0.1:8083")
> > > > 
> > > > newServer({address="1.1.1.1", 
> > > > pool="pub-unsafe-tier1",name="cloudflare"})
> > > > newServer({address="8.8.8.8", pool="pub-unsafe-tier1",name="google"})
> > > > newServer({address="194.242.2.2",pool="pub-safe-tier1",name="mullvad-noadblock",checkInterval=60})
> > > > newServer({address="84.200.69.80", 
> > > > pool="pub-safe-tier2",name="dnswatch1",checkInterval=60})
> > > > newServer({address="84.200.70.40", 
> > > > pool="pub-safe-tier2",name="dnswatch2",checkInterval=60})
> > > > 
> > > > 
> > > > addDOHLocal("0.0.0.0:9090",nil,nil, "/dns-query", { reusePort=true, 
> > > > trustForwardedForHeader=true })
> > > > ```
> > > > 
> > > > When testing on the  locally, here's what I get:
> > > > 
> > > > $ curl  -H 'accept: application/dns-message'  
> > > > 'http://localhost:9090/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
> > > > 
> > > > dns query not allowed
> > > > 
> > > > $ ...
> > > > 
> > > > 
> > > > Where am I going wrong?
> > > 
> > > You have no policy defined. The default policy is to send packets to
> > > the default pool (named ""). Your default pool is empty.  So the query
> > > gets refused, since no policy applies.
> > > 
> > > -Otto
> > > 
> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] DOH configuration issue

2023-03-19 Thread Otto Moerbeek via dnsdist 
On Sun, Mar 19, 2023 at 09:09:47PM +0100, Chandra wrote:

> Thank you.  It seems I missed that one. :) 

It's good form to reply to the list.

-Otto

> 
> On Sun, Mar 19, 2023, at 21:06, Otto Moerbeek wrote:
> > On Sun, Mar 19, 2023 at 04:54:19PM +0100, Chandra via dnsdist wrote:
> > 
> > > Hello all,
> > > 
> > > I am trying to configure DOH over HTTP and I can't seem to figure out 
> > > what I'm doing wrong. I have a nginx proxying the incoming request and 
> > > don't need it on HTTPS.  Here's my config
> > > 
> > > *--- doh over http*
> > > setACL({"0.0.0.0/0", "::/0"})
> > > addLocal('0.0.0.0:7070')
> > > webserver("127.0.0.1:8083")
> > > 
> > > newServer({address="1.1.1.1", pool="pub-unsafe-tier1",name="cloudflare"})
> > > newServer({address="8.8.8.8", pool="pub-unsafe-tier1",name="google"})
> > > newServer({address="194.242.2.2",pool="pub-safe-tier1",name="mullvad-noadblock",checkInterval=60})
> > > newServer({address="84.200.69.80", 
> > > pool="pub-safe-tier2",name="dnswatch1",checkInterval=60})
> > > newServer({address="84.200.70.40", 
> > > pool="pub-safe-tier2",name="dnswatch2",checkInterval=60})
> > > 
> > > 
> > > addDOHLocal("0.0.0.0:9090",nil,nil, "/dns-query", { reusePort=true, 
> > > trustForwardedForHeader=true })
> > > ```
> > > 
> > > When testing on the  locally, here's what I get:
> > > 
> > > $ curl  -H 'accept: application/dns-message'  
> > > 'http://localhost:9090/dns-query?dns=AAABAAABA3d3dwdleGFtcGxlA2NvbQAAAQAB'
> > > 
> > > dns query not allowed
> > > 
> > > $ ...
> > > 
> > > 
> > > Where am I going wrong?
> > 
> > You have no policy defined. The default policy is to send packets to
> > the default pool (named ""). Your default pool is empty.  So the query
> > gets refused, since no policy applies.
> > 
> > -Otto
> > 
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] dnsdist not seeing a valid port

2023-01-15 Thread Otto Moerbeek via dnsdist 
Hi,

Can you query the recursor with dig @::1 -p 5301 ... ?

If you get a timeout, it is likely an ACL isue on the recursor side,
recursor will drop queries from non permitted clients.  See
https://docs.powerdns.com/recursor/settings.html#allow-from


If so, use setVerboseHealthChecks(true) in the dnsdist configuraion
to get detailed health check information to diagnose further.

-Otto

On Sat, Jan 14, 2023 at 08:48:56PM -0500, Larry Wapnitsky via dnsdist wrote:

> I have dnsdist running on my powerdns server, and have just started adding
> in my IPv6 configurations. All seems well until I add in the v6 address for
> my recursor:
> 
> [image: image.png]
> 
> My config is as follows:
> 
> newServer({address="127.0.0.1:53", name="primary", pool={"primary",
> "auth"}})
> newServer({address="[::1]", name="primary", pool={"primary", "auth"}})
> newServer({address='127.0.0.1:5301', pool='recursor'})
> newServer({address='[::1]:5301', pool='recursor'})
> 
> and my ports are live:
> 
> root@ns1:~# ss -tlpn | grep 53
> LISTEN   04096  10.150.33.5:530.0.0.0:*
>  users:(("dnsdist",pid=4041,fd=10))
> 
> LISTEN   0128 127.0.0.1:5301  0.0.0.0:*
>  users:(("pdns_recursor",pid=1223,fd=6))
> 
> LISTEN   0128  10.150.33.15:530.0.0.0:*
>  users:(("pdns_server",pid=304,fd=10))
> 
> LISTEN   0128 127.0.0.1:530.0.0.0:*
>  users:(("pdns_server",pid=304,fd=9))
> 
> LISTEN   04096127.0.0.53%lo:530.0.0.0:*
>  users:(("systemd-resolve",pid=101,fd=13))
> 
> LISTEN   0128 [::1]:5301 [::]:*
>  users:(("pdns_recursor",pid=1223,fd=7))
> 
> LISTEN   0128 [::1]:53   [::]:*
>  users:(("pdns_server",pid=304,fd=12))
> 
> 
> Advice is welcome.
> 
> Thank you,
> 
> *Larry G. Wapnitsky*



> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist

___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] Dnsdist dynamic backend selection between AUTH and RECURSOR

2023-01-07 Thread Otto Moerbeek via dnsdist 
Hi,

My first suggestion would be to not need to do the name based
forwarding by separating the incoming recurosr and auth traffic on ip
address or port. If that is not feasible, take a look at

https://dnsdist.org/reference/kvs.html

Have a process update the kv-database and dnsdist can use that to make
its decisions.

-Otto


On Sat, Jan 07, 2023 at 10:14:17AM +0100, bernd--- via dnsdist wrote:

> Hello!
> 
>  
> 
> I have a question regarding the architecture of DNSDIST in front of an
> authorative pdns instance as well as an recursor.
> 
> I`ve looked at: https://doc.powerdns.com/authoritative/guides/recursion.html
> - however, the solutions described are kind of static.
> 
> Eg. Domains send to the auth-instance have to be specified manually in the
> config.
> 
>  
> 
> What I love to achieve is:
> 
>  
> 
> Let DNSDIST dynamicly select if a Request should be send to AUTH or
> RECURSOR.
> 
> For Latency, the list of AUTH-Domains should be somehow synced locally to
> the DNSDIST-Instance itself.
> 
> DNSDIST should not ask AUTH always and if it fails forward the request to
> the Recursor.
> 
> Also if another Domain is added to the AUTH-Instance, this domain should be
> added to the DNSDIST Config.
> 
>  
> 
> I tought about getting the Domain List via API on Startup and adding new
> records via Control-Socket.
> 
>  
> 
> Has someone done a similar thing already?
> 
>  
> 
> PS: Sorry for some potential false spellings - i`m not native.
> 
>  
> 
> BR
> 
> Bernd
> 
> https://berndklaus.at
> 
>  
> 

> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist

___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] Client query id in the dq-object?

2022-11-03 Thread Otto Moerbeek via dnsdist 
On Wed, Nov 02, 2022 at 05:19:54PM +0100, Tom via dnsdist wrote:

> Hi list
> 
> A few months ago, I've asked the question below and wasn't able to find a
> solution in the meantime. Does someone has a hint, how to achieve this?
> 
> Many thanks in advance.
> Tom
> 
> 
> On 7/28/22 11:17, Tom wrote:
> > Hi
> > 
> > Using dnsdist-1.7.2, I'm trying to get the query id from the
> > client-query, but I can't find the matching parameter in the dq-object.
> > My goal is to find a specific query-id (ex. ) and then use this
> > (same) specific query-id also for the outbound query from dnsdist to the
> > backend server.
> > 
> > Any hints how to achieve this?
> > 
> > Many thanks.
> > Tom

There is no API to get the queryid. It could maybe be added, but
*setting* the query id four outgoing queries is something else.

Keeping track of query-id's is a complex problem, think about multiple
clients, multiple backends, many queries in-flight. This is not
something to be done from Lua, but a job for dnsdist itself. 

To ask a more general question: what problem are you trying to solve?

If we would have more insight in that, we can maybe suggest an
alternative approach to solve your problem.

-Otto
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] Backend Questions

2022-11-02 Thread Otto Moerbeek via dnsdist 
On Wed, Nov 02, 2022 at 01:38:10PM +0100, Klaus Darilion via dnsdist wrote:

> (resent to the list)
> 
> Hi Remi!
> 
> > On 07/10/2022 10:53, Klaus Darilion via dnsdist wrote:
> > 
> > > We use dnsdist with 1 single backend server (PDNS). So if this backend
> > > is overloaded, dnsdist will detect the backend as DOWN. Hence, the only
> > > server for this backend pool down. How will dnsdist behave if all
> > > servers for a backend pool are down? Will it stop senden queries to the
> > > backend, or will it still send queries to the DOWN server as there is no
> > > UP server available?
> > 
> > All of the built-in load balancing policies will stop forwarding queries
> > when all the servers in the selected pool are down. It would be possible
> > to write a custom load-balancing in Lua that does not do that, of
> > course, but I don't think that's what you want in that case.
> > 
> > > So it may be useful to disable healthchecks completely. How can this be
> > > done?
> > 
> > You can force a server in the "up" state using the 'setUp()' method, see
> > [1].
> 
> Shouldn't newServer(...healthCheckMode='UP') also work? In my case it does 
> not work. 
> I have set healthCheckMode='UP' but:
> showServers show status as "up" whereas after setUp() the status is "UP". And 
> it still does helathchecks and status goes "down" if the backend is down.
> 
> What is wrong? The docs? Am I misinterpreting the docs? Bug?

Which version are yor running? healthCheckMode wil only be available
in 1.8.0, which is not released yet. See 
https://dnsdist.org/reference/config.html?highlight=newserver#newServer

-Otto
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] Some questions about applying for GSoC and newBPFFilter

2022-04-10 Thread Otto Moerbeek via dnsdist 
On Sun, Apr 10, 2022 at 06:54:03AM +, Y7n05h via dnsdist wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sat, Apr 09, 2022 at 12:51:56PM +, Y7n05h via dnsdist wrote:
> > Hi!
> >
> > I spent some time this week preparing for and participating in college
> > finals (last semester's finals were postponed this week due to
> > COVID-19), so not much time on DNSDist. Fortunately, the exam is over.
> >
> > I was trying to implement https://github.com/PowerDNS/pdns/issues/9690
> > and found that typing bpf = newBPFFilter(1024, 1024, 1024) would give
> > me an error here.
> >
> > [string "bpf = newBPFFilter(1024, 1024, 1024)"]:1: Caught exception:
> > Error creating a BPF map of size 1024:
> > Operation not permitted stack traceback:
> >[C]: in function 'newBPFFilter'
> >[string "bpf = newBPFFilter(1024, 1024, 1024)"]:1: in main chunk
> >
> >
> > I had the same problem on ArchLinux and Ubuntu 21.10.
> > They all use the default kernel and run DNSDist as root.
> > I wonder why this is.
> >
> >
> > My GSoC proposal has not been submitted due to previous exams.
> > I have now submitted a draft, if possible, please suggest some
> > revisions.
> >
> > A copy of the proposal can be accessed from the link below.
> > Comments are welcome.
> >
> > https://docs.google.com/document/d/1_izkQDoEhrv4Ooa4ja4WVUDyLvsNSKE_GgnRUUJPk-g
> 
> It really bothers everyone. Thanks Sukhbir Singh for the reply. Also
> thanks to ottom for helping me a lot at IRC. This problem was solved
> with the help of ottom.
> 
> The reason for the error is that I failed to notice the need to use
> "addCapabilitiesToRetain(capabilities)" to add capabilities, even
> though I run dnsdist with sudo.

Well, almost. addCapabilitiesToRetain() does not add capabilities, it
prevents them to be dropped, as dnsdist does by default.

-Otto
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] dnsdist: use netmaskGroup with DynBlockRules exclude/includeRange

2021-07-27 Thread Otto Moerbeek via dnsdist 
On Tue, Jul 27, 2021 at 01:38:08PM +, dmachard via dnsdist wrote:

> Hi all,
> 
> I am trying to use a netmaskgroup object in my DynBlockRulesGroup object with 
> the function "includeRange"
> as introduced with the version 1.6.0
> 
> My config:
> 
> nmg_internal = newNMG()
> nmg_internal:addMask("10.0.0.0/8")
> 
> local dbr = dynBlockRulesGroup()
> dbr:includeRange(nmg_internal)
> dbr:setQueryRate(30, 10, "Exceeded query rate", 60)
> 
> function maintenance()
>   dbr:apply()
> end
> 
> 
> The error I am getting:
> 
> Fatal Lua error: [string "chunk"]:40: Unable to convert parameter from nil to 
> 12NetmaskGroup
> stack traceback:
> [C]: in function 'NetmaskGroupRule'
> [string "chunk"]:40: in main chunk
> 
> 
> I am using the following version

My guess it's the "local" keyword in global scope, it's semantics are
such that it's not very useful.

-Otto

> 
> # dnsdist --version
> dnsdist 1.6.0 (Lua 5.1.4 [LuaJIT 2.0.4])
> Enabled features: cdb dns-over-tls(gnutls openssl) dns-over-https(DOH) 
> dnscrypt fstrm ipcipher libsodium lmdb protobuf re2 recvmmsg/sendmmsg snmp 
> systemd
> 
> I can't find what I'm doing wrong, do you have any idea?
> 
> denis
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist

___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] Size of time_t error when building dnsdist 1.6.0 on armv7

2021-05-11 Thread Otto Moerbeek via dnsdist 
On Tue, May 11, 2021 at 06:16:05PM +0200, Peter van Dijk via dnsdist wrote:

> Hello Scott,
> 
> On Tue, 2021-05-11 at 10:54 -0400, Scott Colby via dnsdist wrote:
> > The ./configure step exits with an error:
> > configure: error: size of time_t is 4, which is not large enough
> > to fix the y2k38 bug
> > 
> > This does not happen with an identical environment except using
> > dnsdist 1.5.2.
> > 
> > I didn't see a specific mention of this in the change log, so my
> > best guess is this is an artifact of the upgrade to C++17. This
> > could perhaps also be an artifact of building in QEMU; I'm not sure.
> 
> The changelog appears to be entirely empty, in fact - I'm sure we'll
> get that sorted soon. If it was there, it would probably mention this!
> 
> > Does dnsdist >=1.6 no longer support 32-bit systems/systems with
> > 32-bit time_t types?
> 
> Yes. There is some explanation in 
> https://blog.powerdns.com/2021/03/26/upcoming-package-removals/

It is also mentioned in the release announcement.

https://blog.powerdns.com/2021/05/11/dnsdist-1-6-0-released/

-Otto

> 
> Kind regards,
> -- 
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
> 
> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] cache dnsdist not working for my setup

2021-02-10 Thread Otto Moerbeek via dnsdist 
On Wed, Feb 10, 2021 at 07:04:34AM +, SAMI RAHAL via dnsdist wrote:

> Hi
> I proceeded as Markus said the permission problem is solved but the log file 
> is empty and I have the following message when I want to consult the traffic 
> in the console.
> 
> showResponseLatency()
> No traffic yet.
> 
> PS I don't have these problems with version 1.3!

When swicthing versions, it is very important to read the upgrade
guide (and other docs) first. Also read and understand
https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/

Only if you think for yourself first and give complete information to
the list we can maybe help you. At the moment, your messages only
cause noise on the list.

-Otto


> 
> Regards
> 
> 
> De : dnsdist  de la part de 
> dnsdist-requ...@mailman.powerdns.com 
> Envoyé : mardi 9 février 2021 13:00
> À : dnsdist@mailman.powerdns.com
> Objet : dnsdist Digest, Vol 66, Issue 12
> 
> Send dnsdist mailing list submissions to
> dnsdist@mailman.powerdns.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.powerdns.com/mailman/listinfo/dnsdist
> or, via email, send a message with subject or body 'help' to
> dnsdist-requ...@mailman.powerdns.com
> 
> You can reach the person managing the list at
> dnsdist-ow...@mailman.powerdns.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dnsdist digest..."
> 
> 
> Today's Topics:
> 
>1. Re: cache dnsdist not working for my setup (Pieter Lexis)
>2. Re: cache dnsdist not working for my setup (Markus Ehrlicher)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 9 Feb 2021 10:24:42 +0100
> From: Pieter Lexis 
> To: dnsdist@mailman.powerdns.com
> Subject: Re: [dnsdist] cache dnsdist not working for my setup
> Message-ID: <1c384ba0-5146-4f21-bfff-801b4c66e...@powerdns.com>
> Content-Type: text/plain; charset=utf-8
> 
> Hi,
> 
> On 2/9/21 9:41 AM, SAMI RAHAL via dnsdist wrote:
> > I have adjusted access to the console, but now I have a problem with the 
> > dnsdist log file
> >
> > Fatal Lua error: [string "chunk"]:164: Caught exception: Unable to open 
> > file '/var/log/dnsdist.log' for logging: Permission denied
> >
> > ls -l /var/log/
> > -rw---  1 dnsdist dnsdist0 Feb  8 03:21 dnsdist.log
> > -rw---  1 dnsdist dnsdist0 Feb  7 19:59 dnsdist.log-20210208
> >
> >
> > the log files are empty, I didn't have this problem before installing 
> > version 1.5
> 
> dnsdist runs as the dnsdist user. 2 things might be the case
> 
> 1. the /var/lib directory is not accessable to all users
> 2. a protection setting in the systemd service file might prevent thist
> (most likely ProtectSystem=full)
> 
> Have a look at what might be the culprit here.
> 
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
> 
> 
> --
> 
> Message: 2
> Date: Tue, 9 Feb 2021 10:03:41 +
> From: Markus Ehrlicher 
> To: "'dnsdist@mailman.powerdns.com'" 
> Subject: Re: [dnsdist] cache dnsdist not working for my setup
> Message-ID: <7034235e27fa4916b300db5450ab5...@komsa.de>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> I think, I ran into the same problem ob Ubuntu 20.04. My solution was, to 
> create an folder /var/log/dnsdist with write-permission to the _dnsdist-User 
> and configured all logfiles for dnsdist to this location.
> 
> Best regards,
> Markus
> 
> -Urspr?ngliche Nachricht-
> Von: dnsdist  Im Auftrag von Pieter 
> Lexis via dnsdist
> Gesendet: Dienstag, 9. Februar 2021 10:25
> An: dnsdist@mailman.powerdns.com
> Betreff: Re: [dnsdist] cache dnsdist not working for my setup
> 
> Hi,
> 
> On 2/9/21 9:41 AM, SAMI RAHAL via dnsdist wrote:
> > I have adjusted access to the console, but now I have a problem with
> > the dnsdist log file
> >
> > Fatal Lua error: [string "chunk"]:164: Caught exception: Unable to
> > open file '/var/log/dnsdist.log' for logging: Permission denied
> >
> > ls -l /var/log/
> > -rw---  1 dnsdist dnsdist0 Feb  8 03:21 dnsdist.log
> > -rw---  1 dnsdist dnsdist0 Feb  7 19:59 dnsdist.log-20210208
> >
> >
> > the log files are empty, I didn't have this problem before installing
> > version 1.5
> 
> dnsdist runs as the dnsdist user. 2 things might be the case
> 
> 1. the /var/lib directory is not accessable to all users 2. a protection 
> setting in the systemd service file might prevent thist (most likely 
> ProtectSystem=full)
> 
> Have a look at what might be the culprit here.
> 
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com 
> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist
> 
> 
> --
> 
> Subject: Digest Footer
> 
>

Re: [dnsdist] [Pdns-users] Fourth release candidate for dnsdist 1.5.0

2020-07-20 Thread Otto Moerbeek via dnsdist 
On Sun, Jul 19, 2020 at 12:29:05PM +0200, Stephane Bortzmeyer via Pdns-users 
wrote:

> On Tue, Jul 07, 2020 at 04:41:00PM +0200,
>  Remi Gacogne via dnsdist  wrote 
>  a message of 84 lines which said:
> 
> > While we expected the third release candidate for dnsdist 1.5.0 to be
> > the last one, a race condition that could lead to a crash was discovered
> > by Tomas Krizek from CZ.NIC with the DNS Shotgun tool, leading to a new
> > release candidate.
> 
> Does not compile:
> 
>   CXX  doh.o
> doh.cc: In function ‘void doh_dispatch_query(DOHServerConfig*, 
> h2o_handler_t*, h2o_req_t*, std::string&&, const ComboAddress&, const 
> ComboAddress&, std::string&&)’:
> doh.cc:677:24: error: expected primary-expression before ‘=’ token
>   677 | const char * sni = = h2o_socket_get_ssl_server_name(sock);
>   |^
> make[2]: *** [Makefile:1351: doh.o] Error 1
> make[2]: Leaving directory '/home/stephane/DoH/dnsdist/dnsdist-1.5.0-rc4'
> make[1]: *** [Makefile:1478: all-recursive] Error 1
> make[1]: Leaving directory '/home/stephane/DoH/dnsdist/dnsdist-1.5.0-rc4'
> make: *** [Makefile:1109: all] Error 2
> nice make  689.79s user 101.42s system 95% cpu 13:48.71 total
> 
> I had no problem with all the 1.5.0rc* before.
> 
> Arch Linux, x86_64
> 
> % g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib 
> --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info 
> --with-bugurl=https://bugs.archlinux.org/ 
> --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl 
> --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit 
> --enable-cet=auto --enable-checking=release --enable-clocale=gnu 
> --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function 
> --enable-gnu-unique-object --enable-install-libiberty 
> --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin 
> --enable-shared --enable-threads=posix --disable-libssp 
> --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror 
> gdc_include_dir=/usr/include/dlang/gdc
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 10.1.0 (GCC) 

Thanks for the report. It seems an unfortunate typo slipped in. We
need to figure out why this wasn't caught in our QA.

Removing the extra assignment opetor should work. 

Regards, Otto






___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] how to increase connection qlen on DoH listener?

2020-03-30 Thread Otto Moerbeek via dnsdist 
On Mon, Mar 30, 2020 at 08:37:24AM +0200, Otto Moerbeek via dnsdist wrote:

> On Sun, Mar 29, 2020 at 06:20:00PM +, Christoph via dnsdist wrote:
> 
> > Hi,
> > 
> > due to log entries saying:
> > "Listen queue overflow: 193 already in queue awaiting acceptance"
> > we increased
> > kern.ipc.somaxconn to 2048
> > 
> > 
> > after restarting dnsdist we noticed that while nginx takes
> > the new setting into account dnsdist remains at 128:
> > 
> > netstat -Lan
> > Current listen queue sizes (qlen/incqlen/maxqlen)
> > Proto Listen
> > tcp4  0/0/128  <<< dnsdist
> > tcp4  5/0/2048 <<< nginx
> > 
> > 
> > Is there a way to tell dnsdist to increase the connection queue on the
> > DoH listener?
> > 
> > I didn't not see something like that in the documentation:
> > https://dnsdist.org/reference/config.html?highlight=adddohlocal#addDOHLocal
> > 
> > 
> > This is on FreeBSD 12.1 with dnsdist v1.4.0
> > 
> > thanks,
> > Christoph
> > 
> > 
> > refs:
> > 
> > kern.ipc.somaxconn: Maximum listen socket pending connection accept
> > queue size
> > 
> > from FreeBSD netstat(1) manual page:
> > -L  Show the size of the various listen queues.  The first
> > count shows the number of unaccepted connections, the
> > second count shows the amount of unaccepted incomplete
> > connections, and the third count is the maximum number of
> > queued connections.
> > 
> 
> Reading 
> https://www.freebsd.org/doc/en/books/handbook/configtuning-kernel-limits.html
> I would expect that you want to increase kern.ipc.soacceptqueue
> 
>   -Otto
https://docs.freebsd.org/doc/12.1-RELEASE/usr/local/share/doc/freebsd/en/books/handbook/configtuning-kernel-limits.html

confirms that that is very likely the proper sysctl for your version,

-Otto
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] how to increase connection qlen on DoH listener?

2020-03-30 Thread Otto Moerbeek via dnsdist 
On Sun, Mar 29, 2020 at 06:20:00PM +, Christoph via dnsdist wrote:

> Hi,
> 
> due to log entries saying:
> "Listen queue overflow: 193 already in queue awaiting acceptance"
> we increased
> kern.ipc.somaxconn to 2048
> 
> 
> after restarting dnsdist we noticed that while nginx takes
> the new setting into account dnsdist remains at 128:
> 
> netstat -Lan
> Current listen queue sizes (qlen/incqlen/maxqlen)
> Proto Listen
> tcp4  0/0/128  <<< dnsdist
> tcp4  5/0/2048 <<< nginx
> 
> 
> Is there a way to tell dnsdist to increase the connection queue on the
> DoH listener?
> 
> I didn't not see something like that in the documentation:
> https://dnsdist.org/reference/config.html?highlight=adddohlocal#addDOHLocal
> 
> 
> This is on FreeBSD 12.1 with dnsdist v1.4.0
> 
> thanks,
> Christoph
> 
> 
> refs:
> 
> kern.ipc.somaxconn: Maximum listen socket pending connection accept
> queue size
> 
> from FreeBSD netstat(1) manual page:
> -L  Show the size of the various listen queues.  The first
> count shows the number of unaccepted connections, the
> second count shows the amount of unaccepted incomplete
> connections, and the third count is the maximum number of
> queued connections.
> 

Reading 
https://www.freebsd.org/doc/en/books/handbook/configtuning-kernel-limits.html
I would expect that you want to increase kern.ipc.soacceptqueue

-Otto
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Re: [dnsdist] Feature Request?

2019-08-14 Thread Otto Moerbeek 
Hi,

Submitting an issue to https://github.com/PowerDNS/pdns would be a
first step. 

But it does not hurt to discuss the feature here. Maybe there's a
solution to your problem possible without a new feature.

-Otto


On Tue, Aug 13, 2019 at 10:49:59AM -0400, Brian Sullivan wrote:

> Hi,
> 
> I'd like to know where I should submit a feature request and what that
> process might be?
> 
> Thanks,
> brian
> 
> -- 
> 
> 
> 
> Brian M. Sullivan
> Senior Staff Security Intelligence Engineer
> bsulli...@lookout.com |  www.lookout.com

> ___
> dnsdist mailing list
> dnsdist@mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist

___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist