Re: One more test -- sorry for the noise

2022-01-25 Thread Benny Pedersen 

On 2022-01-25 20:26, Dan Mahoney wrote:

Sorry for the noise, attempting to validate a DKIM issue


Authentication-Results: lists.isc.org;
	dkim=fail reason="signature verification failed" (2048-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=E7VfrLLS


unprotected means opendkim would like to see dnssec in verify :=)

basicly its possible forged dns here

i noted i get spf-helo-pass, spf-pass, dkim-pass, dmarc-pass before 
mailman screwed it all up in return, when dmarc policy is not reject, 
why is chaning from: header still done ?


mailman is worst case of fixing break of dkim ever writed, route to 
solve is


before mailman see any massage, make the ARC-seal, and ARC-sign, later 
when mailman comes to breaking dkim it does not matter becourse dkim 
from the origin poster can still be untrusted or trusted in opendmarc 
when opendmarc verify arc chains, still have to see spamassassin 4 here, 
so far only rspamd verifi it all, but there is perl software that does 
aswell


hope this can close this maillist breaks dkim, its not correct, i bet 
postfix maillist and dovecot does not

___
Please 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: test - ignore

2022-01-25 Thread Dan Mahoney 


> On Jan 25, 2022, at 8:50 AM, Benny Pedersen  wrote:
> 
> On 2022-01-25 17:45, Greg Choules wrote:
>> Hello.
> 
> Authentication-Results: lists.isc.org;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
>   dkim=fail reason="signature verification failed" (1024-bit key; 
> unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z
> 
> dont know why it failed

I may as well answer this since other people chimed in on the test message.  
I'm Dan Mahoney, ISC's sysadmin who runs most of our mail systems, and, 
coincidentally, also do some work with the Trusted Domain Project on opendkim 
and opendmarc.

The headers you cite are lying to you.  :) The message passed DKIM on the way 
IN to lists.isc.org  (the dedicated vm that runs our 
lists), but then, when the message got to the mailman python scripts and then 
shot back out via the MTA, they had an altered body and no longer passed, and 
the header was rewritten to say "fail".  (This is visible from the logging on 
the servers, but nowhere else).

The solution here, is that lists.isc.org  should only be 
running in "signer" mode, and not verifying anything (we verify messages on our 
MXes, and make the decisions there to reject if dmarc says to do so).  The only 
things that lists.isc.org  will sign are things that it 
generates itself (i.e. things from the lists.isc.org  
domain).

> 
> will my dkim fail aswell ?

Re: DKIM failure, both SPF and DKIM is well known to be broken by mailing 
lists.  So if you're running a dmarc-enforced domain with a policy of P=reject, 
it's possible that mail you send via a list will be rejected.

Altering the body or headers at all (whch lists do) will often break the 
hashing.  For this reason, most recent versions of mailman have an option to 
rewrite your mail from:

From: "Benny Pedersen" http://example.com/>>

...to...

From: "Benny Pedersen via bind-users" http://lists.isc.org/>>
Reply-To: "Benny Pederson" http://example.com/>>
Cc: bind-users@lists.isc.org 

...but only in the event you have a restrictive DMARC policy.  I've argued that 
it should be possible to do so for *any* dmarc policy, even p=none, but that 
option is not present in mailman 3, at least.

Here at ISC, we have a little bit of a cheat -- messages *we* send to 
bind-users will pass SPF, because lists.isc.org  is in 
our SPF list.

The upcoming "better" solution for this is ARC: basically a way for 
lists.isc.org  to assert "This thing passed muster when 
it entered our borders, trust us".

-Dan Mahoney

> ___
> Please 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



signature.asc
Description: Message signed with OpenPGP
___
Please 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

One more test -- sorry for the noise

2022-01-25 Thread Dan Mahoney 
Sorry for the noise, attempting to validate a DKIM issue
___
Please 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

test -- please ignore

2022-01-25 Thread Dan Mahoney 
testing, please ignore
___
Please 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: test - ignore

2022-01-25 Thread Eduard via bind-users 
Try using a larger key, at least 2048 bits.

Check all your DNS entries and make sure everything matches correctly, MX, A, 
reverse, etc.

Check to see if your hostname used in the HELO/ELHO process matches what is in 
DNS.

Regards,
 
Eduard Tieseler
Network Operations Director
4050 Truxel Road Suite A
Sacramento, CA 95834
Office  916-922-7584 ext. 288
Fax 916-922-1835
etiese...@metrolist.net
 
   

 
Please consider the environment before printing this e-mail
THE INFORMATION CONTAINED IN THIS ELECTRONIC MESSAGE IS CONFIDENTIAL. THE 
INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT 
IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, ANY USE, DISSEMINATION, OR 
DISTRIBUTION OF THIS COMMUNICATION IS PROHIBITED. IF YOU HAVE RECEIVED THIS 
ELECTRONIC MESSAGE IN ERROR, PLEASE NOTIFY US IMMEDIATELY AND DELETE THE 
MESSAGE. ANY USE, MODIFICATION, OR REPUBLICATION OF THIS COMMUNICATION, 
INCLUDING ANY ATTACHED FILES, DOCUMENTS, DATA OR OTHER INFORMATION WHICH HAS 
NOT BEEN EXPRESSLY AUTHORIZED BY US IS PROHIBITED. WE SPECIFICALLY DISCLAIM 
RESPONSIBILITY FOR ANY UNAUTHORIZED USE OF THIS COMMUNICATION OR ANY 
ATTACHMENTS TO IT.

