On 10 Apr 2017, at 1:04, Richard Gibson wrote:
On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk
<peter.van.d...@powerdns.com>
wrote:
This section calls for limiting the TTL of cached address records to
the
lesser of the ANAME TTL and the TTL of the retrieved address
records, but
section 3 requires servers to follow chained responses. Are the TTLs
of
intermediate records in a chain supposed to be ignored?
What was the response on this point?
Oh, right. I suppose the right answer would be to take the lowest of all
involved TTLs.
Right; I definitely think there should be text explicitly defining
behavior
for timeouts, nonzero RCODEs, and bogus responses received when
looking up
ANAME targets. Section 4 covers part of it (for recursive servers
only),
but doesn't define how to determine when "resolution fails" or what to
do
when not opting to use the accompanying records as a fallback, and
there is
no guidance at all for authoritative servers.
Agreed.
*Section 3.2*
The wording of this section could use some improvement. It seems to
prohibit secondary servers from resolving ANAME targets when they
are
present at the same domain as address types... do I understand
correctly?
Yes, that is correct. We went through a few iterations and thought
exercises and this seemed like the optimal behaviour.
Dyn went another way with our ALIAS functionality, reserving
same-domain
address record sets for fallback data to be used whenever target
resolution
doesn't yield records of the appropriate type (including, perhaps
controversially, NXDOMAIN and NODATA empty responses). Assuming a
secondary
server predating ANAME, the Dyn behavior would be slightly better when
the
primary server is ignorant of that gap (i.e., the secondary would
always
serve fallback data) and identical behavior when it is not (i.e., the
authoritative would pre-expand as the draft specifies in Section 5).
It
also provides support for multi-type host names with single-type
targets,
e.g. static AAAA records sharing a domain with an ALIAS targeting a
name
providing only A records. Where it really shines, though, is in
handling
error cases like those discussed above—it was very important to our
customers that they could prevent us from ever issuing cacheable
negative
responses. What thought exercises took you in this direction?
Working back from the premise that there -will- be ANAME unaware
secondaries, we allow primaries to do the ANAME expansion during
outgoing AXFR (or on load, but in any case the secondary gets actual
(signed!) A/AAAA records). Thus, such a secondary will simply serve the
A/AAAA. To keep things simple, we decided that an ANAME aware auth will
do the same, so behaviour is consistent.
The alternative, of defining those records as fallback, means that ANAME
aware slaves that -do- receive a pre-expanded A/AAAA set, need
configuration knobs to figure out if they should look up the ANAME
target or not. We could automate this to a limit - say, if you are a
slave, you understand ANAME, and you do not have the private key for the
zone, then obviously you have to use what you find in the zone. However,
it was my feeling that this would yield more complexity than we want.
Anyway, I will ponder your use case.
As for ‘AAAA from config, A from ANAME’, we’ve been discussing
allowing multiple ANAMEs at a node, and then you could do something like
this:
www.example.com. ANAME www-v6.example.com.
www.example.com. ANAME example.com.my-cdn.com
www-v6.example.com. AAAA 2001:db8::80
Are such address records still subject to TTL decrementing
(presumably
starting at the time of zone transfer)? And when only a single
address
type
is present (e.g., just ANAME and A), does that still prevent
resolution of
the ANAME target for the other type?
(1) Yes, they are still subject to TTL decrementing, but if the slave
is
not ANAME-aware, no decrementing will happen and the draft allows
this, if
we wrote it all down correctly.
(2) Yes, when any address records are present, the ANAME is deemed to
have
already been expanded. If A is there and no AAAA, then this means
that
there is in fact no AAAA to be had.
I understand the motivation, but there's an interesting wrinkle with
respect to forward compatibility... what happens when a new address
type is
added to the DNS? The assumption that pre-expansion of any address
type
implies pre-expansion of all address types seems like it could lead to
some
dramatic changes in behavior as primary servers, secondary servers,
resolvers, and targeted zones become aware of the new type in a
nonuniform
fashion. Has any consideration been given to that concern?
Not by me so far, I’ll readily admit. Will ponder.
On a related note, should recursive resolvers query for ANAME targets
even
when they *don't* correspond to A or AAAA QTYPEs?
Probably not.
It is also mute on the use of DNSSEC for resolving ANAME target
records,
but that should probably be covered somewhere.
This is an interesting topic actually. There are existing deployments
of
PowerDNS ALIAS (which of course is quite similar to ANAME) that use
it
instead of ‘CNAME to unsigned’ so they can sign the target
addresses (that
they get via a non-DNSSEC but still secure path). This draft should
also
allow that. If you have suggestions for a section on ANAME target
resolving
and DNSSEC, please let us know.
Addressing the above points to explicitly define behavior for bogus
responses will cover the functional requirements, so this will likely
take
the form of MAY or SHOULD guidance for using DNSSEC when resolving
ANAME
targets.
Indeed.
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
