Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

[Bjørn Mork <[e-mail]>]

Is there a need to explictly modify MX and NS records, allowing them to
point to an ANAME?  Or is this already covered by the mandatory A or
AAAA records for the ANAME <owner>?

I believe this needs to be discussed in the light of the RFC2181
wording:

 |   The domain name used as the value of a NS resource record, or part of
 |   the value of a MX resource record must not be an alias. 


Is the ANAME owner an alias?

Should there be a section dealing with using an ANAME owner as a
target of other RRs?  This could probably be made very simple by saying
that an ANAME owner is allowed wherever an A or AAAA owner is.

>    Only one ANAME <target> can be defined per <owner>.  An ANAME RRset
>    MUST NOT contain more than one resource record.

Is there a technical reason for this?  I can easily see usecases for
multiple ANAMEs.  E.g using more than one CDN provider for a given
<owner>.

>    When an ANAME record is present at a DNS node and a query is received
>    by an authoritative server for type A or AAAA, the authoritative
>    server returns the ANAME RR in the answer section.

Is this a MUST, SHOULD or "may occasionally do"?

>    Because not all querying resolvers understand ANAME, the
>    authoritative server MUST also return address records, as described
>    below.
..
>    If resolution of the ANAME <target> yields no address records due to
>    NODATA or NXDOMAIN, then the authoritative server MUST return only
>    the ANAME record.  If the query was for a specific address type, then
>    the response MUST also include the SOA as in a normal NODATA
>    response, along with NSEC or NSEC3 if applicable.


Aren't these requirments conflicting?

There is also an exception for DNSSEC signing failures, where the server
is allowed to return only the ANAME.  I guess the "as described below"
can be interpreted as a condition for the MUST, but I believe the
exceptions should be made clear along with the requirement.  Or at least
make it clear that exceptions will follow.  E.g:

  "...MUST also return address records, except as noted below"

But if A or AAAA aren't really required after all, then why pretend they
are?

> 3.2.  Coexistence with other types
> 
>    If the zone is configured with an A or AAAA RRset at the same DNS
>    node as ANAME, then the ANAME is considered to have already been
>    expanded.  If during query processing any address records are found
>    at the same node as an ANAME RR, then the ANAME RR MUST NOT be
>    further expanded by the authoritative server.
> 
>    ANAME MUST NOT coexist with CNAME or any other RR type that restricts
>    the types with which it can itself coexist.
> 
>    Like other types, ANAME MUST NOT exist below a DNAME, but it can
>    coexist at the same node; in fact, the two can be used cooperatively
>    to redirect both the owner name (via ANAME) and everything under it
>    (via DNAME).
> 
>    ANAME can freely coexist at the same owner name with any other RR
>    type.

Is it really necessary to summarize the CNAME and DNAME rules here?
AFAICS, they are generic and not modified in any way by the introduction
of ANAME.

Maybe include the one ANAME per RRset restriction in this section, if
that is kept?

> 
> 3.3.  DNSSEC signing
> 
>    If the zone in which the ANAME resides is DNSSEC-signed, and if the
>    server has access to its private zone-signing key, then the A and
>    AAAA RRsets MUST be signed, either in advance when populating the A/
>    AAAA answers for the ANAME records, or "on the fly" when responding
>    to a query.
> 
>    If the server does not have access to the private zone-signing key
>    then it MAY return unsigned address records, but this is NOT
>    RECOMMENDED

'NOT RECOMMENDED' is too weak here.  The section conflicts with RFC4035:

 |   For each authoritative RRset in a signed zone, there MUST be at least
 |   one RRSIG record that meets the following requirements:
 |    ...


Suggested alternative text

    The server MUST NOT return unsigned address records.


>          unless every resolver with access to the zone is known to
>    support ANAME (as might be the case in a split-horizon deployment
>    where ANAME records are only served to an internal network with its
>    own resolvers).

I fail to see the relevance of this. You don't need an RFC to tell you
what you can do on your private network.  Although I guess an 'internal
network with its onw resolvers' using a CDN to provide service might
exist, I find this example really confusing.  It looks like a bad excuse
for the RFC4035 violation.  Which nobody is going to care about on your
'internal network' anyway.

I suggest removing this.

