Subject: (internal) DNS dysfunction is enterprise settings

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Mar 2019 12:43:18 -0500

I am top-quoting a bit to introduce. I started a new thread and severed
the references/in-reply-to chain from my message about /.well-known.

Keith makes what I first felt was a very controversial and unsupportable
claim about DNS vs services.  DNS has been widely successful at the Internet
scale.  On the other hand, I happened to be in the offices of a ccTLD
this week doing some non-DNS work.  I happened to be within earshot of
a support person answering the same question about why the ccTLD couldn't fix
the caller's web site/domain...   So maybe it's not so succesful if the
complex web-server/DNS-server/registrar/ccTLD relationship is still opaque
to so many.

Keith Moore <[email-masked]> wrote:
    > The last thing we need is even more use of DNS[*] to locate
    > services. DNS is too often out of sync with reality as it is. A really
    > unfortunate consequence of using DNS for service discovery results from
    > a tendency to centralize DNS administration within an organization,
    > even if (as is often the case) hosts and applications are administered
    > in a distributed fashion. In any organization large enough to have an
    > administrative hierarchy, this is a profoundly dysfunctional
    > arrangement. It gives the central DNS administration a huge amount of
    > ability to break things (whether due to incompetence, poor
    > communication, or petty turf wars - usually some of all of these),
    > whereas the very nature of such an organization makes it almost
    > impossible for them to get things right. Using DNS for SD in a
    > widespread fashion only exacerbates the problem.

It seems that you are arguing for a technology fix to a management problem.
(the "why we can't have nice things" lament comes to mind)

I'm not saying any of your reasons are wrong!  I have observed some of all of
what you point to.    It seems therefore that any proposed technological fix
needs to do a clear analysis of the management issues around IT
(not just specifically around DNS).

I know that the initial DNS-SD effort was thought to be going to be just mDNS
with proxies at the gateways.  We didn't go there: are you thinking about
something like that?

    > Part of the problem is the too-common notion that there are "public"
    > names and "local" names, meaning that the DNS name space is polluted
    > with names
    > that aren't in the hierarchy. A separate, though related, problem is that
    > there's no architected way to distinguish one from the other.

    > [*] By "DNS" here I mean the naming hierarchy, which is of course
    > related to the data model.

I agree with your description above.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Mar 2019 13:47:36 -0500

Michael and Keith,

A few additional comments...

--On Friday, March 8, 2019 12:43 -0500 Michael Richardson
<[email-masked]> wrote:

> 
> I am top-quoting a bit to introduce. I started a new thread
> and severed the references/in-reply-to chain from my message
> about /.well-known.
> 
> Keith makes what I first felt was a very controversial and
> unsupportable claim about DNS vs services.  DNS has been
> widely successful at the Internet scale.  On the other hand, I
> happened to be in the offices of a ccTLD this week doing some
> non-DNS work.  I happened to be within earshot of a support
> person answering the same question about why the ccTLD
> couldn't fix the caller's web site/domain...   So maybe it's
> not so succesful if the complex
> web-server/DNS-server/registrar/ccTLD relationship is still
> opaque to so many.

I'm actually a little surprised that the ccTLD support desk got
the call.  My experience is that users faced with a problem in
that complex space will call whomever they think of a
"Internet", often in terms of who they paid a bill to yet.  That
usually points the finger at the user's ISP.   It might point to
the ccTLD help desk if the user had found the ISP seriously
unhelpful and/or good at excuses to not help (not hard, at least
in my vicinity, to find ISPs who behave like that) and the TLD
operator very helpful about other things (common in my
experience with many ccTLDs who still think their job is to
serve the populations in their countries; much more rare with
those ccTLDs whose motivation is closer to making a fast buck on
name sales).

In any event, as you effectively point out below, not a problem
that is going to be solved by technology.

