Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

[Andrew Sullivan <[e-mail]>]

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
[e-mail]