<div dir="ltr"><div dir="ltr">On Wed, Apr 1, 2020 at 8:36 AM Tony Finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
This error behaviour is mostly specified by the UPDATE protocol (RFC<br>
2136). It's worth reading the RFC becasue (as you have found) some of the<br>
behaviour is a bit surprising. For instance, adding a record that already<br>
exists is not an error because multiple copies of the same record<br>
traditionally get silently de-duplicated in the DNS. (I can't explain the<br>
lack of error in the CNAME case...)<br></blockquote><div><br></div><div>This was a bit unexpected for me too, until I saw that RFC2136 does explicitly</div><div>cover the CNAME case. From Section 3.4.2.2 (the "vice versa" covers the</div><div>original poster's case):</div><div><br></div><div>   "In the case of a CNAME</div>   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME<br>   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update<br>   RR."</div><div class="gmail_quote"><br></div><div class="gmail_quote">The implication is that "ignore" also means set the response code to NOERROR.</div><div class="gmail_quote">Although, I suppose CNAME related UPDATE processing could have been </div><div class="gmail_quote">special cased to return an error code like YXRRSET (even without a specified</div><div class="gmail_quote">prerequisite clause).</div><div class="gmail_quote"><br></div><div class="gmail_quote">Shumon.</div><div class="gmail_quote"><br></div></div>