-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Robert, Thank you for the detailed bug report. In svn trunk rev1137 a fix is in. The fix, for the curious, is only to mark the newegg server lame if it responds lame to both the A and AAAA queries. So the users can intermix A and AAAA queries, with AAAA failing and A working. Man those newegg servers / load balancers are bad stuff. I just noticed it completely drops class CH (e.g., version.bind CH TXT) queries too. This is not a particular problem luckily. This also fixes www.usps.com by the way. Which seems to be running a different setup as version.bind CH TXT is answered with a neat NOTIMP answer (good!). Best regards, ~ Wouter Robert Edmonds wrote: | newegg.com's NS is hosted by ultradns: | | but interestingly ultradns delegates www.newegg.com and | secure.newegg.com to other servers. | | these servers will answer authoritatively for the A records www and | secure, but provide root referrals when asked about the AAAA records. | | unbound, when asked about the AAAA then the A record, as a typical | resolver(3) client will do, responds with SERVFAILs, as it seems the | referral from the failed AAAA query somehow poisons unbound (see | attached newegg-fail.log). when asked for only the A record, unbound | doesn't receive any bad data and returns the record (see attached | newegg-success.log). | | bind and dnscache handle this lameness, so include the usual | new-kid-on-the-block / abuse-of-the-robustness-principle arguments. | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhiF9MACgkQkDLqNwOhpPj4aACcCHjtikwiYYCSmQz3u/wBsG1L sX0AniZp+sXk1LfmzrVhpDGPqkglwxjN =XoKl -----END PGP SIGNATURE-----