Subject: Re: Little endians, big endians, and 16 bit eggs

From: Paul Vixie <[email-masked]>
Date: Sun, 23 Jan 2005 16:04:04 +0000

> Since needs have changed quite a bit since DNS was created,
> 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.

--
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: Paul Vixie <[email-masked]>
Date: Sun, 23 Jan 2005 16:29:24 +0000

> THE QUESTION:
> Does this (fat-object) paradigm fit DNS?

no.

> A majority of the NameDroppers seem to say no.

and rightly so.

dns is a udp app, probably the most popular udp app in the wide area (though
on LANs, nfs and smb are going to be more popular).  since the guaranteed
minimum maximum MTU has not changed (576 for V4) and is still small (1280 for
V6), any udp app for the wide area should be trying to avoid fragmentation.

that means dns will never be useful for fat objects.  don't dispair, though:
there are a lot of thin/dense objects whose need for a reliable, autonomous,
distributed, hierarchical database is met perfectly by dns, or which will be
met perfectly by secure dns.

> Here is a list of workarounds for people that would like to indeed move
> the DNS infrastructure a bit closer to the "other world" (Web Services).
> 
> 1.
> according to Paul Vixie:
>    after EDNS0, the foundations are just fine, thanks.  "more weight."
> 
> But the namedroppers seem skeptical about this and even claim that
> firewalls don't accept this.  Hard to know for me.

some firewalls don't allow it.  these are not the norm, and when faced with
a bug report about it, firewall vendors and operators fix the problem --
dns sails on.  the fingerpointing is always toward the violator of the spec.

> 2
> Another possibility could be:
> You retrieve the authoritative nameservers and in turn call
> these using TCP.  That is, you don't put any major load on
> the infrastructure at large only on the server you have a
> contract with or run on your own.  Is that a viable scheme?

no.  tcp requires state.  state quotas are a vulnerability in the face of
a DoS attack.  tcp must remain a fallback for queries, and be reserved in
the common case for updates and zone transfers.  doesn't matter who runs
the servers, if they're supposed to stay "up" then you can't depend on
them to have room for another tcp protocol control block in the common case.

> BTW, I have "ordered" an XML RR from IANA.  Putting the
> famous process to test.... :-)

i hope they turn you down.  XML would be as bad as TXT.  without subclassing,
every consumer would have to retrieve an arbitrarily large rrset, which is
not "the dns way" to do this.  note that RP and MX share an rdata format but
are used by different applications.  some new application-specific rrtypes
should be defined as having an XML payload, probably carried in a TXT-like
rdata format.  but the rrtype should be be by application, not rdata format.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 23 Jan 2005 18:43:56 +0100

>>You retrieve the authoritative nameservers and in turn call these
>>using TCP.  That is, you don't put any major load on the
>>infrastructure at large only on the server you have a contract with
>>or run on your own.  Is that a viable scheme?

>Seems pointless to me.  If you know you're going to find a server
>using traditional UDP DNS, open a TCP session, give it a key, and it
>gives you back a blob of XML, we already have a widely deployed scheme
>called http to do that.  It's got caches, alleged session security,
>content negotiation, all the trendy bells and whistles.

>What would be the advantage of shoehorning the XML into DNS?

To "find the server" is incorrect.
1. You find the nameserver using standard methods.
2. Now the trauma comes.  how do you identity this unique
object you are looking for?

Your solution:
goto IANA and get an RR.
wait an indefinite time for MSFT to support that in their admin GUI.
If you don't represent a major manufacturer/app you will NEVER get any support.
To *force* people to abandon these tools is a mission that I take no
interest in, irrespective of what I think of Microsoft.  Unless you find
a pleasure in creating things that can only be used by a handful
experts please do that but don't expect everyone else to follow.

Other solution:
1. Define a suitable RR ONCE.  The XML RR.
That *may* get MSFT support.  By using XML Schema import you
can create a "subclassed" GUI admin for *app-defined* XML data.
Does input validation and syntax check in spite of not knowing
what it is.

======================================
IANA and the IETF have nothing matching in the pipe-line
======================================

2. Use a structured prefix (created automatically if you have the
schema at hand) needed to access to your particular XML object.
This object may indeed indirect to http or be direct.  Which method
you end-up using has probly quite a bit with the app to do.
A dynamic thing will use http.  A static one will use direct data unless
it is really huge.

Anders

---

From: Paul Vixie <[email-masked]>
Date: Sun, 23 Jan 2005 18:05:12 +0000

> Not even 4K seems OK?

that depends on whether you have read and whether you agree with the
kent/mogul "fragmentation considered harmful" report, which is online:

<http://research.compaq.com/wrl/techreports/abstracts/87.3.html>

for me, 4K is a fine exception case but on average i think 1500 is
still the right upper bound for wide area udp.  remember that a
fragments of a udp datagram are transmitted back to back with no
congestion awareness (like tcp has.)  congestion awareness requires
state, and statefulness in dns is bad for any number of reasons.

as evidence that i used to be able to do technical work instead of
just arguing on this mailing list, i refer you to RFC 2671, wherein:

