Viktor Dukhovni:
> > Another data point: by default, Postfix uses a 4096-byte buffer
> > when it calls the C library stub resolver, but it will repeat the
> > call with a larger buffer if the response has the 'truncated' flag
> > raised, and leaving it up to the library to switch to TCP as needed.
On Thu, May 13, 2021 at 09:24:34AM -0400, Wietse Venema wrote:
> > > ; EDNS: version: 0, flags: do; udp: 1232
> >
> > Which "dig" uses, but the C library likely sets the historical default
> > of "4096" bytes, expecting that to work. I am not aware of any way to
> > configure the EDNS buffer siz
Hi Wietse,
>
> However, I recall that some stub resolvers (libc-musl?) don't support
> queries over TCP. Could that be the problem?
Postfix is running here on Arch Linux, so usual glibc and no musl is used.
Regards
Bjoern
Wietse Venema:
> Viktor Dukhovni:
> > On Tue, May 04, 2021 at 10:02:49AM +0200, Bjoern Franke wrote:
> >
> > > Do I miss something why postfix has the trouble with the reply?
> > >
> > > $ dig +dnssec -t TLSA _25._tcp.smtp-relay-in-s1.neusta.de
> >
> > You're testing with "dig", which is *not* t
Viktor Dukhovni:
> On Tue, May 04, 2021 at 10:02:49AM +0200, Bjoern Franke wrote:
>
> > Do I miss something why postfix has the trouble with the reply?
> >
> > $ dig +dnssec -t TLSA _25._tcp.smtp-relay-in-s1.neusta.de
>
> You're testing with "dig", which is *not* the same as the C library stub
>
On Tue, May 04, 2021 at 10:02:49AM +0200, Bjoern Franke wrote:
> Do I miss something why postfix has the trouble with the reply?
>
> $ dig +dnssec -t TLSA _25._tcp.smtp-relay-in-s1.neusta.de
You're testing with "dig", which is *not* the same as the C library stub
DNS resolver.
> ;; Truncated, r
Hi Viktor,
thanks for your reply.
>
> I am not sure what you mean by "disables QNAME-minimisation
> automatically", but if it is on by default, and subject to some sort of
> dynamic fallback, I strongly recommend that you instead disable it
> *statically* (always off), or set a very small limit
On Mon, May 03, 2021 at 01:56:32PM +0200, Bjoern Franke wrote:
> It seems neusta.de can be added to the list:
>
> posttls-finger neusta.de
> posttls-finger: warning: DANE TLSA lookup problem: Host or domain name not
> found. Name service error for name=_25._tcp.smtp-relay-in-s1.neusta.de
> type
Hi,
>
> Already here we see that "posttls-finger" did not report trouble looking
> up the TLSA RRs, as it would with e.g. "assugo.be" (one of the 300+
> domains affected by broken denial of existence via axc.nl nameservers):
>
> $ posttls-finger assugo.be
> posttls-finger: warning: DANE
On Thu, Sep 03, 2020 at 06:09:23PM -0400, Bill Cole wrote:
> > Your resolver claims to have validated the answer (the AD bit is set),
> > what do you get with "posttls-finger"?
>
> [root@be03 ~]# posttls-finger mail.deaecom.gov
> posttls-finger: Connected to mail.deaecom.gov[149.101.26.25]:25
>
On 3 Sep 2020, at 0:43, Viktor Dukhovni wrote:
On Wed, Sep 02, 2020 at 11:11:32PM -0400, Bill Cole wrote:
[...]
Yes, I see the same:
[root@be03 ~]# dig @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
That's NOT the same, you're not asking for "+dnssec", which Postfix
does
do when resolving D
On 3 Sep 2020, at 0:34, Marcel de Riedmatten wrote:
Le mercredi 02 septembre 2020 à 23:11 -0400, Bill Cole a écrit :
On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:
On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
I do not understand why Postfix didn't see that as a reason to gi
On Wed, Sep 02, 2020 at 11:11:32PM -0400, Bill Cole wrote:
> > For the domain above, I am able to resolve the TLSA RRs via my
> > resolver.
>
> Able to resolve the non-existence, yes. Me too.
See below.
> Yes, I see the same:
>
> [root@be03 ~]# dig @127.0.0.1 _25._tcp.mail.deaecom.gov. tlsa
Le mercredi 02 septembre 2020 à 23:11 -0400, Bill Cole a écrit :
> On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:
> > On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
> I do not understand why Postfix didn't see that as a reason to give
> up
> on DANE.
>
> There's a local instance of
On 2 Sep 2020, at 19:58, Viktor Dukhovni wrote:
On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
I had a message defer indefinitely, ostensibly due to the lack of a
TLSA
record,
No, not the lack of it, but rather inability to verify presence or
lack of it in a downgrade-resistant
On Wed, Sep 02, 2020 at 07:09:28PM -0400, Bill Cole wrote:
> I had a message defer indefinitely, ostensibly due to the lack of a TLSA
> record,
No, not the lack of it, but rather inability to verify presence or
lack of it in a downgrade-resistant manner. DANE being a defense
against active atta
16 matches
Mail list logo
