Subject: RE: draft-iab-dns-choices-02.txt comments

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Fri, 10 Jun 2005 15:29:41 -0400

Am I missing something?

RFC 2929, as well as allocating RR Type numbers from 65280 - 65534 (0xFF00 - 0xFFFE) for private use also allocates almost half of all RR Type numbers, those from 32768 - 65280 (0x8000 - 0xFEFF), for use based on "Specification Required". That is, as defined in RFC 2434:

      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible.

Isn't getting an RR Type based on just publicly documneting its use liberal enough?

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John R Levine
Sent: Thursday, June 09, 2005 10:54 AM
To: [email-masked]
Subject: Re: draft-iab-dns-choices-02.txt comments

...

We don't need dynamic RR types, there's plenty of them.  We need to 
drastically lower the bar to assigning RR types.  It's a 16 bit field, if 
they handed out a thousand numbers of which only two turned out to be 
useful, it wouldn't be a big deal, it's less than 2% of the address space. 
It might also be good to designate some chunk of the RR space as the 
experimental range where numbers will never be assigned so people can 
safely fool around with private types there.

...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 10 Jun 2005 12:42:25 -0700 (PDT)

> Isn't getting an RR Type based on just publicly documneting its use 

I've not seen any RR types allocated except though IETF consensus and RFC.

Perhaps if RFC2929 is already liberal enough then clarification from
this WG would be good or establishing a better documented procedure for 
requesting new RR (documented in separate document released preferably
as INFORMATIONAL RFC or BCP) would be good enough and allow those who
are proposing new uses of DNS to get RR type numbers quickly though
IANA that they could test their proposals and experiment with real-life
deployment.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John Levine <[email-masked]>
Date: 10 Jun 2005 23:08:03 -0000

> Isn't getting an RR Type based on just publicly documneting its use

You're right, I misremembered 2929.  My bad.

This still leaves us with the question of why we see so few new RR types
in practice.  I guess it's a combination of the difficulty of getting
them into zone files and the dismayingly large number of junkware clients
that can't query them.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 11 Jun 2005 10:53:34 +0200

>them into zone files and the dismayingly large number of junkware clients

Or maybe it is due to much simpler reason such as the fact that enterprises
in contrast to ISPs use MSFT tools and GUIs and there is no way defined way
of extending the GUI for supporting new RR types?

And then we have the thing that people already have mentioned a zillion times.
The development process is hindered by not being able to allocate
an RR in an ad-hoc way without anyone judging if the RR is useful or not.
To state like DomainKeys does, that they "intend" to register an RR when
the things is ready is completely wacko as it leaves the users having
to support TWO schemes.   Indefinitely BTW.  How smart is that?

And then we have the fact that the scheme used in DomainKeys,
prefixed TXT type actually works _perfect_ for the majority of
applications and does not create any larger return set than a
new RR type would.

The only problem with the prefixscheme is that the prefixes are
not registered.  Using URI-encoded prefixes you can safely
add a new "DNS data type" anytime and not even have to
publish it!

That the author of DNS-CHOICES did not invent a new RR
for his famous ENUM stuff but overloaded NAPTR is a sure
sign of that we need to do a reality check.  In what way could
a multivalued NAPTR be different to a multivalued TXT?

Anders R

---

From: John Levine <[email-masked]>
Date: 11 Jun 2005 11:29:48 -0000

>not registered.

That's not much of a problem because the name space is so big.  The
more serious issue is that they don't work with wildcards.

---

From: wayne <[email-masked]>
Date: Sat, 11 Jun 2005 07:55:32 -0500

> to support TWO schemes.   Indefinitely BTW.  How smart is that?

Agreed.  The spf-classic I-D also calls for the creation of a new RR.
I don't ever see it being used in any significant way.  There isn't
any realistic migration plan.

> a multivalued NAPTR be different to a multivalued TXT?

Indeed.  And it isn't just NAPTR that is being overloaded.  Anti-spam
DNSBLs have long overload A records in order to get a bit (or
sometimes a few bits) for flags.  The SPF system codifies this
practice with the exists: mechanism, but I haven't heard any
complaints about this overloading the meaning of A records by SPF.
The CSV system overloads SRV records.

It isn't just TXT records that are being overloaded and I don't recall
dns-choices even mentioning this.

-wayne

---

From: John Levine <[email-masked]>
Date: 11 Jun 2005 21:49:03 -0000

>The CSV system overloads SRV records.

I would say that DNSBLs and CSV reuse other record types, rather than
overloading them.  The important difference is that they have their
own namespaces.  Any A record returned from 1.2.3.4.somednsbl.org
means the same thing, this IP is in this DNSBL.  Wildcards work the
way you'd want, and you can list a /24 witn *.2.3.4.somednsbl.org.
Similarly, the SRV record you get back from _client.smtp.example.org
is always a CSV record.  Wildcards don't work, but that's a problem
with all SRV records.

A simple way to look at it is to say that the combination of the domain
name and the record type identifies the data you want.  If you do a lookup
and you get something back, that's definitely the data you want.

With TXT or TXT99 or whatever, you have to look inside the record to
see what kind it is, and that's the problem.  The data you get back
might be what you want, and might be something completely irrelevant.

R's,
John

---

From: John Levine <[email-masked]>
Date: 11 Jun 2005 21:49:03 -0000

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 12 Jun 2005 20:08:14 +0200

On Jun 11, 2005, at 10:53, Anders Rundgren wrote:

> sign of that we need to do a reality check.

I wrote the draft specifically with experience from ENUM in mind.  
Reusing NAPTR is one of the big problems with ENUM.

I would never do it again, and I don't want anyone else to make the  
same mistake.

But, you should also know that at the day of ENUM origin (1998) the  
view in the DNS community was that addition of a new RR (i.e.  
handling of unknown RR types) was hard.

It is not anymore.

    paf

---

From: "John R Levine" <[email-masked]>
Date: 12 Jun 2005 17:11:51 -0400