| 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
|        reassembly buffer.  Choosing 1280 on an Ethernet connected
|        requestor would be reasonable.  The consequence of choosing too
|        large a value may be an ICMP message from an intermediate
|        gateway, or even a silent drop of the response message.

> >i hope they turn you down.
> 
> Well, then we can dismiss iab-dns-choices right now.
> From DOA to EIP :-)

honestly, the iab has smart and wonderful people on it, but i don't
wait on them and they don't wait on me.  i'm far more interested in
what rob austein thinks as a BIND9 architect than in what he thinks
as an IAB member.  <flame about ivory tower propellerheads elided>.

> >XML would be as bad as TXT.  without subclassing,
> >every consumer would have to retrieve an arbitrarily large rrset
> 
> What does this really mean?  You get ALL TXT records and it is
> the clients who do the actual select?

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

> If that is NOT the case (which I doubt as I cannot find any support for
> that in RFCs) the "structured prefix/suffix" is an easier solution.
> Avtually you HAVE to use this for NAPTR etc. as
> "all NAPTRs are not equal".
> 
> So if we anyway must prefix/suffx why not use that all the way?

there really ought to be a FAQ on this topic.  i know we've been down this
road any number of times.  i wish i had an online whitepaper or archive
i could point you at.  but, see above.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 23 Jan 2005 18:17:43 +0000

> object you are looking for?

i guess you'd put it in the GET command that you send to the indicated server.

> wait an indefinite time for MSFT to support that in their admin GUI.

that's just silly.  no implementation, not even BIND with 90% or more of
the market, has the power to halt innovation.  we added SRV.  during the
years when MSFT didn't support SRV, folks didn't use MSFT's products to
carry SRV.  eventually the market catches on.  that's how it's supposed
to work, though it's bad that all these dns-aware firewalls and NATs are
refusing to carry opaque rrtypes that they don't recognize.  even those
NAT boxes eventually caught onto SRV though, since the market demanded it.
(and soon we will begin educating the NAT market about DNSSEC metatypes.)

> If you don't represent a major manufacturer/app you will NEVER get any
> support.  To *force* people to abandon these tools is a mission that I
> take no interest in, irrespective of what I think of Microsoft.
> Unless you find a pleasure in creating things that can only be used by
> a handful experts please do that but don't expect everyone else to
> follow.

my old boss (ken olsen of DEC) once wondered why anyone would ever want
to have a computer in their home.  now DEC is gone, because compaq and
HP both knew the answer to that question.  it sounds as if you'd like to
cede control over DNS evolution to a bunch of NAT and firewall vendors.
you won't find a lot of fellow travellers here for that road.

> Does input validation and syntax check in spite of not knowing

i need to check through my personal e-mail archives and figure out who
owes me the beer i bet somebody about when the proposal would finally
come to just redo DNS in XML.

listen, though.  DNS was here 20 years before XML became "the fad", and
DNS will still be here 20 years after XML has been replaced by a dozen
more fads.

---

From: "John R Levine" <[email-masked]>
Date: 23 Jan 2005 15:16:48 -0500

> object you are looking for?

Oh, my.  I thought the point I was making was so blindingly obvious that I
wouldn't have to spell it out, but I guess I do.

Your thought here is to have a scheme where you hand a service a URI, it
makes a UDP call to find the address of a second server, it contacts that
second server via TCP which gives you back a blob of XML corresponding to
that URI, is it not?  That scheme has already been invented.  It's called
http, it's used all over the world.  It needs no new DNS record types, no
new servers, no new anything, since as you have probably noted, we all use
it now.

You may argue "but it's not in the DNS."  Quite right.  It doesn't need to
be in the DNS.  Since there is no XML data in the DNS (and probably never
will be), no applications expect to do XML lookups in DNS.  They use http,
because that's where the XML is.

Coding more complex data with XML and fetching it with http is a perfectly
reasonable idea.  The IIM message signing proposal fetches per-user keys
that way.  But putting it in the DNS would be pointless and
counterproductive, since http maps URIs to XML right now,

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: "Anders Rundgren" <[email-masked]>
Date: Sun, 23 Jan 2005 21:31:38 +0100

John,
You did not answer the things that talked in advantage to XML, here thinking
of the GUI and the support you may get from the IT industry supporting
a lot of non-experts (=MSFT).

Yahoo specifies DomainKeys in DNS.  Does this make Yahoo stupid?

XML schemas instead of TXT would add less than 100bytes to
the 200-350 already in place.  Can't see that would kill XML.

Note I don't object at all to use http.  But that does not exclude XML.
IBM have a draft on that although they have managed to make an
XML object that is specific instead of universal.  They will get no
support from the business on this one.  They should have used TXT.

Why did they do a crummy design that goes nowhere? They were afraid that
they would be banned if using TXT.

Anders

----- Original Message ----- 
From: "John R Levine" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, January 23, 2005 21:16
Subject: Re: Retrieving large DNS objects

Regards,

---

From: [email-masked]
Date: Mon, 24 Jan 2005 17:32:42 +0000

> come to just redo DNS in XML.

	don't think it was beer per-se, but we did have this
	discussion.

--bill