Dear colleagues, On Fri, Mar 07, 2025 at 05:39:06PM -0500, Victor Zhou wrote:
Underscore Names that 8552 creates. Our intention is *not* to compete with or replace the underscore naming scheme, but rather to provide a complementary approach specifically focused on progressive adoption of new RR types.
If there is an example of "progressive adoption" of a new RRTYPE I'd like to know of it. The best example of such an intended progression I can think of is SPF, and the history there tells rather strongly against anything like any kind of progressive or even partial adoption. When we did SPFBIS, one of the things we learned was that the specification with a dual path of TYPE99 and TXT turned out to have a subtle bug in which two fully conforming implementations couldn't interoperate anyway. The reason TYPE99 got deprecated was because we had to pick one, and that's the one we picked. (I hope we don't need to re-hash in this thread why that was the correct or incorrect decision. Whatever you, gentle reader, believe about that correctness, I'll accept it as stipulated that my co-chair and I decided incorrectly about consensus.) The lesson I, at least, took from this was that specifying two different ways to communicate the same information through the DNS was a serious conceptual error. That's not too surprising to me, since the very point of strong typing in databases is not to have more than one way to communicate the same information. Also, in my experience in a past life as a database guy, every time you try to accommodate data without using your datatypes (stuffing it all into a blob or whatever) and then later try to normalize the data, you end up dancing through a bunch of transitional hoops to get the stuffed data into your shiny new datatypes. This might work when you're in charge of the database and the consuming clients, too. It doesn't work when you don't own both ends of the communication. I think what this boils down to is that I don't believe phase 3 in section 2.2 of the draft has reliable termination conditions, so it amounts in practice to the principle, "Use TXT for your RRTYPEs," only with the additional provision that all the TXT records have to carry around some additional cruft in their payloads forever. The chunking mechanism strikes me, at least on first reading, as somewhat unreliable given caches and truncation in the DNS. Since any RR of an RRSET ought to be as good as any other, you're not really in a position to signal upstream that you absolutely want the whole RRSET as the authoritative server has it or else you want not to get it. Now, it is true that a cache should not have a partial RRSET that it delivers in an answer if it got that RRSET via UDP and truncated for some reason. I am not convinced it is wise to rely on that principle in order to ensure that the entire RRSET for a given name and type will be guaranteed delivered to a final consumer; yet this chunking mechanism absolutely would require such a guarantee. I'm admittedly pretty rusty, so it might just be rust; but I cannot think of a case where promises about the completeness of the RRSET for a given name and type are made except I suppose in zone transfers. So this seems like an innovation in what we expect of RRSETs, and how we could convince ourselves that the expectation is already met in all deployed software under all deployed conditions is obscure to me. The draft says that implementations must reject a chunked data set with missing chunks and so forth, but I have no clue what an implementation might do if it encounters this condition. That seems to me to be a fatal objection, because the draft proposes this transition mechanism as one for any future new RRTYPE, and so will present an impediment to RRTYPEs that are naturally inclined to scrape the top of the TXT RR limit. It's particularly problematic because this mechanism adds overhead that a native RRTYPE wouldn't have: the "TXT limit problem" might actually be an artifact of using the mechanism in this draft, and yet it could be the source of deployment trouble. In sum, while I understand and have a lot of sympathy with the intent behind this draft (and anyone who has heard my extended complaining about TXT records and datatypes and so on will be able to confirm that sympathy), I don't think it is a good idea to pursue because I do not believe it will achieve what it would need to achieve. It will, however, complicate future specifications for uses of the DNS. It will inevitably encourage people to invent compatibility arrangements through TXT when they are not needed. That will provide a drag on adoption of a hypothetically proposed RRTYPE even as it also causes said RRTYPE to be hammered into the shape of a TXT payload. Unfortunately, this is an example of good intentions and the destination for which they can be pavement. Best regards, A -- Andrew Sullivan a...@crankycanuck.ca _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
