Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Adam
@Ahuren_gitlab
thanks for the input. that looks like a great starting point. once I know how the function can operation, I can hack away to writing to a file. ill test this :)
Adam
@Ahuren_gitlab
@vcunat the frequent function does not list TLD part of query yes?
Vladimír Čunát
@vcunat
item.name in there is the whole name, e.g. github.com. (as lua string)
git-ed
@ookangzheng
on Debian 10 64bit, I do apt update and apt upgrade got this error
Get:1 http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_10  lua-cqueues 20190813-1 [192 kB]
Err:1 http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_10  lua-cqueues 20190813-1
  File has unexpected size (192160 != 191928). Mirror sync in progress? [IP: 130.57.72.10 80]
  Hashes of expected file:
   - SHA256:902d332c7f7b9d8ece5610a4af6aa543fc8140b7e6423f563481c6214f1b1580
   - SHA1:c162b1633f56982069ebd9e517ea503b6986c743 [weak]
   - MD5Sum:e0b0aebb49604dbe4c419effa4a83cfe [weak]
   - Filesize:191928 [weak]
E: Failed to fetch http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_10/./amd64/lua-cqueues_20190813-1_amd64.deb  File has unexpected size (192160 != 191928). Mirror sync in progress? [IP: 130.57.72.10 80]

E: Failed to fetch http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_10/./amd64/lua-cqueues_20190813-1_amd64.deb  File has unexpected size (192160 != 191928). Mirror sync in progress? [IP: 130.57.72.10 80]
   Hashes of expected file:
    - SHA256:902d332c7f7b9d8ece5610a4af6aa543fc8140b7e6423f563481c6214f1b1580
    - SHA1:c162b1633f56982069ebd9e517ea503b6986c743 [weak]
    - MD5Sum:e0b0aebb49604dbe4c419effa4a83cfe [weak]
    - Filesize:191928 [weak]
Adam
@Ahuren_gitlab
@ookangzheng try this steps from documentation: https://knot-resolver.readthedocs.io/en/stable/quickstart-install.html
Vladimír Čunát
@vcunat
I expect it's "Mirror sync in progress?" and will go away soon.
matrixbot
@matrixbot
tkrizek I don't have any such issue on Debian 10, but I might be hitting different mirrors. In any case, it's probably a transient issue with some mirror of Open Build Service
matrixbot
@matrixbot
tkrizek Confirmed - OBS got a big rollback and now it has old packages in the repositories. Folks from #opensuse-buildservice IRC said it should be fixed in a few hours.
Adam
@Ahuren_gitlab

Well, stats.frequent() is "suitable" in the sense that you can program your own logging (or anything) based on it, e.g. this demo (loaded as config):

modules.load('stats')

function log_frequent()
    local f = stats.frequent()
    log("%d elements", #f)
    stats.clear_frequent()
    table.sort(f, function (a, b) return a.count > b.count end)
    for _, item in ipairs(f) do
        log("%s %s", item.name, item.type)
    end
end

event.recurrent(10*min, log_frequent)

@vcunat This is working great along with file write capability. Question: since this is giving me the frequent list of domains per given interval, how can i get hit count for those domains that get listed.? I tried with item.count, item.name but it simply displays all counts instead of frequency. any idea?

Robert Šefr
@robcza

can I somehow remove the .local from special names in policies? https://github.com/CZ-NIC/knot-resolver/blob/eb2b03df5d63c7141bda461c7a5ac7eabb8c630b/modules/policy/policy.lua#L923

I don't want to unload the whole policy module and I have to apply view:addr rules on the .local. That seems impossible in case the policy rule kicks in first and triggers the non-chain action.

Vladimír Čunát
@vcunat
Unless you want to change the order of policy and view modules, I believe you can use a policy.PASS action (within policy rules) to skip over other processing by that module.
@robcza ^^
Robert Šefr
@robcza
@vcunat in case I apply pass to policy will the view:addr be still applied?
Vladimír Čunát
@vcunat
Yes, I believe so. And it's also a confusing aspect. Overall, policy-like config and local data are scattered among multiple modules, and they don't really interact ideally with each other. That's why we're working on a new overall design, making a survey, etc.
Robert Šefr
@robcza
Thanks, will test it out. Survey already sent! :)
@vcunat it works! the view:addr is processed even though I break the chain in policy. Thank you
Georg
@teadur
vcunat: "How frequently do you need to modify configuration? " by that you mean actual configration not zone right ?
matrixbot
@matrixbot
tkrizek Either configuration or something like RPZ updates (for blocklist)
Vladimír Čunát
@vcunat
I'm not sure what other zones you have in a resolver, but I would most likely also count them like RPZ (say, if you serve them authoritatively from the resolver).
Georg
@teadur
k
Kris von Mach
@krismach_gitlab