> the view in the DNS community was that addition of a new RR (i.e.

Considering how hard it is now, it must have been truly stupefying then.

In any event, it's pretty clear that we need to start assigning new RRs to
new applications to create the demand for upgrades to DNS software that
can use it.

Maybe as a band-aid we could use temporary proxies that accept encoded TXT
requests and fetch the real data.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Jun 2005 00:11:55 +0000

> Considering how hard it is now, it must have been truly stupefying then.

adding an rrtype isn't all that hard.  there's an experimental numbering
space, and also, BIND (even late model bind8) can handle opaque rrtypes
including transferring and querying and even updating them.

the difficulty SPF is encountering is not related to the new rrtypes they
want to propose, but rather that community's insistence that the size of
their installed base means they shouldn't be subject to ietf consensus.

> new applications to create the demand for upgrades to DNS software that

this is a fine approach.  any middlebox or authority server who upgrades
to late-model bind8/bind9, or nominum ans/cns, or microsoft's dns server,
will become friendly to rrtypes that did not exist at compile time, and
that upgrade would be a fine thing to push for, for a variety of reasons.

however, new rrtypes are almost certainly the wrong way to solve most of
the problems i've seen discussed on this thread.  what we need is fixed
format rrtypes (like we have, other than TXT or various self-describing
proposals like XML or ASN1), and useful subclassing for application names.

the fact that RP and MX have the same rdata format is a botch.  there ought
to be one rrtype for "has a 16-bit unsigned number, and a domain name" and
the application should be a subdomain (RP._app.VIX.COM, MX._app.VIX.COM,
or even responsible_person._app.VIX.COM and mail_exchanger._app.VIX.COM).

(note that to get this working, we'll need nonterminal wildcards, and we'll
need to shift the wildcard processing from the authority servers to the
endsystem clients.)

> requests and fetch the real data.

that turns out to be a bad idea.  in dns, only the authority can synthesize,
which is completely nonhelpful in the case you're describing.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 12 Jun 2005 21:26:51 -0400

On 6/12/2005 8:11 PM, Paul Vixie wrote:

> there ought to be one rrtype for "has a 16-bit unsigned number, and a
> domain name" and the application should be a subdomain
> (RP._app.VIX.COM, MX._app.VIX.COM, or even
> responsible_person._app.VIX.COM and mail_exchanger._app.VIX.COM).

I agree that there should be well-defined data-types (a four-byte "addr"
record wouldd be considerably better than the 17-byte sequence of textual
octets we have now), but I disagree with the rest of your proposal for
sevearl reasons. Biggest problem is that the namespace is infinitely wide
but it's not infinitely deep, and the use of prefixes in the namespace is
a negative wrt the shallowness of the namespace. Second is that code
values require less computation.

But we absolutely need strong data-typing. It's always kind of seemed
silly to me that the most structured of application protocols is also the
one that has the least amount of formal typing.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Jun 2005 10:12:23 +0100

--On 13 June 2005 00:11 +0000 Paul Vixie <[email-masked]> wrote:

> the fact that RP and MX have the same rdata format is a botch.  there
> ought to be one rrtype for "has a 16-bit unsigned number, and a domain
> name" and the application should be a subdomain (RP._app.VIX.COM,
> MX._app.VIX.COM, or even responsible_person._app.VIX.COM and
> mail_exchanger._app.VIX.COM).
>
> (note that to get this working, we'll need nonterminal wildcards, and
> we'll need to shift the wildcard processing from the authority servers to
> the endsystem clients.)

That sounds an awful lot more pain than either
* one new RR type per _app; or
* one new RR type in total, with _app in the data in sensible form, and
  handle large queries right
for not very much gain.

Either of the above work with "any middlebox or authority server who
upgrades to late-model bind8/bind9, or nominum ans/cns, or microsoft's dns
server," (your words!) right now and don't require reinventing wildcards.

If you are going to rewrite the matching algorithm, I would suggest looking
at the whole thing as a 4-Tuple (with the additional field having an RRType
dependent meaning) rather than a 3-Tuple might be worth looking at. A
4-Tuple query with the additional field set to "any" would have the same
meaning as a current 3-tuple query. That, after all, is "doing it right"
(which is presumably what you are trying to achieve with your proposal).
How's that for invasive? :-)

Alex

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Jun 2005 08:46:52 -0400

>I've not seen any RR types allocated except though IETF consensus and RFC.

Prior to RFC 2929, one example, to pick a flawed one, was the OPT RR. 
The OPT RR process was flawed in that it received the wrong number. 
(It was thought that it would have a number with the meta-types, 
instead it got #41.)  The problem was that no one informed IANA that 
the OPT record deserved a special type number.

This mishap was one reason for the production of RFC 2929.

As far as "isn't ... just publicly documenting" in an RFC or other 
permanent reference "liberal enough?"  I would say no.

These are the type codes defined by documents post RFC 2929:

APL             42 APL                          [RFC3123]
DS              43 Delegation Signer            [RFC3658]
SSHFP           44 SSH Key Fingerprint          [RFC-ietf-secsh-dns-05.txt]
IPSECKEY        45 IPSECKEY                     [RFC-ietf-ipseckey-rr-11.txt]
RRSIG           46 RRSIG                        [RFC3755]
NSEC            47 NSEC                         [RFC3755]
DNSKEY          48 DNSKEY                       [RFC3755]

Note that two of them are in pending RFC's, which kind of violates 
the instructions in RFC 2929.  Some may say that these are "special 
cases" and the rules ought to be bent for these instances.  I'd 
agree, but when we start with unwritten bending of the rules, it's a 
sign we've build a bad bureaucracy.

Note that all of the types listed also originated within the DNSEXT 
WG.  The SSH and IPSEK key work did come from other WG's but that was 
not until the work was expelled in December 2001. (RFC 2929 is dated 
September 2000.)

Since RFC 2929, no application-driven RR type code number has been 
assigned by IANA.  I would say that this is a sign that the policy is 
not liberal enough.

PS - For an added bit of irony, the numbers preceding that list are 41 (the
incorrectly assigned OPT RR) and 40, the SINK record.  There is no 
permanently archived document describing the SINK record.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Jun 2005 13:20:17 +0000

> * one new RR type per _app; or

total number of rdata parsers would go up; this is expensive.

>   handle large queries right

complexity of that one rdata parser would be high; this is expensive.

> for not very much gain.

as a one-time implementor, i took the pain/gain tradeoff directly into
account when making that proposal.

> upgrades to late-model bind8/bind9, or nominum ans/cns, or microsoft's
> dns server," (your words!) right now

i guess almost any rrtype related change can finally make that claim.  yay!

> and don't require reinventing wildcards.

you're right.  neither does this one.  it would just be a kindness to the
dnssec effort to move ALL synthesis to the requestor, in a backward
compatible kind of way of course.

> If you are going to rewrite the matching algorithm, I would suggest
> looking at the whole thing as a 4-Tuple (with the additional field
> having an RRType dependent meaning) rather than a 3-Tuple might be
> worth looking at. A 4-Tuple query with the additional field set to
> "any" would have the same meaning as a current 3-tuple query. That,
> after all, is "doing it right" (which is presumably what you are
> trying to achieve with your proposal).  How's that for invasive? :-)

the type-covered field in RRSIG functions effectively as a subtype, and
when we were discussing it we didn't try to generalize it.  very sad,
but not too late.  if you think a subtype would be easier to shoehorn
in than a subdomain, i'm listening.  frankly, i'd like to have both, but
i consider the subtype or any other change to the q-tuple to be even 
more violent than moving the synthesis processing would be.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Jun 2005 14:33:17 +0100

Paul,

> you're right.  neither does this one.

I'm having imagination failure. How can your scheme work with traditional
wildcards? (i.e. without rewriting the wildcard semantics).

> more violent than moving the synthesis processing would be.

Agree - that's what I meant by invasive. But it is probably "the right
thing to do" (tm).

Alex

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Jun 2005 13:52:22 +0000

> wildcards? (i.e. without rewriting the wildcard semantics).

since noone is currently querying for names under _app.$DOMAIN, we have the
opportunity to require multiple queries.  therefore to simulate the effect
of a nonterminal wildcard such as:

	mail_exchanger._app.**.VIX.COM.

we can put in nodes of the form:

	mail_exchanger._app.VIX.COM.
	*.mail_exchanger._app.VIX.COM.

and clients can be told that if they're looking for a mail_exchanger._app
for a service name of FOO.VIX.COM, they should look up two DNS names:

        mail_exchange._app.FOO.VIX.COM.
        FOO.mail_exchange._app.VIX.COM.

this is NOT AS CLEAN and relies heavily on negative caching, which is ill
supported in the current dns ecosphere.  but it would work using current
wildcard semantics.  i'd rather add nonterminal wildcards, move all wildcard
and other synthesis to clients, and add subtypes.  but that's a ten year
project and we probably have a one month budget, just like always.

> > the type-covered field in RRSIG functions effectively as a subtype,
> > and when we were discussing it we didn't try to generalize it.  very
> > sad, but not too late.  if you think a subtype would be easier to
> > shoehorn in than a subdomain, i'm listening.  frankly, i'd like to
> > have both, but i consider the subtype or any other change to the
> > q-tuple to be even more violent than moving the synthesis processing
> > would be.
> 

if we succeed in injecting some money and coherency into this field, using
MODA and perhaps other efforts, then we could reasonably "do both".  we all
know that DNS could never have been designed under a regime like the current
IETF, nor SMTP or NNTP or probably TCP or IP.  i recommend that we work
toward putting more boats in the water to see which ones really float, and
that we put better boats in the water to get a better idea of "why".

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Jun 2005 16:15:36 +0100

--On 13 June 2005 13:52 +0000 Paul Vixie <[email-masked]> wrote:

> since noone is currently querying for names under _app.$DOMAIN, we have
> the opportunity to require multiple queries.  therefore to simulate the
> effect of a nonterminal wildcard such as:
>

I have visions of sendmail and MX processing circa 1994 here :-)

