Little endians, big endians, and 16 bit eggs
Christian Huitema
For Peace", and it did not refer to 16 bits eggs. Anyhow, let's please
first acknowledge the semantic equivalence between:
Name =3D example.net, Prefix =3D --myNewPseudoType, type =3D TXT, =
content =3D
string
And =20
Name =3D example.net, Prefix =3D null, type =3D myNewType(1234), content =
=3D
string
Sure, there are differences, and it is worth noting them:
- The "prefix" case does not support wildcards (but there are
workarounds)
- There is a fear that some servers do not support new types
But the main difference is about control. Prefixes can be made up on the
fly by whoever thinks about them, while types must be registered through
a rather lengthy and contentious defined IETF process.
It does not have to be so. If this group really believes that inventors
of new protocols should use new types instead of cooking up prefixes,
then it is perhaps time to make sure that record types can be allocated
easily, maybe just as easily as TCP ports. And, by the way, TCP ports
also are 16 bit long.
-- Christian Huitema
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
John Levine
>the fly by whoever thinks about them, while types must be registered
>through a rather lengthy and contentious defined IETF process.
Au contraire. If I want to invent a new RR type and use it among
friends, I can do so. I only need to register it if I want to use it
widely and be confident that it won't collide with other uses. Since
RR numbers are 16 bits, if I pick a number far away from the currently
assigned ones, the chances are good that I can use it for a long time
without anyone else stumbling into it.
By my reading of RFC 2782, the prefixes on SRV names are supposed to
come out of the IANA services list which used to be RFC 1700 and now
is http://www.iana.org/assignments/service-names. Again, I can invent
whatever names I want for private use, but for public use I'd better
register the name to avoid collisions. The name space for prefixes is
certainly larger than 16 bits, but I'd argue that 16 bits already
makes the chance of accidental collision low enough that the
difference isn't important.
To the extent that DNS software complies with RFC 3597 and passes
through unknown names and RRs without crashing or mangling them, I can
use either private RRs or SRV names just like I can use private TCP
ports so long as the hosts on each end agree what they mean. The
practical difference is that at this point the chances that DNS
software will do the right thing with a funky name prefix are a lot
better than with a funky RR.
So I can't help but ask: does Microsoft have a schedule to bring their
DNS software into compliance with RFC 3597? It sure would help
simplify the arguments about what to do.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
D. J. Bernstein
> But the main difference is about control.
No. The main difference is that new types create giant interoperability
problems in the real world. Getting the IETF to allocate a new DNS type
is far easier than (for example) wiping out BIND 8.1.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Alex Bligh
--On 22 January 2005 09:13 +0100 Anders Rundgren
<anders....@telia.com> wrote:
> DNS must be the only IT system in the world that does not support XML!
Is that a complaint or an endorsement?
Serious point: DNS is/was a low level protocol which did a fair job
of turning requests for hostnames into IP addresses with a reasonably
small number of bytes transmitted. The larger the edifice is built,
the more one worries about the humble foundations.
Alex
John Levine
>> come out of the IANA services list
>
>example, not a SRV record.
True, but if you're using prefixes, regardless of what record types
you're (re)using, you need some sort of registry if you want to be
sure that nobody else will use your prefix to mean something else. I
suppose you could use the URI trick to get uniqueness from domain
names, but I have my doubts about how
The issue of how hard it is to get something into the registry is a
separate question from what it is you're registering. I agree that in
retrospect it should have been easier to register new RR types so that
people wouldn't have written DNS software that assumes the set of RR
types is forever fixed.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
http://www.taugh.com
John R Levine
> >names, but I have my doubts about how
>
> agree on a URI-to-DNS-label-translator
Ahem, to finish my sentence, how likely it is that people will configure
long hard to type names into their DNS zones. I realize URI based labels
are common in XML, but there's a lot more people updating DNS zones by
hand than writing XML files by hand.
> >retrospect it should have been easier to register new RR types so that
> >people wouldn't have written DNS software that assumes the set of RR
> >types is forever fixed.
>
> Looking at W2KS DNS GUI server I don't agree. I only supports a limited
> set of types. And since most people actually only need a text-something
> it makes no sense to create a new text-something over and over again.
Actually, it's been a long time since I've seen a type that should be a
text something. TXT records are just the ticket for unstructured textual
data, which few applications use. SPF records, for example, are a highly
structured list of operators and typed operands, with the operand types
including DNS names, IP addresses, CIDR ranges, macros that expand to DNS
names, and probably a few other things I've forgotten. Every DNS client
that uses SPF has to parse the text up into the operators and operands,
and one of the many unanswered questions about SPF is how robust the
parsers are in the face of accidentally or deliberately invalid data.
If I were doing something like SPF, I'd want a record type that was a list
of operator/operand pairs with the operators probably being a single byte,
and the operands being in an appropriate native coding, e.g. five binary
bytes for an IPv4 CIDR and a list of null-terminated strings for a DNS
name. That both avoids the application level parser and forces some
degree of validation as the data goes into the record.
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
--
Mark Andrews
> >I have no problem with XML being used in mobile phone. I strongly
> >disagree with any claim that XML is *the* de-facto configuration
> >language.
>
> Let put it this way. The majority of systems intrduced the last
> three years use XML.
>
> >> So imo DNS is indeed one of the most dated
> >> things in the entire Internet space.
>
> >RFC 791 September 1981
> >RFC 1035 November 1987
>
> >Both IP and DNS have changed since they were developed, and they will
> >change again. I don't believe "one of the most dated things in the
> >entire Internet space" is a reasonable characterization of DNS.
>
> As a directory system it is certainly lagging at least. 512 bytes?
> That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!
>
> >> DUAL MORAL STANDARDS
> >>
> >> The worst is, that things like iab-dns-choices have created a
> >> bad morale among developers that now must (in order to pass
> >> as RFC) support:
> >> TXT to be able to rollout
> >> NEW-specific to please IETF
>
> >Is the problem here the IETF
>
> It is the IETF who have created the incentive for dual standards.
>
> > or the companies that develop systems
> >and applications that make it extremely difficult to introduce new
> >RR types?
>
> The DNS specifications does not contain any kind of RFC
> that supports a _smooth_ introduction of new RR types.
RFC 103[345] basically said that new RRs should be treated
as opaque blobs by servers that don't understand them. It
said don't use compression pointers in new RRs. It said
you should expect to see new RRs. This is all that is
required for a cache / firewall to query, store and pass
new RRs. It still required the authoritative servers that
served the new RRs to be updated and applications that
wanted to use the new RRs to be know about them.
We went ahead and used compression pointers when we shouldn't
have. We didn't treat new RRs as opaque blobs. By doing
this we did cause lots of problem when we introduced new
RRs. This created the *myth* that adding new RRs was hard.
It really isn't hard to add new RRs. We just went about
it the wrong way. We also learned not to do this.
RFC 3597 reinforced what was in RFC 103[345] taking into
account that we had failed to follow RFC 103[345] for a
while and added a default presentation format. This provided
a standard method to add new RRs to authoritative servers
that don't know the new RR format.
The problems people are reporting today are non-compliance
problems. The way to fix non-compliance problems is to
remove the offending software / hardware.
> IF it should work there must be a way to publish not only a puni16-bit number
> but the environment as well so that DNS admin GUIs knows what to do.
>
> This will never happen as:
> 1. There is no _proven_ need for new RR types except for things that only dea
> ls with DNS itself
> 2. Such a scheme would use XML and that seems to be something the DNS communi
> ty
> don't understand at all
> 3. It will take forever and be extremely hard to agree on
>
> The problem is BTW really buried in the archaic DNS system itself. Other
> extension mechanisms allow the introduction of private data here thinking
> of X.509 extensions.
>
> >Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
> Won't hire :-)
>
>
>
> --
> to unsubscribe send a message to namedroppe...@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Danny Mayer
>Since you hopefully represent Microsoft, how about supporting
>an XML companion to TXT? DNS must be the only IT system
>in the world that does not support XML!
No, we, NTP, don't and won't support XML either. That's a huge
overhead just to transfer data. If you want XML in the transferred
data, now you are talking about a much higher level of usage of
TCP which has a much larger overhead just to transfer A records
for example, not withstanding EDNS0.
Danny
Danny Mayer
> >I have no problem with XML being used in mobile phone. I strongly
> >disagree with any claim that XML is *the* de-facto configuration
> >language.
>
>Let put it this way. The majority of systems intrduced the last
>three years use XML.
What kind of systems? DNS is part of the base infrastructure of
the Internet. How many of these systems even have to do with the
base infrastructure? If you want to discuss configuration languages,
that's off-topic. You can use any language you want to tell your
DNS server what the records are you want to serve.
> >> So imo DNS is indeed one of the most dated
> >> things in the entire Internet space.
>
> >RFC 791 September 1981
> >RFC 1035 November 1987
>
> >Both IP and DNS have changed since they were developed, and they will
> >change again. I don't believe "one of the most dated things in the
> >entire Internet space" is a reasonable characterization of DNS.
>
>As a directory system it is certainly lagging at least. 512 bytes?
>That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!
512? See EDNS0.
> >> DUAL MORAL STANDARDS
> >>
> >> The worst is, that things like iab-dns-choices have created a
> >> bad morale among developers that now must (in order to pass
> >> as RFC) support:
> >> TXT to be able to rollout
> >> NEW-specific to please IETF
>
> >Is the problem here the IETF
>
>It is the IETF who have created the incentive for dual standards.
>
> > or the companies that develop systems
> >and applications that make it extremely difficult to introduce new
> >RR types?
>
>The DNS specifications does not contain any kind of RFC
>that supports a _smooth_ introduction of new RR types.
See the unknown record type - RFC 3597.
>IF it should work there must be a way to publish not only a puni16-bit number
>but the environment as well so that DNS admin GUIs knows what to do.
GUI admins for DNS is off topic. That's a function of the DNS implementation.
>This will never happen as:
>1. There is no _proven_ need for new RR types except for things that only
>deals with DNS itself
Neither SRV nor NAPTR are DNS specific RR types.
>2. Such a scheme would use XML and that seems to be something the DNS
>community
>don't understand at all
The DNS community see you advocating sending large amounts of data for
simple requests, forcing the servers to use TCP and greatly increasing the
load not just on the servers but on the networks for no preceived gain. If
you want to contribute a way of reducing the garbage requests that DNS
gets, it would be a big help.
>3. It will take forever and be extremely hard to agree on
You need to decide EXACTLY you want first. There's almost never a
possibility of going back and revisiting the requirements once it's
agreed upon.
>The problem is BTW really buried in the archaic DNS system itself. Other
>extension mechanisms allow the introduction of private data here thinking
>of X.509 extensions.
No, the problem is in thinking the XML should fit everything. If all you have
is a hammer then everything is a nail. You need to look at the objectives
of DNS not your minor application. It's minor in the sense that A, NS
and MX volume swamp almost every other type of request made including
the fact that your application will still need to make those lookups as well
as it's own.
Have you thought about the effect your recommendation would make on
the root servers, TLD's, memory, cache, network utilization, etc? The
list goes on.
Paul Vixie
> of turning requests for hostnames into IP addresses with a reasonably
> small number of bytes transmitted. The larger the edifice is built,
> the more one worries about the humble foundations.
after EDNS0, the foundations are just fine, thanks. "more weight."
Dean Anderson
> >But the main difference is about control. Prefixes can be made up on
> >the fly by whoever thinks about them, while types must be registered
> >through a rather lengthy and contentious defined IETF process.
>
> Au contraire. If I want to invent a new RR type and use it among
> friends, I can do so.
You can do whatever you want among friends, including not using standard
protocols. Of course, other groups may come along and use the same type
codes (intentionally or unintentionally) and standardize the codes for
their defined use, rather severely "crimping your style", as it were.
Sometimes the reasons are proprietary. Sometimes not. The proprietary
reasons I can understand, if I don't agree with them. But sometimes the
reasons are technically unsound. This is now without doubt the case with
SPF. The juggernaut rolls on. The MARID group found the SPF scheme to
have insurmountable technical problems, and shut down. Yet, the SPF
proponents forged ahead despite the unresolved technical problems, and
indeed, pretending as though there are no problems. This unfortunately is
a common activity among the radical anti-spam crowd. Examples include the
so-called "reverse DNS check", the "pop-before-smtp check", and other
failed anti-spam measures too numerous to list, that were described as the
way to end spam.
In presenting the SPF classic draft to this group, it is asserted that the
draft should be considered and standardized because some thousands of
domains (among millions) are using SPF. No mention was made that most of
the SPF-using domains are __spammer__ domains. The number of users
pointing guns at their feet and pulling the trigger is no reason to
standardize the caliber of gun used to blow off toes. The responsible
thing is to tell those users not to shoot themselves (or others) in the
foot. The irresponsible thing is to standardize the weapon used for
self-inflicted wounds, merely because some number of people have shot
themselves in the foot on the fervent irrational faith that doing so will
end spam.
Theorem 1:
"DNS is not suitable for authentication purposes."
Theorem 2:
"Any scheme that depends on DNS for its security is fundamentally
unsound."
That includes (but clearly isn't limited to)
Reverse DNS checking for spam
RMX
SPF
Any other DNS Email Authentication scheme.
It is interesting that the common thread of Dr. Levine's involvement in
DNSEXT has gone from
SPF I-D for review: draft-schlitt-spf-classic-00.txt
Zone cut
Engineering SPF
wildcards vs. RR types, was Faux wildcards
Little endians, big endians, and 16 bit eggs
Each of these discussons have the common thread of finding a new way to
break or abuse DNS. Perhaps the theorems 1 and 2 above should be studied
more closely.
First, we discused RMX. That draft was rejected. Then, the idea was
resurrected again as SPF, ignoring the failures of demonstrated for RMX.
In fact, a special group was created to standardize this. In spite of that
the MARID working group concluded that it couldn't overcome substantial
technical faults. Now, SPF is again resurrected, on yet another IETF
group, again ignoring the two previous failures.
Word has it on the old ietf-mxcomp list that the IETF may create a "DNS
Email Authentication" working group, apparently to specifically ignore the
Theorems 1 and 2 above by including the oxymoron in the name of the group.
So, perhaps merely refusing to ratify a draft is insufficent. Perhaps a
stronger statement on why the idea shouldn't merit further consideration
unless a number of conditions are met first is necessary to stop the waste
of time on such things.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
Pekka Savola
> The problems people are reporting today are non-compliance
> problems. The way to fix non-compliance problems is to
> remove the offending software / hardware.
Hence, IMHO, it seems critical to have a concise document describing
what MUST be implemented (and why), what is optional, etc.
If we would have a draft or RFC of 15-20 pages and could show it to
the offenders, and people buying DNS equipment could request it in
CFTs (see RFC3871).
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Alex Bligh
--On 23 January 2005 03:57 +0000 Paul Vixie <pa...@vix.com> wrote:
> after EDNS0, the foundations are just fine, thanks. "more weight."
I'm not sure that means buildings of any and every type should be built on
top of them though. There may be other types of foundations better suited
to certain types of architecture (pun intended).
As an example, I am not sure whether DNS (alone, rather than over some
other protocol) is the right basis for a directory service where (a) it is
necessary to securely authenticate both client and resolver to eachother,
where there are many to many relationships for large values of "many", and
(b) it is necessary to move large amounts of directory data (c) it is
necessary to encrypt the wire protocol against snooping (d) subsecond
lookup latency is not that important. Whilst I'm sure one *could*
reengineer DNS to do that, I think I'd prefer to do it over https:// with
some certificate management scheme. Sometimes I wonder whether some of the
proposed DNS variants (e.g. carrying large amounts of XML) would not be
better done with a one stage indirection at the DNS layer, and a solution
using some other well known protocol.
Alex
Paul Vixie
> so should DNS.
the needs dns meets have not changed in any way.
> If every web-page drags down 10K and up, averaging on 100K using TCP,
> why should 512 bytes UDP be all a DNS server manages to do?
sounds like you think the web "is" the internet. it's not. the internet
is much, much larger than the web. (and as others have pointed out, EDNS
relaxed the 512-octet limit.)
> XML is today the de-facto config-language. It is even used in mobile
> phones. So imo DNS is indeed one of the most dated things in the
> entire Internet space. That also includes ideas such as having a
> central registry for app-data types. App-data is not protocols or
> ports.
dns is the world's first and, and still the only, distributed coherent
autonomous reliable database. it's quite an achievement, and i think
you ought to show a little more respect toward that achievement. for
example, you ought to admit the possibility that its simplicity is what
makes dns possible at all.
> "app-data" types should not have to be published at all outside their
> user community.
this, i almost agree with. i'm happy to see the ietf asking namedroppers@
for review on app-data rrtypes, but that's just a "model check" to ensure
that the rdata encoding is reasonable and that the query/response pattern
will work. the expected (demanded?) result should be approval, possibly
with modifications but always approval.
with SRV, we sort of snuck it through, largely because we didn't think the
namedroppers@ community was the right forum for deciding how applications
should discover their servers, and because we (the authors) felt that we
knew quite a bit about how to format a new rdata. SRV could not be
standardized today, because the ietf has vastly increased the number of
people who could say "no". this is a real pity, and shows the ietf's age
in a dark way. rrtype review should be of rdata format and query pattern,
and the expected result should be approval, possibly with modifications.
we need to start adding one new rrtype per month (or so) just to show that
we can. perhaps this would be a good first-year focus for DNS-MODA.
Paul Vixie
>
> I'm not sure that means buildings of any and every type should be built on
> top of them though. There may be other types of foundations better suited
> to certain types of architecture (pun intended).
i agree, but you should all take a look at the following, just the same:
<http://www.doxpara.com/dns_bh/Black_Ops_DNS_BH_files/v3_document.htm>
Alex Bligh
--On 23 January 2005 16:33 +0000 Paul Vixie <pa...@vix.com> wrote:
> i agree, but you should all take a look at the following, just the same:
>
> <http://www.doxpara.com/dns_bh/Black_Ops_DNS_BH_files/v3_document.htm>
Indeed. But "can do" != "should do" :-)
Alex
Andras Salamon
> By my reading of RFC 2782, the prefixes on SRV names are supposed to
> come out of the IANA services list
I agree. However, Christian Huitema was suggesting a TXT record in his
example, not a SRV record.
-- Andras Salamon and...@dns.net
Anders Rundgren
>Christian Huitema writes:
>> But the main difference is about control.
Yes, indeed. The ability to introduce a new type whenever you
need and not asking for a "permission".
>No. The main difference is that new types create giant interoperability
>problems in the real world.
There are no such problems if you create unique prefixes which
is trivial by using transklated URIs.
> Getting the IETF to allocate a new DNS type
>is far easier than (for example) wiping out BIND 8.1.
How does TXT + prefixes wipe out BIND 8.1?
Anders
Anders Rundgren
>disagree with any claim that XML is *the* de-facto configuration
>language.
Let put it this way. The majority of systems intrduced the last
three years use XML.
>> So imo DNS is indeed one of the most dated
>> things in the entire Internet space.
>RFC 791 September 1981
>RFC 1035 November 1987
>Both IP and DNS have changed since they were developed, and they will
>change again. I don't believe "one of the most dated things in the
>entire Internet space" is a reasonable characterization of DNS.
As a directory system it is certainly lagging at least. 512 bytes?
That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!
>> DUAL MORAL STANDARDS
>>
>> The worst is, that things like iab-dns-choices have created a
>> bad morale among developers that now must (in order to pass
>> as RFC) support:
>> TXT to be able to rollout
>> NEW-specific to please IETF
>Is the problem here the IETF
It is the IETF who have created the incentive for dual standards.
> or the companies that develop systems
>and applications that make it extremely difficult to introduce new
>RR types?
The DNS specifications does not contain any kind of RFC
that supports a _smooth_ introduction of new RR types.
IF it should work there must be a way to publish not only a puni16-bit number
but the environment as well so that DNS admin GUIs knows what to do.
This will never happen as:
1. There is no _proven_ need for new RR types except for things that only deals with DNS itself
2. Such a scheme would use XML and that seems to be something the DNS community
don't understand at all
3. It will take forever and be extremely hard to agree on
The problem is BTW really buried in the archaic DNS system itself. Other
extension mechanisms allow the introduction of private data here thinking
of X.509 extensions.
>Steinar Haug, Nethelp consulting, sth...@nethelp.no
Won't hire :-)
--
Anders Rundgren
>True, but if you're using prefixes, regardless of what record types
>you're (re)using, you need some sort of registry if you want to be
>sure that nobody else will use your prefix to mean something else. I
>names, but I have my doubts about how
URI are used in numerous other contexts so the only trick is to
agree on a URI-to-DNS-label-translator
>The issue of how hard it is to get something into the registry is a
>separate question from what it is you're registering. I agree that in
>retrospect it should have been easier to register new RR types so that
>people wouldn't have written DNS software that assumes the set of RR
>types is forever fixed.
Looking at W2KS DNS GUI server I don't agree. I only supports a limited
set of types. And since most people actually only need a text-something
it makes no sense to create a new text-something over and over again.
The URI-suffix (not prefix) covers all readonable needs. And it costs
nothing to implement or support either.
Anders
Andras Salamon
> Anyhow, let's please
> first acknowledge the semantic equivalence between:
>
> string
> And
> Name = example.net, Prefix = null, type = myNewType(1234), content =
> string
Agreed, these are largely equivalent. Also somewhat equivalent would be
Name = example.net, Prefix = null, class = someNewClass, type =
someNewType, content = string
However, there _is_ a semantic difference since you are associating
the data with different domain names. As you point out this mostly
affects wildcards, but there are also situations where queries for
--myNewPseudoType "records" for example.net could result in responses
of "string" in the one case, NXDOMAIN in a second case and "NOERROR,
0 answers" in a third, requiring extra client logic to handle the
NXDOMAIN case. After all, --myNewPseudoType.example.net not existing
doesn't say anything about example.net existing or not. In comparison,
if the new RRtype solution returns NXDOMAIN then we know example.net
does not exist, simplifying client-side code.
-- Andras Salamon and...@dns.net
Anders Rundgren
>of turning requests for hostnames into IP addresses with a reasonably
>small number of bytes transmitted. The larger the edifice is built,
>the more one worries about the humble foundations.
Since needs have changed quite a bit since DNS was created,
so should DNS. If every web-page drags down 10K and up,
averaging on 100K using TCP, why should 512 bytes UDP be
all a DNS server manages to do?
XML is today the de-facto config-language. It is even used
in mobile phones. So imo DNS is indeed one of the most dated
things in the entire Internet space. That also includes ideas such
as having a central registry for app-data types. App-data is not protocols
or ports.
There may be problems with prefix,suffix schemes but I cannot find
much substance like that
-you always get *all* TXT records
-you cannot allocate more than about 203 TXT records
DUAL MORAL STANDARDS
The worst is, that things like iab-dns-choices have created a
bad morale among developers that now must (in order to pass
as RFC) support:
TXT to be able to rollout
NEW-specific to please IETF
Then they must also write in the I-D that "TXT is the 'interim' solution,
we expect all to switch to NEW asap". Since the "interim" works
why should this ever happen? It is a blatant lie IMNSHO.
"app-data" types should not have to be published at all outside
their user community.
thinks
Anders
Anders Rundgren
If you look at my DomainKeys example you can see that prefixes
is not the only possible way. "Midfixes" does it all and without
requiring any DNS updates. Look under "performance":
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html
There may be use-cases that don't apply to midfixes.
Since you hopefully represent Microsoft, how about supporting
an XML companion to TXT? DNS must be the only IT system
in the world that does not support XML!
What "this group" thinks about prefix is not important, the "market"
has already done its choice. What's missing are guidelines.
Here is an attempt at least:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00183.html
Anders
----- Original Message -----
From: "Christian Huitema" <hui...@windows.microsoft.com>
To: <namedr...@ops.ietf.org>
Sent: Saturday, January 22, 2005 05:56
Subject: Little endians, big endians, and 16 bit eggs
OK, the real title of the reference papers was "On Holy Wars and a Plea
For Peace", and it did not refer to 16 bits eggs. Anyhow, let's please
first acknowledge the semantic equivalence between:
Name = example.net, Prefix = --myNewPseudoType, type = TXT, content =
string
And
Name = example.net, Prefix = null, type = myNewType(1234), content =
string
Sure, there are differences, and it is worth noting them:
- The "prefix" case does not support wildcards (but there are
workarounds)
- There is a fear that some servers do not support new types
But the main difference is about control. Prefixes can be made up on the
fly by whoever thinks about them, while types must be registered through
a rather lengthy and contentious defined IETF process.
It does not have to be so. If this group really believes that inventors
of new protocols should use new types instead of cooking up prefixes,
then it is perhaps time to make sure that record types can be allocated
easily, maybe just as easily as TCP ports. And, by the way, TCP ports
also are 16 bit long.
-- Christian Huitema
--
sth...@nethelp.no
> in mobile phones.
I have no problem with XML being used in mobile phone. I strongly
disagree with any claim that XML is *the* de-facto configuration
language.
> So imo DNS is indeed one of the most dated
> things in the entire Internet space.
RFC 791 September 1981
RFC 1035 November 1987
Both IP and DNS have changed since they were developed, and they will
change again. I don't believe "one of the most dated things in the
entire Internet space" is a reasonable characterization of DNS.
> DUAL MORAL STANDARDS
>
> The worst is, that things like iab-dns-choices have created a
> bad morale among developers that now must (in order to pass
> as RFC) support:
> TXT to be able to rollout
> NEW-specific to please IETF
Is the problem here the IETF, or the companies that develop systems
and applications that make it extremely difficult to introduce new
RR types?
Steinar Haug, Nethelp consulting, sth...@nethelp.no
Andras Salamon
> As a directory system it is certainly lagging at least. 512 bytes?
DNS has a specific purpose, as defined in the RFCs. It is not a generic
"directory system".
http://www.dns.net/dnsrd/rfc/
See also draft-klensin-dns-role-05.txt for a good overview of how the
"DNS community" sees the function of DNS.
There have been several efforts to set up alternatives, for instance
LDAP and various X.500 directories (for instance, see the above list
of RFCs for the history of some of these). I'm still waiting for
widespread deployment of a next generation directory system which can
handle infrastructure directory duties as well as DNS.
> The DNS specifications does not contain any kind of RFC
> that supports a _smooth_ introduction of new RR types.
You are right. To introduce a new RR type you have to publish an RFC
describing it. Takes a bit of work.
> 1. There is no _proven_ need for new RR types except for things that only deals with DNS itself
That is debatable. It depends on what function you think DNS fulfils.
Again, see draft-klensin-dns-role-05.txt.
> 2. Such a scheme would use XML and that seems to be something the DNS community
> don't understand at all
Methinks you judge too quickly.
-- Andras Salamon and...@dns.net
Douglas Otis
> On Sat, 2005-01-22 at 08:14, Alex Bligh wrote:
>
> > Serious point: DNS is/was a low level protocol which did a fair job
> > of turning requests for hostnames into IP addresses with a reasonably
> > small number of bytes transmitted. The larger the edifice is built,
> > the more one worries about the humble foundations.
>
> Since needs have changed quite a bit since DNS was created,
> so should DNS. If every web-page drags down 10K and up,
> averaging on 100K using TCP, why should 512 bytes UDP be
> all a DNS server manages to do?
A smaller packet size does two things, it ensures the packet can be
handled, and constrains the amount of UDP traffic. The number of
interactions within DNS depends upon a sequence of low latency events
from perhaps many sources. There are additional burdens created with
changes to IP and DNS that make this MTU restriction more of an
imperative. Due to this pressure, perhaps someday the MTU for DNS may
be safely increased without incurring additional problems. Until then,
this would suggest, to accommodate changes to the underlying transport,
new resource records should be assured to be smaller and not larger.
TCP connections require maintaining state for 5 packets of setup and
tear down in addition to the data packets, thus adding a delay of at
least 3 round trips. Should TCP be employed for a common reply, the
ability to sustain DNS service would be reduced by this added overhead.
> XML is today the de-facto config-language. It is even used
> in mobile phones. So imo DNS is indeed one of the most dated
> things in the entire Internet space. That also includes ideas such
> as having a central registry for app-data types. App-data is not protocols
> or ports.
Prefixing script with the conventional XML headers would be prohibitive.
Such as the following 370 bytes:
<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<root xmlns="urn:ietf:params:xml:schema:widget-01"
xmlns:m2="urn:ietf:params:xml:widget-02"
xmlns:m3="urn:ietf:params:xml:widget-03"
xmlns:m4="urn:ietf:params:xml:widget-04"
xmlns:m5="urn:ietf:params:xml:widget-05"
xmlns:xsi="http://www.w3.org/2001/XMLSchema";
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
This header could be replaced by applying a convention for such a header
to preface the resource record or via a standardized token that replaces
such a header. Just using an XML header would be prohibitive. The XML
language itself represents about a 20% increase in script related
encoding. Hardly a good fit when attempting to constrain record size.
> There may be problems with prefix,suffix schemes but I cannot find
> much substance like that
> -you always get *all* TXT records
> -you cannot allocate more than about 203 TXT records
I think a label prefix, virtual or otherwise, will be needed. Ideally a
record should fit within only a fraction of the available packet.
> DUAL MORAL STANDARDS
>
> The worst is, that things like iab-dns-choices have created a
> bad morale among developers that now must (in order to pass
> as RFC) support:
>
> TXT to be able to rollout
> NEW-specific to please IETF
Alas, neither of these techniques solves the underlying problem. The
choice dilemma is predicated upon an expectation wildcards may be used
to assert policy within any possible sub-domain.
> Then they must also write in the I-D that "TXT is the 'interim' solution,
> we expect all to switch to NEW asap". Since the "interim" works
> why should this ever happen? It is a blatant lie IMNSHO.
>
> "app-data" types should not have to be published at all outside
> their user community.
Labeling conventions allow communities to coexist. A case made for
usurping a TXT record seems flawed.
-Doug
Anders Rundgren
I would expect that public key stuff to be less than 4K and so
would most likely XML schemes as well. 4K seems like a reasonable
object these days.
A factor of 8 in 18 years is IMHO a *very* modest improvement.
It seems that no reengineering is necessary either. Assuming that EDNS0
is applicable. Or reverting to a scheme where you using UDP
get the authoritative NSs and then with TCP get the "fat" object
directly from the source.
Regarding the other things, at least I agree.
Anders R
----- Original Message -----
From: "Alex Bligh" <al...@alex.org.uk>
To: "Paul Vixie" <pa...@vix.com>; <namedr...@ops.ietf.org>
Cc: "Alex Bligh" <al...@alex.org.uk>
Sent: Sunday, January 23, 2005 13:39
Subject: Re: Little endians, big endians, and 16 bit eggs
--On 23 January 2005 03:57 +0000 Paul Vixie <pa...@vix.com> wrote:
> after EDNS0, the foundations are just fine, thanks. "more weight."
I'm not sure that means buildings of any and every type should be built on
top of them though. There may be other types of foundations better suited
to certain types of architecture (pun intended).
As an example, I am not sure whether DNS (alone, rather than over some
other protocol) is the right basis for a directory service where (a) it is
necessary to securely authenticate both client and resolver to eachother,
where there are many to many relationships for large values of "many", and
(b) it is necessary to move large amounts of directory data (c) it is
necessary to encrypt the wire protocol against snooping (d) subsecond
lookup latency is not that important. Whilst I'm sure one *could*
reengineer DNS to do that, I think I'd prefer to do it over https:// with
some certificate management scheme. Sometimes I wonder whether some of the
proposed DNS variants (e.g. carrying large amounts of XML) would not be
better done with a one stage indirection at the DNS layer, and a solution
using some other well known protocol.
Alex
--
Samuel Weiler
> > The DNS specifications does not contain any kind of RFC
> > that supports a _smooth_ introduction of new RR types.
>
> You are right. To introduce a new RR type you have to publish an RFC
> describing it. Takes a bit of work.
Not necessarily. RFC2929 sets aside about half of the type code space
as "Specification Required". RFC2434 and 2434bis both define
"specification required" as: "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."
Presumably an academic paper, a book, or even a tech report would
suffice as 'permanent and readily available'. So might a legislative
act or a published decision of a court of law. Even a New York Times
article might meet that standard. As to the specific standard IANA
applies, I'm not certain: I've repeatedly asked that question of Doug
Barton, IANA manager, and I have yet to get an unequivocal answer.
All that said, even publishing an RFC to get a typecode isn't that big
of a deal. Three new typecodes were assigned by RFC3755. The
individual submission that led to 3755 was first published on 27
February 2003. The initial IANA assignments were made on 3 November
2003, approximately 8 months later, after the doc passed the IESG.
The IPSECKEY and SSHFP RRs have also been assigned. IPSECKEY was
approved by the IESG on 28 September 2004 -- IANA made that assignment
on 20 December, less than two months later.
-- Sam
Edward Lewis
>On Sun, 23 Jan 2005, Andras Salamon wrote:
>
>> > The DNS specifications does not contain any kind of RFC
>> > that supports a _smooth_ introduction of new RR types.
>>
>> You are right. To introduce a new RR type you have to publish an RFC
>> describing it. Takes a bit of work.
The ATMA RR type is not defined in an RFC. Here is the definition:
ftp://ftp.atmforum.com/pub/approved-specs/af-saa-0069.000.pdf
This is probably a historical oddity, but it can happen.
>Presumably an academic paper, a book, or even a tech report would
>suffice as 'permanent and readily available'. So might a legislative
>act or a published decision of a court of law. Even a New York Times
>article might meet that standard. As to the specific standard IANA
>applies, I'm not certain: I've repeatedly asked that question of Doug
>Barton, IANA manager, and I have yet to get an unequivocal answer.
Those examples are far fetched. The intent is that the definition be
readily and freely available. The ATM Forum has charged or required
membership for access to some documents. But, as far as I know,
there has never been a charge to retrieve the document mentioned
above. (I am not an authority on the ATM Forum modes of operation.)
>All that said, even publishing an RFC to get a typecode isn't that big
>of a deal. Three new typecodes were assigned by RFC3755. The
>individual submission that led to 3755 was first published on 27
>February 2003. The initial IANA assignments were made on 3 November
>2003, approximately 8 months later, after the doc passed the IESG.
>
>The IPSECKEY and SSHFP RRs have also been assigned. IPSECKEY was
>approved by the IESG on 28 September 2004 -- IANA made that assignment
>on 20 December, less than two months later.
I think that is an overly rosy picture. The time it takes from IESG
approval to IANA reserving the number is usually quite short. But it
is the work up to IESG approval has historically taken quite a lot of
time.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"A noble spirit embiggens the smallest man." - Jebediah Springfield
bman...@vacation.karoshi.com
> three years use XML.
and the life expectancy of these systems is?
> >Both IP and DNS have changed since they were developed, and they will
> >change again. I don't believe "one of the most dated things in the
> >entire Internet space" is a reasonable characterization of DNS.
>
> As a directory system it is certainly lagging at least. 512 bytes?
DNS is not a directory system... :)
> The DNS specifications does not contain any kind of RFC
> that supports a _smooth_ introduction of new RR types.
yet.
> 1. There is no _proven_ need for new RR types except for things that only deals with DNS itself
> 2. Such a scheme would use XML and that seems to be something the DNS community
> don't understand at all
> 3. It will take forever and be extremely hard to agree on
your assertions are interesting, but lack credibility.
there are -proven- needs for new RR types (among other DNS attributes)
Such new things will not all use XML (its too heavy-weight) but some
may.
Forever is a -very long- time. But if its couched in terms of
the life expectancy of "the majority of systems intrduced in the
last three years" ... you may be right.
so.... repeat after me... "The DNS is not a directory system"
--bill
Olaf M. Kolkman
Edward Lewis <Ed.L...@neustar.biz> wrote:
>
> I think that is an overly rosy picture. The time it takes from IESG
> approval to IANA reserving the number is usually quite short. But it
> is the work up to IESG approval has historically taken quite a lot of
> time.
As a working group we cannot do much to speed up that particular part of the
process.
However, the IESG will come to the DNSEXT group for assessment of
these proposals.
<our charter>
The lifetime of the group is set by the work items above but while
these are ongoing the working group has additional tasks:
o Reviewing and providing recommendations about the
specification, by other working groups, of RR types that do
not require any special processing and that do not require any
special naming conventions.
</our charter>
IMHO this is something this group should be able to do within a few
weeks. The earlier such proposals hit this group the better.
(Note the "not require any special processing", what has been causing debate
over the last weeks is just that: the need for special processing to
find the zonecut.)
-- Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC