Subject: Re: Retrieving large DNS objects

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 23 Jan 2005 20:36:28 +0100

Paul Vixie wrote:
> <flame about ivory tower propellerheads elided>.
Propellrheads don't ask questions. They know it all by "default".
I try (not successful but anyhow) to suggest and ask to make sure
that the XML RR I-D and URI-typing I-Ds won't be too bad.

>> What does this really mean?  You get ALL TXT records and it is
>> the clients who do the actual select?

Now it gets interesting!

>in the dark recesses of time, a smart and reasonable guy inside DEC
>tried to subclass TXT by making the first "segment" be RFCXXXX and
>the second segment be an IANA-assigned application identifier.  in
>private communications, i explained that if this led to the existence
>of something like

>   FOO.DEC.COM IN TXT RFCXXXX APP1 "whatever app1 is looking for"
>  TXT RFCXXXX APP2 "whatever app2 is looking for"
>  TXT RFCXXXX APP3 "whatever app3 is looking for"
>  TXT RFCXXXX APP4 "whatever app4 is looking for"
>  TXT RFCXXXX APP5 "whatever app5 is looking for"

>then all five apps would have to retrieve the whole rrset and look
>for the things they wanted, which would be hellishly expensive if
>the number of apps became large or even moderate, or the amount of
>data needed by any one app became large or even moderate.  i said
>that it was a damned shame DNS didn't have subclassing, such that a
>query could actually select a sub-rrset.  i recommended subdomains:

>   APP1.FOO.DEC.COM IN TXT "whatever app1 is looking for"
 >  APP2.FOO.DEC.COM IN TXT "whatever app2 is looking for"
>   APP3.FOO.DEC.COM IN TXT "whatever app3 is looking for"
 >  APP4.FOO.DEC.COM IN TXT "whatever app4 is looking for"
 >  APP5.FOO.DEC.COM IN TXT "whatever app5 is looking for"

>and as you all know, this is how SRV was done.  but it doesn't work
>well with wildcards since wildcards aren't nonterminal.

I recommend this one:

[arguments.]"unique type id".yourdomain IN TXT "data matching type id" 
(
Although not suitable for every app.  This one work wonders for Web Services
and DomainKeys.  Supports wild-carding also.  As-is.  Like listing
all domainkeys. 

If this variant work for the app in question, I don't see any reason for
getting a specific RR.  At least not with respect to RRset. AFAIK.

>if we had nonterminal wildcards then TXT, and even something like XML (although
>XML is just text, and an application wanting XML can just put it in),
>to be used as generic containers without pain or inefficiency.

There are a lot of things that does not need this but I don't see any
contradictions so let there be more powerful wildcards!

Particularly if that gives us yet another reason for *NOT* using iab-dns-choices...

Anders R

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 24 Jan 2005 11:07:50 +0100

On Sun, 23 Jan 2005 20:36:28 +0100

>  getting a specific RR.  At least not with respect to RRset. AFAIK.

I do not immediately see how this scheme supports "wild-cards" in the
presence of delegations. An I-D on this idea would actually help to
structure the discussion and would lift this from "mailistware" to
something more tangible [*]

> contradictions so let there be more powerful wildcards!

See:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00182.html

-- Olaf

[*] I'd reckon that such an I-D would be more in scope for DNSOP than
DNSEXT, but we'll worry about that when its there.

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 25 Jan 2005 10:11:33 +0100

>presence of delegations.

To be fully honest; I don't know either as I am not fully aware of the problem
with wild-cards and delegation.  Is it possible to get a minimal info on this?
I would very much appreciate that.

Anyway, the target apps I work with "Web Services", don't really need wild-cards,
they just look for something they know (a specific object) somewhere where they
have been (OOB) told to look (in a partner domain).  So do most public key stuff
as well although they do usually not depend on any OOB info.

> An I-D on this idea would actually help to structure the discussion and would lift
>this from "mailistware" to something more tangible [*]

I don't plan to make an I-D here assuming that IANA will (as mr. Vixie
hopes) turn down the idea adding yet another TXT-like "container" RR.

I guess "whitepaperware" is considered as even worse than "mailistware"?
XML RR whitepaper: http://web.telia.com/~u18116613/XML-RR.pdf

Namedroppers prefer schemes where you first launch a new "DNS-aware"
app using TXT or hijack SRV (or something  equally stupid), and THEN
asks IANA for "granting" you a new RR and THEN IF you are successful with
IANA, ask your "user community" (which you may have no control of at all)
to change something that actually is working after writing an RFC (which
probably document-wise is entirely different from the rest of your app). 
To make it even more appetizing, MSFT probably don't intend to support any
new RR objects in their DNS GUI admin unless it becomes ubiquitous (or is
used by Windows...).  I can't blame them.  I would do exactly the same.
That's why I suggested an alternative route.  It may not fit everybody's need
but that is valid for the just described "solution" as well.

regaords
Anders R

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 25 Jan 2005 11:36:15 +0100

On Tue, 25 Jan 2005 10:11:33 +0100

>  XML RR whitepaper: http://web.telia.com/~u18116613/XML-RR.pdf

If you expect serious review of your proposal within IETF context
writing an I-D is the way.  And to be somewhat formal, as long as
"whitepaperware" does not have the appropriate copyright notices it is
out of scope. The main reasons for that are documented in the
introduction of RFC3667 to paraprhase: allow the IETF to take
ownership.

> probably document-wise is entirely different from the rest of your app). 

I do not share that perception. Namedroppers prefers rough consensus,
running code and a stable DNS.

> but that is valid for the just described "solution" as well.

Does this group try to engineer a solid architecture that is truly
interoperable or does it try to hack around implementations that do
not care about the existing standards anyway? ---a rhetoric question--
In the end its about making trade-offs and getting rough consensus on
them. Those trade-offs are best made when they are clearly summarized
and structured in an I-D.

--Olaf

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 25 Jan 2005 12:20:17 +0100

Olaf,

I have no problems with the IETF taking ownership.

DomainKeys, SPF, IMM, CSV etc. though all indicate that my
perception of how things actually work differs from IETF's.

Off-list several parties have acknowledged the existence of
this "migration-from-the-interim-to-the-real-solution" trauma.
It is particularly a problem for the commercial sector which
simply doesn't have the time for doing things "the right way".
The so-called right way proponents do not acknowledge the
need for an easier route.   If there was one (well maybe there is...)
it would be judged by entirely different criterions than the right
way is. The question "how do you intend to control that the URIs
are properly used and deployed" is an indication of dual standards,
because it is equally applicable to the "right way" methodology.
The proper answer is of course simply: You cannot.

It is hard to see such information be put in an I-D unless it is
really just a "camouflaged pamphlet" like iab-dns-choices which
carefully avoids mentioning the migration problem.

Advice: Pamphlets are better off in other formats.  :-)

I do understand that real IETFers do not read PDFs.
OTOH, the majority of Internet SW developers have never
read an RFC either...

Anyway, I will keep the list informed on the progress with the XML RR
IANA reg.

Anders

----- Original Message ----- 
From: "Olaf M. Kolkman" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 25, 2005 11:36
Subject: Re: Retrieving large DNS objects

--Olaf