>> services. DNS is too often out of sync with reality as it is.
>> A really unfortunate consequence of using DNS for service
>> discovery results from a tendency to centralize DNS
>> administration within an organization, even if (as is often
>> the case) hosts and applications are administered in a
>> distributed fashion. In any organization large enough to have
>> an administrative hierarchy, this is a profoundly
>> dysfunctional arrangement. It gives the central DNS
>> administration a huge amount of ability to break things
>> (whether due to incompetence, poor communication, or petty
>> turf wars - usually some of all of these), whereas the very
>> nature of such an organization makes it almost impossible for
>> them to get things right. Using DNS for SD in a widespread
>> fashion only exacerbates the problem.

> It seems that you are arguing for a technology fix to a
> management problem. (the "why we can't have nice things"
> lament comes to mind)
> 
> I'm not saying any of your reasons are wrong!  I have observed
> some of all of what you point to.    It seems therefore that
> any proposed technological fix needs to do a clear analysis of
> the management issues around IT (not just specifically around
> DNS).

Please include "customer support" and related issues along with
"management issues".  Good customer support is hard and often
expensive and many organizations have incentives to blow it off
to the extent possible.  The technology then gets blamed whether
it could have been designed in a way that would mitigate the
problems or not.

> I know that the initial DNS-SD effort was thought to be going
> to be just mDNS with proxies at the gateways.  We didn't go
> there: are you thinking about something like that?
 
>> Part of the problem is the too-common notion that there are
>> "public" names and "local" names, meaning that the DNS name
>> space is polluted with names
>> that aren't in the hierarchy. A separate, though related,
>> problem is that there's no architected way to distinguish one
>> from the other.
> 
>> [*] By "DNS" here I mean the naming hierarchy, which is of
>> course related to the data model.
> 

That problem is further aggravated by the observation that we
have two uses of "public" in very wide use wrt the DNS.   One
has to do with names that are accessible to substantially
everyone on the Internet without the need for special
configuration or access rights (probably that is "public" as
distinct from "local", but there may be other distinctions).
The other distinguishes within the public DNS (as described in
the previous sentence) between zones from which names are
delegated to parties not directly related to the zone
administration, usually involving the exchange of money and
zones that are populated from within enterprises, organizations,
etc.  The observation that the latter definition can get a
little fuzzy and may involve edge cases makes things harder
still.  

Again, not a technology problem although it is often our feet
(and those of the support desk personnel) that get hit by the
bullets.

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Fri, 8 Mar 2019 14:55:32 -0500

> (the "why we can't have nice things" lament comes to mind)

To be clear, I was just making some observations.  I don't (yet) have 
any specific fixes in mind.   (So efforts at damage control might be 
premature :)   But neither do I assume that the problem is a management 
problem.   I think it's at least arguable that the "management problem" 
exists because of the design or is exacerbated by it.

I do think we know quite a bit more about what a pervasive network looks 
like now, and what the needs of users and admins and network support and 
product support might be, than we did when the problem was that 
HOSTS.TXT was too big and changing too quickly.

I believe it actually is possible to consider support issues when 
designing networked applications and protocols, along with a great many 
other issues (security, privacy, scalability, etc.).

But I think that this set of problems with DNS illustrates one of many 
areas in which the Internet architecture didn't anticipate the diversity 
that the Internet would become.  I am not pointing a finger at anyone 
either - except /maybe/ IETF itself for abdicating any role in managing 
the Internet architecture.  (and I think I understand why, but that's 
another tangent)

Meanwhile these problems aren't going away and are still getting worse.  
So I think it makes sense to take a step back and look for potential 
fixes.   It might be that most of the fixes aren't technology fixes, and 
those that are, are just small tweaks.

And DNS isn't the only part of the Internet architecture that deserves 
such a look.   It's just that when I read the IETF list these days I 
usually find myself shaking my head sadly at some of the things that are 
said, but thinking it's not worth the trouble to reply.  On this 
particular occasion I decided to take a stab at it.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 8 Mar 2019 14:55:40 -0500

> (the "why we can't have nice things" lament comes to mind)

Sometimes the management structure around a technology reflects the
capabilities of the available tools.

