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

[Edward Lewis <[e-mail]>]

I won't be pedantic (nits, wording) this time around, just raise conceptual issues in section 1

# 1.  Introduction
# 
#    In the Domain Name System [STD13], subdomains within the domain name
#    hierarchy are indicated by delegations to servers which are
#    authoritative for their portion of the namespace.  The DNS records
#    that do this, called NS records, contain hostnames of nameservers,
#    which resolve to addresses.  No other information is available to the
#    resolver.  It is limited to connect to the authoritative servers over
#    UDP and TCP port 53.

Other information must be assumed...this is a crucial weakness.

#    This limitation is a barrier for efficient introduction of new DNS
#    technology.  New features come with additional overhead as they are
#    constrained by the intersection of resolver and nameserver
#    functionality.  New functionality could be discovered insecurely by
#    trial and error, or negotiated after first connection, which is
#    costly and unsafe.

Note that the DNS protocol does not have "connections" - which is a stumbling block before even getting to the "costly and unsafe" stage.  One could point out that it would be possible to introduce connections, thus sessions, in the DNS, but you would need a mechanism like DELEG to get to that point.

#    The proposed DELEG record type remedies this problem by providing
#    extensible parameters to indicate capabilities that a resolver may
#    use for the delegated authority, for example that it should be
#    contacted using a transport mechanism other than DNS over UDP or TCP
#    on port 53.

"it" .... each of the authoritative servers.  Sorry, I won't be pedantic, just to remember that the document has to be very clear and precise.  (Looseness breeds clarification documents...)
 
#    DELEG records are served with NS and DS records in the Authority
#    section of DNS delegation type responses.  Standard behavior of
#    legacy DNS resolvers is to ignore the DELEG type and continue to rely
#    on NS and DS records (see compliance testing described in
#    Appendix A).  Resolvers that do understand DELEG and its associated
#    parameters can efficiently switch to the new mechanism.

and (possibly) ignore the NS and DS resource records.  It would be good to have an idea when NS and DS could be retired.  Perhaps not by us, but by our student's students. __
 
#    The DELEG record leverages the Service Binding (SVCB) record format
#    defined in [RFC9460], using a subset of the already defined service
#    parameters.
# 
#    DELEG can use AliasMode, inherited from SVCB, to insert a level of
#    indirection to ease the operational maintenance of multiple zones by
#    the same servers.  For example, an operator can have numerous
#    customer domains all aliased to nameserver sets whose operational
#    characteristics can be easily updated without intervention from the
#    customers.  Most notably, this provides a method for addressing the
#    long-standing problem operators have with maintaining DS records on
#    behalf of their customers.  This type of facility will be handled in
#    separate documents.

I believe there is a lot more to be said here, relating the benefits of this to the DNS operator community.  It will take a lot of resources to convert from the DNS protocol using NS resource records to a DNS protocol using DELEG resource records for delegation (sounds like ipv4 vs. ipv6) and these resources will come from DNS operations.  The pain of operating DNS today is what DELEG wants to ease, there's the tradeoff.

# 1.1.  Terminology
# 
#    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
#    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
#    "OPTIONAL" in this document are to be interpreted as described in
#    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
#    capitals, as shown here.
# 
#    Terminology regarding the Domain Name System comes from [BCP219],
#    with addition terms defined here:
# 
#    *  legacy name servers: An authoritative server that does not support
#       the DELEG record.
# 
#    *  legacy resolvers: A resolver that does not support the DELEG
#       record.
# 

Legacy is such a generic word.  I'll propose NS-only name servers and NS-only resolvers to capture this distinction.

# 1.2.  Motivation for DELEG
# 
#    *  There is no secure way to signal capabilities or new features of
#       an authoritative server, such as authenticated DNS-over-TLS.  A
#       resolver must resort to trial-and-error methods that can
#       potentially fall victim to downgrade attacks.
# 
#    *  Delegation point NS records and glue address records are, by
#       design, not DNSSEC signed.  This presents a leap of faith.
#       Spoofed delegation point NS records can be detected eventually if
#       the delegated domain was signed, but only after traffic was sent
#       to the (potentially) spoofed endpoint.
# 
#    *  The Registry, Registrar, Registrant (RRR) model has no formally
#       defined role for DNS operators.  Consequently, registrants are the
#       channel between DNS operators and registries/registrars on purely
#       operational elements, such as adding NS records, modify DS records
#       when rolling keys, etc.  Deleg's AliasMode allows the registrants
#       to delegate these facilities to a DNS Operator.
#
# 1.3.  Introductory Examples
# 
#    To introduce DELEG record, this example shows the authority section
#    of a DNS response that delegates a subdomain to another nameserver.
# 
#    example.com.  86400  IN DELEG  1 ns1.example.com. (
#                    ipv4hint=192.0.2.1 ipv6hint=2001:DB8::1 )
#    example.com.  86400  IN NS     ns1.example.com.
#    ns1.example.com.    86400   IN  A  192.0.2.1
#    ns1.example.com     86400   IN  AAAA    2001:DB8::1
# 
#    In this example, the authoritative nameserver is delegating using the
#    same parameters as regular DNS, but the delegation as well as the
#    glue can be signed.

