Hi Wouter, > In svn trunk for unbound r1109 is a fix for this issue. Extremely > lenient acceptance of CNAMEs, if a name has multiple CNAMEs for it, the > first is simply used and the rest is dropped. while as a customer and user I'd appreciate the quick and pragmatic solution to the operational problem, there remain doubts that in this case circumnavigating the bug was the best long term approach. Of course, as a follower, the new kid on the block has a hard time making friends by pointing the others to the rule book instead of playing their way. That said, let's look into the scripture (which also means this may better be discussed on namedroppers): RFC 2181, section 10.1 explains that there must not be multiple CNAMEs for any single owner (it doesn't use RFC 2119 language, but this is basicall it). In section 5, introducing RRSets, there is a strong recommendation against identical RRs in an RRSet. This is later clarified in RFC 4034, section 6.3: [RFC2181] specifies that an RRset is not allowed to contain duplicate records (multiple RRs with the same owner name, class, type, and RDATA). Therefore, if an implementation detects duplicate RRs when putting the RRset in canonical form, it MUST treat this as a protocol error. If the implementation chooses to handle this protocol error in the spirit of the robustness principle (being liberal in what it accepts), it MUST remove all but one of the duplicate RR(s) for the purposes of calculating the canonical form of the RRset. This is for DNSSEC purposes only, but that would hit Unbound sooner or later anyway. The paragraph is tough prose: "... MUST treat this as a protocol error." And later (bending the poor old robustness principle once more): "... MUST remove all but one of the duplicate RR(s) for the purposes ...". All in all I'd suggest with multiple CNAME RRs in parallel, the targets being equal or not, the response is "weird" and Unbound's original unwillingness to accept it, wasn't that bad. Out of curiosity, the other system mentioned in the packet trace gives unusual responses, as well: dig +norec @81.52.250.132 images-na.ssl-images-amazon.com.edgekey.net. will give you random samples of eight out of thirteen root NS RRs in the authority section. Nothing to worry about too much, but another indication that this whole setup is "special". Best regards, Peter