So if the client is looking for a mail_exchange._app for
  foo.bar.baz.example.com.
then technically to get all the appropriate wildcards it's going to have
to query for
  mail_exchange._app.FOO.BAR.BAZ.EXAMPLE.COM.
  FOO.mail_exchange._app.BAR.BAZ.EXAMPLE.COM.
  FOO.BAR.mail_exchange._app.BAZ.EXAMPLE.COM.
  FOO.BAR.BAZ.mail_exchange._app.EXAMPLE.COM.
  FOO.BAR.BAZ.EXAMPLE.mail_exchange._app.COM.
  FOO.BAR.BAZ.EXAMPLE.COM.mail_exchange._app.

because conceivably the non-terminal wildcard could appear anywhere. After
all, we all know wildcards CAN appear in .com, don't we...

Note the latter two may have unpopular scaling problems

I'm pretty sure the above is undesirable even with negative caching.

Alex

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Jun 2005 15:51:37 +0000

> Note the latter two may have unpopular scaling problems

it is very safe to set ndots:2 in a case like this, to prevent the latter two.

> I'm pretty sure the above is undesirable even with negative caching.

with ndots:2 and existing negative caching, life would be bearable.

i'm not saying that in-protocol nonterminal wildcards wouldn't be better;
it would.  for that matter, in-protocol nonterminal wildcards that were
still evaluated on the authority servers are practical in general, if
painful to dnssec.  so, moving wildcard processing into the requestor
is not a strict requirement for nonterminal wildcards.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Jun 2005 17:13:58 +0100

> with ndots:2 and existing negative caching, life would be bearable.

Now try with foo.bar.baz.example.co.uk where you need ndots:3 to be
bearable. But then that would break example.com.

I'm sure there was some discussion about tree traversing lookups on
namedroppers about 6 months ago, quite possibly also SPF inspired (though I
forget), and it was in general thought a "bad thing".

Alex

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Jun 2005 16:28:00 +0000

> bearable. But then that would break example.com.

understood.

> namedroppers about 6 months ago, quite possibly also SPF inspired
> (though I forget), and it was in general thought a "bad thing".

there was and it was.  i was one of those arguing against it, in fact.
i'm not sure if anything has changed.  so it's nonterminal wildcards or
nothing, huh?  anybody else got a way out?  anybody else got a preferred
zone file syntax other than ** ?

---

From: Alex Bligh <[email-masked]>
Date: Mon, 13 Jun 2005 17:55:18 +0100

--On 13 June 2005 16:28 +0000 Paul Vixie <[email-masked]> wrote:

> nothing, huh?  anybody else got a way out?

Well there is always my straw-man subclassed RR proposal (i.e. 2 fields)
with client doing the whole of the subclass matching. Yes, it increases
average size of response, but if intelligently designed it *might* be
able to be made compatible with 4-tuple queries later. And it works in
every environment that supports new RR types (that's everywhere right
Paul? :-) ), though may occasionally require support of large responses.

The main criticism I have of it is that it isn't MUCH different from
just using TXT with some magic string at the front identifying what type
of field it is, other than the possibility 4-tuple forward compatibility.

Alex

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Jun 2005 17:14:08 +0000

> of field it is, other than the possibility 4-tuple forward compatibility.

considering activation energy budgets, it's a fatal flaw to be able to say
of a protocol change that "it's not much different from what we have now."

---

From: wayne <[email-masked]>
Date: Mon, 13 Jun 2005 12:29:00 -0500

> their installed base means they shouldn't be subject to ietf consensus.

I don't recall the argument that there were too many installed SPF
records back when we were discussing using a new RR type (ca Oct
2003).  Instead the concerns were whether a new RR type could be
deployed easily and quickly.

I did not do an exhaustive search on the subject, but I did find the
following posts that I think are relevant:

The earliest reference to using a new RR type that I could find was
from Oct 8, 2003:

http://archives.listbox.com/[email-masked]/200310/0066.html

This reply by Meng Wong to a message from Paul Wouters, where Meng
asks: "does using a new RRtype mean that nameservers everywhere must
be upgraded?"  This thread also brought up the subject of using SRV
records instead of TXT records.

A much more serious concern about using a new RR type was raised
discussed on Oct 19, 2003:

http://archives.listbox.com/[email-masked]/200310/0287.html

In this message Meng received a reply from Hadmut Danisch, whose RMX
proposal *did* define a new RR type.  His response was not at all
positive.  I had read his comments about the problems with using new
RR types before, and they are still available at:
http://www.danisch.de/software/rmx/

Basically, Hadmut claimed that bind could not work with RR numbers
greater than 255.  I never verified this claim, but all in all, the
problems that Hadmut ran into convinced me that there would be large
deployment problems if we used a new RR type.

Another interesting post from Mark Lentczner (former editor of the SPF
I-D) can be found here:

http://archives.listbox.com/[email-masked]/200310/0291.html

Here MarkL makes several claims that I think are still true today.
People are not going to be interested in upgrading their DNS
software.  If you want quick deployment, you need to use an existing
DNS RR type.  MarkL also argues that the size savings of using a
binary record type isn't relevant.  Finally, MarkL argues for the use
of the _prefix trick.

I haven't bothered to hunt down the threads, but the _prefix trick was
removed from the SPF draft later on once a survey of DNS hosting
services showed that underscores were not allowed on many of them.

Ok, so here we are, 18 months later, and we are still discussing the
same issues that lead the SPF community to choose TXT over a new RR
type.

-wayne

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 13 Jun 2005 11:20:33 -0700 (PDT)

>        FOO.mail_exchange._app.VIX.COM.

