Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Vladimír Čunát
@vcunat
Surely some SW does open multiple LMDBs in a single process.
edoo
@ookangzheng
What happend with this domain? http://dnsviz.net/d/oneinstack.com/dnssec/
cuz knot-resolver return SERVFAIL
Vladimír Čunát
@vcunat
It's CNAME in an apex. That's against standards. kresd can deal with it but not when forwarding. (Asking DS oneinstack.com won't provide the necessary proof.)
Jessy
@jvttr_gitlab

Hi, I run knot-resolver on a raspberrypi (v4.2.0). My score about spr is very bad, I checked the entropy and it is up to 2.5k. https://www.dns-oarc.net/oarc/services/dnsentropy

Gui
Number of samples: 47
Unique ports: 47
Range: 33601 - 33790
Modified Standard Deviation: 57
Bits of Randomness: 8 ????

Cli

kdig @localhost +short porttest.dns-oarc.net TXT -d
;; DEBUG: Querying for owner(porttest.dns-oarc.net.), class(1), type(16), server(localhost), port(53), protocol(UDP)
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"x.x.x.x is POOR: 26 queries in 3.8 seconds from 26 ports with std dev 67"
Vladimír Čunát
@vcunat
@jvttr_gitlab: we simply let the kernel choose the ports. I suspect your embedded kernel was simplified in this respect.
Andreas Rammhold
@andir
I've been working on a kresd setup for an upcoming event. I also want to provide DoT and that works great with kresd (4.2.0) and IPv6. Whenever I query via IPv4 I just don't get any response that makes sense (to me). The verbose(true) logs of the server can be seen at https://gist.github.com/andir/1546e4102288cca798a731ed8ea40411 I did run the test using `kdig -4 +tls
google.com A IN @…`. Any idea what we are doing wrong?
Vladimír Čunát
@vcunat
@andir: I didn't look very deep, but I think it's most likely you ran into https://gitlab.labs.nic.cz/knot/knot-resolver/issues/445
(there are work-arounds, too)
Andreas Rammhold
@andir
@vcunat thanks! Will have a look
Andreas Rammhold
@andir
that was it. I read that section in the manual but somehow thought that only happens with ListenStream=[::]:853 and not blanket port statements but as it turns out they are really equivalent (as should have been expected).
Jessy
@jvttr_gitlab

Hi, I would like to undertsand how knot-resolver managed via systemd handle the sockets and if what I found is normal.

correct me if i'm wrong :
kresd.socket and kresd-tls.socket are enabled by default, listening on localhost.
As soon as a packet is received for that socket, a process kresd@1.service is launched.

However, I wonder if is it normal to have port 53 listening by systemd at boot
and as soon as a packet is received for it,
knot-resolver user listen on port 53, with systemd ?

pi@raspberrypi:~ $ sudo lsof -i :53
COMMAND  PID          USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd    1          root   46u  IPv6  10830      0t0  UDP localhost:domain
systemd    1          root   47u  IPv6  10831      0t0  TCP localhost:domain (LISTEN)
systemd    1          root   48u  IPv4  10832      0t0  UDP localhost:domain
systemd    1          root   49u  IPv4  10833      0t0  TCP localhost:domain (LISTEN)

after a query

pi@raspberrypi:~ $ sudo lsof -i :53
COMMAND  PID          USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd    1          root   46u  IPv6  10830      0t0  UDP localhost:domain
systemd    1          root   47u  IPv6  10831      0t0  TCP localhost:domain (LISTEN)
systemd    1          root   48u  IPv4  10832      0t0  UDP localhost:domain
systemd    1          root   49u  IPv4  10833      0t0  TCP localhost:domain (LISTEN)
kresd   3798 knot-resolver    3u  IPv6  10830      0t0  UDP localhost:domain
kresd   3798 knot-resolver    4u  IPv6  10831      0t0  TCP localhost:domain (LISTEN)
kresd   3798 knot-resolver    5u  IPv4  10832      0t0  UDP localhost:domain
kresd   3798 knot-resolver    6u  IPv4  10833      0t0  TCP localhost:domain (LISTEN)
Vladimír Čunát
@vcunat
@jvttr_gitlab: I was wrong. After a few experiments, I think it's correct.
Systemd opens the sockets, and the services get copies of these file-descriptors leading to the same file-descriptions. The fact these are the same is apparently represented by having the same DEVICE number in the output. (I tried to listen on the same address:port thanks to REUSEPORT, i.e. getting FD of a different file-description, and it showed a different number.)
Vladimír Čunát
@vcunat
We tested that port randomization test on Turris (32-bit ARM, modified OpenWRT), and apparently it does not suffer from the same problem.
Jessy
@jvttr_gitlab
Thanks @vcunat
Petr Špaček
@pspacek
@jvttr_gitlab It could also be caused by NAT if there is one.
Jessy
@jvttr_gitlab
@pspacek I was thinking about that, Today I will try from another network.
I have used tcpdump to see the source port used during the test, and compare it with the test result. Surprisingly there is a diff.
Jessy
@jvttr_gitlab
However, I
Sorry, however I tried with unbound, on the same machine, connected to the same network, and I get a GOOD result.
Vladimír Čunát
@vcunat
Right, so most likely it's not about NAT but the kernel.
Jessy
@jvttr_gitlab
@vcunat, Does it mean that the kernel can act differently between knot-resolver and unbound about the source port selection ?
Vladimír Čunát
@vcunat
No, unbound has a different strategy.
I don't know details, but IIRC they allocate a pool of ports and then choose randomly among them.
Jessy
@jvttr_gitlab
ok thank you @vcunat
Jessy
@jvttr_gitlab

@vcunat @pspacek
I have few questions :-)
Question 1 : Regarding kresd via systemd. If I understand well : at boot, systemd listens first, and as soon as it receives a query, sends a copy to kresd. Then, kresd will stay listening.
After that, both systemd and kresd are listening on the same socket. So, I wonder who will handle the queries. Is it like previously, first systemd and copy to kresd. Or only kresd ?

Question 2 : There is a benefit to manage kresd with systemd, instead of running $ sudo kresd ?
Personal DNS resolver usage, at home, on a raspberrypi.

Question 3 : Another question, just by curiosity, is it thanks to SOREUSEPORT that it is possible to share the same socket across multiple instances of kresd ? i.e systemctl enable --now kresd@1.service kresd@2.service kresd@3.service

Vladimír Čunát
@vcunat
  1. systemd copies the file-descriptor. Only kresd really listens to packets.
2. it organizes logs, restarts on abortions, etc. The usual service-management stuff. And it allows you to easily run kresd without elevated privileges/capabilities.
Vladimír Čunát
@vcunat
3.  IIRC systemd doesn't need SO_REUSEPORT for this, as it hands out copies of the file-descriptor pointing to the single file-description that was bound at the start. That has some advantages, but it does not scale that well on Linux with several heavily loaded CPUs (handling the shared file-description).
Jessy
@jvttr_gitlab
thanks a lot @vcunat and your team, very nice job with Knot and Knot-Resolver.
I need a T-Shirt! :-)
Robert Šefr
@robcza

Recently stumbled upon an interesting random subdomain ddos attack pattern:

mx2.mx2.mx2.mx2.mx2.mx2.mx1.mtasts.mx2.mx1.mx1.mx1.mx1.mx2.mx1.webdisk.weaverpublishing.com.
mx2.mx2.mx2.mx2.mx2.mx2.mx1.mx2.mx1.mx2.mx2.mtasts.mx2.mx1.mx2.mx2.mx2.weaverpublishing.com.
mx2.mx2.mx2.mx2.mx2.mx2.mx2.mx1.mx2.mx2.mx1.mtasts.mx1.mx2.mx2.mx1.cpanel.weaverpublishing.com.
mx2.mx2.mx2.mx2.mx2.mx2.mx2.mx1.mx2.mx2.mx1.mtasts.mx1.mx2.mx2.mx1.cpanel.weaverpublishing.com.
mx2.mx2.mx2.mx2.mx2.mx1.mx2.mx2.mx2.mx2.mx2.mx1.mx2.mtasts.mx1.mx2.mx2.autodiscover.weaverpublishing.com.

Do you think that this is actually somehow more troublesome to the Authoritative server? And/or for the resolver (though resolver is not the target of the attack)?
With negative caching and the domain properly signed this will be stop on the resolver anyway, but does it also mean more cpu cycles to make the decision?

And I don't encourage you to visit weaverpublishing[.]com in case you are not a fan of scam iphone contests ;)
Vladimír Čunát
@vcunat
It should take a bit more space on the wire, at the very least. I'm not sure if the string lengths (or label numbers) could make a noticeable difference.
Andreas Rammhold
@andir
The cache_count attribute of the prometheus metrics is supposed to tell me how many entries currently exist in the resolvers cache? Right? It seems to be always zero but looking at it through the control socket shows that cache.current_size is a larger number. Is that bytes vs record count?
Vladimír Čunát
@vcunat
@andir: cache.current_size is the cache size limit in bytes.
cache.count() is the number of entries, roughly the number of RRsets.
Andreas Rammhold
@andir
Ok, so I guessed. So the number of cache entries isn't exported via the prometheus support :/ I'll try to add that as a custom metric in a bit.
Vladimír Čunát
@vcunat
Aah.. right, prometheus shows the output of cache.stats() – showing the counts of low-level operations
... and count in there is the number of cache.count() operations :-)
@andir: I think it will be a one-liner in getstats in prometheus.lua.
Andreas Rammhold
@andir
I think so too. Just have to sit down and do it. :-) (Event is running and there are more pressing issues)
Vladimír Čunát
@vcunat
I opened a ticket with ideas what to improve. Feel free to post other suggestions.
Andreas Rammhold
@andir
Thanks, will do!
Andreas Rammhold
@andir
mhm, I wrote that line now and it works like a charm BUT I was expecting the namespace to be still applied. Knowing that it is just another line that seems to be appended at the end that should have been expected.
Vladimír Čunát
@vcunat
It's the last parameter passed to the merge function that should do the namespacing, on a quick read (it adds a prefix).
Andreas Rammhold
@andir
ok, I'll try to write some feedback for the mentioned issue. In case anyone is curious here are our DNS statistics we are currently collecting: https://dashboard.net.mrmcd.net/d/ELVrZrKZz/dns?orgId=1&from=now-3h&to=now
Vladimír Čunát
@vcunat
I wonder why there are two AA lines in one of the graphs. I looked at my stats.list() at hand and saw nothing wrong about that – just a single answer.aa field.
Andreas Rammhold
@andir
@vcunat: one of them is AD. Was a typo :-)
Ideally all those metrics would be exposed on a common key and just distinguished by different labels (e.g. type=AA)