Re: [DNSOP] DNS-in-JSON draft

"Paul Hoffman" <> Wed, 21 September 2016 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3B6212B91A for <>; Wed, 21 Sep 2016 11:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YHmrOJcbqBhN for <>; Wed, 21 Sep 2016 11:29:19 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C59912B825 for <>; Wed, 21 Sep 2016 11:29:19 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id u8LITFEB032756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Sep 2016 11:29:17 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: "Paul Hoffman" <>
To: "Shane Kerr" <>
Date: Wed, 21 Sep 2016 11:29:15 -0700
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <>
Cc: dnsop WG <>
Subject: Re: [DNSOP] DNS-in-JSON draft
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Sep 2016 18:29:20 -0000

On 5 Sep 2016, at 21:44, Shane Kerr wrote:

>>> First, it seems like it might be nice to have a way to express RDATA
>>> in
>>> DNS presentation format. The document is very clear that no way is
>>> provided for this, but it seems like it would be really, really
>>> useful.
>> If it useful for a particular application for particular RDATA, that
>> application could easily specify a format in its profile. If that
>> catches on, I could update this document with a collection of those. 
>> But
>> I don't want to start now by specifying the formats I would want 
>> myself.
> Hm... I guess I don't see why the DNS-in-JSON draft can't simply say
> that the formats are those documented in the RFC for any particular
> RTYPE? Each RTYPE has a defined format, right?

Sure, but some of those types don't have definitions of names for the 
presentation format, and some of the early ones have less-than-clear 
names. Also, for RTYPEs that have multiple parts to the RDATA, what 
would it mean to get an answer that had only some of them?

>>> Next, is compressedNAME likely to be useful? I'm not arguing 
>>> strongly
>>> against it, but since it involves pointers and those are not going 
>>> to
>>> be useful with a JSON object, I don't really see much point.
>> I doubt they will be that useful, but a receiver might want to know
>> which names in a message were compressed and which were not. I admit
>> that it would be clearer for that receiver to just look through the
>> message or section binary fields.
> Maybe it could be a value that describes something like this:
> "compressedNAME": { "isCompressed": "yes", "length": 7 }
> The "length" would be the compressed length. The uncompressed length
> can be found by looking at the name.

Good suggestion!

>>> I don't see any mention of whether things like TYPEname and 
>>> CLASSname
>>> are case-sensitive and if they are not which case they should be. My
>>> recommendation would be to make them case-insensitive, although not
>>> every field can be so having to tag each might be a bit much?
>> Well, this brought up an ugly problem. The name in the IANA registry 
>> for
>> class 1 is "Internet (IN)". Chaos and Hesiod are similarly bad. I'm
>> going to change the definition of the class names to be 'String whose
>> value is "IN", "CH", "HS", or has the format in {{RFC3597}}'. I don't
>> think I really need to add to TYPEs that the name is case-sensitive,
>> since it says "from the IANA RR TYPEs registry".
> Makes sense. Stupid DNS classes. :)
> Can you explicitly say that TYPEs are case-INsensitive then? It might
> save some poor coder at some point, since programming languages
> generally default to case-sensitive comparisons...

No, but I will say the opposite, which is more deterministic for 

--Paul Hoffman