On Jan 9, 2025, at 16:41, Mark Delany <m...@india.emu.st> wrote: > > On 09Jan25, Edward Lewis apparently wrote: > >> One option (blue sky again) is to switch to an arrangement where the server, >> for >> synthetic or tailored responses, reply with a formula (function). > > (Haven't we talked about this in previous threads?)
I wouldn’t be surprised. There are a lot of ways the DNS could be “improved”, noting that “improved” is in quotes. > I guess my first question is, what constitutes a synthetic answer? If the RRs > are pulled > from a database, is that synthetic? If the database uses stored procedures to > modify the > returned rows, is that synthetic? The RFC 1034/5 definition of the DNS protocol includes AXFR and that is where a synthetic answer is different from, um, unsynthentic (I don’t believe that is a real word). Originally (noting that DNS was defined in earlier RFCs) the way DNS was to reach operational resiliency and stability was to have one source of responses be answered by multiple servers that shared little to no fate. Different code bases (implementations) and maybe even different hosting platforms. It wasn’t uncommon for two schools to secondary for each other, in the days before there was any commercial market for DNS hosting. To achieve this, zone data had to be expressed in a standard zone transfer format (AXFR), printable as a zone file. With the desire even then to synthesize answers for names that did not otherwise exist in a zone, Wildcards(TM) was defined with the feature that the rules to synthesize fit into the AXFR message format. A cardinal rule at the time was coherency - all servers for a zone were expected to respond the same, to fulfill a true sense of resiliency. DNSSEC was defined for that era. For the same reasons “multi-signer” is a topic of discussion, synthetic responses are seen as something different than original zone-based answers. The trouble is - how do you coordinate different operating platforms for the same zone? I like to use the term “tailored answers” as it is true that it’s hard to see what “synthetic” means to a querier that might only see what is in a response. In base DNS, the response reveals little about how the data in it was obtained, DNSSEC just shows that the DNS process was followed. If it matters, any way to synthesize responses, tailor them to queries, other than Wildcards(TM) will require an interoperable (standard) definition so that all code base developers and platform operators could implement and deploy synthesis in the same manner. The design bottleneck is AXFR and what it can carry. But this is not a restriction, whatever way two servers can share instructions on how to synthesize in a coherent or complimentary fashion is what is needed, whether in AXFR or not. > Above and beyond trivial synthesis such as wildcards and reverse query > iterations, what > constitutes synthetic answers is so broad as to ultimately require the client > (I'll use > this term to cover anything closer to the edge) to implement a programming > language and be > able to store data... a lot of data. > > One very common case is geolocation. How does a client generate the answer > without > having a fairly complete copy of the geolocation database? This is a use case I’m familiar with, couple of jobs ago. The client (querier) doesn’t need to have the geolocation database - just be able to determine what information applies to it. Which still may not be easy. What makes this use case problematic is that you can base geolocation on things like cities or things like autonomous system numbers (physical world vs. network topology). It might be hard or impossible for a client to now where it is, physically or virtually. > > Another common case is service availability whereby the response is based on > which > endpoints can accept more requests. This is fairly dynamic data that all > participating > clients would need to refresh frequently. Yeah, in this case, the client can’t decide. The ultimate goal is traffic engineering. Connecting a querier to the best place for a service, with “best” meaning either best for the client or best for the service provider. I don’t think you can expect the DNS to solve this on it's own. > A third common case is split horizons which could be considered the > primordial form of > synthesis. > > Point being, any broadly useful client synthesis is a huge step up from mere > wildcard > expansion. In almost every case I can think of, the authoritative response > will end up > being the moral equivalent of a bundle of javascript and json or maybe an SQL > statement > and a database. That is very true. I wasn’t there when Wildcards(TM) were defined, but I bet it wasn’t to solve the traffic engineering issue. > So unless someone can codify a common and meaningful set of synthesis > capabilities which > a) don't require a lot of dynamic state and b) can be consistently > implemented by many > participating clients and c) doesn't turn clients into abuse targets for > crypto hashing, > then I suspect that you could expend a lot of energy defining very > constrained client > capabilities for very little benefit. > > On the bright side, end-point selection (which is the ultimate goal of > synthesis, right?) As far as the parenthetical question - maybe not. End-point selection is a major concern commercially and has become a big driver for better ways to synthesize answers. But synthesis might just be there to support management of what’s in the zone administrator’s database (like someone that runs cheap web server installations for thousands of customers). > is commonly implemented as HTTP redirects, so maybe the HTTP crowd have > thoughts since > they have far more experience dealing with high-capability clients. If any constituency can provide requirements, there are plenty of DNS engineers available to provide a solution. ;) _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
