On Fri, Nov 9, 2018 at 11:39 AM Tony Finch <d...@dotat.at> wrote:

> Richard Gibson <richard.j.gib...@oracle.com> wrote:
> >
> > First, I am troubled by the requirement that ANAME forces the zone into a
> > dynamic zone.
>
> I don't see how it is possible to implement ANAME without some form of
> dymamic behaviour, either by UPDATEs on the primary, or on-demand
> substitution on the secondaries, or some combination of the two.
>

I think we have different viewpoints here:
- ANAME replaces existing CDN tricks, and the A/AAAA records are always
dynamically generated.  If ANAME leads nowhere, then there is no answer.
Or:
- ANAME is a new feature, which can be used instead the standard A/AAAA
records by the few server where ANAME is implemented.
Updates to the A/AAAA records can be done at the source, the same as any
normal zone update.  No special processing required on the authoritative
servers.  Only the recursive servers use ANAME if they support that new
feature.  If ANAME leads nowhere, then ignore the new broken feature and
return the standard A/AAAA records.  This option could be implementation
dependent.  (This is the view I prefer, at least until ANAME becomes
widespread.)


> > Second, and relatedly, I think the TTLs of replacement records
> established for
> > non-transfer responses are too high. Respecting the TTL of every record
> in a
> > chain that starts with the ANAME requires the TTL of final replacement
> records
> > to be no higher than the minimum TTL encountered over the chain,
> potentially
> > /reduced/ nondeterministically to mitigate query bunching. I would
> therefore
> > add language encouraging resolvers synthesizing those records to engage
> in
> > best-effort determination of original TTLs by (e.g., by directly querying
> > authoritative servers and refreshing at 50% remaining), but *requiring*
> them
> > to decrement TTLs of records for which they are not authoritative.
>
> I'm not sure I understand which TTLs you are worried about here. What are
> "non-transfer responses"? There's certainly some rewording needed to make
> it more clear, but the TTLs returned by resolvers that do sibling address
> record substitution are decremented in the usual way, and resolvers make
> no attempt to determine the original TTLs.
>
> It isn't possible to require a resolver to query authoritative servers
> directly.
>

I am inclined to use the TTL of the sibling A/AAAA records and avoid the
work and concerns of guessing the right ttl.  That gives the zone owner the
control, rather than the owner of the ANAME target.  (I am typically a zone
owner, so I prefer to have control.  Others may differ.)


> > And finally, back on the question of what ANAME sibling address records
> > actually represent, I think that NXDOMAIN and NODATA results should be
> treated
> > as errors for the purposes of ANAME sibling replacement. This position
> can be
> > justified on both practical and principled grounds—replacing functional
> > records with an empty RRSet is undesirable for DNS users (or at least the
> > sample of them that are Oracle+Dyn customers),
>
> Maybe so, but that's what happens with CNAME records.
>

If I view A/AAAA as standard, and ANAME as optional (shiny new feature),
then I prefer the A/AAAA if ANAME fails.  CNAME is standard, which is much
different than ANAME in this viewpoint.


> > and could inappropriately stretch the maximum specified ANAME sibling
> > TTL (on the ANAME record itself) to the SOA MINIMUM value (which is
> > doubly bad, because it results in extended caching of the /least/
> > valuable state).
>
> That's a very good point, thank you.
>
> > Let's please just eliminate all of that by specifying that ANAME
> > processing can never replace something with nothing.
>
> So when the target goes away, you would prefer to leave behind zombie
> address records, and stretch their TTL indefinitely? If the zone admin is
> given only a target hostname (just like a CNAME) they don't have any
> alternative addresses to use when the target goes away. So the options are
> to copy the target by deleting the addresses, or ignore the target and
> leave the addresses to rot.
>
> I'm inclined to say that fallback records should remain a non-standard
> feature. The semantics can be that when you see the target go AWOL, delete
> the ANAME and its siblings, and replace them with the fallback records
> that were specified by some other means. You can apply the same logic to
> CNAMEs too, if you want :-)
>
> > P.S. There is a typographical error in Appendix D; "RRGIG" should be
> "RRSIG".
>
> Thanks.
>
> > P.P.S. I think it has been discussed before, but this document should
> also
> > introduce and use a new "Address RTYPE" registry or subregistry, rather
> than
> > forever constraining ANAME exclusively to A and AAAA.
>
> The -01 draft specified a registry but I dropped that from -02 because I
> was not sure if it should include X25, ISDN, NSAP, ATMA, the ILNP types,
> the Nimrod types, etc. And now I realise that it needs a lot more thought
> about what will happen to interoperability when the registry changes.
>

I agree that needs more thought, but I hope ANAME can cover future address
types.


> Tony.
> --
> f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/
>
>
-- 
Bob Harold
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to