>    Validating resolvers which do not yet implement ANAME will not be
>    able to validate the A and AAAA responses included with an ANAME
>    response unless those responses are validly signed by a DNSKEY at the
>    apex of the zone in which the ANAME resides.  Passing along the
>    RRSIGs associated with the original A and AAAA RRsets from the ANAME
>    <target> will not be sufficient for DNSSEC validation.

Does this say anything useful at all? There is nothing ANAME specific
here. I suggest removing this as well.

The "which do not yet implement ANAME" is confusing at best.  Resolvers
having implemented ANAME will be equally unable to validate unsigned A
and AAAA responses included with an ANAME response.

> 
>    Implementers MAY allow address records associated with the ANAME to
>    be populated and signed by the primary server, then sent along with
>    their RRSIGs to secondaries via zone transfer.  In this case, the
>    master server MUST respect the TTLs of the address records, MUST
>    refresh the address records by re-resolving the ANAME <target> when
>    their TTLs expire, SHOULD respond to address queries with TTLs that
>    count down as they would when answering from a normal DNS cache, and
>    MUST inform secondary servers via DNS NOTIFY they need to refresh the
>    zone when address records have been updated.  A secondary server
>    SHOULD store address records and associated RRSIGs supplied via zone
>    transfer in such a way that their TTLs will count down, as they would
>    in a normal DNS cache, and ultimately trigger a zone refresh query
>    upon reaching zero.  When a secondary server is responding to an
>    address query, it SHOULD answer with the reduced TTL, but when
>    responding to a zone transfer request, it MUST answer with the
>    original TTL received from the primary.
> 
>    If this address record expansion and signing during zone transfer is
>    not supported, then every authoritative server providing ANAME
>    responses in a signed zone SHOULD have access to the private zone-
>    signing key for that zone.  Deployment of ANAME in signed zones where
>    address records cannot be signed due to lack of access to the private
>    zone-signing key is NOT RECOMMENDED.


I agree with Richard Gibson that the zone transfer considerations merit
their own section. This has nothing to do with DNSSEC.

The synthesized A and AAAA RRs are treated as authoritative dynamic
records, and DNSSEC, serial number calculation, zone transfers etc
should simply follow the normal rules for such records. Please don't
define rules allowing slaves to serve different content for the same
serial number.

The TTL handling rules also need to be split out of the DNSSEC section.
These rules should not depend on the zone being signed or not.

>    When ANAME is present in a signed DNS node and address records exist
>    at the ANAME <target>, the type bit map in the NSEC [RFC4034] or
>    NSEC3 [RFC5155] record for that node MUST include bits for A and/or
>    AAAA as well as ANAME.  This is for the benefit of validating
>    resolvers not implementing ANAME which may use a signed proof of
>    nonexistence for type A and AAAA to prevent address queries from
>    being resolved.  The type bit map SHOULD only include address types
>    which are known to exist at the <target>.

This is confusing.  Won't the type bitmap have to be correct for *any*
validating reolver, including those implementing ANAME? Or are they
supposed to modify it? If so, how?

> 4.  Recursive Server Behavior
> 
>    When a recursive resolver sends a query of type A or AAAA and
>    receives a response with an ANAME RRset in the answer section, it
>    MUST re-query for the ANAME <target>.  This is necessary because, in
>    some cases, the address received will be dependent on network
>    topology and other considerations, and the resolver may find a
>    different answer than the authoritative server did.  (This
>    requirement MAY be relaxed if both the ANAME <owner> and <target> are
>    validly signed and provably in the same zone.)
> 
>    If resolution fails -- for example, due to the local resolver being
>    nonfunctional or the ANAME <target> zone being unreachable -- then
>    the resolver MAY use the address records that were included in the
>    authoritative response as a fallback.  Otherwise, these records MUST
>    NOT be cached or returned.

This section needs a DNSSEC discussion.  It seems to be written under
the assumption that a recursive server can modify the answer.  This is
bogus, and you should know that.


Please solve the following problems:

 1) authoritative server answers an A query with with NSEC, ANAME, A,
    and valid RRSIGs for all three RRsets.  The recursive server
    implements ANAME and does further processing of it, replacing the A
    RRset.  What RRSIGs should it send to clients setting 'DO'?
    
 2) autoritative server answers an A query with NSEC + ANAME with valid
    RRSIGs, but no A or AAAA RRsets.  The recursive server implements
    ANAME and does further processing of it, adding an A RRset to the
    answer.  What RRSIGs should it send to clients setting 'DO'?
    



Bjørn