On Tue, Aug 23, 2022 at 02:51:33PM -0700, Brian Dickson wrote:
> - The problem is whether/when/how the DNS queries are considered
> failures, and whether/when/how some sort of fall-back procedure is followed
> in those cases.
Indeed "failure" may not be consistently defined.
- On the one hand we have "lookup failure" to locate the SVCB (or HTTPS)
records: SERVFAIL, timeout, loop, "bogus" (if doing in application
DNSSEC validation), ...
- On the other we have "lookup success" that establishes the
non-existence of the desired SVCB (or HTTPS) record, i.e.
NODATA or NXDOMAIN.
In Section 3, "failure" appears to subsume both cases:
Once SVCB resolution has concluded, whether successful or not, SVCB-
optional clients SHALL append to the priority list an endpoint
consisting of the final value of $QNAME, the authority endpoint's
port number, and no SvcParams. (This endpoint will be attempted
before falling back to non-SVCB connection modes. This ensures that
SVCB-optional clients will make use of an AliasMode record whose
TargetName has A and/or AAAA records but no SVCB records.)
But then in 3.1:
If DNS responses are cryptographically protected (e.g. using DNSSEC
or TLS [DoT][DoH]), and SVCB resolution fails due to an
authentication error, SERVFAIL response, transport error, or timeout,
the client SHOULD abandon its attempt to reach the service, even if
the client is SVCB-optional. Otherwise, an active attacker could
mount a downgrade attack by denying the user access to the SvcParams.
One immediate difficulty is that while a client can request
DNSSEC-validated answers (by setting the DO bit in outgoing queries, or
trusting the "AD" bit from a *loopback* validating recursive resolver),
it is not possible to know whether the response is not "crytographically
protected" when the query times out, or the response is SERVFAIL, ...
So the intent in 3.1 is somewhat unclear. Perhaps the idea is that the
client could have prior knowledge that it ought to have access to
DNSSEC-validated answers (no last-mile issues)? Some clarification may
be appropriate.
Secondly, given that $QNAME (in the case of SVCB rather than HTTPS)
starts out "prefixed" with attrleaf labels, there may be issues
associating A/AAAA records with such labels, in that these violate RFC
1123 Section 2.1:
https://www.rfc-editor.org/rfc/rfc1123#section-2
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
...
zone file validators may flag attrleaf names with address records as
errors. This is not an issue for HTTPS records that don't use prefix
labels, but it is an issue for SVCB. Since the intent is to be sure
to at least follow AliasMode indirection, even if no SVCB records are
ultimately found, the appended name should be *unprefixed* when no
AliasMode records were followed.
It might also be noted that when the final AliasMode target name has
_label prefixes, the zone owner implicitly expects SVCB records at that
target, since such names again should not have A/AAAA records (or is
2.1 of RFC1123 now largely outdated).
> - The ONLY concern is whether an AliasMode record (particularly at the
> zone apex) is treated EXACTLY the same as a constrained CNAME (i.e.
> unconditional QNAME rewrite if the RRTYPE is appropriate).
This question of course only makes sense if the client has managed to
obtain at least one AliasMode SVCB or HTTPS record, thus establishing
that the ambient network environment was not hostile to SVCB/HTTPS
resolution at the time of that query.
In that situation I'd be inclined to make a *stronger* statement:
* When the initial SVCB (also HTTPS, ...) query returns an AliasMode
result, lookup failures in all subsequent SVCB/HTTPS queries are "fatal"
even for SVCB-optional clients.
This more closely approximates predictable client behaviour that doesn't
randomly ignore redirection records on unexpected transient "lookup
failures" (see above vs. "lookup success").
Of course if even the initial lookup fails, the client may well be using
unsecured UDP behind a broken CPE (that mangles queries for unfamiliar
record types), and may have no ability to resolve any SVCB or HTTPS
records, and have no access to DoH or DoT. In that case it seems
somewhat reasonable for SVCB-optional to fall back to status quo ante.
> - Unconditional would imply that an HTTPS-aware (or SVCB-aware, if
> you prefer) client never backtracks to the origin name to look up A/AAAA
> records for use, or more precisely, if the client does look up the
> A/AAAA
> records speculatively, if it gets an AliasMode record, it does not use
> those A/AAAA records under any conditions.
Right, if at least one AliasMode record was seen, then "lookup success"
for further SVCB/HTTPS should be required, or otherwise the connection
fails. This matches the behaviour one would get with CNAME, scoped to
just the service type in question.
> - Conditional would imply that there are conditions under which the
> client MIGHT use sibling A/AAAA records instead of a valid AliasMode
> record, even if the AliasMode record was cryptographically protected and
> did not have a Chain-Length error. This situation, even if only "under
> certain circumstances", is the ANAME behavior.
This I agree would be suboptimal. Once we have establish the viability
of SVCB (or HTTPS) lookups, they need to be used consistently.
> - In section 3, the term "SVCB-optional" specifically only refers to
> "ServiceMode Records" (FIXME qv section 3.1 and 10.1 exceptions)
Correct, some hypothetical clients may not be able to proceed without
some mandatory parameters that an IP address alone cannot provide.
Such clients have no choice but to fail if no SVCB records are found.
Other clients may be able to operate in legacy mode.
Regarless, once AliasMode records are found, these MUST be used and
partial lookup failure along a non-empty (so far) alias chain needs
to be fatal.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
