Subject: [DNSOP] Data model and field names for DNS in JSON or XML

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Jan 2012 16:33:51 +0100

I have a project where DNS data must be transported in Web-friendly
environments, which mean encoded in JSON or XML. I'm not asking IETF
to normalize DNS-in-XML or DNS-in-JSON :-) I will define my format and
the field names, but I hope to save time by reusing analogue work.

I'm aware of draft-mohan-dns-query-xml, which partially solves my
problem (except I would like the RDATA to be structured as well, not a
blob of "hexadecimal data").

Anything for JSON?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Jan 2012 16:52:48 +0100

On Wed, Jan 18, 2012 at 10:41:46AM -0500,
 Paul Wouters <[email-masked]> wrote 
 a message of 20 lines which said:

> The latest unbound supports DNS over (real) HTTPS.

The source and the documentation disagree. It is DNS over TLS, not
over HTTPS.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Jan 2012 10:41:46 -0500 (EST)

See unbound.conf man page options "ssl-port", "ssl-service-key" and
"ssl-service-pem".

You can test it against the nlnetlabs resolver (I believe
open.nlnletlabs.nl ?)

Paul

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Jan 2012 17:35:12 +0000

> You can test it against the nlnetlabs resolver (I believe

this sounds very cool; is there an internet draft or tech note
describing the protocol so that others may also implement this?

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 18 Jan 2012 20:06:54 +0100

Hi Paul,

> describing the protocol so that others may also implement this?

It exists to bypass deep inspection firewalls, and it works.  The plain
DNS format as you would use over TCP, but then on an SSL connection, so
its encrypted by SSLv3.  Uses port number 443 (the https port, no other
use of that protocol, but then, because of SSL the firewall should not
be able to tell).

The SSL-certificates are there to make the SSL connection look legit to
the firewall.  The DNSSEC inside the DNS wireformat provides authentication.

There could be a technote or draft for it, but really: TCP-style-DNS
inside SSL for transport.  That should tell enough for an implementation?

Best regards,
   Wouter

---

From: Paul Vixie <[email-masked]>
Date: Wed, 18 Jan 2012 19:14:27 +0000

> use of that protocol, but then, because of SSL the firewall should not

alas, DPI can tell the difference between HTTPS and TLS in a TCP/443
stream. (the Tor guys told me this.)

> inside SSL for transport.  That should tell enough for an implementation?

it's not enough. in particular, the order in which it's probed (compared
to EDNS0 UDP, EDNS0 TCP, old style UDP, old style TCP) should be
specified. the NS RRset gives no hint of the name server's capabilities.
and the IETF definition of "interoperable" depends not just on
independent implementations being able to talk to each other, but
independent implementations both based on the same specification that
can also talk to each other.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 18 Jan 2012 11:19:25 -0800

> stream. (the Tor guys told me this.)

However, a DNS query over 443 CAN be made to look fully like HTTPS for the purpose of traffic analysis, since the query can easily be constructed in a URL with the results returned as an XML or JSON blob.

An active adversary could probe the server and check, but the point is probably to evade ignorant adversaries (misconfigurations), not active censorship.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Jan 2012 20:41:25 +0100

On Wed, Jan 18, 2012 at 07:14:27PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 74 lines which said:

> in particular, the order in which it's probed (compared to EDNS0
> UDP, EDNS0 TCP, old style UDP, old style TCP) should be

As far as I know, it is not intended to be "probed", Unbound does not
attempt to use this feature with regular zone servers. It is supposed
to be a fixed forwarder that you know and trust, specified in the
configuration file (or via unbound-control), to "tunnel" DNS requests
outside of China/EvilCorporationWithFirewall/France.

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 18 Jan 2012 23:20:40 +0000

> outside of China/EvilCorporationWithFirewall/France.

To which I reply:

Hi Stephane, folks,
 ... and, with today's SOPA/PIPA froth, outside of the US?

Pity -- I had hoped that this was using the dns: URL and an XML format had been defined for the response.
[probe would be, I guess do the usual, and if that doesn't work, try port 443 and a dns: URL (or try that first, then ...)]
sigh.

all the best,
  Lawrence

---

From: todd glassey <[email-masked]>
Date: Sat, 28 Jan 2012 10:31:59 -0800

This may not ultimately be the right place to do this but we from an
operational standpoint need to come up with a method of providing a
RIGHT TO USE statement to people using the DNS "publication system" for
converting DNS addresses.

This is critical to a number of things including criminal prosecution of
spammers for fraud by wire and other copyright infringement claims globally.

That said we have been working with a team of lawyers on just this
subject to get some ideas from a legal standpoint how a lawyer would
look at that process.

What we came to is that the lookup process may need to be amended to
support copyright disclosure for the records responded and that this is
key to global copyright protection.

In the interim we think a COPYRIGHT USE STATEMENT published as a TEXT
type record may work for systems which use legacy packages to operate.

Todd Glassey

---

From: Edward Lewis <[email-masked]>
Date: Mon, 30 Jan 2012 09:02:39 -0500

>type record may work for systems which use legacy packages to operate.

Do you mean like the response to these queries?

$ dig ac. txt +short
or
$ dig at. txt +short
and a handful of others?

Beyond that, there is a process defined to add a new DNS RR type defined in BCP
42.

>key to global copyright protection.

As far as altering the query-response mechanism to always include a 
copyright, the workload amounts to doing DNSSEC all over again. 
Adding a copyright to every response is akin to adding an digital 
signature to every response (set).  Even though adding the text would 
be less of a strain than computing the signatures, alterations are 
needed to the basic algorithms (like my fav "RFC 1034/sec 4.3.2" + 
updates) which in turn means new code all around.

(Starting with the 2004 release of the DNSSEC specs, it took about 6 
years to get the root zone signed.  Imagine trying to decide who the 
copyright holder is for the root zone!)

This wouldn't be easy because the DNS just wasn't designed with legal 
restrictions in mind.  Adding a set of requirements means some amount 
of re-engineering.  And I'd add that this set of requirements might 
not be seen as universal.

What I'm suggesting is that beyond adding TXT records in the apex of 
the zone defining anything is going to be a long hard road.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Jan 2012 15:19:49 +0100

On Sat, Jan 28, 2012 at 10:31:59AM -0800,
 todd glassey <[email-masked]> wrote 
 a message of 26 lines which said:

> This may not ultimately be the right place to do

Recurring legal troll in the IETF, hijacking of an email thread and
spurious request, all in one message.

http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html

(Thanks to JPM)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Jan 2012 15:22:32 +0100

On Mon, Jan 30, 2012 at 09:02:39AM -0500,
 Edward Lewis <[email-masked]> wrote 

> the zone defining anything is going to be a long hard road.

DNS_Borat on Twitter suggested that for the glorious nation of .KZ, we
may prefer the "1.2.+.rp.secret-wg.org. TXT" record.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 30 Jan 2012 15:00:14 +0000

> blob of "hexadecimal data").

In this area, draft-levine-dnsextlang-00 might be helpful.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99