When an the configuration data for a system such as an organization's
DNS is managed as a single "configuration file" or as a datastore
with very coarse-grained access control (permit or deny write access
to all records), it is natural to erect a moat around the system
to keep the marauding hoards at bay.

When on the other hand, the datastore is designed with fine-grained
access control, allowing self-service registration and delegated
life-cycle management for individual data elements, the administrator
responsibities shrink to just keeping the system running, and they
no longer stand in the way of users managing their own data.

The real problem we face is that there is no pervasive user
authentication technology (some organizations have Kerberos, some
PKI smartcards, some just username + password with a variety of
backends) and then also no common way to manage authorization.

Absent a common authentication and authorization substrate and a a
datamodel that tracks fine-grained resource owners and supports
self-service, unsurprisingly, we end up with centrally managed
systems.

To make alternative management structures possible for DNS, there
needs to be a datastore that facilitates delegation of responsibility
for particular nodes or RRsets.  This has to integrate with whatever
goes for authentication and authorization in the organization in
question.

A few organizations invest in building such systems.  Most organize
around whatever tool comes from the DNS vendor, with DNS administration
determined by the choice of Microsoft Active Directory, Infoblox,
PowerDNS, BIND with flat-file zone data, ...

The problem isn't DNS, it is that we lack a broadly applicable
technology that most organizations can use to expose fine-grained
access control for configuration data.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Sat, 9 Mar 2019 09:35:51 -0500

> access control for configuration data.