I'm conflicted when it comes to signing glue.  I understand the concern about unsigned glue but signing it has to be understood in its context.  When glue is signed, it can be assumed to be what came from the registry/database managed by the parent which does not quite put it on the level of what is in the registry/database of the child.  The two gaps are the child keeping the parent up to date and the possibility that the parent's copy is fraudulently changed (e.g., child's provision account password is weak).  Signing is good, but what a validated glue record means is important.

I have seen situations where resolvers have used glue to reach an answer despite the child's nameservers being broken.  Sometimes the less authentic is better than the authentic (i.e., glue address is better than SERVFAIL from child if the ultimate target is still up).  The things you see in operations...

#    Like in SVCB, DELEG also offer the ability to use the Alias form of
#    delegation.  The example below shows an example where example.com is
#    being delegated with a DELEG AliasMode record which can then be
#    further resolved using standard SVCB to locate the actual parameters.
# 
#    example.com.  86400  IN DELEG 0   config2.example.net.
#    example.com.  86400  IN NS     ns2.example.net.
# 
#    The example.net authoritative server may return the following SVCB
#    records in response to a query as directed by the above records.
# 
#    config2.example.net 3600    IN SVCB . (
#                    ipv4hint=192.0.2.54,192.0.2.56
#                    ipv6hint=2001:db8:2423::3,2001:db8:2423::4 )
# 
#    The above records indicate to the client that the actual
#    configuration for the example.com zone can be found at
#    config2.example.net
# 
#    Later sections of this document will go into more detail on the
#    resolution process using these records.
# 
# 1.4.  Goal of the DELEG record
# 
#    The primary goal of the DELEG records is to provide zone owners a
#    method to signal capabilities to clients how to connect and validate
#    a subdomain.  This method coexists with NS records in the same zone.
# 
#    The DELEG record is authoritative in the parent zone and, if signed,
#    has to be signed with the key of the parent zone.  The target of an
#    alias record is an SVCB record that exists and can be signed in the
#    zone it is pointed at, including the child zone.

A third goal lies in the problem behind the old DBOUND WG and what has given rise to the Public Suffix List, that is the ability to determine when a delegation crosses an administrative boundary.  For example, from a "top level domain" to a paying customer, as opposed to a delegation within an enterprise network.  Adding a flag to indicate the "distance" between the parent and child borders on scope creep and possibly can be achieved via another method, but if we are collecting all pertinent information about a delegation in one place, this should be considered as a piece of pertinent information.

"Third goal lies" ... take that as "perhaps."  I think this is something to consider but it's not obviously something to include.

# 1.5.  DNSSEC is RECOMMENDED
# 
#    While DNSSEC is RECOMMENDED, unsigned DELEG records may be retrieved
#    in a secure way from trusted, Privacy-enabling DNS servers using
#    encrypted transports.
# 

This is awkward.  DNSSEC targets data security, not channel security, so suggesting that a secure channel without DNSSEC is on par with DNSSEC's work seems to be a stretch.  Maybe not for the end point of the secure channel, but if it tries to pass the information onward (operating as a cache), it'll lead to some "sharp edges" in corner case land.

#    FOR DISCUSSION: This will lead to cyclical dependencies.  A DELEG
#    record can introduce a secure way to communicate with trusted,
#    Privacy-enabling DNS servers.  For that, it needs to be DNSSEC
#    signed.
# 
# 1.5.1.  Preventing downgrade attacks
# 
#    A flag in the DNSKEY record is used as a backwards compatible, secure
#    signal to indicate to a resolver that DELEG records are present or
#    that there is an authenticated denial of a DELEG record.  Legacy
#    resolvers will ignore this flag and use the DNSKEY as is.
# 
#    Without this secure signal an on-path adversary can remove DELEG
#    records and its RRsig from a response and effectively downgrade this
#    to a legacy DNSSEC signed response.

I get concerned when I hear that flags are defined for things like this - there's a bit of trouble tracking DNS public keys because Automated Updates (RFC 5011) adds a revoked but, which alters the key tag calculation for the DNSKEY resource record.  So before being convinced this is a good idea or necessary, I need to ask "wouldn't a DELEG-expecting resolver be able to determine that there's no DELEG resource record set at the parent in the same NSEC* record(s) used to determine whether there is a DS resource record set published by the parent for the child?"

# 1.6.  Facilities
# 
#    The DELEG record is extensible in such a way that future innovations
#    in the domain name system, such as new methods of secure transport,
#    message encoding, error reporting, etc, does not depend on a re-
#    design of the DNS.

But the DELEG resource record enables redesigning (portions or all of) the DNS.  I think the point is that DELEG allows the DNS namespace to continue to be published while there are transitions in the DNS publication protocol (motivated by improving the state of operations).