Subject: [DNSOP] Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

From: Shane Kerr <[email-masked]>
Date: Fri, 8 Jul 2016 16:38:53 +0200

Hello,

I've put together some high-level thoughts I had about DNS.  I started
thinking about this a year or so ago, and typed up an earlier version 9
months ago, but wasn't sure what to do with it. I've been struggling to
figure out how to actually make the types of changes that I am thinking
of - in the end I guess that the IETF is the best place for this work,
if it is possible. So I finally turned them into a draft.

My main goal is to try to make the DNS a more agile protocol. Until
this is done, working in DNS will always be an exercise in pushing
boulders uphill.

GitHub page here for pull requests:

    https://github.com/shane-kerr/DNSManifesto

I'm not really sure what the next steps are, if any. One fear I have is
that nobody is looking at the overall architecture of the DNS, and so
we'll end up muddling along one patch at a time, forever. Hopefully not!

Please let me know what you think. Also, I'll be in Berlin for the IETF
and happy to discuss things there, with or without beer. ;)

Cheers,

--
Shane

p.s. I did this using Miek Gieben's awesome mmark tool. Writing a
     Internet Draft in Markdown instead of XML is awesome. AWE-SOME.
     https://github.com/miekg/mmark

Subject: New Version Notification for draft-shane-dns-manifesto-00.txt
From: [email-masked]
To: "Shane Kerr" <[email-masked]>
Date: Fri, 08 Jul 2016 07:14:26 -0700

A new version of I-D, draft-shane-dns-manifesto-00.txt
has been successfully submitted by Shane Kerr and posted to the
IETF repository.

Name:		draft-shane-dns-manifesto
Revision:	00
Title:		A DNS Manifesto
Document date:	2016-07-08
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-shane-dns-manifesto-00.txt
Status:         https://datatracker.ietf.org/doc/draft-shane-dns-manifesto/
Htmlized:       https://tools.ietf.org/html/draft-shane-dns-manifesto-00

Abstract:
   The DNS protocol has many things to fix or improve, but this is
   difficult to do because changing the protocol is very hard.  This
   paper explores the good and bad features of the protocol, and calls
   for an effort too make the protocol flexible enough that it can
   evolve in the future.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Davey Song(宋林健) <[email-masked]>
Date: Mon, 11 Jul 2016 10:11:00 +0800

When I first looked into DNS, I was recommended with a complex figure of DNS
protocol family describing the dependency and activeness of many RFC
documents. I'm wondering if it is possible to attach versions to DNS
protocol similar like IPv4 and IPv6, http/1.1 and HTTP/2 which can give
clear path of DNS evolution and help to keep protocol conformance. 

Davey
-----邮件原件-----
发件人: DNSOP [mailto:[email-masked]] 代表 Shane Kerr
发送时间: 2016年7月8日 22:39
收件人: [email-masked]
主题: [DNSOP] Fw: New Version Notification for draft-shane-dns-manifesto-00.
txt

Hello,

I've put together some high-level thoughts I had about DNS.  I started
thinking about this a year or so ago, and typed up an earlier version 9
months ago, but wasn't sure what to do with it. I've been struggling to
figure out how to actually make the types of changes that I am thinking of -
in the end I guess that the IETF is the best place for this work, if it is
possible. So I finally turned them into a draft.

My main goal is to try to make the DNS a more agile protocol. Until this is
done, working in DNS will always be an exercise in pushing boulders uphill.

I'm not really sure what the next steps are, if any. One fear I have is that
nobody is looking at the overall architecture of the DNS, and so we'll end
up muddling along one patch at a time, forever. Hopefully not!

Please let me know what you think. Also, I'll be in Berlin for the IETF and
happy to discuss things there, with or without beer. ;)

Cheers,

--
Shane

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2016 04:04:02 -0000

>clear path of DNS evolution and help to keep protocol conformance. 

In a word, no.  EDNS0 is the closest thing we have to versioning, and
even though it's designed to be as backwards compatible as possible,
things still break.

The main problem is that there's a lot of dusty old firewalls and the
like that have dusty old software with a rigid and obsolete idea of
what DNS packets to allow through.  We all would like people to get
with the program and use less cruddy and obsolete software, but good
luck with that.