That's an interesting observation and a constructive suggestion.   I 
don't think it addresses the entire problem, but it definitely takes a 
stab at part of it.  I also note that the lack of a recommended model 
for such access control, and lack of standards for DNS update that are 
broadly applicable, are part of that problem.   (For instance, the fact 
that many routers intercept port 53 traffic and drop update requests 
means that you can't expect to fix the problem using port 53.)  With the 
current situation, even if an enterprise adopts a DNS server product 
that provides such features, they're likely locked in to it, which 
itself becomes a barrier to widespread adoption.    (Vendor lock-in 
stifles innovation.)

Beyond those issues, I observe that many small networks don't bother 
with DNS because it's not understood and/or seen as too much trouble.  
Yes, LLMNR exists, but it's implemented differently from one platform to 
another, so you end up needing to use different names from different 
hosts to accomplish the same thing.   I observe that when a network is 
intermittently-connected, behavior of applications using hostnames 
changes when connectivity changes, even when IP packets would be able to 
reach their intended destinations.   I observe that lack of a 
broadly-applicable standard update protocol, along with failure of many 
registrars to support DNSSEC via their proprietary user interfaces, 
hinders adoption of both DNSSEC and other technologies that require it.  
I see DNS used as a means of access control, which is not only 
ineffective but also increases the tendency to centralize DNS.   It 
isn't the fault of DNS itself that it's used this way, but it is 
arguably a failure of the architecture to address important user needs.  
I observe that it has now become common for various parties (not just 
border routers) to intercept DNS requests and falsify responses.  In my 
opinion this should be regarded as fraud and legally actionable, but to 
some degree (not always) this is being done to address limitations in 
the architecture.   (Arguing about whether those failures are "DNS's 
problem" seems unhelpful - and I would argue that our well-established 
practice of narrowly scoping discussions in order to reduce the 
appearance of tussles is one contributor to these architectural failures.)

And so on.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Sun, 10 Mar 2019 11:21:28 +1100

First of all, firewall vendors are changing their views on DNS.  Lots of default blockage have gone and UPDATE is no more dangerous than QUERY. 

Checkpoint have removed their default QUERY blocks. Similarly Juniper have also remover their default blocks.  If there are blocks on UPDATE they can similarly be removed. Nameservers that support UPDATE don’t need external protection. 

UPDATE has had fine grain authentication for 15+ years since the invention of TCP, TSIG and SIG(0). See update-policy in BIND for a example.  TCP is still hard to spoof and is useful for some updates especially in the reverse tree. 
 
Mark
-- 
Mark Andrews

> On 10 Mar 2019, at 01:35, Keith Moore <[email-masked]> wrote:
> 
> That's an interesting observation and a constructive suggestion.   I don't think it addresses the entire problem, but it definitely takes a stab at part of it.  I also note that the lack of a recommended model for such access control, and lack of standards for DNS update that are broadly applicable, are part of that problem.   (For instance, the fact that many routers intercept port 53 traffic and drop update requests means that you can't expect to fix the problem using port 53.)  With the current situation, even if an enterprise adopts a DNS server product that provides such features, they're likely locked in to it, which itself becomes a barrier to widespread adoption.    (Vendor lock-in stifles innovation.)
> 
> Beyond those issues, I observe that many small networks don't bother with DNS because it's not understood and/or seen as too much trouble.  Yes, LLMNR exists, but it's implemented differently from one platform to another, so you end up needing to use different names from different hosts to accomplish the same thing.   I observe that when a network is intermittently-connected, behavior of applications using hostnames changes when connectivity changes, even when IP packets would be able to reach their intended destinations.   I observe that lack of a broadly-applicable standard update protocol, along with failure of many registrars to support DNSSEC via their proprietary user interfaces, hinders adoption of both DNSSEC and other technologies that require it.  I see DNS used as a means of access control, which is not only ineffective but also increases the tendency to centralize DNS.   It isn't the fault of DNS itself that it's used this way, but it is arguably a failure of the architecture to address important user needs.  I observe that it has now become common for various parties (not just border routers) to intercept DNS requests and falsify responses.  In my opinion this should be regarded as fraud and legally actionable, but to some degree (not always) this is being done to address limitations in the architecture.   (Arguing about whether those failures are "DNS's problem" seems unhelpful - and I would argue that our well-established practice of narrowly scoping discussions in order to reduce the appearance of tussles is one contributor to these architectural failures.)
> 
> And so on.
> 
> Keith
> 
>

---

From: Keith Moore <[email-masked]>
Date: Sat, 9 Mar 2019 19:27:23 -0500

> UPDATE has had fine grain authentication for 15+ years since the invention of TCP, TSIG and SIG(0). See update-policy in BIND for a example.  TCP is still hard to spoof and is useful for some updat…

Yes, but there are zillions of SOHO routers deployed that still 
implement such blocks in firmware, are unlikely to be updated, and will 
be replaced only slowly.

It's been awhile, but last time I looked, I couldn't find a single DNS 
registry that implemented UPDATE.   For better or worse, many 
organizations (some large ones) use godaddy or similar services for 
their public-facing DNS.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Sun, 10 Mar 2019 13:35:44 +1100

> On 10 Mar 2019, at 11:27 am, Keith Moore <[email-masked]> wrote:
> 
> Yes, but there are zillions of SOHO routers deployed that still implement such blocks in firmware, are unlikely to be updated, and will be replaced only slowly.
> 
> It's been awhile, but last time I looked, I couldn't find a single DNS registry that implemented UPDATE.   For better or worse, many organizations (some large ones) use godaddy or similar services for their public-facing DNS.
> 
> Keith

Mostly because they are hooked on EPP.  Note there really isn’t a reason UPDATE can’t
be used to drive EPP updates.  While below says TSIG this works equally as well with
SIG(0).

https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sat, 9 Mar 2019 22:22:00 -0500

On 3/9/19 9:35 PM, Mark Andrews wrote:

> Mostly because they are hooked on EPP.
Perhaps, but I somehow doubt that's the only reason.    It seems to have 
become widely accepted that the way ordinary mortal zone maintainers 
update their RRs is via the registrar's web UI.  And why would the 
registrars bother supporting UPDATE if clients can't use it due to 
blocking?   After all, customer dependence on the registrar's UI (or 
proprietary API) is yet another thing that deters customers from 
changing registrars.
> Note there really isn’t a reason UPDATE can’t
> be used to drive EPP updates.

Perhaps another piece of the puzzle (i.e. part of the solution). Though 
I don't think that will address the issues with router firmware.

> While below says TSIG this works equally as well with
> SIG(0).
>

If zone maintainers can't directly send updates to their servers, what 
does it matter?

To be clear, I don't think that this part of the problem is (mostly) a 
protocol issue except perhaps that the most expedient way to address the 
blocking problem might be to allocate another port or let update be 
port-agile.   But I strongly suspect that there are several practical 
barriers like this to widespread use of DNSSEC, which impacts DANE and a 
lot of other things that we need very badly.

More generally, if we took a step back and asked ourselves "In what ways 
are people not using DNS, or not using DNS the way we think they 
should?"   (and "why?"), we might uncover several things like this that 
deserve at least some attention.    The fixes might be simple tweaks - 
that would be great - but we might be much better off for asking those 
questions.

Keith

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Mar 2019 22:53:32 -0600

On Fri, Mar 08, 2019 at 02:55:40PM -0500, Viktor Dukhovni wrote:
> > >                                   [...]. Using DNS for SD in a

And ofter software architecture reflects organization.

> to keep the marauding hoards at bay.

Typically the moat is a proxy that does implement appropriate access
control policy.

> no longer stand in the way of users managing their own data.

Indeed.

If only we had a reasonable and widely-used authorization system...

> backends) and then also no common way to manage authorization.

