Hi, On Tue, Jul 18, 2017 at 05:09:00PM +0100, Tony Finch wrote: > In my view an authoritative server which does online signing and on-demand > record synthesis is a master server. You can make all your public > authoritative servers into masters if you like, but it must not be > required. > > If (like me) you have a more traditional setup then ANAME is an > instruction to the master server about zone maintenance, saying that it > needs to periodically update the sibling A and AAAA records, similar to > periodic re-signing, or as if some script were periodically `nsupdate`ing > the records. The secondary servers can continue to work the same as they > do now, but they'll work better if they know about some helpful additional > section rules for ANAME.
I think I (at least mostly) agree. One possible way to sort out these bits of potential confusion is to break the problem up into conceptual parts, so that one can see the way that they work together. One part is, "How do you give this instruction to the master server(s)?" It covers representation in the master file format, what a master is supposed to do on input, how to refresh the data, and so on. A second part is, "How do you give this instruction to a slave?". This covers transferring zones, the trade-offs in handing the slaves the ANAME vs the "resolved" records, refresh timers and so on. DNSSEC considerations at least are split between these, which suggests to me that these topics could be covered by one document in two parts; but these are nevertheless separate and separable functional questions. A third part has to do with downstream resolvers and caches and so on. This is really a separate problem: how to handle ANAME-aware vs ANAME-unaware systems, the consequences of an ANAME-unaware cache ending up with an ANAME in the cache, the effects of having an A and not AAAA in cache, &c &c. A fourth part, which might be yet a separate problem or might be the same document, is what this all looks like from a stub and what happens when there are chains of forwarders and caches and so on with a mix of ANAME-awareness and -obliviousness. I still think that in addition a clear description of why this is hard would be helpful. The troublesome thing about Stupid DNS Tricks is that they're always >80% there, and all the really hard parts are in that last <20%, and the difficulties in those <20% cases are manifold and completely unexpected when you think in the abstract cases. The people who worked through all the gnarly problems of caches and the interaction with DNSSEC already went through this once (I came in at the tail end and mercifully missed most of that), but we're about to revisit those problems for a different set of questions. I think we need to understand why this is more complicated than it looks, and I think any future implementer will need a clear guide to that also. ### WARNING: IETF ADMINISTRATIVE WRANGLING AHEAD ### Since there's been talk about an interim, it strikes me that the current issue is the sort of specific topic that deserves one. But I also wonder whether this isn't bumping up pretty hard against the DNSOP charter, and whether this mightn't be a case where we put together a tightly focussed statement of work that gets chartered as a WG, with a plan never to meet (or to meet only as "part of" a DNSOP meeting or something like that), if only to avoid pain and misery when the documents describing all this go to IETF LC. I am not interested even a little bit in making more administrative overhead, but I'm very much interested in avoiding a "this is off charter" discussion during IETF LC should we get there. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