I'm having an issue looking up certain .mil MX records. I would get SERVFAIL. However looking them up through other resolvers works. And also if I do a NS lookup before MX lookup, then it works too. For example:

kdig us.af.mil @127.0.0.1 MX
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 7115
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; us.af.mil. IN MX

;; Received 27 B
;; Time 2020-06-25 23:32:07 EDT
;; From 127.0.0.1@53(UDP) in 126.0 ms

kdig us.af.mil @127.0.0.1 NS
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 63682
;; Flags: qr rd ra; QUERY: 1; ANSWER: 6; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; us.af.mil. IN NS

;; ANSWER SECTION:
us.af.mil. 5 IN NS osan-ns10.afnoc.af.mil.
us.af.mil. 5 IN NS scott-ns10.afnoc.af.mil.
us.af.mil. 5 IN NS wpafb-ns10.afnoc.af.mil.
us.af.mil. 5 IN NS hickam-ns10.afnoc.af.mil.
us.af.mil. 5 IN NS langley-ns10.afnoc.af.mil.
us.af.mil. 5 IN NS peterson-ns10.afnoc.af.mil.

;; Received 188 B
;; Time 2020-06-25 23:32:09 EDT
;; From 127.0.0.1@53(UDP) in 156.9 ms

kdig us.af.mil @127.0.0.1 MX
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 55917
;; Flags: qr rd ra; QUERY: 1; ANSWER: 11; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; us.af.mil. IN MX

;; ANSWER SECTION:
us.af.mil. 39 IN MX 10 pri-usaf-eemsg.eemsg.mail.mil.
us.af.mil. 39 IN MX 20 scott-mail4.afnoc.af.mil.
us.af.mil. 39 IN MX 20 scott-mail5.afnoc.af.mil.
us.af.mil. 39 IN MX 20 scott-mail6.afnoc.af.mil.
us.af.mil. 39 IN MX 20 scott-mail7.afnoc.af.mil.
us.af.mil. 39 IN MX 20 scott-mail8.afnoc.af.mil.
us.af.mil. 39 IN MX 20 wpafb-mail4.afnoc.af.mil.
us.af.mil. 39 IN MX 20 wpafb-mail5.afnoc.af.mil.
us.af.mil. 39 IN MX 20 wpafb-mail6.afnoc.af.mil.
us.af.mil. 39 IN MX 20 wpafb-mail7.afnoc.af.mil.
us.af.mil. 39 IN MX 20 wpafb-mail8.afnoc.af.mil.

;; Received 358 B
;; Time 2020-06-25 23:32:12 EDT
;; From 127.0.0.1@53(UDP) in 47.7 ms

Kris von Mach
@krismach_gitlab
This is default install of Knot Resolver 5.1.1 from opensuse depo on latest debian
Vladimír Čunát
@vcunat
Thanks, that seems to be a bug on our side.
Vladimír Čunát
@vcunat
@krismach_gitlab: I'm sorry, this bug won't be solved in this week's release. I'm tracking it in this issue. I posted two possible work-arounds there, too.
Kris von Mach
@krismach_gitlab
@vcunat: Thank you, I'll use the workaround for now
waclaw66
@waclaw66
Ahoj. Mám problém s Knot Resolverem 5.1.1 na FC32, nepřekládá některé wilcard subdomény (CNAME) třetího řádu pokud se použije resolver od Cloudflare, vrací SERVFAIL. Ostatní resolvery fungují bez problému, nezdá se mi, že by to bylo nastavením doménového záznamu. https://pastebin.com/qxGCCdWc Předem díky za pomoc!
Vladimír Čunát
@vcunat