A few things:

1) _Naming_ is the most important thing.

   It doesn't matter whether you use Kerberos or PKIX or whatever,
   provided you can get useful, simple, usable names out of it.  All the
   better if you can support a common naming scheme across multiple
   autheotcation systems.

   Just say no to x.400/x.500-style naming.  Kerberos gets it almost
   right.

   Of course, you can also have systems that convey authorization data
   stripped of identifying information, but even then, you need to be
   able to name things if not users.

2) There is no universal *user* authentication system, and this doesn't
   look like it's going to get better anytime soon.

3) There's no universal authorization system.  We do have things like
   SAML and OAuth, which are built mostly for browsers and which at
   least federate, but that's it.

Re: authentication, my theory is that we can leverage TLS and DANE to
authenticate not just services, but issuers of rfc822Name SAN bearing EE
certs to authenticate users, using the DNSSEC PKI.  Such a system would
have instant federation via normal DNS(SEC) zone delegation/signing.

A DANE-based system for authenticating users would be no worse than the
WebPKI (which anyways isn't useful for authenticating users), and
probably better because DNSSEC is a proper hierarchical PKI.  DNSSEC
does have all the issues that any PKI has (issuers can impersonate), but
it's still better than a system where federation has to be manually
agreed, like Kerberos.  We'd still need something like certificate
transparency, naturally.

> self-service, unsurprisingly, we end up with centrally managed

Worse: we end up with non-federation.

Users have to make myriad accounts authenticated with passwords, instead
of just a few (one for each of one's online personas) authenticated with
devices.

> goes for authentication and authorization in the organization in

My proposal would be to take a page from labelled security systems and
have a _notional_ (but optionally real) label indicated by either a
"_label" RRset or a LABEL RR type whose RDATA names a label for
authorization.  Such a label would be associated with rules/policies --
ACLs if you wish -- detailing who can do what with the domainname the
_label is prefixed to.

    ; Protects all things below foo.bar.example. that don't have their
    ; own label.
    _label.foo.bar.example. IN TXT "foo_group_private_resources"

    ; Protects all things below host1.foo.bar.example. that don't have
    ; their own label.  The "|parent_label_applies" means that that
    ; foo.bar.example.'s label also applies (i.e., a subject must be
    ; granted access by both authorization labels)
    _label.host1.foo.bar.example. IN TXT "jane_user_resources|parent_label_applies"

> access control for configuration data.

+1.  But worse than that: *anything else* than DNS will tend to have the
same issues.  LDAP, for example, has the same damned problems.

Thus, to say "DNS is too difficult to manage, let's build something
else", without addressing these issues, is bound to result in more of
the same.

It's so easy to reinvent wheels, and so hard to get rid of legacy.  We
should at the very least understand the issues with the old wheels
before we discard them -- they're never really removed, only left to rot
and give us new old fun security vulnerabilities.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 9 Mar 2019 23:05:23 -0600

On Sat, Mar 09, 2019 at 09:35:51AM -0500, Keith Moore wrote:
> That's an interesting observation and a constructive suggestion.   I don't
> think it addresses the entire problem, but it definitely takes a stab at
> part of it.  [...]

Self-service tooling *requires* fine-grained authorization.

No fine-grained authz -> no self-service tooling -> users must call for help.

The secret to (sys)admin. cost reduction is self-service tooling.

Now, it's hard for an RFC to say much about how authz is done in the
backend, even when using protocols like OAuth.

But without a widely used (and copied) authz system, we'll get nowhere.

Each organization / vendor is an island with their own [expensive]
tooling.

> Beyond those issues, I observe that many small networks don't bother with
> DNS because it's not understood and/or seen as too much trouble.  [...]

Everything has to be turn-key that can be.  And everything has to have
self-service tooling.  This requires a comprehensive authz technology.

As it happens, I hope to publish a paper on this topic soon, describing
a candidate authz system into which I've sunk much of the past few years
of my work.  (Hopefully my client will open source much of it.)  I need
a decent venue for this paper, preferably one w/o a pay-wall.
Suggestions welcomed.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Mar 2019 13:32:54 -0400

> Yes, but there are zillions of SOHO routers deployed that still implement
    > such blocks in firmware, are unlikely to be updated, and will be replaced
    > only slowly.

SOHO routers are not enterprises, and most do rather fine today with mDNS.

And homenet is making progress for front-end naming under the end-user's
control.  So, this is a red herring.

    > registry that implemented UPDATE.   For better or worse, many organizations
    > (some large ones) use godaddy or similar services for their public-facing
    > DNS.

Lots of dumb people out there :-)
Many enterprises use primary DNS providers that expect a stealth primary and
use AXFR.   Most could support UPDATE if the customer asked for it, I think.
(I worked for one for a year)

