Apologies for the lack of clarity. We performed a major F5 upgrade recently – for which we were delegating some zones from our ISC BIND servers (just Plain Old NS record delegation) and ever since then, clients using nslookup and host, which query the BIND servers (the recursers) are getting back both the correct A records as well as two SERVFAILS as the AAAA and MX record queries error out (both nslookup and host query those record types in addition to the A record query)– both of which cause the log emissions that we see in this string. Can see the F5s handing back incorrect data in the sniffer – so the BIND servers are acting correctly – the F5s are not. We’re working that through.
J From: Bagas Sanjaya <bagasdo...@gmail.com> Date: Saturday, July 5, 2025 at 8:12 AM To: Jeff Sumner <kc4...@gmail.com>, bind-users@lists.isc.org <bind-users@lists.isc.org> Subject: Re: question about resolving of AAAA amazoses.com On 7/5/25 18:55, Jeff Sumner wrote: > Doing battle with the exact same problem – from an over-the-weekend F5 > upgrade. > > So funny this is coming up now. We’re not considering a code upgrade > yet, but users are complaining about the Real ISC-BIND servers returning > SERVFAIL for AAAA queries (not subzone, yada yada) against F5 delegated > servers. > I'm confused. Do you mean these BIND users recursing into authoritative F5 servers? Exactly what troublesome queries? -- An old man doll... just what I always wanted! - Clara
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
