A while back, I realized that I needed a full DNS client implementation to do proper DNS discovery. So I reduced the existing specs to a file that does capture the syntax:
https://github.com/hallambaker/Mathematical-Mesh/blob/master/Libraries/Goedel.Discovery/Domainer.domainer I use that file to generate implementations of the parsers for client and server for both the wire and config file format in c#. The same generator could be used to generate implementations for C, go or whatever. The file could be annotated with descriptive matter and used to generate a draft with consolidated syntax. Going further than a consolidated, consistent reference becomes tricky because the group would have to decide on what the DNS architecture has become. It certainly is not what it was intended to be. Whether it is now one thing is debatable and there would be arguments. Harder still would be to get progress on what the architecture should be in the future. Nothing invites ideology more than the topic of naming and one of the biggest problems is that there are too many folk who consider themselves to be the supreme, infallible and sole expert on the topic to the point. I was once in a WG in another forum where 30 people got into a room and 29 of them managed to convince themselves that the world would embrace a protocol in which an account identifier was http://just.how.stupid.is.this.com/alice. My view is that naming in a protocol architecture is whatever meets the needs of the protocol and in particular of the users. Consistency is also important but that does not justify insisting on something that consistently fails to meet the needs of users. If we were to re-engineer the DNS protocol, I would apply the following principles: 1) Separate the client-resolver and resolver-authoritative protocols. These are separate problems and should be supported independently because they have entirely different deployment bases. If we ever want to change the DNS protocol, we will have to consider the two deployments as entirely separate. So for example, let us imagine someone invents a new resolver-authoritative protocol which is more efficient, aware of DNSSEC, SRV and geo-location issues, etc. Such a protocol would be focused on the problem of optimizing the process of cache update. It might even be push-based rather than pull. Such a protocol would adopt the DNS data model and record structure but could change everything else. It could probably deliver real value if it was only adopted by a handful of major ISPs and hosting providers. If anyone wants to do this, they can probably shake $50 million out of a VC by doing little more than wearing a black turtleneck and mumbling 'blockchain' a lot. We are already looking at changing the client-resolver model in DPRIV. It is a slippery slope. They are going down it slowly and carefully, I wanted to use skis. 2) Make [RFC6763] the preferred approach for all service discovery and description S. Cheshire and M. Krochmal "DNS-Based Service Discovery" RFC 6763 DOI 10.17487/RFC6763 February 2013 One corollary of this would be to admit defeat on DANE which is a dead end for reasons that were explained 7 years ago. RFC6763 has deployment, it is the way the home internet works today and how all Internet services should work in the future. There should be one mechanism to discover and describe services. That is what RFC6763 describes.. * Prefixed SRV records on the service address define the host addresses * Prefixed TXT records on the service address describe the service properties * Prefixed TXT records on the host address describe the host properties It is clear, logical, precise, consistent. That TXT record is obviously the place I want to specify that clients MUST use TLS/1.3, that they can use JSON, JSON-B or CBOR encoding, etc. So why would I specify the TLS source of authority anywhere else? 3) Understand DNSSEC as being a mechanism to authenticate security policy statements distributed through the DNS. DNSSEC secures those TXT and SRV records. Well that is how I plan to go forward at any rate. Unless someone wants to suggest a better approach that meets my needs. On Wed, Mar 28, 2018 at 9:41 AM, Suzanne Woolf <suzworldw...@gmail.com> wrote: > Note this discussion has started to split into (at least) two: cleaning up > the DNS standard (protocol, documents, or both), possibly in a new WG; and > whether/how the existing DNSOP WG needs to adjust its efforts. > > > On Mar 27, 2018, at 3:49 AM, Ondřej Surý <ond...@isc.org> wrote: > > > > Hi Suzanne, > > > >> If the WG feels that the previous view of how DNSOP should work has > been overtaken by events, we can certainly work with our Area Director (hi > Warren!) on a revised charter. > > > > > > I strongly believe that any work on cleaning up DNS protocol and/or > rewriting RFC1034/RFC1035 and associated document would need a new WG with > tightly defined charter. > > > > Hence, I will not request or I won’t support adopting my > deprecating-obsolete-rr-types as a WG document - it might become one of the > first documents for new WG, or it might end up as individual submission. > While this work might be considered as “protocol maintenance”, I think it > is bigger then simple protocol maintenance. > > > > Again, from experience from dnsext, I would strongly suggest that any > work in this area is split into CHANGE documents and REWRITE documents, > with strict scope. Documents rewriting existing RFCs while adding more > stuff at the same time tend to not reach the finish line. > > This all makes sense to me. > > I have no opinion (yet) on what the desired output should be (some new > RFCs? A reference implementation/RFC set? Something else?), but agree it > doesn’t fit DNSOP. > > Personally I think it’s within charter for DNSOP to facilitate this > discussion, permit it to stay on the WG mailing list, etc. while people > work out how they want to approach it, in substance and process. For > instance, DNSOP helped get DPRIVE going by having a session at an IETF > meeting on the DPRIVE drafts and adopting one of them (QNAME minimization). > The important thing should be whether there’s an identifiable work item and > whether the will exists to get it done, not how to charter a WG or > otherwise work the process machinery. There are quite a few DNSOP (and > IETF) regulars who are current or past WG chairs, ADs, and document > editors, with experience of making the IETF machinery turn, who would be > happy to advise proponents. This includes the current DNSOP chairs and AD.. > > I do have to say I support the warnings about getting bits committed to > documents (and possibly code). As another anecdote to add to the stack, I > remember (as I assume Paul Vixie, Matt Larson, Rob Austein, Ed Lewis, and > Roy Arends do) the effort it took to get the DNSSEC RFCs done: a series of > interop workshops, a couple of open source companies sponsoring development > in well-known code bases, and money to support production of both code and > documents. Resources committed as an afterthought were not getting it done. > > This is a different project, and I think it’s doable, but it’s not a > weekend undertaking. > > > > Suzanne > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
