<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 November 2016 at 12:06, Jim Reid <span dir="ltr"><<a href="mailto:jim@rfc1035.com" target="_blank">jim@rfc1035.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br></span><span class=""><br>
>  I've always been a little annoyed that no "do not send updates" signal was never considered when the UPDATE mechanism was codified.<br>
<br>
</span>But how would someone get that signal without sending an unwanted update? :-)<br>
<br></blockquote><div><br></div><div>Heh. :)   </div><div><br></div><div>If the MNAME hadn't been overloaded in that way, and instead we'd used a new record (I don't think SRV was around yet, but defining things like MX was still in vogue.. maybe a UX record?)  then the desire not to receive updates could have been encoded in that record, and the TTL set to some arbitrarily high value.   </div><div><br></div><div>Alternatively, 2136 could have defined an RCODE response that indicates "never send updates here."  The meaning assigned to REFUSED can (and is) interpreted as a refusal to accept that individual update, and so it's perfectly reasonable to assume the next update might be accepted.  </div></div></div></div>