<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 12:36 PM, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@anvilwalrusden.com" target="_blank">ajs@anvilwalrusden.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 04, 2016 at 11:16:50AM -0700, Colm MacCárthaigh wrote:<br>
><br>
> I don't interpret either RFC as a command to treat unknown RR-types as<br>
> something that must be agnostically passed around, even if you don't know<br>
> how to handle them<br>
<br>
If you are a slave, you have approximately no reason to claim that you<br>
know better than the master that you're slaving from what the contents<br>
of the zone ought to be.  </blockquote><div><br></div><div>You have every reason to claim that you know what record types you understand and can confidently serve though.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are lots of people operating slave services for others, and the<br>
master in those cases can easily be operated by someone else.  </blockquote><div><br></div><div>Exactly.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adding<br>
a requirement that zone transfers only succeed when the slave knows<br>
about the RRTYPE basically recreates the condition that RFC 3597 was<br>
created to solve: we need to be able to deploy new RRTYPEs without the<br>
precondition being, "Upgrade every server and resolver in the<br>
universe."<br></blockquote><div><br></div><div>I didn't invent the requirement and I'm not adding it; DNAME and DNSSEC are the precedent - and they only work when you upgrade the servers. They break when you don't. Future RRtypes may repeat this, so it's good and sensible operations to accommodate that. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>, or to stop serving a zone that is handling traffic.<br>
<br>
The expire time _absolutely is_ an instruction that you stop serving<br>
the zone if you can't show you have a current zone by then.  You're<br>
supposed to SERVFAIL, and the idea that anyone would even think about<br>
doing something else alarms me greatly.<br></blockquote><div><br></div><div>o.k - a lot of folks use rsync and even proprietary protocols for standardizing zone data; it's pretty commonplace not to delete what may be production critical data simply because an update mechanism has been failing. Beyond saving disk space, there's really no benefit either - it's all downside; you might cause an outage. There's no sense in that. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> it's valid to serve stale zones (dns is eventually consistent) and it's<br>
<br>
It's only eventually consistent if people follow the rules about<br>
letting things expire when they're told to.  Otherwise, it's<br>
potentially never consistent.<br></blockquote><div><br></div><div>A "SERVFAIL" because a network path broke (say a firewall) isn't consistent. </div><div> </div></div>-- <br><div class="gmail_signature">Colm</div>
</div></div>