Re: [DNSOP] Minimum viable ANAME

[Paul Wouters <[e-mail]>]

On Wed, 19 Sep 2018, Paul Vixie wrote:

> Tony Finch wrote:
>>  Anthony Eden<anthony.eden=[e-mail]>  wrote:
>>
>>>  FWIW, there's still always
>>>  https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/
>>
>>  I get the impression that a lot of the objection to the current ANAME
>>  draft is that it specifies that auth servers do ANAME target lookups and
>>  record substitution; your draft says the same thing. I think those
>>  objections are reasonable, but I don't think the problem lookups are
>>  particularly important (or even helpful).
>
> +1.

4.  Security Considerations

    To function properly with DNSSEC-aware resolvers, authoritative name
    servers MUST sign the materialized records produced by the ALIAS
    resolution.

    Implementors MAY either materialize A and AAAA records offline and
    sign the resulting records at that time, or sign the resulting
    materialized records at request time.


This is not a proper Security Consideration section. Please see https://tools.ietf.org/html/rfc3552
What is described here is a fundamental flaw in this proposal.

That fact is even more clear by the MAY in that section, which basically
says "you can address this security issue or not, whatever"

A mechanism could be designed that is more generally usable.

Forcing a authoritative servers to do DNS lookups is asking for trouble.
Some deployments combine auth+recursive and such a server now needs a
working resolv.conf, and one that cannot point to itself. Clearly this
is going to break stuff. We have known for decades that combining
authoritative plus recursive was a bad idea, yet here it is again
glueing these two parts together so the auth server needs resolving
code. The place to do anything is on the resolver, the authoritative
server should just serve blobs.

Synthesizing (here called "materialising" ?) records is awful. It does
not work with offline DNSSEC signers, and if we want to solve this
properly, we can do so easilly with a solution that does not have
this limitation.

The design goals of a solution in this space should be:

- Fully supports DNSSEC
- Does not require AUTH server changes other then supporting a new
   RRTYPE presentation / wire format and/or serving a new RRTYPE as
   Additional Data.
- All optimization work is done on the resolver. If this includes
   'rewriting' A/AAAA records, DNSSEC proofs MUST be included for
   stub clients doing validation.


for example, why not serve an ALIAS record as additional data to A/AAAA
queries? Then resolvers that dont support this are as bad of as now.
Resolvers supporting this, will pick up the ALIAS, resolve it, put those
A/AAAA records in cache, and serve any clients asking for these A/AAAA
with the A/AAAA, ALIAS and target A/AAAA records.

Paul