Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Robert Šefr
@robcza

(kresd 5.1.3) We are using the configuration line in cases where we want to bind to all available IP addresses and it works very well:
for name, iface in pairs(net.interfaces()) do pcall(net.listen, {iface['addr'], 53 }) end

Usually the port binding is immediate, but on a particular instance we see a huge delay. It takes almost a minute before the kresd process(es) binds to the ports (as observed through netstat)
Does anyone have an idea what could be the root cause for such a behavior?

Vladimír Čunát
@vcunat
@robcza: and in the meantime those kresd processes still won't answer anything?
Robert Šefr
@robcza
@vcunat no, they basically don't even log anything - there is silence for about 40-50s and then everything just goes through, it binds to the ports and starts working as usual
Vladimír Čunát
@vcunat
Right, apparently some operation that blocks for longer time gets executed.
Maybe it will be easiest to debug by sending some signal that will cause a coredump. Then we can have a look at backtrace from time when it's stuck and hopefully determine the probably cause more easily.
sudo pkill -SIGABRT kresd perhaps
Robert Šefr
@robcza
sounds good, will try
Vladimír Čunát
@vcunat
Though I don't know what your coredump settings are. Standard coredumctl setup makes this rather easy.
Robert Šefr
@robcza
Vladimír Čunát
@vcunat
Yes, the open() syscall on data.mdb, apparently.
I can't see a reason why it might take such a long time.
Robert Šefr
@robcza
Thanks a lot. Will investigate, will be something specific to that environment. In case we find something helpful, will report back
Robert Šefr
@robcza
it seems like the ramdisk is not a ramdisk actually and the cache is set to more than 3GB - in total it takes a lot of time to allocate the mdb file
Vladimír Čunát
@vcunat
In recent versions we use posix_fallocate() to force allocation of the space. For example, in case of tmpfs that means those 3G will always "exist as reserved", either in RAM or in swap.
(Otherwise out-of-space could happen in really irrecoverable moments.)
Andreas Oberritter
@mtdcr
Hi! I'm running knot-resolver 5.1.3 and I just stumbled upon a problem. I have a host called "cloud", which has an IPv4 entry in a file loaded with hints.add_hosts(). Apparently, also a TLD called "cloud" exists, and with my entry in the hosts file DNSSEC verification fails for all .cloud domains.
Is this something I should expect? With the recent flood of gTLDs, this may become a frequent issue, I guess.
Vladimír Čunát
@vcunat
Yes, that's why you should be careful with squatting on namespace which belongs to someone else. Especially the "very nice" names are prone to collisions.
In your case you can probably avoid the worst by adding a simple config line
hints.use_nodata(false)
But I'd rather recommend to change the naming.
Andreas Oberritter
@mtdcr
Alright, thanks! I guess I'll remove plain host names from the file. It was just an old habit. Maybe it would be good to show a warning if somebody accidentally overrides a known TLD.
beckhamaaa
@beckhamaaa_gitlab
there are the DGA(Domain Generation Algorithm)or C& C filtered modules in the kresd?
@vcunat
Vladimír Čunát
@vcunat

No. There's nothing really specific for fighting malware.

By the way, I believe that names generated by modern DGAs are not recognizable (without knowledge of their private crypto-secret), so there's no simple way of fighting these... it's more of a research topic.

