Re: Sparklight and DNSSEC
Petr Špaček writes: > named.conf statement 'dnssec-enabled yes;' allows forwarding DNSSEC > signatures (and other metadata) without validating them. > > named.conf statement 'dnssec-validation auto;' then enables DNSSEC > validation itself. > > In other words, it is possible to allow DNSSEC to work for forwarders > without doing validation itself. If the ISP in question resists > enabling DNSSEC then at least 'dnssec-enabled yes; dnssec-validation > no;' configuration would improve situation for people who care. Thanks. Did not know this. Sorry for the disinformation. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sparklight and DNSSEC
> Please allow me to correct this: > > named.conf statement 'dnssec-enabled yes;' allows forwarding DNSSEC > signatures (and other metadata) without validating them. Slight problem here: My 9.18.5 named doesn't know about dnssec-enabled: Sep 26 09:00:51 xxx named[38797]: /usr/local/etc/namedb/named.conf:18: unknown option 'dnssec-enabled' A bit of searching makes it look like dnssec-enable is what we want, but: Sep 26 09:08:21 xxx named[38797]: /usr/local/etc/namedb/named.conf:18: option 'dnssec-enable' no longer exists What am I missing here? Steinar Haug, Nethelp consulting, sth...@nethelp.no -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sparklight and DNSSEC
On 26. 09. 22 9:15, sth...@nethelp.no wrote: Please allow me to correct this: named.conf statement 'dnssec-enabled yes;' allows forwarding DNSSEC signatures (and other metadata) without validating them. Slight problem here: My 9.18.5 named doesn't know about dnssec-enabled: Sep 26 09:00:51 xxx named[38797]: /usr/local/etc/namedb/named.conf:18: unknown option 'dnssec-enabled' A bit of searching makes it look like dnssec-enable is what we want, but: Sep 26 09:08:21 xxx named[38797]: /usr/local/etc/namedb/named.conf:18: option 'dnssec-enable' no longer exists What am I missing here? Oh, I'm sorry. I forgot this option was removed and DNSSEC metadata are _always_ passed around in modern versions of BIND. It is that way since 9.16.0, and the option was completely removed in 9.17.0. I think that underlines the point that filtering DNSSEC metadata is a bad idea :-) -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sparklight and DNSSEC
Bjørn Mork skrev den 2022-09-26 08:50: Petr Špaček writes: named.conf statement 'dnssec-enabled yes;' allows forwarding DNSSEC signatures (and other metadata) without validating them. named.conf statement 'dnssec-validation auto;' then enables DNSSEC validation itself. In other words, it is possible to allow DNSSEC to work for forwarders without doing validation itself. If the ISP in question resists enabling DNSSEC then at least 'dnssec-enabled yes; dnssec-validation no;' configuration would improve situation for people who care. Thanks. Did not know this. Sorry for the disinformation. imho dnssec-validation auto; have a bug as it validates domains without DS set hope bind developpers can confirm or deny it dnssec-enabled yes; is depricated in gentoo latest stable version 9.16.30 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sparklight and DNSSEC
> On Sep 24, 2022, at 3:20 AM, Bjørn Mork wrote: > > Philip Prindeville writes: > >> How many ISP's squelch DNSSEC like that? I hope it's not a common practice! > > More common than you'd like to think. See Geoff's excellent world map > at https://stats.labs.apnic.net/dnssec > > Note that no validation implies no signatures for downstream resolvers. > Which makes the non-validating resolvers useless in a forwarder > statements, like you discovered. And useless in many other situations > as well. You can't do DANE for example. > > FWIW, we (as in Telenor Norway) enabled validation in 2015, along with > most of the other major Norwegian ISPs, after being educated with a > sufficiently powerful LART by the local domain registry (NORID). They > invited all the local resolver operators for a workshop in May 2015, > focusing on the importance of validation. This is the primary reason > Norway is green on that map.. > > I must admit I was a bit worried in the beginning. But we've had > surprisingly few problems. And no major issues AFAIR. > > There's really no reason to avoid dnssec-validation in 2022. Just go > poke your ISP if they've disabled it. > > > Bjørn > -- So... was 2019 the year that Netflix had no Norwegian viewers? ;-) Nice job Saudi Arabia, BTW... 2nd highest rank after SJ which doesn't really count. -Philip -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Mailing list questions (DMARC, ARC, more?)
On Sat 24/Sep/2022 00:23:03 +0200 Matus UHLAR - fantomas wrote: another test done Thanks for reporting. This is slightly OT, as it concerns the list functioning rather than DNS. I hope it doesn't afflict... I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. On 25.08.22 18:10, Alessandro Vesely wrote: Please tell us. On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote: so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" On 04.09.22 12:56, Alessandro Vesely wrote: They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid. I haven't studied the ARC standard, but this looks correct. However, I was repeatedly unable to make opendmarc to accept arc result: Authentication-Results: fantomas.fantomas.sk; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: fantomas.fantomas.sk; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=itqgpF3K; dkim-atps=neutral IMHO, it is correct to say dkim=fail, but DMARC should have been redeemed by ARC if trusted. Authentication-Results: [...] Authentication-Results: fantomas.fantomas.sk; arc=pass smtp.remote-ip=149.20.1.60 arc.chain="isc.org:isc.org:isc.org" That arc=pass doesn't say if it was trusted or not. As you say, trust doesn't seem to make any difference. Paradoxical. From: frank picabia Gmail has p=none. However, I tried to send to this list an unauthenticated message from a domain with p=reject and spf-all. It was rejected by: 550 5.7.1 Blocked by SpamAssassin That looks like accumulating a score, not a formal rejection after policy requirements. - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) I have tried both, no result. There is a school of thought according to which receivers should blindly trust ARC headers, except spam or known bad actors. When enabled, arc=pass should override dmarc=fail p=reject. We never get this, because bind-users rewrite From: if author's domain has p=reject. This should not be a problem, since we should trust isc.org servers when they provide wortking ARC-Seal: Yes, but we still receive munged From:'s. The idea was that with ARC they could be avoided. The way to do it is the 1st method in my draft[*], but I cannot find a list willing to experiment. Trusting isc.org should suffice. Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them. do you mean, I should trust all domains in ARC-Seal, listed in Authentication-Results header? RFC8617 talks about "sealing domain" of a given ARC set, surmising that the d= tag should have the same value in ARC-Seal and ARC-Message-Signature. - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) I tried the Perl ARC verifier included in Mail::DKIM. On your message it outputs: ale@pcale:~/tmp$ arc-verify.pl < arc1.eml this is not in debian distribution. when tried it, it shows correct: uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arc1.eml RESULT: pass uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arctest RESULT: pass however, I was unable to make my dkim/dmarc PASS on a mail from this list that was: - arc-signed by ISC - DKIM fail (not munged) The header is ok, but the body has an added footer. Using zdkimfilter (3rd method in that draft[*]) I get the following on your message: INFO: zfilter: zdkimfilter[13097]:ip=NULL: domain isc.org whitelisted by list.dnswl.org DEBUG: zfilter: zdkimfilter[13097]:ip=NULL: retrieved fantomas.sk->fantomas: rsa-sha256, 2048 bits INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling body parse (sigs pass: 1, could pass: 0) INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling retry (badsig, bh ok: 0; badsig, bh bad: 0; pass, bh bad: 1) INFO: zfilter: zdkimfilter[13097]:ip=NULL: transformation enabled for "Matus UHLAR - fantomas " retry body only INFO: zfilter: zdkimfilter[13097]:ip=NULL: transform message from base64 back to identity with footer. INFO: zfilter: zdkimfilter[13097]:ip=NULL: sig failure d=fantomas.sk, s=fantomas: body hash mismatch INFO: zfilter: zdkimfilter[1309
Re: Sparklight and DNSSEC
On 27/09/2022 3:58 am, Benny Pedersen wrote: imho dnssec-validation auto; have a bug as it validates domains without DS set hope bind developpers can confirm or deny it Hi Benny. Until DS records are published in the parent zone, the (signed) zone is considered 'insecure', and validation doesn't occur. i.e. The behaviour you described above is how it is supposed to work. Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sparklight and DNSSEC
Nick Tait via bind-users skrev den 2022-09-26 23:50: On 27/09/2022 3:58 am, Benny Pedersen wrote: imho dnssec-validation auto; have a bug as it validates domains without DS set hope bind developpers can confirm or deny it Hi Benny. Until DS records are published in the parent zone, the (signed) zone is considered 'insecure', and validation doesn't occur. i.e. The behaviour you described above is how it is supposed to work. +1 https://gitlab.isc.org/isc-projects/bind9/-/issues/3465 https://www.irccloud.com/pastebin/YlJORfJK/delv%20plex.tv%20and%20later%20logs just an example log https://bugs.gentoo.org/872449 dont know if that will solve it or not on some domains its possible to just do "rndc nta domain" to solve it shurtly, as some domains cant be sent email to before its nta listed :/ Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sparklight and DNSSEC
> On 27 Sep 2022, at 00:58, Benny Pedersen wrote: > > Bjørn Mork skrev den 2022-09-26 08:50: >> Petr Špaček writes: >>> named.conf statement 'dnssec-enabled yes;' allows forwarding DNSSEC >>> signatures (and other metadata) without validating them. >>> named.conf statement 'dnssec-validation auto;' then enables DNSSEC >>> validation itself. >>> In other words, it is possible to allow DNSSEC to work for forwarders >>> without doing validation itself. If the ISP in question resists >>> enabling DNSSEC then at least 'dnssec-enabled yes; dnssec-validation >>> no;' configuration would improve situation for people who care. >> Thanks. Did not know this. Sorry for the disinformation. > > imho dnssec-validation auto; have a bug as it validates domains without DS > set Ever answer is supposed to be validated. This is what is REQUIRED by DNSSEC. The result of that validation can be insecure, valid, or bogus. The presence or absence of DS at the delegation tells the validator or a answers from a zone should be signed or not and if they are signed what DNSSEC algorithms are present. It is a myth that zones without DNSSEC are not validated. > hope bind developpers can confirm or deny it > > dnssec-enabled yes; is depricated in gentoo latest stable version 9.16.30 > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