---

From: Keith Moore <[email-masked]>
Date: Sun, 10 Mar 2019 14:41:59 -0400

> control.  So, this is a red herring.

I emphatically disagree with the idea that there should be different 
protocols for different kinds of IP networks.   That's something we 
should be fighting as much as possible because it degrades 
interoperability.   Users and networks don't cleanly split into distinct 
classes.   And if you don't think that enterprises use SOHO routers, or 
don't realize that people on SOHO networks need DNS update, I 
emphatically disagree with that also.

> Lots of dumb people out there :-)
can't disagree with that, but we might disagree about where they are.
> (I worked for one for a year)

Yes, and that works.  But it's naive and unrealistic to expect everyone 
who manages a DNS zone to operate it that way, or to assume that the 
other zones don't need UPDATE.

Keith

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Mar 2019 18:10:35 -0500

See subject:

   Self-service tooling requires fine-grained authz -- it's NOT about
   the application protocol.

If someone says "let's put this config data in DNS" and someone responds
"DNS is too difficult to manage", the answer isn't necessarily "let's
invent a new protocol".

After all, similar things could be said of LDAP.

This is bound to happen over and over until this sinks it:

 - it's not easy to manage if there's no self-service tooling

 - self-service tooling requires fine-grained  authorization

 - self-service tooling requires delegation of authorization[*]

 - no self-service tooling -> helpdesks

Nico

[*] Delegation of authorization == the ability to grant the ability to
    grant to others.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Mar 2019 10:34:22 +1100

The DNS has had that for ~2 decades now.  KEY records provide that.  You need a
administrator to add a KEY record.  They authorise future changes by signing
them with the private part of the key record using SIG(0).  This exists in products
TODAY.  The same can also be done with TSIG but requires different key management.

zone example.com {
	type master;
	file “master.db”;
	update-policy {
		grant * self . [type list];
		grant admin-key zone .;
	};
};

