https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7547
Bill Cole <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |[email protected] | |cconsult.com Resolution|--- |INVALID --- Comment #5 from Bill Cole <[email protected]> --- (In reply to Kevin A. McGrail from comment #0) > I'm also seeing issues with ISIPP which is in 20_dnsbl_tests.cf. I've > attached the message I sent them as well as their reply. Another issue > I noticed with ISIPP is > > Sep 16 12:09:38 localhost named[1284]: host unreachable resolving > 'ns1.ns.isipp.com/A/IN': 67.227.190.38#53 > Sep 16 12:09:38 localhost named[1284]: host unreachable resolving > 'ns2.ns.isipp.com/A/IN': 67.227.190.38#53 This is common when NS glue records for a domain (e.g. those provided by *.gtld-servers.net for isipp.com) come with a mix of A and AAAA records, and the host where named is running has an IPv6 interface configured but has no IPv6 connectivity to the Internet at large. The simple problem is that named does not know that AAAA records are not usable. > Problem, or something I shouldn't concern myself about? Not a serious problem, although it adds a little sludge to the process of doing some resolutions, somewhat randomly. So if you have an IPv6 interface that can't actually be used to reach public IPv6 space, you should add '-4' to the named command line arguments to avoid ever trying to query an IPv6 address. In the reverse case (which seems unlikely...) you can give it '-6' to only ever use IPv6. The 2 errors from January are far-end problems lost likely caused by transient local issues on the cited nameservers. -- You are receiving this mail because: You are the assignee for the bug.