On 1/25/22, 8:51 AM, "bind-users on behalf of Benny Pedersen" 
 wrote:

On 2022-01-25 17:45, Greg Choules wrote:
> Hello.

Authentication-Results: lists.isc.org;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z

dont know why it failed

will my dkim fail aswell ?
___
Please 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



___
Please 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: test - ignore

2022-01-25 Thread Benny Pedersen 

On 2022-01-25 17:45, Greg Choules wrote:

Hello.


Authentication-Results: lists.isc.org;
	dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5;
	dkim=fail reason="signature verification failed" (1024-bit key; 
unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z


dont know why it failed

will my dkim fail aswell ?
___
Please 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

test - ignore

2022-01-25 Thread Greg Choules 
Hello.
___
Please 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: CDS records created from ZSK records?

2022-01-25 Thread Mark Elkins 

Found it my problem.

I used to create the CDS records using a binary that has now been 
withdrawn by ISC (around November/December 2021) and now use...


dnssec-dsfromkey -C $key

...except I was running that on all keys - including ZSK's...

I have a bash shell script that does the signing. First written in 2011.
Yes - I am testing with "dnssec-policy"...

---

dnssec-policy "posix-ecdsa256-policy" {
    dnskey-ttl 3600;
    keys {
    ksk lifetime unlimited algorithm ecdsa256;
    zsk lifetime 34d algorithm ecdsa256;
    };
};

zone "smtp.co.za" {
    type master;
    file "/etc/ns.d/pri/smtp.co.za/db.smtp.co.za";
    key-directory "/etc/ns.d/pri/smtp.co.za/keys";
    dnssec-policy "posix-ecdsa256-policy";
    serial-update-method date;
};
---

... but until there is a trigger system so I can call code to do an EPP 
based KSK rollover to the parent, will keep what I've got as it 
(usually) works.


On 1/25/22 12:58 AM, Mark Andrews wrote:



On 25 Jan 2022, at 07:35, Mark Elkins  wrote:

I've just noticed that in the last few days that "BIND 9.16.22 (Extended Support Version) 
" appears to be generating CDS records for both KSK ***and ZSK*** 
records!

Nothing on my side has been changed although I do run automated updates. I'm on 
a Linux machine running Gentoo.

$ dig DNSKEY EDU.ZA

; <<>> DiG 9.16.6 <<>> DNSKEY EDU.ZA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22867
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;EDU.ZA.INDNSKEY

;; ANSWER SECTION:
EDU.ZA.9378INDNSKEY256 3 13 
U9/K052f1oBX5WYbedZhLM0jd+rNAwEYNfuRUAsf2S3U7UNaEKV2pYtM 
3dHSOdsNDiLkr0H77x9U2ZFtoN7U2A==
EDU.ZA.9378INDNSKEY256 3 13 
YPgTWLFxFXWMXlVaJB2bCA5F75l5yryFO/h9w+xXS/GfhhmvyZvh9NCv 
MLPZckLRGbeZ5/BkyH9ae4X0IyzKYA==
EDU.ZA.9378INDNSKEY257 3 13 
75OMA5R90131FVGX1QcJiCGAUboYSmazf3dPpAPL0t33YLcx7bBnio6Y 
qyrR77MRVZKNpWIBLcnz7YOLWNZXmQ==

---

$ dig CDS EDU.ZA

; <<>> DiG 9.16.6 <<>> CDS EDU.ZA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11376
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;EDU.ZA.INCDS

;; ANSWER SECTION:
EDU.ZA.86400INCDS569 13 2 
350F4414CB611C04AD829CD2C23A5C60296EA635BF59D7F0B44CD02F 6B396A94
EDU.ZA.86400INCDS9355 13 2 
B0A16FBB3F5D6274665DE272FE5FF182ABC89B3072B668589E5EC6F0 513E36C9
EDU.ZA.86400INCDS49988 13 2 
6F99A6D6A4657F0A528AD2791B8B3E02AFB34E5DB79F5C53EA022A55 1874D40A

These are also the values from inside my signed zone. Anyone have any thoughts?
This is going to screw up systems that poll for CDS records.

Well CDS records are for DNSKEYs without the SEP bit are perfectly valid as the 
SEP bit is purely advisory and
no it should screw up systems that poll for CDS records.  You will however have 
to manage them properly in the
future.

You haven’t said how you are managing DNSSEC and named supports several models 
so it is hard to a) tell if
there was a bug in our code or b) an error on your part.

Assuming that you are not using dnssec-policy you should be able to use 
'dnssec-settime -D sync date/offset’
on the ZSK’s to tell named to stop publishing the CDS records but remember you 
still need to account for the
fact that they where published as you go forward.

Mark

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 



Posix SystemsVCARD for MJ Elkins

___
Please 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