Posted: Oct 17, 2011 @ 05:19 PM             Msg. 1 of 3

Hi,

We've been having some DNS failures resolving subdomains of openecry.com where we get results like this:


dig prod.openecry.com

; <<>> DiG 9.7.3 <<>> prod.openecry.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5821
;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;prod.openecry.com. IN A

;; ANSWER SECTION:
openecry.com. 28798 IN DNAME www.openecry.com.
prod.openecry.com. 28798 IN CNAME prod.www.openecry.com.
prod.www.openecry.com. 28798 IN CNAME prod.www.www.openecry.com.
prod.www.www.openecry.com. 28798 IN CNAME prod.www.www.www.openecry.com.
prod.www.www.www.openecry.com. 28798 IN CNAME prod.www.www.www.www.openecry.com.
prod.www.www.www.www.openecry.com. 28798 IN CNAME prod.www.www.www.www.www.openecry.com.



The expansion continues on for several more lines.

After some testing and communicating with others on the internet we have found that this affects at least ISC's BIND 9 versions 9.6.ESV.R4+dfsg-0+lenny1 and 9.7.3.dfsg-1~squeeze3 as shipped with Debian 5.0 and 6.0 and only if querying in this order:

Query openecry.com DNAME, then query for www.openecry.com or prod.openecry.com.

If we query for the subdomains before querying for DNAME, everything works as expected. I am not sure why the DNAME query happens, but once triggered, the other queries for the subdomains is poisoned for at least eight hours.

In testing and communicating with others we found that the bindless resolver shipped with recent Debian versions does not have this problem, neither does the Google Public DNS or OpenDNS.

While we could switch to one of these others, we prefer not to for other reasons including local DNS setup. We will file a bug report with Debian for bind 9 since other resolvers seem to handle this issue regardless of the use of the DNAME being correct or not.

I am not sure how or why you are using a DNAME for openecry.com to www.openecry.com, but I encourage you to consider other alternatives that would allow you to remove it altogether. Even on the "working" DNS resolvers, the DNAME mapping either returns nothing (prod.www.openecry.com @8.8.8.8) or times out (prod.www.openecry.com @208.67.222.222) so the entry appears to be incorrect and ineffective.

Thanks,
Jacob

Posted: Oct 18, 2011 @ 11:54 AM             Msg. 2 of 3

Jacob,
I made some changes to our DNS. Can you flush DNS of the machine your using and try again.

---

Robert Vinicky

Posted: Oct 18, 2011 @ 12:04 PM             Msg. 3 of 3

I just tested and can no longer reproduce the bug using the steps I described now that the DNAME record doesn't exist.

I will watch them today and reply back here if I see it again, but I expect that the issue is avoided now.

Thank you,
Jacob