URI doesn't have quite the flexibility of SRV + TXT though.
One issue that might be relevant here is the transition from using the same protocol for client/resolver and for resolver/authoritative to a mode where the client talks to the resolver via an authenticated, encrypted protocol.
The client doesn't need or want most of the information it gets back in a traditional DNS exchange and the information it does require is split over multiple RRs and domains, each of which requires separate DNSSEC chains.
So I am thinking that as things stand, DNSSEC to the client is a heavy lift, but that is maybe not so much of a problem as we are going to have to rethink things for PQC world anyway. It is reasonable to expect the resolver to perform DNSSEC validation though and the resolver can do a lot of that offline by aggressively prefetching RRs and authenticating them before they expire.
So the client DNS lookup should be shortened to 'tell me the IP address, the port, the URI stem and the attributes for <protocol> at <service>', the resolver only needs to return one result at a time, the client will have to wait for a timeout before making a second attempt in any case. If there is a new RR that combines this information into one RR, that is fine, but otherwise, the resolver assembles the response from SRV + TXT.
Since the client is already 'in flux' as we try to deploy encryption, there might be a window of opportunity for deployment.
To get DNSSEC to work with PQC, we are going to have to replace the current approach with a Merkle tree type approach. So we build a Merkle tree over the RRs and instead of sending the full signature with each RR, we send the Merkle tree paths to complete the validation.
One trick I incorporated into my own DNS secure transport proposal a decade ago was to stretch the protocol so that while requests still have to fit into a single UDP packet, responses can be up to 16 packets. If any packet is lost, repeat the query.
I am now looking at combining the role of trusted DNS resolver with the role of presence service. If I am connected to a chat-like service, my client has to establish contact with some service that connection requests from third parties are directed to. So why not reuse that connection?
On Mon, Sep 18, 2023 at 9:09 PM Patrik Fältström <paf=40paftech.se@xxxxxxxxxxxxxx> wrote:
On 18 Sep 2023, at 14:17, Keith Moore wrote:
> I was thinking about what bugs me about trying to make SRV, or NAPTR+SRV, apply to all protocols.
This is why some of us made URI RR Type...
Patrik
> In addition to this being merely a potentially disruptive, incompatible change, that doesn't take into account subtle differences in the way different protocols use ports,
> it would also have a disruptive effect on internal network administration and politics of countless organizations. Specifically it would give enterprise top-level DNS administrators even more power than they have now, for better or (more often I suspect) for worse.
>
> (I'm still remembering a case in which company A divested company B from itself, and the new company B's marketing people decided to redo the company's web site, and told the IT people to replace ALL of the company's DNS records (including NS) with a new set of records, that wiped out every single web service that the company's products depended on working... And yes, the marketing people and the C*s who enabled them were incompetent beyond measure, but incompetence is part of the human condition. And how DNS needs to work is surprisingly subtle and invisible even to most computer people. And DNS as currently defined, or implemented by most service providers, arguably doesn't have the kind of access control that's needed for organizations in all of their complexity.)