beckhamaaa
@beckhamaaa_gitlab
ok, thanks a lot !
waclaw66
@waclaw66
Zdravim, rad bych se zeptal cim muze byt zpusobena hlaska kresd[14932]: DNSSEC validation failure fedoraproject.org. DNSKEY kresd-5.1.3, zacalo to delat po upgradu na Fedoru 33 u spousty domen. nslookup fedoraproject.org vraci SERVFAIL, pri dotazu primo na 1.1.1.1 nebo jakoukoliv jinou adresu vrati uspesne adresy
Vladimír Čunát
@vcunat
F33 zapnula systemd-resolved, tak s tím to možná souvisí? Celkově tohle moc neříká, takže bych to viděl na verbose logy, nejjednodušeji dočasně zapnout pomocí verbose(true) v konfiguraci.
waclaw66
@waclaw66
systemd-resolved jsem vypnul, verbose zapnul, odtamtud je ta hlaska, mam podezreni, ze to muze souviset s SSL, vyskakujou na me ruzny SSL chyby i pri dnf update
Vladimír Čunát
@vcunat
A systémový čas je správný?
(rozbil by jak TLS/SSL tak DNSSEC)
waclaw66
@waclaw66
cas je ok, ani curl nestahne zadne https url, vypada, ze upgrade Fedory udelal neco s ulozistem certifikatu... curl: (60) SSL certificate problem: unable to get local issuer certificate
waclaw66
@waclaw66
ne, tak v certifikatech problem neni, ty potize zpusobovaly nedostupne domenove nazvy, zkusil jsem nahodit systemd-resolved a s tim vse funguje, takze to spis vypada na knot-resolver, tady je log... https://pastebin.com/wP3GDwTr, jako workaround pomuze vypnout DNSSEC trust_anchors.remove('.')
Vladimír Čunát
@vcunat
OK, díky, myslím že vím o čem to bude. Prozkoumám(e). Asi jsem při testování vlivu těch jejich novinek něco přehlídl. (blokování zastaralých crypto-algoritmů v F33)
waclaw66
@waclaw66
Taky diky!
Vladimír Čunát
@vcunat
Jo, potvrzeno.
waclaw66
@waclaw66
Jeste co to znamena pro uzivatele knot-resolver? Pockat na novou verzi? Nebo musi neco opravit Fedora?
Vladimír Čunát
@vcunat
Vyhození alespoň některých řádek z /etc/crypto-policies/back-ends/gnutls.config by to snadno vyřešilo, ale nevím jak těžké je bude přesvědčit. A zatím nevidím jiný způsob.
Budeme hledat řešení.
waclaw66
@waclaw66
Ok, diky za podporu.
Vladimír Čunát
@vcunat
waclaw66
@waclaw66
@vcunat Ano, vypada to na SHA1. Dalsi mozny workaround, ktery jsem zkusil, je nastaveni crypto-policies na LEGACY, ale to je spis nouzove reseni. Jsem zvedav, co dalsiho s tim Fedora 33 "rozbila".
Ed
@ookangzheng
Can I do fork 2 in the future?
   Main PID: 1419726 (kresd)
      Tasks: 2 (limit: 2295)
     Memory: 161.1M
     CGroup: /system.slice/knot-tls.service
             ├─1419726 /usr/sbin/kresd -c /etc/knot-resolver/kresd-tls.conf -f 2
             └─1419728 /usr/sbin/kresd -c /etc/knot-resolver/kresd-tls.conf -f 2

Oct 29 20:52:03 fin1 systemd[1]: Starting Knot-tls...
Oct 29 20:52:03 fin1 kresd[1419726]: deprecation WARNING: support for running multiple --forks will be removed
Petr Špaček
@pspacek
You can get better results using multiple instances, please read https://knot-resolver.readthedocs.io/en/v5.1.3/systemd-multiinst.html
6 replies
Petr Špaček
@pspacek
matrixbot
@matrixbot
tkrizek Ed (Gitter): how did you set up the OBS repo in your system? Installing our knot-resolver-release package from https://www.knot-resolver.cz/download/ should work just fine, unless your system is in some weird state (possibly caused by prior attempts to add the repo/key)
Robert Šefr
@robcza

I'm getting these warnings on resolver restarts:

[cache] detected size change (by another instance?) of file '/var/lib/kres/cache/data.mdb': file size 10485760 -> file size 1017118720

Cache size is set (done only by one of the processes) in the configuration file like this:

cache.size = os.getenv('970') * MB

Is this something to worry about?

Martin Weinelt
@mweinelt
please disregard the above, reposting to knot :)
Petr Špaček
@pspacek

@robcza Can you clarify

Cache size is set (done only by one of the processes) in the configuration file

? How many instances do you have, how differs configuration file between them etc.?

Vladimír Čunát
@vcunat
Changing cache size from a different process shouldn't be a problem, though the line perhaps hints at something unexpected happening.
Elctro
@Elctro
Hello. I am having difficulties with dnstap module, specifically with grpc endpoint, which requires "The unix socket and the socket reader must be present before starting resolver instances.". When my socket reader crashes and is restarted, it no longer receives data. Do you have any recommendation how to approach this problem? I'd like to avoid resolver restarts.