<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Paul makes excellent points here. The only security slogan I adhere to is that security by slogan is usually bad security.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Today, the DNS protocol serves three distinct sets of requirements:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Locating the authoritative server for a delegated zone</div><div class="gmail_default" style="font-size:small">2) Service discovery at the authoritative</div><div class="gmail_default" style="font-size:small">3) Client to caching resolver</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">These are three separate applications which should have three separate protocols.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><b>1) Locating an authoritative service.</b></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><b>2) Service discovery at the authoritative</b><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><b>3) Client to caching resolver</b><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 16, 2022 at 2:34 PM Paul Vixie via dns-operations <<a href="mailto:dns-operations@dns-oarc.net">dns-operations@dns-oarc.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">---------- Forwarded message ----------<br>From: Paul Vixie <<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>><br>To: DNS-Operations <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>Cc: <br>Bcc: <br>Date: Thu, 16 Jun 2022 11:25:48 -0700<br>Subject: Re: [dns-operations] [Ext] How should work name resolution on a modern system?<br><br>
<br>
David Conrad wrote on 2022-06-16 08:26:<br>
> ... What ISC defined as “views" in BIND 9 is simply an implementation of an <br>
independent namespace. The fact that it is (now) most frequently used in <br>
the context of an independent address space is irrelevant.<br>
<br>
when considering BIND9, bob halley and i knew of many BIND4 and BIND8 <br>
installations who ran a different name server instance for each IP <br>
interface address, in order that different audiences would receive <br>
different results. this seemed to us like the long way around, and we <br>
wanted BIND9 to handle this situation natively.<br>
<br>
while RFC 1597 (later reissued as RFC 1918) was widely practiced at the <br>
time BIND9 was designed, it's true as david recounts above that the <br>
primary use case we had for "views" was enterprise-internal naming <br>
systems. (when i did some consulting for sony electronics, we had to <br>
keep 43/8 addresses from leaking to the outside world.)<br>
<br>
see also <<a href="http://family.redbarn.org/~vixie/proxynet.pdf" rel="noreferrer" target="_blank">http://family.redbarn.org/~vixie/proxynet.pdf</a>>.<br>
<br>
-- <br>
P Vixie<br>
<br>
<br><br><br>---------- Forwarded message ----------<br>From: Paul Vixie via dns-operations <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>To: DNS-Operations <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>Cc: <br>Bcc: <br>Date: Thu, 16 Jun 2022 11:25:48 -0700<br>Subject: Re: [dns-operations] [Ext] How should work name resolution on a modern system?<br>_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div></div></div></div>