The problem with this approach is determining which name is a host and
which is a parent domain in FOO.VIX.COM, i.e. you could have zone
  my.really.weird.host.vix.com

Would you then look at it as:
         mail_exchange._app.my.really.weird.host.vix.com
         my.really.weird.host.mail_exchange._app.vix.com
OR:
         mail_exchange._app.my.really.weird.host.vix.com
         my.mail_exchange._app.really.weird.host.vix.com

And why would you prefer one over the other? And if you chose the first
one then why did you choose vix.com and what if if twas vix.co.uk, would
you have looked at ....mail_exchange._app.co.uk?

So saying that its not clean underestimates the issue. Its simply not
easily doable without non-terminal wildcards in dns.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Jun 2005 02:05:56 -0700

On Mon, 2005-06-13 at 12:29 -0500, wayne wrote:
> MarkL also argues that the size savings of using a binary record type
> isn't relevant.

The complexity and resulting size of many of these email path
registration RRs are creating overly broad declarations when collapsing
this into fewer records.  Here is an SPF record published by a provider
after extensive reduction efforts.  This was done by listing large
address blocks.  This still required 236 bytes plus overhead to define
this rather crude list.  A list that may collide with a different SPF
revision, adding just scope, for more than double the response size. : (

TXT RR for SPF:

v=spf1
ip4:24.30.203.0/24
ip4:24.28.200.0/24
ip4:24.28.204.0/24
ip4:24.30.218.0/24
ip4:24.93.47.0/24 
ip4:24.25.9.0/24
ip4:65.24.5.0/24
ip4:24.94.166.0/24
ip4:24.29.1 09.0/24
ip4:66.75.162.0/24
ip4:24.24.2.0/24
ip4:65.32.5.0/24
+mx ~all

This record could be done using a binary SPF TLV structure.  Assume a
TLV tag list of the following:

 0 = next name marker
 1 = a
 2 = cidr+a
 3 = mx
 4 = cidr+mx
 5 = ip4+cidr 
 6 = ip6+cidr
 7 = ptr
 8 = include
 9 = redirect
10 = exist
11 = strict-path mfrom (-all) Ending tags could include a checksum.
12 = test-path mfrom (~all)  
13 = neutral-path mfrom (?all)
14 = open-path mfrom (+all)
15 = strict-path pra  (-all)
16 = test-path pra (~all)  
17 = neutral-path pra (?all)
18 = open-path pra (+all)
19 = strict-path mfrom+pra  (-all)
20 = test-path mfrom+pra (~all)  
21 = neutral-path mfrom+pra (?all)
22 = open-path mfrom+pra (+all)
23 = white-listing only

This list could be extended at anytime, where a recipient which does not
understand the content of the tag could skip over the element.  Some
formats use a scheme where a range of tags will not allow this behavior,
such as 192-255 for example.  There may also be a range of tags that
would always appear last, such as 11-48.

Where length permits, elements are repeated.  Have a rule for tags that
use names, where the related entries are separated by a zero.  This use
of a zero permits creation of name lists.  Names would also allow the
same SPF macros, if needed.  Perhaps even add a DNS style name
compression confined solely within the RR.

The ip4, ip6 tags would use a single byte CIDR notation, where when the
most significant bit is set in the mask, this would indicate this range
of addresses are excluded (without modifying the nature of the path
declaration as currently implemented).  With Tag and Length values
defined as octets, the example file given becomes:

+---+---+---+---+---+---+---+---+
|            SPF-TAG            |
+---+---+---+---+---+---+---+---+
|         Element Length        |
+---+---+---+---+---+---+---+---+
/            Element            /
+---+---+---+---+---+---+---+---+

Binary RR possible:

5,60,24,30,203,0,24,
24,28,200,0,24,
24,28,204,0,24,
24,30,218,0,24,
24,93,47,0,24,
24,25,9,0,24,
65,24,5,0,24,
24,94,166,0,24,
24,29,109,0,24,
66,75,162,0,24,
24,24,2,0,24,
65,32,5,0,24,
3,0,
12,0

This TLV binary approach reduces the RR size for _exactly_ the same data
goes from 236 byte to 65 bytes.  This approaches a 4 times reduction in
the RR size.  How can this not be relevant?  This reduction would allow
either better path declarations or reduced cache consumption.  When SPF
limits already expect 11 TXT record fetches, size matters.

Employ the approach RFC3597 standardizes.  A text representation handled
by the various DNS tools to permit text entry of unknown structures into
their true binary form.  A token of '\#', followed by an unsigned
decimal integer byte length, declares the use of this convention.  It
represents a binary format with two hexadecimal characters for each
actual byte.  DNS entry is not the greatest hurdle anyway.

A practice of using intelligent entry forms to generate RFC3597 text
outputs would help overcome barriers to implementing new RR types.  The
APL RR, RFC3123, already provides a suitable RR to define paths.  

Some considerations to improve this RR type:
http://www.techfak.uni-bielefeld.de/~pk/dns/draft-koch-dns-apl-domainname-01.html

-Doug

---

From: wayne <[email-masked]>
Date: Tue, 14 Jun 2005 05:01:42 -0500

In <[email-masked]> Douglas Otis <[email-masked]> writes:

> [...]                     Here is an SPF record published by a provider
> this rather crude list.  [...]
>
> [snip]
> goes from 236 byte to 65 bytes.

Using the libspf2 encoding, the record is reduced to 80 bytes.  I know
that the libspf2 encoding is not ambigious and handles all SPF
records, and includes support for versioning and such.  Your encoding
can't handle things like -ip4 and such.  I suspect that if you fleshed
out your idea to fully support SPF records, you would have to add a
few bytes to your 65 count.

Be that as it may, I don't think the difference between 65 bytes and
80 bytes is significant.

>                                  This approaches a 4 times reduction in
> the RR size.  How can this not be relevant?

The reduction is only a factor of 4 when you don't take into account
IP, UDP and DNS packet overhead.  Currently the rr.com TXT record uses a
411 byte DNS packet, IP packet overhead is 20 bytes and UDP adds 8
bytes, giving a total of 439 bytes.  If you reduce the SPF information
to 65 bytes, that drops it down to 268 bytes.

This isn't even a factor of 2 reduction.

Ok, now take into account that the ip4: mechanism gets the best
compression of all SPF mechanisms.  IPv4 addresses can use up to 15
bytes in text, but only require 4 bytes in binary.  IPv6 addresses use
hex and are therefore much more compact.  All other mechanisms get
almost no benefit from binary encoding.

So, yes, when you are talking about some of the very largest SPF
records that have been published, there is some savings, but not even
a factor of 2.  I don't think this savings is worth that much compared
with the advantages of not having to update all the DNS software in
the world to be able to deal with a new format.

Now, consider whether the typical new DNS record type is going to be
anywhere near the size of SPF record you gave.  I suspect that the
size savings for most new DNS records will be only a few percent.

-wayne

---

From: Paul Vixie <[email-masked]>
Date: Tue, 14 Jun 2005 14:04:13 +0000

since spf isn't a tlv but is rather a mini programming language, txt is
no longer the wrong choice (as it was earlier, when a simple cidr-block
RR would have been better).

note that we should still have a cidr-block RR.  but don't put the whole
list in one rr, that's what rrsets are for.  if order matters, put in a
priority field like MX has.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Jun 2005 23:29:31 +0900

> RR would have been better).

