Subject: [DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-spartacus-system-00.txt

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Oct 2014 18:58:04 -0700

Hi,
This is the second of the pair of drafts submitted together for
consideration.
(See the first post for the full description.)
Brian Dickson
---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Oct 15, 2014 at 6:11 PM
Subject: New Version Notification for
draft-dickson-dnsop-spartacus-system-00.txt
To: Brian Dickson <[email-masked]>

A new version of I-D, draft-dickson-dnsop-spartacus-system-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:           draft-dickson-dnsop-spartacus-system
Revision:       00
Title:          System to transport DNS over HTTP using JSON
Document date:  2014-10-15
Group:          Individual Submission
Pages:          34
URL:
http://www.ietf.org/internet-drafts/draft-dickson-dnsop-spartacus-system-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-spartacus-system/
Htmlized:
http://tools.ietf.org/html/draft-dickson-dnsop-spartacus-system-00

Abstract:
   This is the SPARTACUS DNS gateway system.  It is designed to
   facilitate the transport of DNS messages opaquely, across problematic
   sections of the Internet.  It uses JSON encoding, and HTTP(S) as the
   protocol for transport.

   The main criteria of SPARTACUS is that it preserve DNS messages
   verbatim, and that only properly formatted DNS messages are passed.

   There are two modes (so far) defined: DNS forwarder (dns clients
   point to a local gateway, which forwards to a remote gateway for
   sending to a DNS resolver); and transparent proxy (DNS packets are
   intercepted, passed to a local gateway, which sends them to the
   remote gateway, with original destination IP address etc. encoded,
   and used by the remote gateway as the destination).

   DNS messages are NAT-friendly, so changes to IP or UDP headers do not
   impact them.  Thus, SPARTACUS does not interfere with TSIG, SIG(0),
   or Eastlake Cookies.

   This document describes the system, the components, and behavior,
   with examples.

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: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 27 Oct 2014 14:16:41 -0400

I understand what is being attempted here and I am a big fan of JSON. But I
don't see the value in representing DNS information in an alternative
syntax.

If we are going to change the discovery interface I would want to go a step
up in abstraction and present the type of interface the application layer
needs. An application is not interested in the details of DNS, it just
wants to connect to a particular service at a particular named site. Using
SRV service names and DNS names is what the application needs.

This is the approach I take in omnibroker:

https://datatracker.ietf.org/doc/draft-hallambaker-omnibroker/

Here the discovery protocol is a meta-discovery protocol taking information
from multiple sources.

On Wed, Oct 15, 2014 at 9:58 PM, Brian Dickson <
[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>