@waclaw66: řádka

kresd[1985961]: [64036.16][iter]   <= rcode: SERVFAIL

říká že SERVFAIL přišel od 1.1.1.1.

waclaw66
@waclaw66
@vcunat příkaz nslookup sub.domena.com 1.1.1.1 ale vždy vrací adresu správně :/
Vladimír Čunát
@vcunat
Mně se to neděje vůbec.
waclaw66
@waclaw66
jde ještě nějak jinak ověřit, že problém není v kresd ale u Cloudflare?
Vladimír Čunát
@vcunat
Provoz z kresd k 1.1.1.1 lze zachytit přes tcpdump/wireshark.
waclaw66
@waclaw66
hláška range search found stale or insecure entry se mi moc nezdá
Vladimír Čunát
@vcunat
To je normální stav.
Ne vždy se v cachi najde vhodný záznam.
waclaw66
@waclaw66
ještě můžu zkusit nahodit bind se stejnou konfigurací, mělo by se to tedy chovat stejně, wireshark je na mě už moc
Vladimír Čunát
@vcunat
Nebo tak. Potvrzené chyby v 1.1.1.1 pak hlásím na jejich fóru, třeba https://community.cloudflare.com/t/incomplete-nxdomain-proofs-with-qtype-ds/183499 (ale mně se tohleto neděje)
waclaw66
@waclaw66
Bind překládá správně :/ je tedy bez TLS
waclaw66
@waclaw66
Nahodil jsem zpět kresd a teď vrací IP v pořádku, že by opravdu nějaké problémy u Cloudflare. Je mi divný, že to dělala jen ta zmíněná doména
waclaw66
@waclaw66
Zatím díky, budu to nějakou dobu sledovat, jestli z toho nevyplyne nějaká souvislost.
waclaw66
@waclaw66
Ke včerejšímu problému, situce v síti... server/router s FC32 + knot resolver Cloudflare vraci opakovane po vyprseni TTL SERVFAIL, klient s Win10 DNS primo na Cloudflare po vyprseni TTL vrati spravnou adresu a pote zacne i na serveru vracet Cloudflare NOERROR. Oba stroje za NATem se stejnou IP, jediny rozdil je klient kresd/win10. Bind na serveru taky bez problemu. Nerozumim tomu. Tohodle chovani sem si zacal vsimat az po upgradu na 5.1.1, ale nemusi to s tim souviset.
Petr Špaček
@pspacek
To zní jako nějaký problém se stavem cache u Cloudflare, ale těžko říct bez dalších podrobností.
Nejlepší by bylo nastavit proměnnou SSLKEYLOGFILE podle https://gnutls.org/manual/html_node/Debugging-and-auditing.html aby ji viděl kresd, logovat provoz směrem k 1.1.1.1 do PCAPu a pak nám to celé poslat, abysme se mohli podívat.
waclaw66
@waclaw66
Vypnul jsem u knotu jeste TLS, aby byly podminky DNS klientu uplne stejne. Pak by, predpokladam, SSLKEYLOGFILE nebylo treba?
Vladimír Čunát
@vcunat
Přesně tak.
waclaw66
@waclaw66
Na jakou adresu mohu ten pcap poslat? Nechci ho tu davat verejne. pcapng nebo jen pcap?
Petr Špaček
@pspacek
Pokud vám máme pomoci tak to bude potřeba postnout někde veřejně: Pravidla jsou zde https://www.knot-resolver.cz/support/free/
waclaw66
@waclaw66
Rozumím, tady to je... https://cloud.waclaw.cz/index.php/s/DWYkHyq2mGpjEie Díky! Snad to k něčemu bude.
Vladimír Čunát
@vcunat
@waclaw66: jednoznačně mi to přijde na chybu u nich, otevřel jsem vlákno.
waclaw66
@waclaw66
@vcunat Diky, ja bych nevedel co reklamovat :) Prekvapily me i ty rozhazeny velikosti pismen v domene, to je normalni?
Vladimír Čunát
@vcunat
Ano, alespoň u nás. Jinde to asi není častý default. Detaily: https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20