Subject: [dnsext] Draft of an RRTYPE extension language

From: "John Levine" <[email-masked]>
Date: 19 Aug 2011 05:04:40 -0000

I was supposed to be doing something else tonight, so I wrote
up a draft of my extension language thing instead.  See

http://www.ietf.org/id/draft-levine-dnsextlang-00.txt

R's,
John
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: George Michaelson <[email-masked]>
Date: Fri, 19 Aug 2011 15:11:11 +1000

> http://www.ietf.org/id/draft-levine-dnsextlang-00.txt

I think this is interesting. I think the main interest I have is that its a formalism to describe the new RR, which could be done many ways: C struct, ASN.1, (E)BNF.

I think this is no worse than other ways, and it doesn't proscriptively limit the SEMANTIC meaning of the new RR.

I wonder if its going to be sufficiently extensible for forseeable requirements. SRV for instance encodes structures like regex() which is 'powerful' (ie complicated)

But that aside, I found the draft readable, and interesting.

I think this is worth discussion.

-George

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2011 01:26:58 -0400

> I wonder if its going to be sufficiently extensible for forseeable requirements. SRV for instance encodes structures like regex() which is 'powerful' (ie complicated)

SRV is three integers and a domain name.  Do you mean NAPTR?  It includes 
a regex, but the regex isn't interpreted within the DNS, only by clients, 
so as far as the DNS is concerned, it's just a string.

  NAPTR:35 I2 I2 S S S N[A]

I should probably emphasize that this isn't supposed to be the FUSRP*. 
Some RRs require that the DNS server do something new, so if for example 
we added a BNAME record, it'd be easy enough to describe the syntax, but 
that wouldn't tell the DNS server about all the new synthesis rules.

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

* - Final Ultimate Solution to the RRTYPE Problem
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: George Michaelson <[email-masked]>
Date: Fri, 19 Aug 2011 15:30:59 +1000

On 19/08/2011, at 3:26 PM, John R. Levine wrote:

> SRV is three integers and a domain name.  Do you mean NAPTR?  It includes a regex, but the regex isn't interpreted within the DNS, only by clients, so as far as the DNS is concerned, it's just a string.
> 

Yes I meant NAPTR.

And, as you say...

> I should probably emphasize that this isn't supposed to be the FUSRP*. Some RRs require that the DNS server do something new, so if for example we added a BNAME record, it'd be easy enough to describe the syntax, but that wouldn't tell the DNS server about all the new synthesis rules.

its descriptive only, in a structural Octet-level-encoding sense. 

> * - Final Ultimate Solution to the RRTYPE Problem

I really hate use of the words Final and Solution in one sentence. we've both just aquired a huge amount of Baysian for Godwin filters.

-G

---

From: Tony Finch <[email-masked]>
Date: Fri, 19 Aug 2011 10:58:47 +0100

> http://www.ietf.org/id/draft-levine-dnsextlang-00.txt

I think this is an interesting idea.

For auto-provisioning user interfaces I think you need a description for
each field, e.g.

MX:15
  I2      Priority
  N[A,C]  Mail server

SRV:33
  I2    Priority
  I2    Weight
  I2    Port
  N[A]  Server

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: Southeast becoming cyclonic 5 to 7, increasing gale 8 for a time.
Moderate or rough, becoming very rough or high later. Rain or showers.
Moderate or good, occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Posner, Sebastian" <[email-masked]>
Date: Fri, 19 Aug 2011 14:54:56 +0200

> http://www.ietf.org/id/draft-levine-dnsextlang-00.txt

