Paul makes excellent points here. The only security slogan I adhere to is that security by slogan is usually bad security.
Just as it is impossible to render most technical arguments in a tweet, boiling them down to three word slogans 'Security Through Obscurity' completely misses the original points being made. Back in 1992 there were some people calling me all sorts of names for suggesting that UNIX systems should be configured to use shadow passwords and that salted hashes are not a sufficient control. 'Security through obscurity' they screamed. That stopped a few weeks later when CRACK came out. The biggest weakness in most Internet security designs is that they are designed so that a single point of failure causes a complete collapse. We are only just getting to deploy multi-layer security. I really can't see much point in changing the naming system API unless we are also going to change the naming/discovery system. This does not mean we throw DNS away and start again but it would mean learning from the past 30 years and building a system that meets our current needs. Today, the DNS protocol serves three distinct sets of requirements: 1) Locating the authoritative server for a delegated zone 2) Service discovery at the authoritative 3) Client to caching resolver These are three separate applications which should have three separate protocols. *1) Locating an authoritative service.* I don't suggest we throw ICANN away completely but I think we can provide a sidegrade that is better for individual users. $10/yr is far too much for a domain name. I can do $0.10 with no renewal fee. It will be necessary for $BTC and the Ponzi coins to die die die before a public goods proposal can work in that space but fortunately that appears to be well underway. I plan a notarized append only log of signed assertions specifying the root of trust for a callsign @alice. This may optionally include the address of an authoritative DNS service for the zone alice.mesh. The intention being that Alice can use alice.mesh in place of .local and thus avoid all the inevitable confusion that .local entails. *2) Service discovery at the authoritative* Existing DNS protocol is almost OK. But needs to be extended so that ad hoc extensions such as geographic responses are formalized. Can also optimize the protocol in various ways such as allowing multiple response packets for a single request and introducing new query types optimized for the new discovery mechansim. *3) Client to caching resolver* DPRIV isn't doing it for me, sorry. The basic problem here is that DNS protocol as implemented only allows one error code per request and so even though you can have multiple requests in theory, you can only make one query per packet in practice. I want to move to the DNS Service Discovery approach (RFC6763). Every service is discovered by means of an SRV record lookup. In normal circumstances, a client would never query for the A or AAAA records, they would ask for the _SRV and get the TXT and A/AAAA as additional records. This is the approach I am using in my own work. The big change I would to make in the future is to allow the DNS resolution to be access controlled and thus make use of private views more tractable. On Thu, Jun 16, 2022 at 2:34 PM Paul Vixie via dns-operations < [email protected]> wrote: > ---------- Forwarded message ---------- > From: Paul Vixie <[email protected]> > To: DNS-Operations <[email protected]> > Cc: > Bcc: > Date: Thu, 16 Jun 2022 11:25:48 -0700 > Subject: Re: [dns-operations] [Ext] How should work name resolution on a > modern system? > > > David Conrad wrote on 2022-06-16 08:26: > > ... What ISC defined as “views" in BIND 9 is simply an implementation of > an > independent namespace. The fact that it is (now) most frequently used in > the context of an independent address space is irrelevant. > > when considering BIND9, bob halley and i knew of many BIND4 and BIND8 > installations who ran a different name server instance for each IP > interface address, in order that different audiences would receive > different results. this seemed to us like the long way around, and we > wanted BIND9 to handle this situation natively. > > while RFC 1597 (later reissued as RFC 1918) was widely practiced at the > time BIND9 was designed, it's true as david recounts above that the > primary use case we had for "views" was enterprise-internal naming > systems. (when i did some consulting for sony electronics, we had to > keep 43/8 addresses from leaking to the outside world.) > > see also <http://family.redbarn.org/~vixie/proxynet.pdf>. > > -- > P Vixie > > > > > ---------- Forwarded message ---------- > From: Paul Vixie via dns-operations <[email protected]> > To: DNS-Operations <[email protected]> > Cc: > Bcc: > Date: Thu, 16 Jun 2022 11:25:48 -0700 > Subject: Re: [dns-operations] [Ext] How should work name resolution on a > modern system? > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations >
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
