Subject: [dnsext] An RRTYPE extension language

From: "John Levine" <[email-masked]>
Date: 18 Aug 2011 03:22:24 -0000

I was pondering why it's such a pain to deploy a new RRTYPE.  First,
you have to change the code in the authoritative servers (BIND,
Maradns, whatever) to parse the new RR.  Nearly everyone uses some
sort of provisioning system with a web front end or the like to manage
the zone files, so you need to make code changes to the provisioning system,
to handle new RRTYPEs, too.

But most RRTYPEs (not all, but most) are syntactically pretty simple.
How hard would it be to define an RRTYPE definition language for DNS
software that could handle most new RRTYPEs?  If we did that, and
systems had a conventional place to put the definitions, analogous to
/etc/ports, then for new RRTYPEs that don't require either exotic
syntax or semantic changes to the DNS, you add a line or two to the
definition file, and you're done.

So I went through the list of all the RRTYPEs to see what sort of
fields they include.  Disregarding the exotic one-off types like the
longitude and latitude in signed milliseconds in LOC records, it's
nearly all names, strings, and integers of various sizes.  Some of the
integers have named values, or are decoded into named bitmask fields,
but it's still pretty simple.

So if we were adding the KX records from RFC 2230, it'd be something
like this:

KX:36 I2 N

Its name is KX, its RRTYPE is 36, and it has two fields, a two-byte
integer and a domain name.  It'd also need some sort of flag to note
that the server should include additional section info for the N
field, which is typical for N fields.

For SSHFP records from RFC 4255:

SSHFP:44 I1 I1 X

The name is SSHFP, type is 44, record contains two one-byte numbers
followed by a hex string.

For the CERT record in RFC 4398 which has named codes, something
like this:

CERT:27  I2<1:PKIX,2:SPKI,3:PGP,4:IPKIX,5:ISPKI,6:IPGP,7:ACPKIX,\
    8:IACPKIX,253:URI,254:OID> I2 \
    I1<1:RSA/MD5,2:Diffie-Hellman,3:DSA/SHA-1,4:Elliptic,5:RSA/SHA-1> B

The CERT record is three numbers followed by a base64 field. The first
and third numbers can also be written as mnemonic values.  (Feel free
to adjust the syntax to be less ugly.)

Again, this isn't supposed to handle every possible new RRTYPE, but I
think it'll handle enough to make it a lot easier to add the sorts of
types that are now punted to TXT records with prefixed names.

R's,
John

----------------------------------------------------------------------
field types
?     field is optional, must be at the end
<flags> field has named flag bits
<code> field has named code values

A     32 bit IPv4 address as n.n.n.n
AAAA  128 bit IPv6 address as h:h::h
N     uncompressed domain name
CN    compressed domain name
MN    domain name interpreted as a mailbox
CMN   compressed domain name interpreted as a mailbox
S     counted string
MS    one or more counted strings
LS    long string, multiple strings logically concatenated
B     string written as base64
I1    one-octet integer
I2    two-octet integer
I4    four-octet integer
T     Unix timestamp written as YYYYMMDDHHMMSS
X     uncounted string of hex digits

TYPE         Value and meaning                              Reference
-----------  ---------------------------------------------  ---------
A            1 a host address                               [RFC1035]
val A

NS           2 an authoritative name server                 [RFC1035]
val CN

MD           3 a mail destination (Obsolete - use MX)       [RFC1035]
val CN

MF           4 a mail forwarder (Obsolete - use MX)         [RFC1035]
val CN

CNAME        5 the canonical name for an alias              [RFC1035]
val CN

SOA          6 marks the start of a zone of authority       [RFC1035]
val CN CMN I4 I4 I4 I4

MB           7 a mailbox domain name (EXPERIMENTAL)         [RFC1035]
val CN

MG           8 a mail group member (EXPERIMENTAL)           [RFC1035]
val CN

MR           9 a mail rename domain name (EXPERIMENTAL)     [RFC1035]
val CN

NULL         10 a null RR (EXPERIMENTAL)                    [RFC1035]
value is ignored

WKS          11 a well known service description            [RFC1035]
val A I1 <bit map>

PTR          12 a domain name pointer                       [RFC1035]
val CN

HINFO        13 host information                            [RFC1035]
val S S

MINFO        14 mailbox or mail list information            [RFC1035]
val CN CN

MX           15 mail exchange                               [RFC1035]
val I2 CN

TXT          16 text strings                                [RFC1035]
val MS

RP           17 for Responsible Person                      [RFC1183]
val MN N

AFSDB        18 for AFS Data Base location                  [RFC1183][RFC5864]
val I2 N (maybe CN)