Let's use TXT RRs and BASIC with line numbers to overcome the
deficiency of DNS that RRs are not orderd.

						Masataka Ohta

---

From: [email-masked]
Date: Tue, 14 Jun 2005 15:24:57 +0000

> deficiency of DNS that RRs are not orderd.

	a powerful extention to the DNS... i think 
	that ohta-san is on to something.

--bill

---

From: Alex Bligh <[email-masked]>
Date: Tue, 14 Jun 2005 16:55:58 +0100

> 	that ohta-san is on to something.

Perhaps we could subtype the TXT RR by the first character of the
label, for instance labels beginning i, j, k, l, m or n, could correspond
to TXT fields containing integers.

Alex

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 12:22:34 -0400 (EDT)

> I've not seen any RR types allocated except though IETF consensus and RFC.

IANA has repeatedly told me that they've never gotten requests for
'specification required' type codes.  Yesterday Anders Rundgren
claimed that IANA had turned him down for lack of an RFC, and I'm be
curious to know if he had any other permanent reference.  (Per the
Specification Required definition below, an i-d shouldn't be
sufficient, because it's not permanent.)

Unfortunately, IANA has refused to give an unequivocal answer to the
question of what sort of document might be sufficient to meet the
threshhold of: "Values and their meaning must be documented in an RFC
or other permanent and readily available reference, in sufficient
detail so that interoperability between independent implementations is
possible."  Perhaps DNSEXT could tell them what that answer should be?

I've discussed this before on this list, too:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00243.html

-- Sam

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 12:23:23 -0400 (EDT)

On Mon, 13 Jun 2005, Edward Lewis wrote:

> the instructions in RFC 2929.

I disagree.  IANA has to do the assignment at some point in time, and,
per the RFC Editor's processes, that's during the editing process[1].
That process has happened for SSHFP -- SSHFP is just waiting for a
normative reference to be cleared up.

And IPSECKEY (RFC4025) was published in February -- IANA just hasn't
updated their registry (despite two notes on this list urging them
to).  Perhaps the IANA's processes need to include reviewing all
published RFCs to remove these temporary citations in the registries.

-- Sam

[1] ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 13:55:48 -0400

At 12:23 -0400 6/14/05, Samuel Weiler wrote:

>... IANA has to do the assignment at some point in time, and,

By the time an effort is in the "editing process" it is already too 
late to assign a type code.  If I had my druthers, I would have at 
least mocked up the application, tested it in a workshop environment 
before trotting out a formal document.

Whatever happened to running code and rough consensus?  Remember the 
days when code ruled?  We are letting regulation get ahead of 
technology.

>published RFCs to remove these temporary citations in the registries.

Ok, but which came first - the RFC number or the type code number?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jun 2005 14:38:45 -0400 (EDT)

> before trotting out a formal document.

I'm confused.  First I heard what sounded like a complaint that these
two type codes were issued based only on I-D's instead of RFCs, now
the text above.  Perhaps they're not incongruous after all -- I
suppose one could want the process to change while still complaining
that the current process isn't being followed closely enough.

In any case, I agree with your point that we need the type codes
earlier.  It's particularly galling that it might be easier to get a
type code for something that's happening completely outside IETF
processes than something inside (since an i-d isn't a permanent
reference).  Then, too, no one has tested that premise.

> Ok, but which came first - the RFC number or the type code number?

Per [1], the type code.  As it happened, that was the actual order,
too.

-- Sam

---

From: Allison Mankin <[email-masked]>
Date: Tue, 14 Jun 2005 12:51:59 -0700

To Sam's point:
RFC 2434 and RFC 2929 (and the IETF IANA practice) cause the allocation
to appear in the registry when the document is approved, and then IANA 
updates the registry reference to the RFC number when the RFC is published.

To Ed's point:
There is a BCP providing for an early allocation practice for
cases where the working group makes a careful justification (it also
explains revocation if anything goes wrong).  It has conditions; 
it can only be used for Standards Action policy codepoints (this
woudl work for the kind of type code assignments being
discussed here) and there are documentation requirements.
Take a look at RFC 4020 (BCP 100).

Allison

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 16:35:52 -0400

>Take a look at RFC 4020 (BCP 100).

I agree with the premise of the document - especially that 
interoperability of implementations is the goal, and this is helped 
by number assignments.  But I don't see the process in the document 
as a solution.

Setting aside a segment of space for "early assignment" is not 
operationally tenable.  E.g., what if one assignment from that space 
becomes a Full Standard - the space is now "polluted" by a real 
assignment.

I've seen similar ideas in network address assignments.  Segmenting 
number space (whether for addressing or coding) isn't that beneficial 
once you have "cross overs."  By a cross-over, I mean a successful 
early assignment and a failed late assignment.

I also think that requiring "standards track" is too high of a bar, 
or even getting WG consensus.  What about things like the DNS A6 RR, 
which started as a standards track item and then slipped to 
experimental?

For non-WG activities, i.e., those that sometimes lead to a BoF and 
then a WG, counting on finding a sympathetic ear of an Area Director 
sounds like a subjective process.  Bureaucracies that rely on 
subjective processes don't scale well.

Finally, a lot of us have thrown RFC 2929 around as the definition of 
the process IANA is to follow.  How would I have navigated from RFC 
2929 to RFC 4020 to see these new "rules?"

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Jun 2005 16:15:48 -0400

>that the current process isn't being followed closely enough.

Both appear to be problems.

If the rules say "RFC or other permanent record" then any 
pre-assignment is out of order.  It's not healthy if "but that's the 
way it works."

If the rules are making "doing the right thing" hard or worse - 
encouraging short cutting the proces, then the rules ought to be 
changed.

---

From: Allison Mankin <[email-masked]>
Date: Tue, 14 Jun 2005 14:01:21 -0700

Ed,

> becomes a Full Standard - the space is now "polluted" by a real 

Perhaps you read a little fast.  The space just becomes
eligible for Early Assignment - it is not set aside en bloc
foro early assignment.  The normal Standards Track space is "amended
to permit Early Allocation" so it has both early and normal 
allocations out of it.  

> which started as a standards track item and then slipped to 

The point about making these assignments before the document is
finished by the working group is make sure that the codepoint is
for something stable and expected to need the acceleration of
the deployment of the early allocation.  The working
group judges that.  Did the A6 RR need that?  If the working
group and Chair had figured out a case for that, they'd ask the
AD for that, and it would get the type early.  We're only talking
about time here, after all.  It would get the codepoint later
if not.

> 2929 to RFC 4020 to see these new "rules?"

They're not yet new "rules" that update 2929 unless a given WG
goes through the process of updating its space.  At that point,
the WG needs to have the knowledge, but also, we probably need to
mark the RFC Index to say that RFC 4020 updates some other document
(I'm not sure of this - I haven't brought this up with others).
I brought up RFC 4020 because I guessed it hadn't crossed most WGs'
paths, and because the IANA process interests me.

Allison

---

From: "IANA" <[email-masked]>
Date: Tue, 14 Jun 2005 08:25:15 -0700

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. Please fix your 
   subscription addresses. ]

