[dnsext] An RRTYPE extension language
"John Levine" <johnl@iecc.com> Thu, 18 August 2011 03:21 UTC
Return-Path: <johnl@iecc.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFC45E8003 for <dnsext@ietfa.amsl.com>; Wed, 17 Aug 2011 20:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_13=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd0pVlv25cUG for <dnsext@ietfa.amsl.com>; Wed, 17 Aug 2011 20:21:57 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7575E8002 for <dnsext@ietf.org>; Wed, 17 Aug 2011 20:21:56 -0700 (PDT)
Received: (qmail 16603 invoked from network); 18 Aug 2011 03:22:47 -0000
Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 18 Aug 2011 03:22:47 -0000
Received: (qmail 70816 invoked from network); 18 Aug 2011 03:22:46 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2011 03:22:46 -0000
Date: Thu, 18 Aug 2011 03:22:24 -0000
Message-ID: <20110818032224.45073.qmail@joyce.lan>
From: John Levine <johnl@iecc.com>
To: dnsext@ietf.org
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Subject: [dnsext] An RRTYPE extension language
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2011 03:21:58 -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
- [dnsext] An RRTYPE extension language John Levine
- Re: [dnsext] An RRTYPE extension language Paul Wouters
- Re: [dnsext] An RRTYPE extension language John R. Levine
- Re: [dnsext] An RRTYPE extension language Edward Lewis
- Re: [dnsext] An RRTYPE extension language John R. Levine
- Re: [dnsext] An RRTYPE extension language Paul Wouters
- Re: [dnsext] An RRTYPE extension language John R. Levine
- Re: [dnsext] An RRTYPE extension language Jim Reid
- Re: [dnsext] An RRTYPE extension language Edward Lewis
- Re: [dnsext] An RRTYPE extension language John R. Levine
- Re: [dnsext] An RRTYPE extension language Andrew Sullivan
- Re: [dnsext] An RRTYPE extension language John Levine
- Re: [dnsext] An RRTYPE extension language Murray S. Kucherawy
- Re: [dnsext] An RRTYPE extension language Warren Kumari