X25          19 for X.25 PSDN address                       [RFC1183]
val S

ISDN         20 for ISDN address                            [RFC1183]
val S S?

RT           21 for Route Through                           [RFC1183]
val I2 N

NSAP         22 for NSAP address, NSAP style A record       [RFC1706]
val S S <second is hex string with dots that are ignored>

NSAP-PTR     23 for domain name pointer, NSAP style         [RFC1348] 
val N

SIG          24 for security signature                      [RFC4034][RFC3755][RFC2535]
val I2<rrtype> I1 I1 I4 T T I2 CN B

KEY          25 for security key                            [RFC4034][RFC3755][RFC2535]
val I2<flags> I1<code> I1<code> B

PX           26 X.400 mail mapping information              [RFC2163]
val I2 N N

GPOS         27 Geographical Position                       [RFC1712]
val S S S

AAAA         28 IP6 Address                                 [RFC3596]
val AAAA

LOC          29 Location Information                        [RFC1876]
val <latitude and longitude encoded as milliseconds, and some usually defaulted params>

NXT          30 Next Domain - OBSOLETE                      [RFC3755][RFC2535]
val CN <bit map>

EID          31 Endpoint Identifier                         [Patton]
NIMLOC       32 Nimrod Locator                              [Patton]
SRV          33 Server Selection                            [RFC2782]
val I2 I2 I2 N

ATMA         34 ATM Address                                 [ATMDOC]
val I1<type determined from 2nd arg> S<hex or +E.164 phone number, with ignored dots>

NAPTR        35 Naming Authority Pointer                    [RFC2915][RFC2168][RFC3403]
val I2 I2 I2<flags> S S N

KX           36 Key Exchanger                               [RFC2230]
val I2 N

CERT         37 CERT                                        [RFC4398]
val I2<code> I2 I1<code> B

A6           38 A6 (Experimental)                           [RFC3226][RFC2874]
val I1 <address suffix>? N?

DNAME        39 DNAME                                       [RFC2672]
val N

SINK         40 SINK                                        [Eastlake]
OPT          41 OPT                                         [RFC2671]
val I2<code> I2 <stuff>

APL          42 APL                                         [RFC3123]
val I2 I1 <one-bit flag> <7 bit length> <stuff>

DS           43 Delegation Signer                           [RFC4034][RFC3658]
val I2 I1<code> I1<code> X

SSHFP        44 SSH Key Fingerprint                         [RFC4255]
val I1<code> I1<code> X

IPSECKEY     45 IPSECKEY                                    [RFC4025]
val I1 I1 I1 <A/AAAA/N> B

RRSIG        46 RRSIG                                       [RFC4034][RFC3755]
val I2<rrtype> I1<code> I1 I4 T T I2 N B

NSEC         47 NSEC                                        [RFC4034][RFC3755]
val N <rrtype bitmap>

DNSKEY       48 DNSKEY                                      [RFC4034][RFC3755]
val I2 I1 I1<code> B

DHCID        49 DHCID                                       [RFC4701]
val B

NSEC3        50 NSEC3                                       [RFC5155]
val I1 I1 I2 <count/hex> <count/base32> <rrtype map>

NSEC3PARAM   51 NSEC3PARAM                                  [RFC5155]
val I1 I1<zero> I2 <count/hex>

Unassigned   52-54
HIP          55 Host Identity Protocol                      [RFC5205]
val <multiple stuff with lengths>

NINFO        56 NINFO                                       [Reid]
RKEY         57 RKEY                                        [Reid]
TALINK       58 Trust Anchor LINK                           [Wijngaards]
CDS          59 Child DS                                    [Barwood]
Unassigned   60-98
SPF          99                                             [RFC4408]
val LS

UINFO        100                                            [IANA-Reserved]
UID          101                                            [IANA-Reserved]
GID          102                                            [IANA-Reserved]
UNSPEC       103                                            [IANA-Reserved]
Unassigned   104-248
TKEY         249 Transaction Key                            [RFC2930]
TSIG         250 Transaction Signature                      [RFC2845]
<does not appear in zone files>

??? next four are qtypes, not rrtypes
IXFR         251 incremental transfer                       [RFC1995]
AXFR         252 transfer of an entire zone                 [RFC1035][RFC5936]
MAILB        253 mailbox-related RRs (MB, MG or MR)         [RFC1035]
MAILA        254 mail agent RRs (Obsolete - see MX)         [RFC1035]
*            255 A request for all records                  [RFC1035]

