[dns-operations] How should a modern name system work? Re: [Ext] How should...?

[Phillip Hallam-Baker]

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 <
dns-operations at dns-oarc.net> wrote:

> ---------- Forwarded message ----------
> From: Paul Vixie <paul at redbarn.org>
> To: DNS-Operations <dns-operations at dns-oarc.net>
> 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 <dns-operations at dns-oarc.net>
> To: DNS-Operations <dns-operations at dns-oarc.net>
> 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
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220616/60d515f3/attachment.html>