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 <
brian.peter.dick...@gmail.com> wrote:
> 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:
> Date: Wed, Oct 15, 2014 at 6:11 PM
> Subject: New Version Notification for
> draft-dickson-dnsop-spartacus-system-00.txt
> To: Brian Dickson
>
>
>
> 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
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