URI          256 URI                                        [Faltstrom]
CAA          257 Certification Authority Authorization      [Hallam-Baker]
Unassigned   258-32767
TA           32768   DNSSEC Trust Authorities               [Weiler]           2005-12-13
DLV          32769   DNSSEC Lookaside Validation            [RFC4431]
val I2 I1<code> I1<code> X

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Aug 2011 09:30:28 -0400 (EDT)

On Wed, 18 Aug 2011, John Levine wrote:

> Subject: [dnsext] An RRTYPE extension language
> 
> I was pondering why it's such a pain to deploy a new RRTYPE.

People just think it is. It is not.

> First, you have to change the code in the authoritative servers (BIND,

That's rare. Like for DNSSEC that was needed, but for most RRTYPEs that's not true.

> to handle new RRTYPEs, too.

This is why the unknown record type was invented.

http://tools.ietf.org/html/rfc3597

I'm playing with DANE and I can just specify a new RRTYPE without hacking either
bind or nsd or unbound. I just put in the zone:

_443._tcp.www.xelerance.com. IN TYPE65468 \# 34 010130102FA54AE5CD5852D0CFAF1FE5F467C547D766A13410079BB2B01319B702B9

34 is the two bytes for the dane subtype plus 32 bytes for the SHA1 length, telling the parser
who long the rrdate is.

You could express your other examples in this syntax. It might not be the nicest syntax,
but it works.

Paul

---

From: "John R. Levine" <[email-masked]>
Date: 18 Aug 2011 09:45:21 -0400

> People just think it is. It is not.

Sigh.

> _443._tcp.www.xelerance.com. IN TYPE65468 \# 34 
> 010130102FA54AE5CD5852D0CFAF1FE5F467C547D766A13410079BB2B01319B702B9

Perhaps "deploy" means something other than what you think it does.  Yes, 
most DNS servers have an escape syntax that lets you specify arbitrary 
record types in hex or octal.  I've added kludges to my provisioning 
software to translate a syntax for AAAA recors into octal escapes that 
tinydns can handle.

But are you volunteering to take the support calls from all my users to 
explain to them how to translate everything into hex when they want to add 
new records into my provisioning system?  If you expect people who are not 
DNS weenies to use new RRTYPEs, they have to be able to provision them in 
terms they can understand.

DANE is relatively tough, since a useful provisioning system will need not 
just the RR syntax but some way to describe the certs.  But most RRs are 
easier than that, hence this proposal.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Aug 2011 10:00:13 -0400

At 9:45 -0400 8/18/11, John R. Levine wrote:

>explain to them how to translate everything into hex when they want to add new
>records into my provisioning system?  If you expect people who are not DNS
>weenies to use new RRTYPEs, they have to be able to provision them in

A point was missed.  The unknown record type RFC describes how the 
DNS passes back and forth data it doesn't understand and doesn't need 
to.  (The DNS needs to know what's in an SOA, NS, A, AAAA, dnssec, 
MX, CNAME, DNAME and a few others, it doesn't need to know about 
NAPTR, SRV, TXT, and others.)

The "UI" around this can do whatever it wants.

"Your provisioning system" is free to present to the user what ever 
data presentation you want.  It can be in French, Hindi, pictograms 
or even in Hex.  You just need to, behind the scenes, translate it to 
the wire format (or in the printed wire format if you are shoe 
horning this onto something like "a" BIND that needs text file 
input).  And then to present to the user, parse the wire back to 
pretty format.

Applications can put what ever gunk they want into the DNS.  There 
are even type codes reserved that don't need to be documented 
publicly or reserved specially.  All that needs to know how to handle 
it are the ends of the transfer.

The painful part is getting people to switch from the type code used 
in testing to the type code eventually allocated once the paperwork 
is done.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.

---

From: "John R. Levine" <[email-masked]>
Date: 18 Aug 2011 10:29:24 -0400

> "Your provisioning system" is free to present to the user what ever data 
> presentation you want.  It can be in French, Hindi, pictograms or even in 
> Hex.  You just need to, behind the scenes, translate it to the wire format 
> (or in the printed wire format if you are shoe horning this onto something 
> like "a" BIND that needs text file input).  And then to present to the user, 
> parse the wire back to pretty format.

Right.  But my point is that without a working provisioning system, it is 
in practice impossible to use an RR other than for the 0.0001% of people 
who are DNS weenies like us.  Hence my desire to make it easier to update 
them to do so.

Regards,

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Aug 2011 10:37:52 -0400 (EDT)

On Thu, 18 Aug 2011, John R. Levine wrote:

>> like "a" BIND that needs text file input).  And then to present to the 
>> user, parse the wire back to pretty format.
>
> Right.  But my point is that without a working provisioning system, it is in 
> practice impossible to use an RR other than for the 0.0001% of people who are 
> DNS weenies like us.  Hence my desire to make it easier to update them to do 
> so.

