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

[Tony Finch <[e-mail]>]

I have read through the draft. I like it a lot and I really want this
feature! I've quoted bits of it below (indented) and added my comments
and questions. Warning, this is nearly 1400 words...

1.  Introduction

Is it worth explicitly mentioning the case of subdomains such as
`department.example.edu` that have an MX and a web site at the same
domain?

2.  The ANAME Resource Record

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

Thinking out loud, I quite like the idea of relaxing this requirement,
but then I imagine what happens to the unlucky resolver that is
presented with a huge ANAME RRset...

3.  Authoritative Server Behavior

Should the intro to this section say that the auth server is expected
to cache the address records, not resolve them each time?

I think this auth section needs to be split into separate sections for
primary and secondary authoritative servers: primary servers do ANAME
target address record lookups (and have DNSSEC private keys for signed
zones); secondary servers passively receive ANAME + address records
via AXFR/IXFR, and do no lookups or signing.

In the secondary case, the cache logic is a bit different. The
upstream primary is responsible for implementing the TTL logic, but it
only needs to notify the secondaries when the records actually change.

3.1.  Address records returned with ANAME

   Address records with expired TTLs MUST NOT be used to answer
   address queries until refreshed by sending a new query to the ANAME
   <target>.

Can we make this a SHOULD NOT to allow for authoritative service to
continue working during an outage (serve-stale)?

   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.

I think it might be clearer if this paragraph is moved up to the start
of section 3.1 following the A and AAAA paras. You can then tie it
more directly to the presence/absence wording for each addr type.

   If resolution of the ANAME <target> yields no address records due to
   some other failure, and the query was for a specific address type,
   the response MUST include the ANAME record and set the RCODE to
   SERVFAIL.

It would be nice to allow for serve-stale here too.

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.

I think this should be conditional on whether the server is primary or
secondary wrt this zone. (The "already present" case sort of implies
secondary, but I think the difference should be more explicit.)

In the primary case I wonder if it would make sense for the server to
include the address records in the zone's persistent storage. It's
mildly tricky, tho, because:

(a) The server needs to distinguish between the case where it is
loading from a master file and it really is the primary, or it's
loading a master file that has been provisioned by some other system
that expands ANAME (i.e. it looks like a trad primary but it's
functionally a secondary that just isn't using AXFR/IXFR),

(b) What if the server starts off with a zone that lacks ANAME address
records, but they get subsequently added by an UPDATE?

(c) When it is loading a zone without ANAME address records, how does
it know that it is supposed to be a primary and resolve the ANAME
target, or that it ought to behave like a secondary but the ANAME
resolver found no records at the target?

(d) A primary that supports ANAME and ECS may need to persist the ECS
metadata in the zone file, and if that is the case there should be a
presentation format for ECS options and associated variant RRsets.
This is a horrible can of worms.

>From the server config / ops point of view it probably makes sense to
have a `resolve-aname-addresses` option which defaults to `on` for a
master/primary zone and off for a slave/secondary zone.

   Like other types, ANAME MUST NOT exist below a DNAME,

Should this mention occlusion?

3.3.  DNSSEC signing

   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

I think it would be better if this is a MUST NOT - either the server
is a primary and has the signing keys, or it's a secondary that
receives pre-re-signed address records from a primary.

   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.

I would upgrade this to a SHOULD - servers can skip this if they don't
support zone transfers.

   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.

Does this mean that there should be a NOTIFY every TTL? And when the
secondary refreshes the zone and finds there has been no change, it
can start counting down the TTL again?

   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.

I think a secondary server can know it needs to perform this special
countdown behaviour because the address records are next to an ANAME.

   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.

Yes - or, in the terminology I am using, without signed zone
transfers, every authoritative server has to act as a primary.

4.  Recursive Server Behavior

I think this needs changing for DNSSEC. Suggestion:

If the resolver is responding to a client with DO=1 and CD=0 and the
answer is signed, then it must return the authoritatively signed
address records to the client.

If the client queries with DO=0 or CD=1 or the answer is unsigned,
then the resolver can return its own version of the ANAME target
address records.

(In all cases the value of the AD bit in the query does not matter.)

In practice nowadays I think the majority of resolver clients (i.e.
stubs) have DO=0 - clearly it'll be good to get ANAME out the door
before end-user DNSSEC becomes a lot more common :-)

5.  Examples

   A query for example.com/AANME would receive only the ANAME in the

Typo!

6.  Operational Considerations

   When a zone containing ANAME records is transferred to a secondary
   server, the ANAME records are transferred, but the A or AAAA records
   retrieved from the ANAME <target> may not be.

In this case, in my primary/secondary split model, the secondary would
have to do the equivalent of flipping the `resolve-aname-addresses`
setting.

7.  Implementation Status

Maybe I should write a thing to periodically UPDATE a zone with
address records from an ANAME target (in my copious spare time) :-)

8.  Security Considerations

   An authoritative server which implements ANAME resolves address
   queries on behalf of its clients, either internally or by querying an
   external resolver.  This resolution must be allowed to take place
   regardless of whether the client would ordinarily have been permitted
   by local policy to send recursive queries.

I think this should be cross-referenced from earlier, because it's an
implementation requirement rather than just a consideration.

...

That's all for now, I think!

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet, Irish Sea: Southwest 5 or 6, veering west 6 to gale 8.
Moderate or rough, becoming very rough or high in Lundy and Fastnet. Rain with
fog patches then showers. Moderate or good, occasionally very poor.