I think I'd like to see a qualifier for N that restricts
the contained Domain Name to be something that *directly*
leads to an address-RR, as required e.g. for the "target" 
of SRV-Records (http://tools.ietf.org/html/rfc2782).

Kind regards,

Sebastian
--
Sebastian Posner
Unix-Systemspezialist
AM Data Center Services, Shared Infrastructure
Deutsche Telekom AG, Products & Innovation
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2011 11:01:56 -0400

> For auto-provisioning user interfaces I think you need a description for

I had the same thought about five minutes after I posted the draft.  Will 
try and work up a revised version.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2011 11:15:00 -0400

> of SRV-Records (http://tools.ietf.org/html/rfc2782).

You can't enforce that -- even if the target is OK now, someone might 
change it later, and if I'm editing records in a provisioning system, I 
might enter the SRV record before the A records it points to.  We can also 
have an argument about whether anyone still cares about that rule in a 
more than hypothetical way, but not here, please.

I suppose there might be some value in assertions that a provisioning 
system or DNS server could check to warn about semantic errors, but I do 
not want to fall down the slippery slope to reimplementing the entire DNS 
in an interpreter.

Regards,

---

From: Ben Clifford <[email-masked]>
Date: Fri, 19 Aug 2011 19:37:36 +0200

On Aug 19, 2011, at 5:15 PM, John R. Levine wrote:
> 
> You can't enforce that -- even if the target is OK now, someone might change it later, and if I'm editing records in a provisioning system, I might enter the SRV record before the A records it points to.  

If this draft is aimed squarely at provisioning systems, then the compression and additional record processing flags are irrelevant. (If its aimed more to "encapsulate the machine usable pieces of the defining RFC, whatever that machine may be", then not so...)

It can still have some potentially useful advisory role that is still machine checkable. (modulo the "does anyone care" that was mentioned elsewhere)

Human readable descriptions are advisory too although even less enforceable (for example, try enforcing that the IP address in an A record really is the address of the host I intend it to be).

--

---

From: "John R. Levine" <[email-masked]>
Date: 19 Aug 2011 17:59:56 -0400

> If this draft is aimed squarely at provisioning systems, then the compression and additional record processing flags are irrelevant. (If its aimed more to "encapsulate the machine usable pieces of…

My plan, which I think is expressed reasonably clearly in the draft, is 
that it's also aimed at authoritative server software, so they can handle 
new RRTYPEs without code changes and without having to sneak them in via 
hex escape codes.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Aug 2011 05:04:50 +1000

In message <[email-masked]>, "John R. Levine" wr
ites:
> >> You can't enforce that -- even if the target is OK now, someone might chan
> ge it later, and if I'm editing records in a provisioning system, I might ent
> er the SRV record before the A records it points to.
> >
> > If this draft is aimed squarely at provisioning systems, then the compressi
> on and additional record processing flags are irrelevant. (If its aimed more 
> to "encapsulate the machine usable pieces of the defining RFC, whatever that 
> machine may be", then not so...)
> 

Compression will NEVER happen with new records.

What I do worry about this is that it will artificially limit new
RR's to formats that can be expressed in this language.  Also this
doesn't have to be formalised.  ISC's DHCP, for example, supports
the defining new DHCP options in the DHCP server and client
configurations.  The older definition language doesn't support DNS
encoding of domain names or AAAA addresses but I believe the newer
one does.

You will also need stuff like I2[LEN(F1),B] (2 byte int, length of
field(#), not printed(B)). For this to be useful you need to be
describing presentation to wire and some wire fields don't exist
in the presentation.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Aug 2011 12:18:52 -0700

On Aug 21, 2011, at 12:04 PM, Mark Andrews wrote:

> RR's to formats that can be expressed in this language.  

Not at all. No one has to make their records work with the new language: they can expect domain admins to still do hex-stuffing like they do today.

> Also this
> doesn't have to be formalised.  

Correct. Formalization is very useful, but not required. Sometimes work in the DNSEXT WG is meant to be very useful even if not required.

--Paul Hoffman

---

From: "John R. Levine" <[email-masked]>
Date: 21 Aug 2011 15:20:03 -0400

> Compression will NEVER happen with new records.

I know.  I put it in there to give people the option of describing 
some existing records the same way as new ones.

> RR's to formats that can be expressed in this language.

I suppose, but opposed to the current situation of no new RRs at all 
unless people are incredibly desperate (DNSSEC), it doesn't seem like a 
bad tradeoff.  If you think there are other field types that are likely to 
be popular enough to be worth describing, I'm not opposed to that.  It 
also occurred to me that if this limits people's desire to add random hard 
to describe new field types, that wouldn't necessarily be bad.

>  Also this doesn't have to be formalised.

Of course it does.  The whole point is to be able to distribute 
descriptions of new RRTYPEs and have some hope that large numbers of 
servers and provisioning systems can use them.

> field(#), not printed(B)).

Ewww.  I can see that you might want to insert fixed fields (although that 
strikes me as an admission that the RRTYPE is poorly designed), but I 
really don't see it as desirable to encourage people to invent new fields 
that are so big you can't encode the length in one byte.

Regards,