Subject: Re: [DNSOP] Spartacus and new record types

From: Brian Dickson <[email-masked]>
Date: Wed, 12 Nov 2014 11:07:37 -1000

IIRC, there is support for generic-named types similar to BIND's record
type name/number thing.

The RRTYPE would be a given a name which is something like "rrtypeNNNN",
and numeric value associated with the name, which is NNNN.

The RDATA would be encoded as a specified-length base-64 encoded binary
blob.

The RDATALEN specifies the length of the RDATA.

As to maintaining the specification, given that this is a -00 version, it
might need to be clarified.

I think that this would best be handled in an IANA registry, on the basis
of the existing registered DNS types, names, etc.

I think there is perhaps a need to specify how to craft the entries in that
registry.

Long-term, it may be better to include the encoding as table entries for
the DNS types, as first-class citizen(s) within those other registry
entries.

All of this is flexible.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Nov 2014 10:26:52 +1100

> IIRC, there is support for generic-named types similar to BIND's record

It is RFC3597 format not "BIND's record name/number thing".
 
> and numeric value associated with the name, which is NNNN.

TYPENNNN is reserved for all NNNN [0..65535].  Why reinvent the wheel?

> The RDATA would be encoded as a specified-length base-64 encoded binary

Why switch to base64 rather than continuing with hex?
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Wed, 12 Nov 2014 13:42:36 -1000

Sent from my iPhone

> On Nov 12, 2014, at 1:26 PM, Mark Andrews <[email-masked]> wrote:
> 
> 

Yes, but I believe bind implements said RFC. (Incorporate by reference.)

> TYPENNNN is reserved for all NNNN [0..65535].  Why reinvent the wheel?

Note the word "like". Wheel not reinvented. TYPE is used.

> Why switch to base64 rather than continuing with hex?

It may indeed be hex. No objection to use of hex, hex it is.

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Nov 2014 13:42:41 +0000

I have not had time to look at these drafts, but I think there is
significant overlap with John Levine's DNS description language.
http://tools.ietf.org/html/draft-levine-dnsextlang

Its extension mechanism uses the DNS to store RDATA descriptions, so in
principle software will not need to be updated to support new types.

What I wanted to do in this area (but I have not been able to pursue it)
is make the description language capable of being used to translate
between any of wire format, master file format, whatever json format
anyone might define, and a GUI editing interface. The latter means the
language needs to also be able to describe mnemonic field names and values
and support localised descriptions of them.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Southeast veering southwest 7 to severe gale 9, decreasing 5
or 6 for a time. Rough or very rough. Rain or thundery showers. Moderate or
good, occasionally poor.