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

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

>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.

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

----- Original Message ----- 
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, June 11, 2005 01:08
Subject: Re: draft-iab-dns-choices-02.txt comments

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

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.

--
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/>

--
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: 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: 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: Paul Vixie <[email-masked]>
Date: Mon, 13 Jun 2005 13:20:17 +0000

> ...

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: 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

<br />
<b>Fatal error</b>:  Maximum execution time of 30 seconds exceeded in <b>/home/httpd/gmane/download/download.php</b> on line <b>28</b><br />