On Wed, 27 Jul 2005 domainkeys-feedbackbase02(_at_)yahoo(_dot_)com wrote:
It is in fact that design that makes putting public key in dns an issue.
The designers did not really see DNS as appropriate for that kind of work.
But why don't you ask designers yourself - namedroppers is the place.
Well, I don't know about namedroppers, but Paul Mockapetris seems quite
comfortable with extending DNS in surprising ways, such as ENUM where all
4 billion phone numbers are in the DNS, or RFID, where every RFID tag is
in the DNS.
Phone numbers are pretty small records and ENUM is also being proposed in
the totally separate dns TLD tree. These are good examples on how to
extend use of dns in way that can be controlled.
This narrowly defined notion of "appropriate" DNS usage is akin to those who
insist that email was only designed for text and sending attachments is
"inappropriate" and risks destroying the email infrastructure.
Where did you hear that in my response? BTW - MIME was designed exactly to
deal with problem of attachments in the right way, was not easy task either.
What such naysayers don't want to accept is the fact that using a
technology in novel ways is a measure of its success, not a cause for
concern.
I think you're hinting at HTTP here. And BTW, overloading of HTTP has
also become an issue that IAB raised recently. But HTTP is not at the
core of all other applications on the Internet and if something does
not work, its only a problem for http server or its client, i.e for
actual implementors - with dns its not quite like that.
I might add that experience suggests that the DNS infrastructure is
amazingly resilient and has survived all sorts of "abuse" that
namedroppers never anticipated or wanted.
I agree, its amazingly good design for 20 year old system. But the
abuse of DK (and SPF) goes beyond some of the things tried before
and on different scale.
How so?
Think RBLs. People have deployed and queried RBL services without
bothering to get the sanction of namedroppers
That is actually not true. RBL was invented by Paul Vixie who is big
on namedroppers. We can probably check the archives, but I would not
be surprised if he first mentioned it there as well.
they didn't create an appropriate new RR, rather they "abused" A RRs.
And I personally did not understand why new RR was not proposed for it,
we can ask Paul. But as far as RBL, they are all done at what can be
called as specific dns tree (for each RBL), again this is quite a bit
different then record per each domain. Specific TLD trees are easier to
manage in DNS and debug problems and cache is done differently with RBLs
as well.
They also started with zero queries per day, and rapidly rose to perhaps
billions per day. Surprise surprise, the global DNS did not collapse.
Think reverse lookup load.
Part of DNS infrastructure by design, checking it for each TCP connection
was encouraged and part of tcpwrapper for many years.
We have turned on and off reverse look-ups on our inbound email at
various times over the last 4-5 five years. That's a net
change of billions of largely uncachable DNS queries per day.
Did anyone notice?
Yes, they did. Operational folks noticed that changes in lookups
and RIR servers had spikes. But on the whole picture your change
may not have been enough (because the data on ns of nameservers for
ISPs is already in your cache and lookups for those records are
done anyway by others).
Not that I heard. Did the sky fall in? Not that I noticed.
Think size of responses. At various times, for operational reasons, the
MX for yahoo.com has returned a large list of A records that are very
close to the maximum size response that fits in a UDP packet. At other
times - such as now - it returns a relatively small list of A records. I
know the same has been true of other large MX targets, such as AOL and
Hotmail. In aggregate, these three sites probably represent a substantial
proportion of cached MX entries.
No, not really - in fact its minuscule. Few large size changing or
adding couple new MX records and A addresses is not going to effect
local cache. MX and A are small and number of such sites is small even
if almost everyone communicates with them.
But all domains adding [multiple] large DNS PK records is going to be
noticeable because its all those small domains that are primarily what
is in the cache.
Think call-back SMTP. I know a number of widely used products and large
ISPs woke up one day and started doing SMTP call-backs to try and verify
MAIL FROM addresses. Did anyone notice the extra millions of MX lookups
when they turned the switch on? Not that I heard.
Actually in that case it was noticed (for those whose domains are often
being forged). But for others it was not a problem, because it too often
that for legitimate communication if they communicate with you, you
communicate back (i.e. the MX for those servers would be checked by you
anyway). And again few big sites doint it is not going to be a big problem,
its many small sites that implement SMTP-Call back that could be noticed.
The simple fact of the matter is that the global DNS has proven to be
resilient, flexible and scalable time and time again. That email is a
small and diminishing part of Internet traffic is also an important
observation. Consequently, to suggest that the global DNS is a fragile
beast and any novel use by email needs sanction from namedroppers, for
fear that the sky will fall in, might make namedroppers feel important,
and it might be PC, but it's not even close to being a deployment
necessity or imperative.
You would not mind if I keep this saved and send it to namedroppers
at appropriate moment, do you?
In any case to answer it, its not such a small "novel use" - you're talking
about putting very large dns records into every domain to be used at every
email transaction. This is big staff and appropriate review not only should
but MUST be done about it by dns core and operations folks.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net