Rich Felker:
> > The __RES value varies wildly between different platforms. __RES
> > never changes for glibc, but it does change on other platforms.
> >
> > #define __RES 19991006// Fedora 30, glibc 2.29
> > #define __RES 19991006// Alpine 3.11.5, pretends-to-be glibc 2.29
>
On Wed, May 20, 2020 at 05:41:46PM -0400, Wietse Venema wrote:
> Rich Felker:
> [dnssec end-to-end probe, log a warning if for any reason results
> do not have the authentic data' bit set]'.
> > This sounds like a great plan that will also mitigate the problem of
> > glibc's AD-stripping by default
Rich Felker:
[dnssec end-to-end probe, log a warning if for any reason results
do not have the authentic data' bit set]'.
> This sounds like a great plan that will also mitigate the problem of
> glibc's AD-stripping by default. FYI I've raised concerns about that
> again on libc-alpha:
>
> https:/
On Wed, May 20, 2020 at 01:59:47PM -0400, Wietse Venema wrote:
> Viktor Dukhovni:
> > On Tue, May 19, 2020 at 05:19:26PM -0400, Wietse Venema wrote:
> >
> > > > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633
> > >
> > > I understand that the AD (authentic
Viktor Dukhovni:
> On Tue, May 19, 2020 at 05:19:26PM -0400, Wietse Venema wrote:
>
> > > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633
> >
> > I understand that the AD (authentic data) bit now is 'true' if
> > DNSSEC validation was successful. Thanks for
On Tue, May 19, 2020 at 07:00:57PM -0400, Viktor Dukhovni wrote:
> On Tue, May 19, 2020 at 05:19:26PM -0400, Wietse Venema wrote:
>
> > > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633
> >
> > I understand that the AD (authentic data) bit now is 'true' if
On Tue, May 19, 2020 at 06:51:57PM -0400, Viktor Dukhovni wrote:
> On Tue, May 19, 2020 at 04:08:32PM -0400, Rich Felker wrote:
>
> > I'm not encouraging any to do that; rather I've encouraged them to
> > take measures to both:
> >
> > (1) ensure that DANE is not silently ignored, by either patch
On Tue, May 19, 2020 at 05:19:26PM -0400, Wietse Venema wrote:
> > https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633
>
> I understand that the AD (authentic data) bit now is 'true' if
> DNSSEC validation was successful. Thanks for that.
>
> Meanwhile I'll lo
On Tue, May 19, 2020 at 04:08:32PM -0400, Rich Felker wrote:
> I'm not encouraging any to do that; rather I've encouraged them to
> take measures to both:
>
> (1) ensure that DANE is not silently ignored, by either patching
> Postfix to work with old musl (prior to the above commit) or patching
>
Rich Felker:
> > > > Do let us know when libc-musl provides an indication whether a DNS
> > > > lookup result is authentic (DNSSEC pass).
> > >
> > > It is now in master. I've also recommended the patch to Alpine.
> >
> > A pointer to how one would use the updated code would be welcome,
> > perhap
On Tue, May 19, 2020 at 01:25:52PM -0400, Wietse Venema wrote:
> Rich Felker:
> > On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote:
> > > Rich Felker:
> > > > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> > > > > Rich Felker:
> > > > > > The is fundamentally no build
On Tue, May 19, 2020 at 10:28:57AM -0400, Rich Felker wrote:
> On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> > Rich Felker:
> > > The is fundamentally no build-time test possible for this. Even if we
> > > were willing to make flags for each bug (or missing feature) that was
> >
Rich Felker:
> On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote:
> > Rich Felker:
> > > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> > > > Rich Felker:
> > > > > The is fundamentally no build-time test possible for this. Even if we
> > > > > were willing to make fla
On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote:
> Rich Felker:
> > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> > > Rich Felker:
> > > > The is fundamentally no build-time test possible for this. Even if we
> > > > were willing to make flags for each bug (or missi
Rich Felker:
> On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> > Rich Felker:
> > > The is fundamentally no build-time test possible for this. Even if we
> > > were willing to make flags for each bug (or missing feature) that was
> > > ever fixed indicating the change, that would o
On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> Rich Felker:
> > The is fundamentally no build-time test possible for this. Even if we
> > were willing to make flags for each bug (or missing feature) that was
> > ever fixed indicating the change, that would only tell you whether th
Rich Felker:
> The is fundamentally no build-time test possible for this. Even if we
> were willing to make flags for each bug (or missing feature) that was
> ever fixed indicating the change, that would only tell you whether the
> version present at build time had the property, not whether the
> v
On Tue, May 19, 2020 at 09:22:59AM -0400, Wietse Venema wrote:
> Viktor Dukhovni:
> > Robust detection of MUSL features at build time would be much
> > appreciated. Precludes any tests that depend on live DNS queries.
> > The tests need to *statically* test the features of the platform's
> > C lib
On Tue, May 19, 2020 at 05:06:10AM -0400, Viktor Dukhovni wrote:
> On Tue, May 19, 2020 at 01:44:30AM -0400, Rich Felker wrote:
>
> > > This sounds reasonable. Will there be a way for Postfix to detect the
> > > new library version, so that we don't disable DANE for musl-libc
> > > versions that
Viktor Dukhovni:
> Robust detection of MUSL features at build time would be much
> appreciated. Precludes any tests that depend on live DNS queries.
> The tests need to *statically* test the features of the platform's
> C library.
Agreed. You're welcome to provide a reliable static test (no live
Am Dienstag, den 19.05.2020, 05:06 -0400 schrieb Viktor Dukhovni:
> We have no choice, we can't ship code that silently fails to honour
> its
> configuration. I'm not worried about DANE "working", I'm worried
> about
> DANE *not* working, and the user being none-the-wiser.
>
Just my 50cents to mak
On Tue, May 19, 2020 at 01:44:30AM -0400, Rich Felker wrote:
> > This sounds reasonable. Will there be a way for Postfix to detect the
> > new library version, so that we don't disable DANE for musl-libc
> > versions that do set the AD bit?
>
> I'm really disappointed with the detection, which m
On Mon, May 18, 2020 at 10:38:14PM -0400, Viktor Dukhovni wrote:
> On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote:
>
> > > Mostly dig, unbound-host, ... Most of the platform C libraries support
> > > DO=1, which obviates the need for AD=1, so they don't do that, but it is
> > > nevert
On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote:
> > Mostly dig, unbound-host, ... Most of the platform C libraries support
> > DO=1, which obviates the need for AD=1, so they don't do that, but it is
> > nevertheless safe. AD=1 is much cheaper than DO=1, because you get back
> > just
On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote:
> > > That RFC was published in 2013. That's long enough ago.
> >
> > We support environments that haven't been touched since 2009 or so,
> > and to a lesser/minimal-support extent ones that haven't been touched
> > since around 200
* Rich Felker:
> On Wed, Apr 15, 2020 at 08:27:08PM +0200, Florian Weimer wrote:
>> >> I don't understand your PTR example. It seems such a fringe case that
>> >> people produce larger PTR responses because they add all virtual hosts
>> >> to the reverse DNS zone. Sure, it happens, but not often
On Thu, Apr 16, 2020 at 11:40:59PM -0400, Rich Felker wrote:
> TC bit is for truncation, and means that the complete response would
> have been larger than 512 bytes and was truncated to whatever number
> of whole RRs fit in 512 bytes.
Actually whole RRsets. Nameservers must not truncate in the
On Wed, Apr 15, 2020 at 08:27:08PM +0200, Florian Weimer wrote:
> >> I don't understand your PTR example. It seems such a fringe case that
> >> people produce larger PTR responses because they add all virtual hosts
> >> to the reverse DNS zone. Sure, it happens, but not often.
> >
> > I think it'
On Wed, Apr 15, 2020 at 02:01:49PM -0400, Rich Felker wrote:
> I'd be interested in reading more on this if you know any references.
> Over 512 bytes of MX records seems like a lot, and seems like a really
> bad idea for a domain configuration since there have always been (as
> you noted, with qma
* Rich Felker:
> On Wed, Apr 15, 2020 at 07:19:43PM +0200, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > This is true for users running local nameservers, which ideally will
>> > eventually be everyone, but at present that's far from the case.
>> > Differences like concurrent attempts from mult
On Wed, Apr 15, 2020 at 07:19:43PM +0200, Florian Weimer wrote:
> * Rich Felker:
>
> > This is true for users running local nameservers, which ideally will
> > eventually be everyone, but at present that's far from the case.
> > Differences like concurrent attempts from multiple nameservers and/or
* Rich Felker:
> This is true for users running local nameservers, which ideally will
> eventually be everyone, but at present that's far from the case.
> Differences like concurrent attempts from multiple nameservers and/or
> lack of TCP fallback on TC are what makes netstat fast on musl vs
> rep
Am Mittwoch, den 15.04.2020, 05:05 -0400 schrieb Viktor Dukhovni:
> On Wed, Apr 15, 2020 at 10:36:26AM +0200, Christian wrote:
>
>
> I don't yet have access to systems with this recent a glibc to
> confirm
> the above, but this is likely relevant to Postfix administrators who
> enable DANE. You m
On Wed, Apr 15, 2020 at 10:36:26AM +0200, Christian wrote:
> > I don't yet have access to systems with this recent a glibc to confirm
> > the above, but this is likely relevant to Postfix administrators who
> > enable DANE. You may need to explicitly add the "trust-ad" option to
> > your /etc/re
Am Mittwoch, den 15.04.2020, 02:28 -0400 schrieb Viktor Dukhovni:
> On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote:
>
>
> but if that is incompatible with other stub resolver libraries on the
> same machine, you may need a private musl-specific configuration file.
>
> My money is o
On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote:
> but if that is incompatible with other stub resolver libraries on the
> same machine, you may need a private musl-specific configuration file.
>
> My money is on this being unnecessary. I'll let [you] know what I find
> from dns-
On Tue, Apr 14, 2020 at 12:06:41PM -0400, Rich Felker wrote:
> > Well, ISP resolvers and anycast resolvers from Google, Cloudflare,
> > Verisign and Quad are generally not too far away.
>
> If you're on dialup or saturated DSL or cellular link, they're easily
> 300-1000 ms away. Each round trip c
On Tue, Apr 14, 2020 at 02:16:20AM -0400, Viktor Dukhovni wrote:
> On Mon, Apr 13, 2020 at 11:53:03PM -0400, Rich Felker wrote:
>
> > > Your local nameserver has already done the TCP failover and paid the
> > > cost of obtaining the full RRset, your stub resolver is just failing to
> > > give it t
On Mon, Apr 13, 2020 at 11:53:03PM -0400, Rich Felker wrote:
> > Your local nameserver has already done the TCP failover and paid the
> > cost of obtaining the full RRset, your stub resolver is just failing to
> > give it the opportunity to return the full data to you. The performance
> > cost is
On Mon, Apr 13, 2020 at 05:41:38PM -0400, Viktor Dukhovni wrote:
> > Fallback to tcp on TC would also yield very bad performance for users
> > who are not running a local nameserver whenever looking up names with
> > ridiculous numbers of A/ records, where the truncated response
> > certainly s
On Mon, Apr 13, 2020 at 03:35:05PM -0400, Rich Felker wrote:
> > It is also not uncommon for applications that use SRV records to
> > encounter large RRsets (e.g. Windows Domain controller lists for
> > large Active-Directory domains in MIT Kerberos or Heimdal).
>
> The justification here has alw
On Mon, Apr 13, 2020 at 03:04:12PM -0400, Viktor Dukhovni wrote:
> On Mon, Apr 13, 2020 at 02:35:22PM -0400, Rich Felker wrote:
>
> > > The problem can be partly resolved by setting the "AD" bit in the
> > > outgoing DNS query header sent by the musl-libc stub resolver. Then
> > > the local itera
On Mon, Apr 13, 2020 at 02:35:22PM -0400, Rich Felker wrote:
> > The problem can be partly resolved by setting the "AD" bit in the
> > outgoing DNS query header sent by the musl-libc stub resolver. Then
> > the local iterative resolver will return the AD bit in its response.
> >
> > However, lac
On Mon, Apr 13, 2020 at 02:15:14PM -0400, Viktor Dukhovni wrote:
> > On Apr 13, 2020, at 7:18 AM, Christian wrote:
> >
> > FYI: I put your findings forward to the musl-libc mailing list and
> > asked what they now think what should be done.
>
> The problem can be partly resolved by setting the "
> On Apr 13, 2020, at 7:18 AM, Christian wrote:
>
> FYI: I put your findings forward to the musl-libc mailing list and
> asked what they now think what should be done.
The problem can be partly resolved by setting the "AD" bit in the
outgoing
DNS query header sent by the musl-libc stub resolve
To finalise this as solved
Just moved Postfix to a Debian based container and now DANE is working as
expected.
Hence if anyone comes by this thread, follow Viktors advice:
> DO NOT run Postfix over musl-libc.
Hence not on regular Alpine.
Am Montag, den 13.04.2020, 06:57 -0400 schrieb Viktor Dukhovni:
>
> On Apr 13, 2020, at 6:38 AM, Christian wrote:
>
> Nevertheless, it should probably be included in the Postfix DANE
> documentation to avoid muslc setups with postfix for now.
>
> Postfix expects a C-library implementation of the D
> On Apr 13, 2020, at 6:38 AM, Christian wrote:
>
> Nevertheless, it should probably be included in the Postfix DANE
> documentation to avoid muslc setups with postfix for now.
Postfix expects a C-library implementation of the DNS stub resolver
routines that is compatible with the original BSD d
Am Montag, den 13.04.2020, 05:52 -0400 schrieb Viktor Dukhovni:
>
> On Apr 13, 2020, at 4:56 AM, Christian wrote:
>
> The container is running on alpine, hence with muslc libc. After
> seeing
> the tcpdump yesterday, I thought as well, if that could be an issue.
>
> I am no programmer, however 2 t
> On Apr 13, 2020, at 5:52 AM, Viktor Dukhovni
> wrote:
>
> Indeed searching the github repo for RES_USE_DNSSEC and RES_USE_EDNS0 finds
> hits only the header file, and similarly:
>
>
> https://raw.githubusercontent.com/runtimejs/musl-libc/master/src/network/res_state.c
>
> pretty much rules
>> The validator [1] says TLSA is ok, so is this even be a DNS issue? If I
>> have to guess, Postfix encounters the following situation:
>>
>>
>> When TLSA records are found, but are all unusable the effective security
>> level is "encrypt"
>>
>> The documentation does not state that self-signed c
> On Apr 13, 2020, at 4:56 AM, Christian wrote:
>
> The container is running on alpine, hence with muslc libc. After seeing
> the tcpdump yesterday, I thought as well, if that could be an issue.
>
> I am no programmer, however 2 things strike me:
> Dig is able to construct a proper request and I
Hi Damian,
Am Montag, den 13.04.2020, 11:22 +0200 schrieb Damian:
> The validator [1] says TLSA is ok, so is this even be a DNS issue? If I
> have to guess, Postfix encounters the following situation:
>
>
> When TLSA records are found, but are all unusable the effective security
> level is "encry
[ To the OP: feel free to ignore the below response, it is irrelevant. ]
> On Apr 13, 2020, at 5:22 AM, Damian wrote:
>
> The validator [1] says TLSA is ok, so is this even be a DNS issue? If I
> have to guess, Postfix encounters the following situation:
>
>> When TLSA records are found, but ar
The validator [1] says TLSA is ok, so is this even be a DNS issue? If I
have to guess, Postfix encounters the following situation:
> When TLSA records are found, but are all unusable the effective security
> level is "encrypt"
The documentation does not state that self-signed certificates are
in
Hello Viktor,
thanks again, please see my answers inline.
Am Sonntag, den 12.04.2020, 22:47 -0400 schrieb Viktor Dukhovni:
> On Mon, Apr 13, 2020 at 02:12:49AM +0200, Christian wrote:
>
>
> thanks for the response! Apparently the mail was too long (>4000) and
> got rejected, hence I put it to past
On Mon, Apr 13, 2020 at 02:12:49AM +0200, Christian wrote:
> thanks for the response! Apparently the mail was too long (>4000) and
> got rejected, hence I put it to pastebin: https://pastebin.com/1e3sR0Hq
The query in your PCAP file was not sent to 127.0.0.11, and had no EDNS
OPT record (so no "D
Hi Viktor,
thanks for the response! Apparently the mail was too long (>4000) and
got rejected, hence I put it to pastebin: https://pastebin.com/1e3sR0Hq
I think the tcpdumps are interesting, as they show that postfix is not
requesting with the right flags (If I am not reading everything wrong).
K
On Sun, Apr 12, 2020 at 04:20:48PM +0200, Christian wrote:
> I am running in a docker setup (alpine based on debian host) with my own
> unbound DNS resolver.
What is the content of /etc/resolv.conf?
> I started to check if I have problems in my DNSSEC checks. running a
> "dig com. SOA +dnssec"
Hi there,
I tried the DANE Test on "havedane.net" and figured, that outgoing DANE
is not working. I get the following:
Email to non-DANE domain delivered.
Email to DANE domain delivered.
Email to domain with invalid DANE delivered.
So apparently the check for the last one is failing (at least).
60 matches
Mail list logo