Regarding the second paragraph in Sam's message:

IANA has a process to update the reference in the registry after the
RFC-Editor notifies the IANA what the RFC number is and the date of
publication.  We are a bit behind in updating these in efforts to get
documents awaiting IANA actions for publication to the RFC-Editor, however
we have already begun updating references where the document has been
published as an RFC.

I'll go ahead and take care of the (RFC4025) reference update today.

Thanks,

Michelle

-----Original Message-----
From: Samuel Weiler [mailto:[email-masked]] 
Sent: Tuesday, June 14, 2005 9:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: New type code assignments (was: RE: draft-iab-dns-choices-02.txt
comments)

On Mon, 13 Jun 2005, Edward Lewis wrote:

> Note that two of them are in pending RFC's, which kind of violates the 
> instructions in RFC 2929.

I disagree.  IANA has to do the assignment at some point in time, and, per
the RFC Editor's processes, that's during the editing process[1].
That process has happened for SSHFP -- SSHFP is just waiting for a normative
reference to be cleared up.

And IPSECKEY (RFC4025) was published in February -- IANA just hasn't updated
their registry (despite two notes on this list urging them to).  Perhaps the
IANA's processes need to include reviewing all published RFCs to remove
these temporary citations in the registries.

-- Sam

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Jun 2005 18:37:26 -0700

On Tue, 2005-06-14 at 05:01 -0500, wayne wrote:
> Douglas Otis <[email-masked]> writes:
> 
> that the libspf2 encoding is not ambiguous and handles all SPF

You missed inclusion of the technique used in the APL RR. 
,---
| The ip4, ip6 tags would use a single byte CIDR notation, where when
| the most significant bit is set in the mask, this would indicate this
| range|of addresses are excluded.
'---

The hurdle facing SPF is imposing a change to the typical scale of DNS
answers.  Normally a query provides information regarding a single
service, where even a partial answer is often acceptable.  With SPF, a
query must scale to offering full results for potentially hundreds of
discrete services.  SPF uses a minimum of more than one hundred DNS
lookups to achieve this. 

In one approach, you advocate text because people can read it.  When
confronting the size issue, you suggest compressed text.  How does
converting an entry form to a text script, then to compressed text, be
better than a single conversion of an entry form into a TLV binary data?
At least there are people that can read TLV binary data, whereas
compressed information is more challenging. 

I was not suggesting the binary TLV example to make execution faster,
although this would entail far less code and would be more extensible.
I was attempting to illustrate how SPF scaling issues demand greater
consideration of size constraints.  SPF is already challenging the
scalability, or for that matter, the suitability of DNS for this
purpose.  While Paul Vixie is right that DNS allows elements to be
expressed as individual RRs, even this approach carries an overhead
which works very much against the Herculean scaling goal of SPF.

While SPF could be described as a script language, it is primarily
attempting to authorize paths for a mailbox identity, with some term
added to define the severity of a path authorization failure.  The
example TLV structure offers that capability.

A process that demands recipients seek information in secession from
perhaps more than one hundred domain name servers, makes defending this
task difficult.  With the inclusion of pointers, exists, and exp macros
for somewhat related features, come at the expense of security.

> This isn't even a factor of 2 reduction.

Have you considered the problem created by the collision of subsequent
RR reversions in this scripting scheme?  The overhead remains relatively
static, which returns focus on the actual RR size once again.  Of
course, the SPF draft also expects some cases will need many more than
just one TXT record to resolve the authorized paths as well.

> almost no benefit from binary encoding.

The assumptions of benefits for other elements with names could be
advantaged by DNS style binary techniques for name compression confined
to the RR, as I have suggested.  Even names include CIDR notation that
also shrink by the same amount as seen in the ip4 example.  Binary has
served DNS well, yet you seem to insist only text is a valid choice.
Adding scripts and compression, the ability to ensure secure code is
made much more difficult.

> I don't think this savings is worth that much compared with the
> advantages of not having to update all the DNS software in

Ensuring that RFC3597 allows implementation of new RR types could happen
in less time, than changing the way email is handled to support SPF.
SPF may eventually improve upon a repudiation process to some extent,
depending upon odd schemes to daisy-chain bounce-addresses.  However,
SPF's authorization will never provide validations useful as a basis for
reputation accrual, or even offering safe recipient assurances.  Those
advocating a filtering paradigm based upon SPF authorization as
sufficient grounds for accruing reputations, have not considered how
this may seriously hurt the average domain owner.

-Doug

---

From: Ben Laurie <[email-masked]>
Date: Wed, 15 Jun 2005 12:04:34 +0100

> zone file syntax other than ** ?

I don't have another suggestion, but it seems to me that nonterminal 
wildcards are going to make nonexistence proofs in DNSSEC very hard indeed.

-- 
 >>>ApacheCon Europe<<<                   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Alex Bligh <[email-masked]>
Date: Wed, 15 Jun 2005 12:43:45 +0100

> wildcards are going to make nonexistence proofs in DNSSEC very hard

Hmmm... yes. To be specific, because DNSSEC non-existence proofs
fundamentally rely on a single canonical ordering of the zonefile, and the
concept of a single closest encloser, we have a problem when the closest
encloser can only be synthetic. We don't see this with RR-Type because
non-existence applies to ANY RR, not the specific RR queried for.

$ORIGIN example.com
bar	IN	A	1.2.3.4
foo	IN	A	2.3.4.5
mail.**	IN	A	3.4.5.6
mail.foo	IN	A	4.5.6.7
mail.zag IN	NS	5.6.7.8
mail.zap	IN	TXT	"blah"
zip	IN	A	6.7.8.9

And I query xyzzy.example.com, then there is no obvious closest
encloser, because mail.xyxxx.example.com exists, as does
mail.xyxxx.example.com (which in NSEC-classic each enclose
xyzzy.example.com).

To throw more rocks, what does a QTYPE=A query do for
 mail.bar.example.com
 mail.foo.example.com
 mail.zag.example.com
 mail.zap.example.com

The same problem will, I think, occur with 4-Tuple-type queries or RR
"subclasses" (assuming the server doesn't return all subclasses) unless the
NSEC record is adapted to to indicate which subclasses are present and
which are not (just as it does with RR-Types). Yuck.

Alex

---

From: Paul Vixie <[email-masked]>
Date: Wed, 15 Jun 2005 20:02:59 +0000

> non-existence applies to ANY RR, not the specific RR queried for.

indeed, this is why moving the wildcard processing to the requestor, and
not doing any responder-side synthesis at all, seems strongly indicated.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 15 Jun 2005 23:04:54 +0100

--On 15 June 2005 20:02 +0000 Paul Vixie <[email-masked]> wrote:

>> fundamentally rely on a single canonical ordering of the zonefile, and
>> the concept of a single closest encloser, we have a problem when the
>> closest encloser can only be synthetic. We don't see this with RR-Type
>> because non-existence applies to ANY RR, not the specific RR queried for.
>

How does that work? I presume something like, with every query, return
any wildcard record that might match it OR a proof of nonexistence
illustrating there is no such wildcard (else there is a MiM attack
in stripping wildcards from responses). In which case aren't you back
with the same problem with non-terminal wildcards, in that you they
are "not in order"? Clearly one can return the whole zone in response
to each query, but that's presumably not a desirable form of
requester processing :-)