R's,
John

---

From: George Michaelson <[email-masked]>
Date: Mon, 11 Jul 2016 14:10:55 +1000

I think you missed the point John. Its a manifesto, and it can take
radical positions. If you read Shanes markup its clear a lot of things
which are implicit in 'UDP/EDNS0' are up for grabs.

I for one, would welcome versioning models closer to HTTP. I'd also
welcome client-capability signalling and negotiation, another thing
which won't happen in my lifetime on port 53.

-G

On Mon, Jul 11, 2016 at 2:04 PM, John Levine <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2016 01:02:19 -0400

> which won't happen in my lifetime on port 53.

I agree that a protocol that had versioning and signalling and negotiation 
and other stuff would be cool, but it wouldn't be DNS.  With respect to 
the stuff in the manifesto, I think it needs to take another step back and 
figure out what problem(s) the DNS is supposed to solve, which affects 
questions like whether wildcards are a good idea.

The DNS was originally mostly a way to map names to IP addresses, but even 
at the beginning it had other stuff like MX and HINFO and TXT.  In its 
current incarnation it's a tree structured database with weak searching 
(just terminal wildcards) where you can put whatever you want so long as 
the records aren't more than a few K each.  DANE has done a little of that 
with TLSA, but you can go way beyond that.

A while back I wrote a draft that put a B-tree in the DNS, for fairly 
efficient prefix matches for lookups, with the intended application being 
IPv6 DNSBLs.  Last year I wrote a draft that put a state machine for a DFA 
for regular expressions in the DNS, to do more general string pattern 
matching, with the intended application being e-mail address local parts. 
Or look at the DBOUND drafts that Casey Deccio and I wrote, that use 
wildcards in parallel subdomains to publish boundary info sort of like the 
PSL.

Even if the main application is still finding addresses for host names, 
I'd want to push what SRV does into the protocol so I can say I want to 
find the web server or the mail server for foo.example, and it'd tell me 
the IP addresses and the ports and some hints about what sort of 
connection to make, TLS over TCP or whatever.

We already have a draft for DNS over HTTP.  Perhaps we can bootstrap from 
there once we understand what we're trying to do.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Jul 2016 15:58:52 +1000

In message <CAKr6gn32s=9OPrAnRgDFWUkt+tpR592uaPxF6QSCXq=[email-masked]>
> which won't happen in my lifetime on port 53.

Checkpoint are removing the version != 0 checks and edns flags !=
0 checks which cause packets to be dropped.  This will fix a lot
of the issues we see in the EDNS compliance checks.

F5 have fixed the broken version != 0 handling.
https://support.f5.com/kb/en-us/solutions/public/17000/000/sol17086.html

Complaining to operators does work.  Bug reports do make it back
to DNS vendors by doing that.  Servers do get upgraded / reconfigured
as a result.

If we just go ahead and use the features the servers will be fixed.
We have seen this time and time again.

We should not be afraid to use EDNS features.  Just choose the one
that is optimal for the problem you are trying to solve.

Mark

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

---

From: George Michaelson <[email-masked]>
Date: Mon, 11 Jul 2016 16:13:04 +1000

Thats good to know Mark. I took a dark view of change in DNS, but I do
recall believing that for some problems, with tractable volumes of
change-effectors, you can move on them. So, thanks for pushing: it
helps.

Things like client capability signalling, I suspect are in a harder
bucket. I won't say intractably hard, but last time I floated
capability flagging, I got pretty strong pushback.

-G

---

From: Ray Bellis <[email-masked]>
Date: Mon, 11 Jul 2016 13:19:17 +0100

> capability flagging, I got pretty strong pushback.

I think capability flagging is difficult in a stateless protocol like
UDP - there's no guarantee that the next endpoint that you send a packet
to is the same one that just told you what capabilities it has.

It could be done over TCP, and perhaps in other protocols that add a
pseudo-session on top of UDP (e.g. DNS-o-DTLS?) but even then the
signaling should only really apply to the current connection / session.

