> I'm sorry but I don;t understand the point you are making here.
- A DNS query for an FQDN with a length of 255 using DNSSEC leads to a
336b message on the wire. It is unlikely that we will cram enough
into DNS to raise this above 1280.
- In the past, some vocal voices were rather clear that any changes
should be transparent for recursive implementations, as it is
unlikely that these will be changed so quickly.
- If a recursive receives responses from authoritatives adhering to
draft-ietf-dnsop-avoid-fragmentation-20, i.e., also the guidance
on authoritatives in draft-momoka-dnsop-3901bis-06, the messages
the recursive will receive will be fine.
- A recursive replying from cache might then create on-the-wire
messages that creates an issue. That, though, would either require
providing explicit guidance on recursive implementations w.r.t.
packet size, which was discouraged earlier given the difficulty of
changing all in-place implementations, or need to accept that this
already is a visible problem and in the authority of an individual
operator.
Hence, even though i do see the appeal in regulating this aspect, I
am currently unsure how it interacts with earlier suggestions on the
draft.
Also, I do have some scope concerns. Resolving those, would likely
require a more comprehensive approach, ensuring a tighter per-ID
scope.
> >
> HE territory? For the acronym challenged (myself included) what
> are you referring to here?
Ah, I was referring to 'Happy Eyeballs'; Initially in RFC6555, later
revised in RFC8305, this specifies how clients should interact in dual-
stack setting for selecting the IP protocol to use.
At the moment, there is draft-pauly-v6ops-happy-eyeballs-v3 ongoing.
This draft also includes guidance on transport protocol selection as
well, even though--at the moment--this only provides guidance on TCP
vs. QUICK.
> I would've though that a document that is recommending dual stack
> operation of DNS resolvers would either provide some clarification on
> its dual stack behaviour or provide a pointer to an RFC that
> contains this clarification.
The idea here was to seperate the operational requirement (equal
footing operation of IPv4 and IPv6) in this document, in line with the
prior phrasing of RFC3901, while leaving the selection aspect out of
scope. Adding this in this document would conflict with the prior work
of generally specifying that behavior in a dedicated draft.
This leaves, in my opinion, four options:
- Leave this aspect unmentioned, as per the approach in the (pre HE)
original RFC3901
- Create dedicated document(s) specifying transport protocol selection
for DNS (which might be relevant given the abundance of transports;
DoUDP, DoTCP, DoT, DoH, and all of that for v4 and v6); Especially
for DoT and DoH, though, this would also necessitate specifying
public key discovery for the authoritative and recursive case (i
recently pondered over TLSA in ADDITIONAL for that); There is also
the case of recursive discovery there, that needs to be addressed,
especially in the absence of PKI valid certificates; Even though
there TLSA in ip6.arpa/in-addr.arpa might be a thing.
- Add it in the current draft, potentially creating conflicting
guidance for DNS in comparison to the general efforts going on
- Add these considerations to the discussion around
draft-pauly-v6ops-happy-eyeballs-v3
I _personally_ would argue that the second approach would be the way to
go, aggregating the corresponding documents in a BCP ('a' BCP, as BCP91
is currently 'DNS IPv6 Transport Operational guidelines'; The BCP could
rather become 'Operational Guidelines on Discovering, Providing, and
Selecting DNS Transports for Authoritative and Recursive Servers')
Such would then have to contain (at least; open for suggestions):
- 3901bis
- draft-ietf-dnsop-avoid-fragmentation
- draft-tbd-dnsop-dns-auth-transport-selection
Guidance on how to select from available protocols; Would need
an additional document draft-tbd-dnsop-dns-auth-key-discovery
to enable DoH/DoT without names; Which should be straight
forward
- draft-tbd-dnsop-dns-rec-transport-selection
Expanding on, among others RFC9606, also needing an additional
document draft-tbd-dnsop-dns-rec-key-discovery for recursive
DNS key discovery in the case of DoH/DoT
The issue there is that there are some rather neat things that can be
done, especially to bring DoT/DoH to authoritative DNS (via TLSA in
additional, given that that would signal proto/port already);
However, there are also just 24h in my day, so if the WG would be
interested in a more fundamental 'all bases covered' approach that does
not blow a single document beyond clarity (imho), it might be good to
discuss this in Dublin more extensively (and have some of the documents
authored by more people, if there would be interest in such a
fundamental overhaul ;));
I do certainly see the appeal of nailing down that door for good by
creating an (extensible) BCP covering all bases.
With best regards,
Tobias
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