Alex

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Jun 2005 04:27:47 +0000

> > ..., this is why moving the wildcard processing to the requestor, and
> in stripping wildcards from responses).

yes.  and in the case of a nonterminal wildcard, that's one NSEC RR.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 16 Jun 2005 09:22:16 +0200

The problem with adding new DNS data types is often associated
with the IANA registration process for new RR types.  Although
this is indeed a problem (I have tried it myself so I should know),
the fundamental problem is that this way of allocating/defining
a new data type differs from most (if not all), other Internet-related
extension schemes.

For instance, anybody can within a URI-space they have control
of, define a new XML schema and immediately begin to use it
in an arbitrary small or large community. 

The same is valid for adding an X.509v3 certificate extension, as long
as you do it on your own OID ARC, you may add an extension without
interfering with other peoples' extensions.

Both of these extension schemes are independent of a central extension
registry like IANA, as domain and OID registries have no opinion on the
what you actually use your domain or OID for.  The "publishing" of a
particular extension may due to that span from being in the head of the
developer, to being a part of an internationally acclaimed standard.

=========================================
The only existing DNS extension scheme that meets the requirement
that a "user community" may go from one person to the entire
planet, is using translated, URI-encoded, host-prefixes linked to a
universal container-type such as TXT.
=========================================

That is, if there are any thoughts (can't really see why it is needed) of creating
a new DNS data type extension scheme, it MUST allow fully distributed development
and definitions, preferably by building on already existing name-space schemes.

Just my 2 cents

Anders Rundgren

---

From: Ben Laurie <[email-masked]>
Date: Thu, 16 Jun 2005 09:53:28 +0100

> yes.  and in the case of a nonterminal wildcard, that's one NSEC RR.

At least one per dot, surely? Plus one for the terminal wildcard.

--

---

From: Alex Bligh <[email-masked]>
Date: Thu, 16 Jun 2005 10:36:25 +0100

> yes.  and in the case of a nonterminal wildcard, that's one NSEC RR.

I'm still being dumb (or alternatively it's really ugly and you're OK with
that!). The whole principle of NSEC is that it proves non-existence of all
names between the closest enclosers of the QNAME. Whilst obviously one can
still canonically order QNAMEs, with non-terminal wildcards, isn't the
concept of a single closest encloser ill-defined (or to be more accurate
multi-valued)?

What I mean by the above is that if wildcard processing is being done
client (requester) side, don't you now have to prove (putting traditional
wildcards aside for a minute)
a) that the QNAME itself doesn't exist
b) that no non-terminal wildcard covers the QNAME in question.

I'm interested in how one might prove (b), because non-terminal wildcards
can appear anywhere in the ordering.

If I restrict the names-space to 3 character alpha to illustrate
the point (because successor and predecessor are easier to calculate):

$ORIGIN example.com

ghi.**	IN	A	1.1.1.1
jlk.**	IN	A	2.2.2.2
abc	IN	A	1.2.3.4
def	IN	A	2.3.4.5
jkl	IN	A	3.4.5.6

IF I send a query for aaa.ddd.example.com, I need to prove not only that
aaa.ddd does not exist.

With client (requester) side processing, sending an interval like
	def	NSEC	jkl
is not sufficient to prove it, because it doesn't tell me there
is no non-terminal wildcard that might match - for instance there
might have been a record like
	aaa.**	IN	A	7.7.7.7

So I will have to tell the requester client about EVERY non-terminal
wildcard. So I will have to do something like
	.		NSEC	ghi.**	
	ghi.**	NSEC	jkl.**
	jkl.**	NSEC	abc
(and that's enough, because abc has no ** in, I can now assure the
sender they've got all the non-terminal wildcards).

If we don't do this, the requester cannot securely prove the non-existence
of aaa.ddd.example.com because there might HAVE been the 7.7.7.7
non-terminal wildcard there, and the reply only proving the non-existence
of the record itself might have been replayed by a man in the middle.

Aside from the fact every answer size is now multiplied by the
number of non-terminal wildcards, the situation would seem to get
even hairier when non-terminal wildcards can exist at multiple levels
to the left of the zone-cut, for instance foo.**.bar and foo.baz.**.

Alex

---

From: Edward Lewis <[email-masked]>
Date: Thu, 16 Jun 2005 09:29:57 -0400

>interfering with other peoples' extensions.

But you have to get an OID from a central location.  There are many, 
including IANA, that do this.  The bureaucratic burden is negligible.

The difference between the URI and x509v3 environments is that you 
are not dealing with a fixed length field as is the case DNS.  You 
can't run out of OID's, for instance.

>developer, to being a part of an internationally acclaimed standard.

But is that the role of DNS?  Is that only because the label space is 
less regulated than the type code space?  The label space is 
size-limited, and when you get into multi-byte-per-glyph scripts, it 
shrinks up fast.

>That is, if there are any thoughts (can't really see why it is needed) of
>creating a new DNS data type extension scheme, it MUST allow fully distributed
>development and definitions, preferably by building on already existing name-
>space schemes.
>
>Just my 2 cents

DNS is supposed to be lightweight and simple.  That has translated 
into fixed size boundaries of fields - to simplify parsing code - 
with fixed semantics.  Self-describing data is great, but it take the 
end pieces longer to process it.  Plus, more moving parts are needed, 
which may (may) break.

I'm not debating the benefits of the extensibility of URI's or X509v3 
against DNS.  The extensibility of the two are very useful but do 
come at a cost.  That cost *was* not affordable in the days of the 
design of the DNS.  That cost may still not be affordable at the 
architectural level of the DNS today.  (I.e., DNS is under 
applications.)

Had the extensibility of URI's/x509v3/et.al. been affordable a decade 
ago, we would be seeing a lot more LDAP, x500, and ASN.1 deployment. 
I think that's the pragmatic demonstration of my contention.  (I 
won't say proof.)

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 16 Jun 2005 17:06:50 +0200

Ed,
>less regulated than the type code space? 

Absolutely. That was a nice way of expressing it BTW :-)

>The label space is size-limited, and when you get into multi-byte-per-glyph
>scripts, it shrinks up fast.

I don't understand why this is fact if you allow multi-label prefixes.

Today's de-facto DNS data type extension standard:

  _shortprefix.example.com TXT "blah"

This works perfect in most cases except in this list :-|

A slightly cleaner version of the de-facto standard could spell:

   http_2_4_4xmlns_1b2bstandards_1org_42005-01-01_4_registry.example.com TXT "blah"

which using a URI translation scheme[*] declares a data object of the type:

   http://xmlns.b2bstandards.org/2005-01-01/Registry

in "example.com".

>end pieces longer to process it.  Plus, more moving parts are needed, 

For DNS servers this adds no extra work AFAIK.  It is just another label.

Long URIs would produce dot-separated labels but that does not hurt either.

I would not call this self-describing data.  It is only a GUID scheme for
defining data types.  The actual data type definition is held by each GUID
definer and may be in any shape.

Anders

*] Any agreed-upon will do fine.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 16 Jun 2005 16:59:15 +0000

> At least one per dot, surely? Plus one for the terminal wildcard.

