On Fri, Aug 28, 2020 at 04:47:50PM +0800, daniel via Exim-users wrote:
> I have an update of this problem.
>
> Today I found out the solution of this problem.
>
> The solution is to NOT using any google DNS server (8.8.8.8 8.8.4.4).
>
> I am not sure how these two things does not work to each other; But once
> i switch to not using it, for example, use 1.1.1.1 instead, it INSTANTLY
> works again.
If you're using *remote* DNS servers (doesn't matter which, Google,
Clouflare, Verisign, Quad9, your ISPs, ...) its game over. You're
wasting your time enabling DANE. Just turn it off.
When the network path between your system and your DNS resolvers is not
tamper-proof, you get zero security from DANE (in Exim and Postfix, or
any other MTA that does not validate DNSSEC replies internally in its
resolver library, but instead trusts the "AD" bit from the resolver).
> >>> We recently received many of our end users complains that they are having problem sending email to *.gov.hk with this exim error:
> >>> DANE ERROR: TLSA LOOKUP DEFER
> >> Their DNS is broken.
In the DANE/DNSSEC survey I find only one .gov.hk domain with TLSA
records resolution issues: tid.gov.hk.
This domain has nameservers that mishandle the client's EDNS buffer
size. When the response wouldn't fit in the client's requested buffer
size limit, they set the TC bit, but then don't actually truncate the
response! Consequently, large UDP packets are sent that require
fragmentation, and these don't always get through. So depending on
where I ask from loookups for the TLSA records of the MX hosts of
tid.gov.hk may time out.
Otherwise, the 570 other DNSSEC-signed .gov.hk domains I do know about
all seem to work fine.
--
Viktor.
