In
<5(_dot_)2(_dot_)1(_dot_)1(_dot_)0(_dot_)20050506040731(_dot_)0421dea8(_at_)pop(_dot_)mail(_dot_)yahoo(_dot_)com>
David MacQuigg <dmquigg-spf(_at_)yahoo(_dot_)com> writes:
At 02:05 AM 5/6/2005 -0400, Radu Hociung wrote:
wayne wrote:
In
<5(_dot_)2(_dot_)1(_dot_)1(_dot_)0(_dot_)20050504164603(_dot_)043275e0(_at_)pop(_dot_)mail(_dot_)yahoo(_dot_)com>
David
MacQuigg writes:
Here are my partially formed opinions:
1) DNS has a few flaws in its design. [snip]
Yeah, but for something that was deployed in 1983(?), back when a lot
of people didn't even have a PC, it has scaled amazingly well with
very few changes.
Indeed ... a great example of good engineering, with little left to chance.
The little that was left to chance was security, and it's taken 10 years
of farting around, and DNSSEC is still a dream. If that detail were
considered from the beginning, it would have saved at least 10 years,
and who knows how many millions of dollars in related costs (diverted
websites, security complaints, down time to patch the cache spoofing
bug, etc).
Let's learn from history, shall we?
Attention to detail is all I preach and practice.
If you could go back to 1983, what would you change in DNS? It seems
like DNSSEC, would have involved a lot more overhead than was
appropriate at that time.
Yeah, back in '83, backbone connections on the Internet were 56k, many
university campuses had a single 9600bps link, and 300bps links were
very common. The PC/AT hadn't been released yet, and even if it was,
it was too slow to do the number of RSA calculations that DNSSEC
requires. Oh, and RSA had just been released to the public and had
just been patented. The IETF back then wouldn't have dreamed of
considering that kind of patented technology for core Internet
protocols. My, how times have changed.
2) SPF made a mistake in abandoning the _trick. Now we have to deal
with overcrowded TXT records, and a migration headache from TXT to SPF.
[...]
If we're slightly worried about overcrowding now, when it's not yet a
prominent problem, how will it be in 5 or 10 years ? Is it likely to
actually become a real problem? I think so.
My recommendation to the DNS folks is that the should define a bunch
of clones of the TXT RR (a dozen? a hundred? even more?). There are
currently tens of thousands of RR numbers sitting idle, allocating a
few isn't going to hurt. By creating them now, there may be a chance
that in 5-10 years that most name servers will support them.
I'm very close to reaching a conclusion that the least painful
alternative for a new service needing multiple TXT-type records is to
use the _namehack. The one issue I need to nail down is Wayne's
concern about the conflict between this and certain web interfaces to
DNS hosting services. Is this something easily fixed, like a common
PHP script used by all the web interfaces with this problem, or is it
something much more embedded?
The biggest problem I see is education and support. The underscore is
legal in domain names, but not in host names.
Note: a "host name" is defined to be a domain name that has a computer
connected to it. All host names are domain names, but not all domain
names are host names. There is a common misunderstanding that host
name is just a FQDN, but domain names aren't. Of course, FQDN means
Fully Qualified Domain Name, so this confusion is kind of silly, but
I've seen it happen.
Ok, so if DNS hosting services allow an underscore in the domain names
and a customer creates www_2.example.com, they are going to wonder why
it can't be used as a web server. The _name trick is being used more
and more as a way of saying "this isn't a host name, even if it has an
A RR", so more and more applications are going to make that (correct)
distinction, even if they don't already.
Did any of the other services using
_namehacks encounter this problem?
other than SRV records used in closed, (exclusive) MS environments, I
don't know of any real use of the _name trick. At one of the MARID
sessions at an IETF convention, this question came up and the JABBER
folks said that they had experienced problems with the use of SRV
records on the wide Internet.
So, I think the answer is: yeah, what little use of the _name trick
there has been, people have encountered problems.
How about the _namehacks in
DomainKeys and CSV?
Their deployment problems are their concern. Remember, SPF had more
deployment after a couple of months from the "SPF spec freeze" of Dec
2003 than either of those systems have after a couple of years. (Ok,
DK is grown recently, but still...)
-wayne