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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/