that depends on the encoding and power given to the nonterminal wildcard
feature.  for example, we might decide to permit

	  **	       zero or more labels
	  *?*	       zero or one label
	  *-*	       exactly one label
	  *+*	       one or more labels

or we might only allow the *?* and *-* forms and require that zone files
concatenate several of them to build the other forms.  that's more likely.

but you're right, it could be one NSEC per label, depending.

---

From: wayne <[email-masked]>
Date: Thu, 16 Jun 2005 20:13:35 -0500

In <a06200704bed4c8225d1c@[10.31.32.153]> Edward Lewis <[email-masked]> writes:

> late to assign a type code.

I strongly agree.  In the case of SPF, as I documented in a reply to
Paul a while back, we were discussing the various options of TXT vs a
new RR type back in Oct 2003.  I suspect that if we couldn't have had
a fully functional and stable RR type assigned by Nov or Dec of 2003,
we would have made the same choice of going with TXT.

The SPF I-D still isn't in the RFC Editor's queue.

>                              If I had my druthers, I would have at

I'm not sure what happened to running code and rough consensus.  I was
complaining about the lack of running code and test results all during
the MARID WG lifetime.  Only in the last few weeks were a couple of
very small tests made, and I'm not convinced they actually implemented
the spec.

The IESG is currently saying that they think that the 1.5 years of SPF
deployment and testing needs to be ignored in order to be "fair" to
SID, since SID doesn't have any (real?) deployment yet.

It appears that creating running code is now a waste of time, as far
as the IETF is concerned.

I stated several times during MARID that I thought that running code
was needed in order to get a rough consensus.  We spent far too much
time arguing theoretical stuff, with no test results.

-wayne

---

From: wayne <[email-masked]>
Date: Thu, 16 Jun 2005 20:17:53 -0500

In <a06200714bed72bf548a3@[192.168.1.100]> Edward Lewis <[email-masked]> writes:

> end pieces longer to process it.

Can you give me an example of something that is *SO* time critical
that a little processing on the end pieces would make a difference?

I don't believe this is a problem now a days.  Really.  And I think
this mindset needs to go.

-wayne

---

From: wayne <[email-masked]>
Date: Thu, 16 Jun 2005 20:38:09 -0500

> You missed inclusion of the technique used in the APL RR. 

I don't think that solves the problem of expressing -ip4:, but I also
think that is irrelevant.  Whether the SPF record is 65 or 80 bytes
doesn't make much difference compared with the other overhead that is
involved.

> better than a single conversion of an entry form into a TLV binary data?

My suggestion for compressed DNS data was that it would be compressed
when sent across the network, much like compressed HTML is done right
now.  The end points wouldn't see the compressed data.

> I was attempting to illustrate how SPF scaling issues demand greater

I don't think this is the appropriate list to discuss this aspect of
SPF.  

> static, which returns focus on the actual RR size once again.

Yes, this is true, multiple records will change the ratio.  I still
don't think it will change the ratio enough to justify binary encodings.

> made much more difficult.

Coding in assembler servered the computing world well for many decades
too.  The insight that the Unix folks had is that, yes, you recould
code most of the OS and apps in a high level language.  They also
realized that plain text files had a lot of advantages.

Times have changed.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Jun 2005 20:47:34 -0700

> doesn't make much difference compared with the other overhead that is

If you want to bifurcate results into three sets: unknown, authorized,
and not authorized, then that would require another tag definition.
Whether it is 360% or 24%, your approach requires more processing
complexity and uses more packet allocation.  By compressing the script,
this makes it extremely difficult to identify errors.  Network level
examination is likely the only tool available initially for any new RR
type, where a binary TLV structure would be much simpler to evaluate.

> now.  The end points wouldn't see the compressed data.

Do you expect to see a compression layer added to DNS?

>From 236 byte to 65 bytes represents the difference between surviving a
a collision, or needing to re-engineer a highly record-limit sensitive
structure.  Adding "includes" as a work around goes against the scaling
concern.

> Coding in assembler served the computing world well for many decades
> too.  The insight that the Unix folks had is that, yes, you could

This appears to be stilted justification for using script in DNS.
Scripts are often fraught with security issues due to their evaluation
complexity, and are forever growing due to their propensity for feature
creep.  The UDP packet size has not substantially changed with respect
to ensuring compatibility.  This has been true and will remain true for
some time.

Physical aspects of memory work against justifications for increasing
the size of DNS data structures, or the use of scripts.  Memory
bandwidth does not pace with Moore's law.  The performance for hard
storage random access is largely limited by the rotational speed of the
disc.  This physical limitation has changed little in several decades!
These limitations are reasons for retaining lean data structures for
DNS.  DNS runs out of limited memory to meet increasing performance
requirements for sustaining this critical service as the network grows.

Time is relentless and inexorable.  

-Doug

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Jun 2005 15:11:21 -0400

>that a little processing on the end pieces would make a difference?

The DNS lookup process itself.  Delays in it are amplified by applications.

>this mindset needs to go.

You should really also look at replacing the DNS then.

I'm all for layering more complex and functional look up systems over 
the top of the DNS.  I'm just leery of trying to extend the creaking 
base and the possible unintended consequences on applications that 
like it just fine as it is.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 20 Jun 2005 17:19:22 -0400 (EDT)

> The DNS lookup process itself.  Delays in it are amplified by applications.

And this makes a lot of difference.  There were studies done back in the
80's about mainframe vs workstation response latencies and impact on
users. It is truly remarkable how much difference a little latency makes.

But it's not just latency. Its also resolver code size. TCP stacks are
winding up on smaller and smaller systems, in larger and larger numbers.  
And its also upgrade/replacement cycles.  ROM'd stacks are hard to
upgrade, and last a long time.

That's why you can't think of adding new RRs trivially. You can easily
conduct experiements on lab systems; there is plenty of open source
software and cheap pc systems. But its much, much different when people
start to talk about changes to millions and millions of production
systems.

And sometimes its not just the large numbers. Anycast DNS roots was a good
example of a bad choice that once taken, can't be "un-taken", for even a
small number of systems. Carelessness has lasting impact. Its not at all
like a software program or company that might be hot for a few years, and
in a couple years hence, no one even remembers it. Making a bad choice on
DNS will have a long lasting impact. The "Dot-com" mindset is bad for DNS:  
It can't just go bust and be forgotten. Bad DNS choices will have to be
fixed.

Those who think of DNS as a distributed database simply have no
understanding of what DNS is, nor what role it plays.

> >this mindset needs to go.

Not only is it a "problem", but its much worse than it used to be. The
"cement" is deep and broad.  Shifting it is very dangerous and needs to be
done with great care.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Ben Laurie <[email-masked]>
Date: Wed, 22 Jun 2005 11:41:46 +0100

> of the record itself might have been replayed by a man in the middle.

This sounds wrong to me.

. NSEC ghi.**

proves nonexistence of aaa.**.

Cheers,

Ben.

--

---

From: Alex Bligh <[email-masked]>
Date: Wed, 22 Jun 2005 12:06:54 +0100

> proves nonexistence of aaa.**.

Hmmm... yes. I now don't understand my own point :-) I'm sure it made
sense at the time.

Alex