El vie, 4 dic 2020 a las 1:42, Sergio Belkin (<seb...@gmail.com>) escribió:
> > > El jue, 3 dic 2020 a las 22:23, Viktor Dukhovni (< > postfix-us...@dukhovni.org>) escribió: > >> > On Dec 3, 2020, at 7:28 PM, Sergio Belkin <seb...@gmail.com> wrote: >> > >> > Thanks Bastian, I had to obfuscate the domain name due to privacy >> issues :-/ >> > But I told to Wietse, that domain name has a MX record with an 'A' >> record associated, but lacks of 'AAAA' record. >> > What is weird for me is that it happens sometimes not always with that >> domain... >> >> Even after Wietse and I prowled around in all the >> dark places in the code, we still failed to find >> a plausible way for a soft error in IPv4 lookups >> to fail to suppress a hard NODATA for IPv6 lookups. >> >> The only possible explanations are: >> >> - Your resolver erroneously reported NODATA for IPv4 >> - The authoritative nameservers reported NODATA for IPv4 >> - Neither of us was able to spot a subtle bug >> >> To distinguish between these, it would be helpful if you >> set: >> >> debug_peer_list = another-example-com.mail.protection.outlook.com >> debug_peer_level = 1 >> >> and if/when the problem happens again, either posted a sanitised >> log (with the guilty domain name obscured as appropriate) to the >> list, or sent a copy to just me and Wietse off list. >> >> I'd like to see the actual queries and responses logged by the >> Postfix SMTP delivery agent. >> >> -- >> Viktor. >> >> > Thanks Viktor and Wietse, up to now the error didn't happen again. > Some information about my software that may be useful: > libc-2.17-260.el7_6.4.x86_64 > glibc-2.17-260.el7_6.4.i686 > dnsmasq-2.76-7.el7.x86_64 > > > Just in case: the first package is glibc-2.17-260.el7_6.4.x86_64 -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org
