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
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
waclaw66
@waclaw66
@vcunat Zajímavé, člověk se i něco přiučí :)
Petr Špaček
@pspacek
Let's switch back to English so we do not deter other people :-)
waclaw66
@waclaw66
Regarding the topic from yesterday, I have test results, first command nslookup commuting.waclaw.cz returns SERVFAIL, second command nslookup commuting.waclaw.cz 1.1.1.1 NOERROR. Could you check this pcap? Thanks! I will attach it to the Cloudflare issue too.
Vladimír Čunát
@vcunat
Yes, it could give a hint that some of the flags from kresd make a difference in this case, but it's hard to guess. The important information is why the SERVFAIL is happening, and we can't well see that. (There's a fresh RFC that will hopefully help with such cases in future by sending more information.)
If it keeps repeating, I expect they'll look into their logs.
waclaw66
@waclaw66
For me as an amateuer the only difference between those two queries and its packets is different case of letters within domain name. Is it possible to turn this 0x20 feature off, just for a test?
waclaw66
@waclaw66
I found there should be NO_0X20 flag, although I didn't managed to put it together with current settings policy.add(policy.all(policy.FORWARD('1.1.1.1'))) Could you help, please?
Vladimír Čunát
@vcunat
Before this rule you can add policy.add(policy.all(policy.FLAGS({'NO_0X20'}))) but I'm fairly confident that CloudFlare won't have problems with this feature (and case sent to auths should be independent).
waclaw66
@waclaw66
You're right, even SAFEMODE doesn't help too.
waclaw66
@waclaw66
BUT, querying nslookup commuting.waclaw.cz 1.1.1.1 in SAFEMODE doesn't recover following nslookup commuting.waclaw.cz, it still returns SERVFAIL, that's different to not using SAFEMODE. Cloudflare apprently struggles with queries from knot resolver.