Re: New DNS Record Types

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.
I agree with Wayne, DNS is a remarkably good design for such an old 
protocol.  If I could go back, I would 1) make the CLASS attribute a NAME 
attribute instead, or at least *add* a NAME attribute to all DNS 
records.  2) I would eliminate wildcards. 3) I would think about anything 
simple I could add to improve security, though I'm not sure anything short 
of DNSSEC would make a difference.
Having a NAME attribute from the start would have eliminated the need to 
abuse the TYPE attribute every time a new record is needed, and would have 
eliminated the need to abuse domain names with constructs like 
_client._smtp.mydomain.com.
Eliminating wildcards would have made zone files a few lines larger, but 
would have avoided the problems that have now risen to the level of an IAB 
"Architectural Concern": 
<http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html>http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html 
- IAB Commentary: Architectural Concerns on the Use of DNS Wildcards.  By 
the way, this document is an excellent review of the history and present 
status of DNS wildcards.
> >>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.
> >
> > Before we switched to putting the SPF record at the email domain
> > level, there were two surveys done.  One looked at how often there
> > were already TXT records there, and the other, as you mention above,
> > about how many DNS hosting services would allow an underscore.  The
> > TXT record usage showed that we would probably be safe and that there
> > really wasn't much "overcrowding" of TXT records.  Later, during the
> > MARID WG, I did much more extensive surveys on TXT record usage and
> > the size of SPF records and showed that there REALLY isn't an
> > "overcrowding" problem with TXT records.
> >
> > In hind sight, I think we made the right choice.
>
> At the time there was no overcrowding, but now everyone wants to put
> their stuff in the TXT record at the top level.
>
> Had you chosen an extension, the competing ideas would also be picking
> their own extensions.
>
> Picking the top-level domain as a host for the SPF record was setting an
> example for future ideas. More attention should have been paid, not to
> the then-current crowding situation of the top-level TXT record, but to
> the unfolding of subsequent events.
>
> 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.
>
> Anyway, there's not much point debating this, I don't think, because
> like you mentioned, an SPF-replacement standard is probably needed to
> clean up the deficiencies of the "Classic" spec.
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?  Did any of the other services using _namehacks encounter this 
problem?  How about the _namehacks in DomainKeys and CSV?
According to IAB document above, there are a "number of conventions and, in 
some cases, protocols, which use labels at the left (least significant) 
ends of the names of resource records to distinguish between records 
..."  The SRV protocol is one example, and that protocol is used by 
CSV.  (See 
<http://www.ietf.org/rfc/rfc2782.txt>http://www.ietf.org/rfc/rfc2782.txt 
For example, if you want to see if example.com has an LDAP server using 
TCP, look for an SRV record at _ldap._tcp.example.com.)
My guess is that the problem with web interfaces to DNS hosting services 
will be fixed because they will run into this problem from other services 
as well.  We could use some other n-amehack, or just use a normal name, but 
the leading _underscore is such a universal convention for namehacking 
(e.g. Python language), that I hate to drop it because of some poorly 
implemented web interface.
--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************     *