On Mon, Sep 22, 2014 at 01:37:03PM -0400, Olafur Gudmundsson wrote:
> I’m getting confused about what the exact semantics of the proposed
> mechanisms are.
We're here to figure those out. Thanks for your input Olafur, appreciated!
>
> Q1: The intent is that ALIAS/ANAME/etc are a fallback rewrite operation if
> the name does not have the type asked for?
The intent is to solve the 'CNAME at apex'-problem. The implementation needs
to keep SOA, NS etc alive, but override at least A and AAAA. Hence the
fallback, to retain SOA and NS.
> Q2: Is there a good reason to restrict this to just the apex of a zone?
No, and it isn't implemented like that right now.
> Q3: Is there a good reason to restrict the target of A* to be in-zone ?
No, since the specific use-case is to hand off to a CDN name, which is
unlikely to be in-zone.
> Q4: Is there a good reason to restrict this to specific types? (Think about
> DANE cases with names like _443._tcp.@apex)
I think Tony's input that you might end up with an incompatible SPF
if you fall-through for MX makes a good case to restrict to 'address
records', currently A and AAAA.
The open questions are: what to do on an ANY query? You can't proxy on an
ANY query to auth as an ANY query to a resolver since the semantics are
different. ANY queries are fragile enough as is, but to maintain any
semblance of working, an ANY query hitting an ALIAS type should be proxied
on as an A and an AAAA query, and both should be tacked on to the answer.
Bert
>
>
> On Sep 22, 2014, at 6:03 AM, Tony Finch <d...@dotat.at> wrote:
>
> > I can see roughly three ways this might be done, in order of increasing
> > complexity...
> >
> > (1) Master-only. The master observes an ANAME record at the apex of a zone
> > it loads and uses it to periodically refresh the relevant records in the
> > zone (as if you had a cron job running dig | magic | nsupdate).
> >
> > Disadvantage: potentially lots of XFR traffic if the TTLs are low.
>
> Disadvantage: if the target is a CNAME what does the master do?
> It either need to know ALL possible types that may exist or use NSECx record
> to determine what exists.
> Possible disadvantage: Master/master signer needs access to resolver to
> access out of zone-data.
>
> Further disadvantage: if the A* target is out of zone at a CDN then the
> answers the “master” gets back reflect its
> location.
>
> >
> > (2) Authority-only: All authority servers recognize ANAME records,
> > PowerDNS style.
> >
> > Disadvantage: all authority servers need DNSSEC private keys.
>
> Not an absolute requirement, we could play type code tricks that allow master
> server to store
> A* target records as different types but servers know that to check for them
> if A* exists.
> Disadvantage: All authority serves supporting A* need to know about type
> translation and signers need to know to perform actions.
>
> >
> > (3) DNAME-style: Authority servers and resolvers recognize ANAME records.
> > ANAME-aware servers (auth and rec) return the synthesized records for
> > backwards compatibility, without signatures. For DNSSEC purposes the
> > signed ANAME goes in the answer section and the original signed target
> > goes in the additional section.
> >
> > Disadvantages: forklift upgrade; DNSSEC codepoint rollover.
> >
>
> You mean DNSKEY alg code points,?
> We only have 5 popular algorithms so that is not a big deal?
>
> Olafur
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