If you want to allow prefix labels you use selfsub instead of self.

zone example.com {
	type master;
	file “master.db”;
	update-policy {
		grant * selfsub . [type list];
		grant admin-key zone .;
	};
};

If the update comes in validly signed with foobar.example.com then in the
first example anything at foobar.example.com can be changed subject to the
type list.  In the second anything at or below foobar.example.com can be
changed.

RFC 3007 - Secure Domain Name System (DNS) Dynamic Update + a way to specify
policy.

Mark

> On 12 Mar 2019, at 10:10 am, Nico Williams <[email-masked]> wrote:
> 
> See subject:
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Mar 2019 19:34:57 -0400

>     the application protocol.

Unless, of course, the application protocol constrains the granularity 
of authentication.   But I don't think that's the case for DNS update.

> "DNS is too difficult to manage", the answer isn't necessarily "let's

Agree in principle.  But while authentication granularity isn't really a 
problem with DNS update (as far as I know), there are other problems 
with DNS update that might best be fixed by protocol tweaks.   
Separately from that, there are other reasons why it might be 
appropriate to consider migrating to a "DNS next generation" 
protocol.    Arguably this is already happening whether we want it or not.

There are several problems, some of which are interrelated.   I am not 
insistent that any of them be fixed by protocol changes, though I 
suspect that some changes and/or new protocol work would be desirable.  
I also suspect that some new tooling is desirable.   I also suspect that 
some policy changes might be appropriate.   And perhaps some operational 
recommendations.

There's a danger of trying to boil the ocean.  There's also a danger of 
thinking that some new tool will solve the problem, and scoping the 
effort narrowly in terms of creating that new tool, when the new tool 
that emerges years later only has the effect of moving the problem and 
adding additional complexity to what's already Pandora's box.

At the moment I'm just trying to wrap my head around the problem, or to 
put it another way, to discover what scope for the problem could result 
in less overall complexity rather than more.

Keith

p.s. agree with your summary of self-service tooling requirements.

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Mar 2019 21:42:57 -0500

> TODAY.  The same can also be done with TSIG but requires different key management.

The difficult part there is key management.

You can absolutely get fine-grained authz using cryptography like that.
But it won't be terribly user friendly.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Mar 2019 22:48:01 -0500

On Mon, Mar 11, 2019 at 07:34:57PM -0400, Keith Moore wrote:
> Unless, of course, the application protocol constrains the granularity of
> authentication.   But I don't think that's the case for DNS update.

Authorization presupposes authentication (not necessarily to the RP;
perhaps the RP doesn't get to learn the client's identity).

If your application doesn't give you a way to authenticate, you have a
bigger problem than how to do authorization!

> problem with DNS update (as far as I know), there are other problems with
> DNS update that might best be fixed by protocol tweaks.   Separately from
> that, there are other reasons why it might be appropriate to consider
> migrating to a "DNS next generation" protocol.    Arguably this is already
> happening whether we want it or not.

I agree that DNS Update is not a very good protocol.  I would support a
replacement.

But DNS as a protocol for *reading* configuration?  That's another story.

DNS may or may not be good for reading configuration for some app, but
if one would say it's not good because "DNS is hard to manage", well,
that's just because there's no self-service support for DNS management,
and anything that would replace it would absolutely need it.

It's ironic that there are DNS appliance products out there that do not
provide self-service admin interfaces.  I've seen customers write
proxies of sorts to provide the missing self-service layer!

> insistent that any of them be fixed by protocol changes, though I suspect
> that some changes and/or new protocol work would be desirable.  I also
> suspect that some new tooling is desirable.   I also suspect that some
> policy changes might be appropriate.   And perhaps some operational
> recommendations.

The IETF doesn't build tooling.  Just protocols (and APIs, though some
will nay-say that in 3, 2, ...).

We should consider building authz protocols -- something a wee bit more
generic than OAuth, perhaps -- that provide just the right level of
granularity *.

* too much granularity can == unmanageable mess.  The right level of
  granularity is for the customer to determine.

