[DNSOP] Comments on draft-dnsop-deleg-00.txt - section 2

[Edward Lewis <[e-mail]>]

As I'm not writing code, my comments will be less detailed...

# 2.  DELEG Record Type
...

# 2.1.  Difference between the records
# 
#    This document uses two different resource record types.  Both records
#    have the same functionality, with the difference between them being
#    that the DELEG record MUST only be used at a delegation point, while
#    the SVCB is used as a normal resource record and does not indicate
#    that the label is being delegated.  For example, take the following
#    DELEG record:
# 
#    Zone com.:
#    example.com.  86400  IN DELEG 1   config2.example.net.

Introducing something via an example leads to problems later on, as "definitions by example" create corner case gaps.  Even though it is said that the DELEG shares the format of the SVCB record, it would be good to give the generic definition first.

For one, having not read the SVCB document, the first RDATA field (1 or 0) seems to indicate whether the second field is the target for the requester or is another domain name the requester needs to consult.  It's not clear what happens if this value is 2 or more.
 
...
 
#    The primary difference between the two records is that the DELEG
#    record means that anything under the record label should be queried
#    at the delegated server while the SVCB record is just for redirection
#    purposes, and any names under the record's label should still be
#    resolved using the same server unless otherwise delegated.

Earlier it is said that the DELEG resource record is like the SVCB resource record, with some differences. When applying for an entry in the Resource Record (RR) TYPEs registry an application has to justify why a new type is needed.  For this, it would be good to have a section enumerating the reasons why DELEG needs a different type than SVCB.  (I know there are reasons, would be good to put them up with a generic definition of the resource record.)
 
# 2.2.  AliasMode Record Type
...
# 
#    example.com.    86400    IN  DELEG     0   config1.example.net.

Does the "0" mean that this is AliasMode?

# 2.2.2.  Loop Prevention
# 
#    The TargetName of an SVCB or DELEG record MAY be the owner of a CNAME
#    record.  Resolvers MUST follow CNAMEs as well as further alias SVCB
#    records as normal, but MUST not allow more then 4 total lookups per
#    delegation, with the first one being the DELEG referral and then 3
#    SVCB/CNAME lookups maximal.

A few questions - why 4?  (Besides it being tradition?)
Does the count of 4 include CNAME's?  What if it is DELEG CNAME CNAME CNAME SVCB CNAME CNAME CNAME?
What are the practical reasons for such chains (e.g., why would an operator ever see this)?

...I'm asking in the sense that some protocol elements are defined to be as general as possible, which winds up being a code implementation headache and then operator headache with little or no payoff...I'm not denying this may be useful, but a case should be made for it.

#    Special care should be taken by both the zone owner and the delegated
#    zone operator to ensure that a lookup loop is not created by having
#    two AliasMode records rely on each other to serve the zone.  Doing so
#    may result in a resolution loop, and likely a denial of service.  The
#    mechanism on following CNAME and SVCB alias above should prevent
#    exhaustion of server resources.  If a resolution can not be found
#    after 4 lookups the server should reply with a SERVFAIL error code.

It seems that the intent is to count each DELEG->CNAME->SVCB transition.  Okay, but the question of "why 4" still holds.

# 2.3.  Deployment Considerations
...
# 2.3.3.  Availability
# 
#    If a zone operator removes all NS records before DELEG and SVCB
#    records are implemented by all clients, the availability of their
#    zones will be impacted for the clients that are using non-supporting
#    resolvers.  In some cases, this may be a desired quality, but should
#    be noted by zone owners and operators.

There are application servers (web servers) that function (poorly) today where there is a delegation from a parent to a child zone that does not answer to NS records.  I used to see a lot of mangled DNS implementations that would only return address records (A resource records and maybe even AAAA resource records).  These situations work because of liberal resolvers, making use of the glue to send address requests to what the glue indicates, and those servers answering to A or AAAA requests.

When an operator decides to go all DELEG, meaning no more NS (DS), it might look like today's "broken set up" that only answers addresses.  I don't think that last sentence adequately covers the situation.  I don't have a suggest now.

# 2.4.  Response Size Considerations
# 
...This has become a larger concern (meaning from the 90's to the now's) than when DNSSEC was first designed.  Besides trying to make the DELEG as bitspace-efficient as possible, what can be done to simplify the use to minimize the number of DELEG/SVCB/... are needed (without getting specific here on what metric is minimized.)