As it happens, the Session Signaling draft I submitted last week
originally had an option for exchanging the end-points' EDNS0 option
support, but some of my co-authors didn't like it so I removed it...

Ray

---

From: George Michaelson <[email-masked]>
Date: Tue, 12 Jul 2016 07:55:05 +1000

UDP+cookies could work for you?

-G

---

From: Ray Bellis <[email-masked]>
Date: Tue, 12 Jul 2016 08:01:12 +0100

> UDP+cookies could work for you?

Yes, it possibly could, but it's still "to be determined".

Ray

---

From: Shane Kerr <[email-masked]>
Date: Tue, 12 Jul 2016 22:32:45 +0200

George,

I *do* want people to consider radical positions - although I feel very
strongly that we should focus on an evolutionary path for the
technology.

What I mean is that we should not feel constrained by the DNS as it is
today when thinking of ideal solutions, *but* that we should at some
point ensure that we have a backward-compatible path to get there. (I'm
hoping for something more like the 4-byte ASN roll-out and less like
the IPv6 roll-out.)

I deliberately avoided putting possible solutions in this document
because I'd like it to be something like a problem statement, rather
than hinting too much at solutions.

----

Having said that, I do think that we already have some hints as to what
we can do to improve the situation. If we look at how DNSSEC uses the
DO bit and RRSIG+DS records, we can see that it is possible for a
resolver to signal to an authority server that it supports a specific
feature and for the authority server to respond differently based on
that. While imperfect (because a single bit doesn't tell us which
algorithms are supported on the client, or what the trust anchors are,
and probably a whole bunch of other stuff that might be useful if we
ever considered the possibility), it is basically successful and shows
at least one way to perform capability negotiation that is
backward-compatible. Imagine if instead of just adding a couple of RR
to the response that the master actually sent clients to different
servers (or different ports on the same servers) if they understood
FancyPantsDNS instead of just DNS.

I think versioning is important because it gives us a way to more easily
add (and remove!) stuff from the protocol - something we really don't
have today. :)

Cheers,

--
Shane

At 2016-07-11 14:10:55 +1000

---

From: Shane Kerr <[email-masked]>
Date: Tue, 12 Jul 2016 23:03:32 +0200

John,

At 2016-07-11 01:02:19 -0400

> questions like whether wildcards are a good idea.

I'm happy to call it anything other than DNS. ;)

But I take your point, that we should definitely make sure that we
solve the right problems. I guess thinking about what DNS gets right
doesn't really address *why* people use DNS in the first place.

> wildcards in parallel subdomains to publish boundary info sort of like the 

Hm... interesting. For me the question is, do these ideas affect the
fundamental architecture? If I understand them, they are
transformations that take place on queries at specific labels, right?
The hierarchical nature of the DNS remains, right?

> connection to make, TLS over TCP or whatever.

Yes, that sounds good. Perhaps another way to say it is that the main
application would actually be finding how to connect to a specific
service rather than finding addresses for hosts?
 
> there once we understand what we're trying to do.

I'm not sure I see the relationship, but I won't rule it out. :)

Cheers, 

--
Shane

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 17:26:31 -0400

> The hierarchical nature of the DNS remains, right?

In the first two of those applications, I was just using the DNS as a flat 
key store.  For the B-trees, the labels were just block numbers, e.g. 
48933.blacklist.example.  For the DFA, the labels were state numbers and 
tokens, e.g. if you were in state 123 and your next character was an A, 
the node name would be 41.123.somenames.example (41 is the hex ASCII for 
A.)  In that latter case I made the character leaf node so I could use 
*.123.somenames.example for the common case where there's a default rule 
for all the letters that don't have explicit rules.

For the PSLish stuff, I used wildcards and the closest encloser rule so if 
you wanted to find the boundary for, say, www.bigbank.co.uk, you'd look up 
www.bigbank.co._ob.uk (_ob is organizational boundary) and that would be 
matched by *.co._ob.uk since co.uk is a boundary.

I'm not sure how helpful this is, but do keep in mind that just because 
you don't use some feature of the DNS, it doesn't mean other people don't 
use it.

Regards,