Hello Richard,
On 9 Apr 2017, at 3:38, Richard Gibson wrote:
I'm happy to see progress being made on this front. Some comments:
Thank you for taking the time for this.
*Section 3.1*
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 is the expected behavior when the target record set is empty, or
bogus, or when resolution fails?
Empty becomes empty. The common case will be ‘the ANAME target only
has A, no AAAA’ which means the AAAA lookup encounters a valid ‘no
data’.
If resolution fails (i.e. runs into an actual SERVFAIL-like error
condition, including ‘bogus’), we should also SERVFAIL. If the draft
is unclear on this we should definitely fix that.
*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.
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.
*Section 3.3*
Although labeled "DNSSEC signing", this section also contains more
general
specification (e.g., "the master server MUST respect the TTLs of the
address records" and "TTLs [of address records in a secondary server]
will
count down").
Then the section is misnamed or those specifications should be moved. I
will look at that.
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.
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
