question about resolving of AAAA amazoses.com

[Crist Clark]

Another operational impact of these broken servers, broken DNS64. BIND
wants to verify no AAAA records exist for a QNAME before synthesizing
records, but since it can’t get a valid denial of existence, it won’t
return synthesized AAAAs.


On Sat, Jul 5, 2025 at 6:44 AM Bagas Sanjaya <bagasdotme at gmail.com> wrote:

> On 7/5/25 19:17, Jeff Sumner wrote:
> > 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.
> >
>
> OK, thanks!
>
> --
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250705/c864823e/attachment.htm>