Someone needs to translate. Its either your provisioning system, or the user.
In the dane example, I would let the user select "TLSA" and "cert type" and
a hostname, and I'd have the provisioning system to the dane.py call to
probe the TLS and covert it to zonefile digestable syntax. Perhaps let the user
verify it before commiting.

Paul

---

From: "John R. Levine" <[email-masked]>
Date: 18 Aug 2011 10:42:23 -0400

> probe the TLS and covert it to zonefile digestable syntax. Perhaps let the 
> user verify it before commiting.

It appears we agree that a new RR such as DANE is not in practice usable 
until there is support for it in provisioning systems.  So would it be a 
good idea to automate adding support to provisioning systems where 
possible?

R's,
John

---

From: Jim Reid <[email-masked]>
Date: Thu, 18 Aug 2011 15:46:55 +0100

On 18 Aug 2011, at 15:29, John R. Levine wrote:

> But my point is that without a working provisioning system, ...

For some unspecified definition of "working".

> Hence my desire to make it easier to update them to do so.

I don't see the point quite frankly. I doubt anyone will use such a  
beast if it existed because the control panels and what have you that  
are in use today are unlikely to ever be replaced or dragged out of  
the Stone Age. [The week before last one of them told me an IPv6  
address in colon notation was not an IP address!] In general these  
provisioning systems are so tightly coupled to existing business  
processes, CRM systems and back-end databases that they are just too  
difficult to change. And there are other things that those programmer  
hours could be spent on.

Anyhow, further discussion of these provisioning systems isn't needed  
IMO. Just write up an I-D on your proposed extension language (or  
gather a set of requirements). A proper document is the obvious  
starting point for a meaningful discussion.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 18 Aug 2011 10:50:18 -0400

>who are DNS weenies like us.  Hence my desire to make it easier to update

That (your point) is true for any technology.  Usually the place to 
solve this is in the provisioning interface (the UI) and not the guts 
of the system.  In this case, the DNS already has the guts - unknown 
record type rules - and it is up to "you" to decide what to enter and 
what to extract from the type you want.

It's always been all about the user interface, perhaps the user user 
interface tells an application and the application uses an 
application interface - the same but with a level of indirection.

OTOH, maybe you want to dig up the old SINK RR history (never made it 
to RFC but has a type code reserved) - 
http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02 .  I'm 
not raising that to be funny, maybe I and at least Paul are assuming 
more about the problem then you intend.

I'm overly entertained.

---

From: "John R. Levine" <[email-masked]>
Date: 18 Aug 2011 14:06:15 -0400

> I don't see the point quite frankly. I doubt anyone will use such a beast if 
> it existed because the control panels and what have you that are in use today 
> are unlikely to ever be replaced or dragged out of the Stone Age.

You many be right, but that doesn't seem like a reason not to offer a path 
to make them relatively future-resistant, rather than patching each time 
there's a new RR.

> Anyhow, further discussion of these provisioning systems isn't needed IMO. 
> Just write up an I-D on your proposed extension language (or gather a set of 
> requirements). A proper document is the obvious starting point for a 
> meaningful discussion.

I'm happy to do that, but there's not much point if people will just 
insist that either provisioning isn't a problem, or it's too grubby for 
DNSEXT to think about.

Regards,

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Aug 2011 14:34:14 -0400

On Thu, Aug 18, 2011 at 02:06:15PM -0400, John R. Levine wrote:
> insist that either provisioning isn't a problem, or it's too grubby
> for DNSEXT to think about.

Speaking personally, I think it _is_ a problem and I am willing to
review such a draft.

Speaking as a co-chair but without having conferred with Olafur, I'm
not totally sure this is something that would fit correctly in
DNSEXT's charter, since this is in support of wire changes instead of
a protocol issue _per se_.  This might actually be DNSOP fodder
instead.  We can have a jurisdiction fight after there's a draft,
however.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2011 18:48:36 -0000

>Speaking personally, I think it _is_ a problem and I am willing to

Oh, good.  I'll go write something, with luck by the end of
next week.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Aug 2011 12:18:58 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Thursday, August 18, 2011 11:34 AM
> To: [email-masked]
> Subject: Re: [dnsext] An RRTYPE extension language
> 

Ditto.

-MSK

---

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Aug 2011 16:16:52 -0400

> Speaking personally, I think it _is_ a problem and I am willing to

Coming late to the party, but I too am willing to review and / or contribute...

> instead.  We can have a jurisdiction fight after there's a draft,

Yah.

W

> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>