Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Richard Gibson]

On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk 
wrote:

> Thank you for taking the time for this.


My pleasure; this topic has frequently been on my mind over the past
several years. Thank you for drafting it.

*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 was the response on this point?

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 ’ which means the  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.
>

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.

*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  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?

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 , then this means that
> there is in fact no  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?

On a related note, should recursive resolvers query for ANAME targets even
when they *don't* correspond to A or  QTYPEs?

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.
___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Peter van Dijk]

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 ’ which means the  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 , then this means 
that there is in fact no  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

[DNSOP] The DNSOP WG has placed draft-hunt-dnsop-aname in state "Candidate for WG Adoption"

[IETF Secretariat]

The DNSOP WG has placed draft-hunt-dnsop-aname in state 
Candidate for WG Adoption (entered by Tim Wicinski)

The document is available at
https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop