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
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.
Vladimír Čunát
@vcunat
Maybe some utility like socat could solve this... but I'd expect that just unloading and reloading the module is enough.
Elctro
@Elctro
Thanks
Petr Špaček
@pspacek
Kris von Mach
@krismach_gitlab

I'm having trouble resolving spam.molax.co.kr but it works with 1.1.1.1. Any ideas as to what might be an issue?

kdig spam.molax.co.kr
;; WARNING: response timeout for 127.0.0.1@53(UDP)
;; WARNING: response timeout for 127.0.0.1@53(UDP)

kdig spam.molax.co.kr @193.17.47.1
;; WARNING: response timeout for 193.17.47.1@53(UDP)
;; WARNING: response timeout for 193.17.47.1@53(UDP)

kdig spam.molax.co.kr @1.1.1.1
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 23320
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; spam.molax.co.kr. IN A

;; ANSWER SECTION:
spam.molax.co.kr. 1024 IN A 211.105.253.26

;; Received 50 B
;; Time 2020-11-16 13:23:19 EST
;; From 1.1.1.1@53(UDP) in 2.2 ms

Petr Špaček
@pspacek
Their authoritative servers seem to be broken:
[65536.17][resl]   => id: '26902' querying: '211.105.253.20#00053' score: 10 zone cut: 'molax.co.kr.' qname: 'SPAM.mOLaX.CO.kR.' qtype: 'A' proto: 'udp'
[65536.17][iter]   <= answer received: 
;; ->>HEADER<<- opcode: QUERY; status: FORMERR; id: 26902
;; Flags: qr cd  QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: Unused

;; QUESTION SECTION
spam.molax.co.kr.        A

;; ADDITIONAL SECTION
[65536.17][iter]   <= rcode: FORMERR
Interesting, maybe they just do not support EDNS or something like that.
Petr Špaček
@pspacek
Ah right, dig @211.105.253.20 SPAM.mOLaX.CO.kR. explodes with FORMERR but dig +noedns @211.105.253.20 SPAM.mOLaX.CO.kR. actually works.
Maybe we have a bug in FORMERR fallback when EDNS is not supported. Thank you for reporting this!
@krismach_gitlab As a workaround for now you can put this line into your config file:
policy.add(policy.suffix(policy.FLAGS({'SAFEMODE'}), {todname('spam.molax.co.kr.')}))
Sorry for inconvenience!
Kris von Mach
@krismach_gitlab
thank you for your help @pspacek
mrvne
@mrvne
Hello, is knot-resolver debian repo currently down? Failed to fetch http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_10/InRelease Could not connect to download.opensuse.org:80 (2001:67c:2178:8::13), connection timed out same for IPv4
matrixbot
@matrixbot
tkrizek Seems like it - someone hinted about an outage of Nurnberg openSUSE datacenter in #opensuse-buildservice an hour ago
Vladimír Čunát
@vcunat
I confirm download.opensuse.org appears to be down from my point as well.
matrixbot
@matrixbot
mrvne
@mrvne
sad :/