Thanks for separating.
Forwarded the remaining thread that was decoupled from the mailing list:
> Von: Ömer Güven
> Datum: 9. Februar 2025 um 18:30:08 MEZ
> An: akritrim® Intelligence™
> Betreff: Aw: [pfx] Re: [Bug report] Allow opportunistic DANE when non-DNSSEC
> signed MX p
This is not a tlspol question.
> sending to gmail shows up as verified connections but
With Postfix, 'verified' means that the certificate matched, either
by name or by fingerprint (from certificate or public key).
> recieving from gmail shows up as trusted connections
With Postfix, 'trusted'
Please consider this example:
tum.de is dane-only
mri.tum.de is dane (because they didn‘t sign the MX record, but the MX is
virtually the same signed DANE-supporting SMTP server)
The Postfix config looks like this:
smtp_dns_support_level = dnssec
smtp_tls_security_level = may
Please open an issue in GitHub for problems with postfix-tlspol in the future.
I can say that you probably misconfigured something. It has to say ‚Verified
TLS‘, so it didn‘t work in your case.
Did you use the correct port and socketmap verb?
It isn‘t the same as postfix-mta-sts-resolver
(socket
On Sun, Feb 09, 2025 at 04:35:03PM +0100, Ömer Güven via Postfix-users wrote:
> I can only endorse this. Simply setting it to „dane“ should solve the
> hassle and make the operation more consistent and predictable.
The whole thing is a misunderstanding. The insecure MX setting is only
ever used
I can only endorse this. Simply setting it to „dane“ should solve the hassle
and make the operation more consistent and predictable.
Thanks,
Ömer
> Am 09.02.2025 um 15:58 schrieb Wietse Venema via Postfix-users
> :
>
> I think that the mistake was to make smtp_tls_dane_insecure_mx_policy
>
e policy.
>
>I have to calculate the worst-case, like an user configuring „encrypt“ as
>default tls policy, and sending a mail to a domain that is not dnssec signed
>itself, but points to a third-party mail provider that securely implements
>TLSA.
>Now tlspol would return „da
I think that the mistake was to make smtp_tls_dane_insecure_mx_policy
dependent on smtp_tls_security_level
Will it please Viktor and Omer if I change the default to
smtp_tls_dane_insecure_mx_policy = dane
That seems to have less of a WTF factor.
Here is my motivation to make make dane poli
licy.
>
> I have to calculate the worst-case, like an user configuring „encrypt“ as
> default tls policy, and sending a mail to a domain that is not dnssec signed
> itself, but points to a third-party mail provider that securely implements
> TLSA.
> Now tlspol would return „dan
default tls policy, and sending a mail to a domain that is not dnssec signed
itself, but points to a third-party mail provider that securely implements TLSA.
Now tlspol would return „dane“ because the domain does not have all
requirements for „dane-only“ set, but opportunistic DANE is still a
On Sun, Feb 09, 2025 at 03:00:22AM +0100, Ömer Güven wrote:
> How did I misunderstand the settings if Wietse said that
> smtp_tls_dane_insecure_mx_policy only defaults to dane, when the
> smtp_tls_security_level variable is set to dane, else it defaults to
> may, regardless of the security level r
I tested it: it is true. Setting the default security level to anything other
than „dane“ (even encrypt, verify, secure…) and having the socketmap server
return „dane“ downgrades to „may“ (but then negotiates unauth TLS because the
remote of course supports encryption).
This is a major design fl
How did I misunderstand the settings if Wietse said that
smtp_tls_dane_insecure_mx_policy only defaults to dane, when the
smtp_tls_security_level variable is set to dane, else it defaults to may,
regardless of the security level returned by smtp_tls_policy_maps?
Either is Wietse wrong or you di
On Sat, Feb 08, 2025 at 11:06:08PM +0100, Ömer Güven via Postfix-users wrote:
> * Also: the current behavior is counter-intuitive and makes returning
> „dane“ completely useless unless the default is also set to „dane“,
> because postfix-tlspol only returns „dane“ if „dane-only“ isn‘t
> possible b
On Sat, Feb 08, 2025 at 04:41:53PM -0500, Wietse Venema via Postfix-users wrote:
>
> smtp_tls_dane_insecure_mx_policy = ${{$smtp_tls_security_level} == {dane} ?
> {dane} : {may}}
>
> I have one question:
>
> - Should this expression use the security level from
>main.cf:smtp_tls_security_l
Postfix-users:
>>>> On Sat, Feb 08, 2025 at 05:28:31PM +0100, ?mer G?ven via Postfix-users
>>>> wrote:
>>>> RFC 7672 says that Opportunistic DANE (security level ?dane?, but not
>>>> ?dane-only?) may accept non-DNSSEC derived MX records be eligib
ers
> :
>
> Viktor Dukhovni via Postfix-users:
>>> On Sat, Feb 08, 2025 at 05:28:31PM +0100, ?mer G?ven via Postfix-users
>>> wrote:
>>>
>>> RFC 7672 says that Opportunistic DANE (security level ?dane?, but not
>>> ?dane-only?) may accept non-DN
Viktor Dukhovni via Postfix-users:
> On Sat, Feb 08, 2025 at 05:28:31PM +0100, ?mer G?ven via Postfix-users wrote:
>
> >RFC 7672 says that Opportunistic DANE (security level ?dane?, but not
> >?dane-only?) may accept non-DNSSEC derived MX records be eligible for
> &g
ostfix-users wrote:
>
>> RFC 7672 says that Opportunistic DANE (security level „dane“, but not
>> „dane-only“) may accept non-DNSSEC derived MX records be eligible for
>> DANE on the DNSSEC-signed (e. g. external) SMTP server.
>>
>> RFC 7672 Section 2.2.1:
On Sat, Feb 08, 2025 at 05:28:31PM +0100, Ömer Güven via Postfix-users wrote:
>RFC 7672 says that Opportunistic DANE (security level „dane“, but not
>„dane-only“) may accept non-DNSSEC derived MX records be eligible for
>DANE on the DNSSEC-signed (e. g. external) SM
Hi!RFC 7672 says that Opportunistic DANE (security level „dane“, but not „dane-only“) may accept non-DNSSEC derived MX records be eligible for DANE on the DNSSEC-signed (e. g. external) SMTP server.RFC 7672 Section 2.2.1: Since the protocol in this memo is an Opportunistic Security protocol
Dear Viktor, dear Wietse,
Am 25.11.22 um 17:25 schrieb Viktor Dukhovni:
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
Viktor Dukhovni:
However, in this case the issue is a minor oversight in the Postfix TLS
client code. The intended logging behaviour does not happen. Patch
On Mon, May 22, 2023 at 09:53:36PM -0400, Viktor Dukhovni via Postfix-users
wrote:
> Key reuse as a *default* rollover approach is robust. When it is time
> to change keys, one can do so deliberately, and with due care to
> prepublish TLSA records matching the *next* key, then after a few TTLs
>
On Mon, May 22, 2023 at 02:34:41PM +0200, Joachim Lindenberg via Postfix-users
wrote:
> reusing the private key for too long (say a year or more) is
> considered a bad security practice. Imho it is easier to monitor
> changes of the issuing CA (I do) or just mark your calendar to update
> in Sept
Joachim Lindenberg via Postfix-users writes:
> (...) just mark your calendar to update in September 2025 ...
Hellow Joachim! Thanks for remarkble tip ^^^
Sincerely, Byung-Hee
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe
decide on
her/his own.
Cheers,
Joachim
-Ursprüngliche Nachricht-
Von: raf via Postfix-users
Gesendet: Samstag, 20. Mai 2023 00:53
An: postfix-users@postfix.org
Betreff: [pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 08:54:16PM +0200, Joachim Lindenberg via Postfix-users
wrote
any servers carrying "non-test" traffic.
>
> You can publish TLSA records for some test host with a self-signed
> cert, and check monitoring detects incorrect TLSA records when
> mismatched TLSA records are configured (and is not complaining
> when the TLSA records are correct).
On Thu, May 18, 2023 at 08:54:16PM +0200, Joachim Lindenberg via Postfix-users
wrote:
> For Letsencrypt certificates I´d definitely go with 2 1 1
> 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D and
> optionally the R4 derivate and add their successors when these are about to
Benny Pedersen via Postfix-users writes:
> Byung-Hee HWANG via Postfix-users skrev den 2023-05-19 04:26:
>
>> Thanks for advice!
>>
>>>[renewalparams]
>>>reuse_key = True
>>>preferred_chain = ISRG Root X1
>
>> And
>> I can't say anything yet. I need some test for long tim
Byung-Hee HWANG via Postfix-users skrev den 2023-05-19 04:26:
Thanks for advice!
[renewalparams]
reuse_key = True
preferred_chain = ISRG Root X1
And
I can't say anything yet. I need some test for long time. If i am sure
what DANE is,
posttls-finger example.org, basic
Viktor Dukhovni via Postfix-users writes:
> On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users
> wrote:
>
>> And now i added TLSA record for only *outbond* smtp server,
>> .
>
> It is also your secondary MX host:
>
> https://stats.dnssec-tools.org/explore/?doraji.xyz
uot; boil down to an initial leap of faith.
That said, if you do go with "2 1 1", please look over:
https://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
Hello Byung-Hee ,
for testing you may want to try https://blog.lindenberg.one/EmailSecurityTest.
Best Regards,
Joachim
-Ursprüngliche Nachricht-
Von: Byung-Hee HWANG via Postfix-users
Gesendet: Mittwoch, 17. Mai 2023 10:16
An: Postfix-users
Betreff: [pfx] Re: DANE and DNSSEC
Now i
-Ursprüngliche Nachricht-
Von: Viktor Dukhovni via Postfix-users
Gesendet: Donnerstag, 18. Mai 2023 15:12
An: postfix-users@postfix.org
Betreff: [pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users
wrote:
> And now i added TLSA record for o
On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users
wrote:
> And now i added TLSA record for only *outbond* smtp server,
> .
It is also your secondary MX host:
https://stats.dnssec-tools.org/explore/?doraji.xyz
the primary MX host does not yet have TLSA records. Th
On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users
wrote:
> Byung-Hee HWANG via Postfix-users writes:
>
> > Now i added DNSSEC. Currently it is being registra job. 10 minutes ago,
> > i did make some DS record at Cloudfalre.
> >
> > Than
Byung-Hee HWANG via Postfix-users writes:
> Now i added DNSSEC. Currently it is being registra job. 10 minutes ago,
> i did make some DS record at Cloudfalre.
>
> Thanks to Joachim, Patrick and raf ^^^
And now i added TLSA record for only *outbond* smtp server,
<>. I rea
Now i added DNSSEC. Currently it is being registra job. 10 minutes ago,
i did make some DS record at Cloudfalre.
Thanks to Joachim, Patrick and raf ^^^
Sincerely, Byung-Hee
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe
raf via Postfix-users writes:
> On Thu, May 11, 2023 at 03:17:21PM +0900, Byung-Hee HWANG via Postfix-users
> wrote:
>
>> Hellow Postfix hackers,
>>
>> I have a questions while reading DANE docs. Is DNSSEC mandotary? For
>> making DANE mail server.
>&
On Thu, May 11, 2023 at 03:17:21PM +0900, Byung-Hee HWANG via Postfix-users
wrote:
> Hellow Postfix hackers,
>
> I have a questions while reading DANE docs. Is DNSSEC mandotary? For
> making DANE mail server.
>
> For now i'm running two postfix servers in public. Act
Dear Patrick,
Patrick Ben Koetter via Postfix-users
writes:
> (...)
> You don't need DNSSEC for your DNS zone *if* your server should DANE-verify
> other DANE enabled receiver platforms. In this case all you need to do is run
> a DNSSEC-verifying DNS resolver on your se
Hey Byung-Hee!
* Byung-Hee HWANG via Postfix-users :
> Hellow Postfix hackers,
>
> I have a questions while reading DANE docs. Is DNSSEC mandotary? For
> making DANE mail server.
>
> For now i'm running two postfix servers in public. Actually i'm beginner
> in
Joachim Lindenberg via Postfix-users writes:
> DNSSEC is mandatory for DANE.
Hellow Joachim!
Thanks for kind replying ^^^
Sincerely, Byung-Hee
--
^고맙습니다 _布德天下_ 감사합니다_^))//
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscr
DNSSEC is mandatory for DANE.
Greetings,
Joachim
-Ursprüngliche Nachricht-
Von: Byung-Hee HWANG via Postfix-users
Gesendet: Donnerstag, 11. Mai 2023 08:17
An: Postfix Users
Betreff: [pfx] DANE and DNSSEC
Hellow Postfix hackers,
I have a questions while reading DANE docs. Is DNSSEC
Hellow Postfix hackers,
I have a questions while reading DANE docs. Is DNSSEC mandotary? For
making DANE mail server.
For now i'm running two postfix servers in public. Actually i'm beginner
in both DANE and DNSSEC.
Any comments welcome!
Sincerely, Byung-Hee
--
^고맙습니다 _布德
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
> Viktor Dukhovni:
> > However, in this case the issue is a minor oversight in the Postfix TLS
> > client code. The intended logging behaviour does not happen. Patch
> > below:
>
> Is there an equivalent for the still supported Postf
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
> > However, in this case the issue is a minor oversight in the Postfix TLS
> > client code. The intended logging behaviour does not happen. Patch
> > below:
>
> Is there an equivalent for the still supported Postfix version 3.5?
>
Viktor Dukhovni:
> However, in this case the issue is a minor oversight in the Postfix TLS
> client code. The intended logging behaviour does not happen. Patch
> below:
Is there an equivalent for the still supported Postfix version 3.5?
That would also fix Postfix version 3.4 which has the same
On 2022-11-21 at 14:45:52 UTC-0500 (Mon, 21 Nov 2022 20:45:52 +0100)
Paul Menzel
is rumored to have said:
Dear Bill,
Thank you for your reply.
Am 21.11.22 um 19:05 schrieb Bill Cole:
On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100)
Paul Menzel is rumored to have said:
Dear Bill,
Thank you for your reply.
Am 21.11.22 um 19:05 schrieb Bill Cole:
On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100)
Paul Menzel is rumored to have said:
With Postfix 3.6.0-RC1 and
# postconf -n smtp_tls_security_level
smtp_tls_security_level = dane
th
in in the email
> address does not support DNSSEC.
That's where "smtp_tls_dane_insecure_mx_policy" comes into play.
> Testing with level `dane` it indeed does mark the TLS connection as
> untrusted:
>
> $ posttls-finger -c -l dane -P /etc/ssl/certs rki.de
>
On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100)
Paul Menzel
is rumored to have said:
Dear Postfix folks,
With Postfix 3.6.0-RC1 and
# postconf -n smtp_tls_security_level
smtp_tls_security_level = dane
the Postfix SMTP client logs several untrusted TLS connection
have to do with the
SMTP servers publishing TLSA records, but the domain in the email
address does not support DNSSEC.
Testing with level `dane` it indeed does mark the TLS connection as
untrusted:
$ posttls-finger -c -l dane -P /etc/ssl/certs rki.de
posttls-finger: MX RRset insecure
On Wed, Oct 12, 2022 at 09:05:34AM -0400, PGNet Dev wrote:
> when selecting DNSSEC signing algorithms for eventual use with DANE
> setup, checking first @
>
>
> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1
>
>
On 2022-10-12 at 09:05:34 UTC-0400 (Wed, 12 Oct 2022 09:05:34 -0400)
PGNet Dev
is rumored to have said:
*must* I sign my DNSSEC keys for my domains with the same algo in-use
by the respective TLDs' roots in order to not fubar DANE usage
specifically,
No.
or can I (arbitrarily) use any
when selecting DNSSEC signing algorithms for eventual use with DANE setup,
checking first @
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1
both algos 8 & 13 are listed as options:
Number Description Mnem
to mention, that this is all handled internally. I haven’t
tried from another domain.
Not that we have dane-only TLS policy configured for our domains, as we
use DNSSEC and the MTAs all have TLSA records published. (And dane TLS
policy unfortunately falls back to encrypt and not secure
internally. I haven’t
tried from another domain.
Not that we have dane-only TLS policy configured for our domains, as we
use DNSSEC and the MTAs all have TLSA records published. (And dane TLS
policy unfortunately falls back to encrypt and not secure.)
Indeed for github.molgen.mpg.de no MX record
reply.github.molgen.mpg.de:
$ dig mx reply.github.molgen.mpg.de +dnssec +short
5 mx3.molgen.mpg.de.
MX 7 5 7200 20220318110038 20220216110038 14960 molgen.mpg.de.
kTDvX9PKXC9sk96QViR09wUATN3m96sz6Ha6FrMRBrjxUa1OU1AdhvVj
cJbRyetiHy3v+uOPdrng4NLVAow/omnF7Ph0twfz9p9EXUfOBBC/6QJJ
Dan Mahoney wrote
>> Here's an SMTP DANE validator that I use when I make changes to my server.
>> https://dane.sys4.de/
>>
>> I'm not sure if it is just what you're looking for, though.
>
> No, I am looking for a server to which I can send mail to make sure DANE is
> being looked up and used
ssing if there's a full cert path, that "wins"? Is TLSA still
> validated at all in this case?
That guess is not correct. Postfix honours the specified security
level. If you request "dane" you get DANE. You then only get "Trusted"
when TLSA records are not publi
On 2022-01-03 23:02, Dan Mahoney wrote:
On Jan 3, 2022, at 1:46 PM, Mike wrote:
On 1/3/2022 2:38 PM, Dan Mahoney (Gushi) wrote:
[snip]
One more question: Does anyone know of a "reflector" like service
that one
can use to test DANE validation, i.e. a site that one is allowed to
send
test me
> On Jan 3, 2022, at 1:46 PM, Mike wrote:
>
> On 1/3/2022 2:38 PM, Dan Mahoney (Gushi) wrote:
>> [snip]
>>
>> One more question: Does anyone know of a "reflector" like service that one
>> can use to test DANE validation, i.e. a site that one is allowed to send
>> test messages to, that *onl
On 1/3/2022 2:38 PM, Dan Mahoney (Gushi) wrote:
>[snip]
>
> One more question: Does anyone know of a "reflector" like service that one
> can use to test DANE validation, i.e. a site that one is allowed to send
> test messages to, that *only* has DANE as the trust mech (so, say, a
> self-signed
s) that may fix
this, but right now if you're following RFC7706, this check is lying to you.
That said, whomever put this in was good enough to put in a knob to disable it -- but
from the docs, it's unclear as to what happens: is dane simply ignored, or is this just a
warning that &qu
Dan Mahoney:
> > If you enable DNSSEC lookups, Postfix will log a warning when the root
> > zone appears unsigned. See:
> >
> >http://www.postfix.org/postconf.5.html#dnssec_probe
> >
> >This feature is available in Postfix 3.6 and later. It was
&
lidated.
>
>> In reading over what's required to enable DANE support in postfix, I see
>> that there's a compile-time requirement for the DNS lib in the OS to
>> support it, which our OS does according to resolv.h. I don't see any
>> options in the port
for the DNS lib in the OS to
> support it, which our OS does according to resolv.h. I don't see any
> options in the port to enable/disable this feature.
Most extant Unix-like systems have a DNS stub resolver that supports
DNSSEC queries. Postfix just needs the AD bit set in request
ound mail?
If you've set smtp_tls_security_level=dane, but haven't set
smtp_dns_support_level=dnssec, is a warning logged?
-Dan
--
Dan Mahoney
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
FB: fb.com/DanielMahoneyIV
LI: linkedin.com/in/gushi
Site: http://www.gushi.org
---
On Mon, Nov 15, 2021 at 11:58:02AM +0800, Philip Paeps wrote:
> On 2021-11-15 11:36:00 (+0800), Benny Pedersen wrote:
> > plantmarknaden.com
> >
> > https://dane.sys4.de/smtp/plantmarknaden.com
> > https://dnsviz.net/d/plantmarknaden.com/dnssec/
> >
> >
On 2021-11-15 11:36:00 (+0800), Benny Pedersen wrote:
plantmarknaden.com
https://dane.sys4.de/smtp/plantmarknaden.com
https://dnsviz.net/d/plantmarknaden.com/dnssec/
why diffrent results ?
I don't see 'different' results. That domain is broken.
Neither of the listed
plantmarknaden.com
https://dane.sys4.de/smtp/plantmarknaden.com
https://dnsviz.net/d/plantmarknaden.com/dnssec/
why diffrent results ?
nny Pedersen wrote:
> > | [T] kolabsys.com. 86400 IN DNSKEY 256 3 5 ;{id = 47193 (zsk), size =
> > 2048b}
>
> Warning I am not dnssec expert, but I think algo 5 is now deprecated
Though algorithm 5 is deprecated, it is still supported by mainstream
resolvers, so while they sho
= 1280b}
| [T] kolabsys.com. 86400 IN DNSKEY 256 3 5 ;{id = 47193 (zsk), size =
2048b}
| [T] kolabsys.com. 86400 IN A 212.103.80.148
| ;;[S] self sig OK; [B] bogus; [T] trusted
warning i am not dnssec expert, but i think algo 5 is now depricated
https://dane.sys4.de/smtp
Hi Benny
On Tue, May 04, 2021 at 09:35:29PM +0200, Benny Pedersen wrote:
> in bind9 i just do
> rndc nta kolabsys.com
> it have being a problem very long time now :/
What is the problem you are seeing? Yes, kolabsys.com is not in good
shape, see https://dnsviz.net/d/kolabsys.com/dnss
in bind9 i just do
rndc nta kolabsys.com
it have being a problem very long time now :/
after that i see that ssl gives untrusted, but mail to maillist is
atleast delivered
should i resolve the untrusted part seen from
posttls_finger lists.roundcube.net
?
thanks Viktor
El 28/03/2021 a las 1:21, Viktor Dukhovni escribió:
On Sun, Mar 28, 2021 at 01:08:44AM +0100, Francesc Peñalvez wrote:
Right now dnssec is activated in the external manager zoneedit.com, in
which I cannot modify the type of encryption or the length of the key.
If there are no
On Sun, Mar 28, 2021 at 01:08:44AM +0100, Francesc Peñalvez wrote:
> Right now dnssec is activated in the external manager zoneedit.com, in
> which I cannot modify the type of encryption or the length of the key.
If there are no key size or algorithm settings in zoneedit.com, then
indeed
Right now dnssec is activated in the external manager zoneedit.com, in
which I cannot modify the type of encryption or the length of the key.
And if I am looking to activate inbound and outbound dnssec with my postfix
El 28/03/2021 a las 1:03, Viktor Dukhovni escribió:
On Sat, Mar 27, 2021 at
hough I have another installed and running locally.
OK, so you have an outsourced public authoritative server for your
DNSSEC signed domain
> Both in the external and internal services of bind I have the same
> configuration of dmarc and dkim and of course I would like to know, I
> am real
services of bind I have the same
configuration of dmarc and dkim and of course I would like to know, I am
really a novice in system administration, if the external dnssec
configuration that manages the domain, zoneedit, is enough to use dnssec
correctly?
El 27/03/2021 a las 13:34, Viktor Dukhovni
On Sat, Mar 27, 2021 at 12:51:36PM +0100, Francesc Peñalvez wrote:
> I have the dns of the domain managed externally, configured with
> dnssec, and another host running postfix. How could I integrate that
> postfix use the dnssec configuration? Would it be enough to add the
> dns of
I have the dns of the domain managed externally, configured with dnssec,
and another host running postfix. How could I integrate that postfix use
the dnssec configuration? Would it be enough to add the dns of the
external service to the postfix resolv.conf?
--
smime.p7s
Description: Firma
Viktor Dukhovni:
> > On Sep 28, 2020, at 7:09 PM, Wietse Venema wrote:
> >
> > We could log the DNSSEC status only if DNS was 'secure', like we
> > log the connection reuse counter only when a connection was used
> > more than once.
>
> Makes sens
> On Sep 28, 2020, at 7:09 PM, Wietse Venema wrote:
>
> We could log the DNSSEC status only if DNS was 'secure', like we
> log the connection reuse counter only when a connection was used
> more than once.
Makes sense I think, and would probably do the job. The key
q
Viktor Dukhovni:
> On Sun, Sep 27, 2020 at 05:56:52PM -0400, Wietse Venema wrote:
>
> > A draft manpage is below.
> >
>
> It looks very reasonable. The news might not reach the folks who
> only search for particular queue ids in the logs, but shoehorning
> a (sa
On Sun, Sep 27, 2020 at 05:56:52PM -0400, Wietse Venema wrote:
> A draft manpage is below.
>
It looks very reasonable. The news might not reach the folks who
only search for particular queue ids in the logs, but shoehorning
a (say the MX lookup) DNSSEC status into each smtp delivery log
Earlier this year there was a thread about Postfix failing to notice
that some TLSA record was corrupted, because
- Postfix was configured to use opportunistic DANE, which ignores
TLSA records when they aren't DNSSEC validated.
- Some system library API did not indicate whether responses
Microsoft has finally decided to add DANE and DNSSEC support to
Exchange Online servers.
https://techcommunity.microsoft.com/t5/exchange-team-blog/support-of-dane-and-dnssec-in-office-365-exchange-online/ba-p/1275494
--
Jerry
pgpn6634G_3L3.pgp
Description: OpenPGP digital signature
Florian Weimer:
> > I exposed these two options in Postfix configuration using the
> > existing names and semantics, so that users would not need to learn
> > different names with different semantics. Humans have better things
> > to do than riding bikes with a reversed steering mechanism.
>
> Exc
* Wietse Venema:
>> This is an interesting data point because the interaction between
>> RES_DEFNAMES, RES_DNSRCH, and the ndots and no-tld-query options are
>> far from obvious. Even the exact impact of RES_DEFNAMES and
>> RES_DNSRCH probably varies between code written from scratch and the
>> B
t;> >>
> >> >> >> This will not give the result that Postfix programmers want on newer
> >> >> >> glibc versions (not without the trust-ad flag in /etc/resolv.conf).
> >> >> >
> >> >> > The problem with using low-
st-ad flag in /etc/resolv.conf).
>> >> >
>> >> > The problem with using low-level res_*mkquery() is that Postfix
>> >> > would have to re-implement all the high-level res_search() features
>> >> > such as RES_DEFNAMES, RES_DNSRCH, retries ov
h using low-level res_*mkquery() is that Postfix
> >> > would have to re-implement all the high-level res_search() features
> >> > such as RES_DEFNAMES, RES_DNSRCH, retries over TCP after receiving
> >> > a truncated response, and so on.
> >>
> >> I
search() features
>> > such as RES_DEFNAMES, RES_DNSRCH, retries over TCP after receiving
>> > a truncated response, and so on.
>>
>> I don't think this is actually an issue: TCP fallback is still
>> performed with res_send. If you care about DNSSEC va
receiving
> > a truncated response, and so on.
>
> I don't think this is actually an issue: TCP fallback is still
> performed with res_send. If you care about DNSSEC validation, you
> cannot really use search list processing anyway because you might not
> get back the name
;
> The problem with using low-level res_*mkquery() is that Postfix
> would have to re-implement all the high-level res_search() features
> such as RES_DEFNAMES, RES_DNSRCH, retries over TCP after receiving
> a truncated response, and so on.
I don't think this is actually an issue: TCP
Florian Weimer:
> * Rich Felker:
>
> > A solution that would work with existing and future versions of musl
> > as well as glibc, and would (I think) avoid the need to poke at _res
> > to set the glibc trustad flag, would be replacing the call to
> > res_query with res_mkquery, |='ing the AD bit i
* Rich Felker:
> A solution that would work with existing and future versions of musl
> as well as glibc, and would (I think) avoid the need to poke at _res
> to set the glibc trustad flag, would be replacing the call to
> res_query with res_mkquery, |='ing the AD bit into place, then
> res_send.
On Sun, Apr 19, 2020 at 02:16:01PM -0400, Viktor Dukhovni wrote:
> On Sun, Apr 19, 2020 at 08:02:41PM +0200, Matus UHLAR - fantomas wrote:
>
> > On 19.04.20 13:11, Wietse Venema wrote:
> >
> > >Warning: libc-musl breaks DANE/TLSA security.
> > >Use a glibc-based Linux distribution instead.
> > >Re
1 - 100 of 227 matches
Mail list logo