> thinking that some new tool will solve the problem, and scoping the effort
> narrowly in terms of creating that new tool, when the new tool that emerges
> years later only has the effect of moving the problem and adding additional
> complexity to what's already Pandora's box.

Indeed, let's not boil the oceans, but let's not reinvent the wheel and
miss the one thing that was critical.

> At the moment I'm just trying to wrap my head around the problem, or to put
> it another way, to discover what scope for the problem could result in less
> overall complexity rather than more.

Ah, well, right at this moment I am proposing nothing in particular.
Just making an observation that I hope will resonate.

I do have proposals in mind, but that can wait.

> p.s. agree with your summary of self-service tooling requirements.

Recognizing the problem is a good step on the way to making progress.

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Mar 2019 23:55:11 -0400

> will nay-say that in 3, 2, ...).

I don't think it should be forbidden to discuss problems observed with 
DNS and to try to understand which measures would effectively address 
those problems, even while understanding we're not going to produce all 
of those fixes within IETF.   For those parts of the solution which we'd 
normally consider beyond our scope, documenting what we think those 
parts might look like could still be a valuable contribution.   And IETF 
people know people who can get some of these things done.

The alternative is for IETF to erect a "somebody else's problem" field 
and hope that the problem will disappear.  That's what we've often done, 
but I don't think it works well.

Keith

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Mar 2019 23:21:41 -0500

On Mon, Mar 11, 2019 at 11:55:11PM -0400, Keith Moore wrote:
> I don't think it should be forbidden to discuss problems observed with DNS
> and to try to understand which measures would effectively address those
> problems, even while understanding we're not going to produce all of those
> fixes within IETF.   For those parts of the solution which we'd normally
> consider beyond our scope, documenting what we think those parts might look
> like could still be a valuable contribution.   And IETF people know people
> who can get some of these things done.

I... didn't suggest anything should be forbidden!  We should certainly
describe desirable tools.

Maybe the IETF should get in the business of building open source
implementations of things that aren't necessary to conducting the IETF's
business.  That it certainly doesn't today is just an observation.

Nico
--

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Mar 2019 17:55:29 +0000

> "DNS is too difficult to manage", the answer isn't necessarily "let's

This is outside the areas I am familiar with, but there's some really
interesting DNS stuff going on in the Kubernetes world, for dynamic
service discovery. But I get the impression they are using DNS for
compatibility with existing software, not because they care about
connecting their container cluster to a global namespace.

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Southerly 5 to 7,
occasionally gale 8 at first in North Utsire, becoming cyclonic, then
northwesterly, 5 or 6. Rough, occasionally very rough at first, becoming
moderate. Showers. Good, occasionally poor.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Mar 2019 23:16:00 -0400

> connecting their container cluster to a global namespace.

Yes, but it's terribly *IPv4* NAT44-everything-you-can centric.
It's nice that docker and kubernetes have made themselves IPAMs, but it turns
out that turning that off is actually rather difficult.

---

From: Simon Leinen <[email-masked]>
Date: Wed, 13 Mar 2019 11:12:16 +0100

> out that turning that off is actually rather difficult.

This pains me as well.  There has been some effort to add IPv6 support
to Kubernetes.  Some of that was actually released in Kubernetes 1.9
(maked as "alpha"), but there's still quite a bit missing.  In
particular, the Kubernetes data model still assumes each pod has "an"
(one) IP address.  At the current level of IPv6 support (as far as I
understand it), this can now be an IPv6 address *instead of* an IPv4
address.  So there's no real support for dual stack yet; this is tracked
under

https://github.com/kubernetes/enhancements/issues/563

The efforts seem to have stalled a bit lately, so help in this area
might be welcome.  I'm not sure how to best engage with the vibrant
Kubernetes/cloud native community, but for all anyone who'd like to help
fix this and willing to hack some Golang => OPPORTUNITY

https://github.com/kubernetes/enhancements/issues/508#issuecomment-454838090
-- 
Simon.