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