Subject: RE: TXT records, are they alive?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 20 Apr 2003 19:36:00 -0700

Some of the spam blacklists use A records to encode their opinion of the
domain in question.

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Sunday, April 20, 2003 7:00 PM
> To: Florian Weimer
> Cc: Peter Koch; Mohammad Awad; [email-masked]
> Subject: Re: TXT records, are they alive?
> 
> 
> Florian Weimer <[email-masked]> writes:
> 
> > However, as far as I can tell, stub resolvers lack convenient
> > interfaces for extracting TXT RRs.  This might explain why a lot of
> > DNS applications use A RRs to encode things which actually aren't IP
> > addresses. 8-/
> 
> What applications do something like this?  An A record is extremely
> limited in what it can hold (namely, a 4 octet address).  So, I'd be
> interested in hearing about "DNS applications" that hold something
> else or somehow use A records differently.
> 
> -derek
> 
> -- 
>        Derek Atkins
>        Computer and Internet Security Consultant
>        [email-masked]             www.ihtfp.com
> 
> --
> 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/>
> 

--
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: "'Derek Atkins'" <[email-masked]>
Date: 20 Apr 2003 23:15:17 -0400

Sure, but it's still just returning a IP Address..  Nothing says that
that IP Address has to be real or routable or accurate..  It's still
limited to 4 bytes.

But I conceed that people are actually using it from things other than
hostname looking to contact that host.

-derek

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Apr 2003 09:44:32 -0400

This (below) concerns me at some level.  Without pontificating on the 
morality of this at all, I'm worried that this happens.

Why do the application writers of this software opt to use an 
existing RR in a manner not intended?  Why are they unwilling to 
define a new RR?

Has the IETF made it too hard for engineers to do the right thing? 
Do the application writes feel disenfranchised?  Why are they not 
coming to and actively participating in the WG process?  How has the 
IETF failed in this way?

Has the IETF failed in educating developers, presumably newer 
developers, in good engineering practices?  The IETF once prided 
itself on not educating folks, to discourage 'tourists,' maybe the 
IETF has succeeded in building a large body of work that may go 
misunderstood by the next generation of engineers because of this?

I'm not disappointed that developers do whatever they can to seek out 
the path of least resistance towards meeting a goal.  I'm 
disappointed that the IETF hasn't carved a path - making it least 
resistance - that meets high-quality engineering practice.

Back to DNS -

Why I am concerned in this case - although the IETF does not enforce 
protocol use, I hope not to have to maintain backwards compatibility 
with wayward extensions and operations.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I'm sorry, sir, your flight is delayed for maintenance.  We are
pounding out the dents from the last landing."

---

From: Greg Hudson <[email-masked]>
Date: 21 Apr 2003 11:25:17 -0400

> existing RR in a manner not intended?  Why are they unwilling to 

A new RR type wouldn't be supported by the majority of deployed primary
DNS servers for years.  (djbdns allows you to input RRs of new types by
giving the binary representation of the RR, but even that's not terribly
friendly.)  Even leaving aside operational issues associated with caches
and secondary servers which don't do the right thing with new RR types,
using a new RR type for your application would be a high barrier to
entry.

And they don't use a more generic RR type, like TXT or UNSPEC, because
you'd have to parse a DNS packet to do so, which is a lot harder than
calling gethostbyname() and comparing to a few IP addresses.

> resistance - that meets high-quality engineering practice.

What are we going to do, reconcieve DNS as a text protocol and add
something akin to XML namespace support?  I guess there's been periodic
talk of a "next-generation DNS," but it would be one hell of a
transition.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Apr 2003 11:38:22 -0400

>DNS servers for years.  (djbdns allows you to input RRs of new types by

Is that because of the IETF bureaucracy or stubbornness of the code writers?

>using a new RR type for your application would be a high barrier to

True, if we had "unknown type code" support in the older code.

>calling gethostbyname() and comparing to a few IP addresses.

Interesting - the API's surrounding DNS are lagging even more than 
the protocol and the server implementations.

>talk of a "next-generation DNS," but it would be one hell of a

I was thinking more of the process.  The process of following good 
engineering practices (including research, open discussion, 
documentation, testing, among others) shouldn't become so onerous 
that cutting corners on this is attractive.  I wasn't thinking that 
we beef up DNS to do more, just to make sure those relying on DNS 
know what DNS is really about - and to make sure the DNS protocol 
designers know of the changing requirements imposed by the changing 
environment.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Greg Hudson <[email-masked]>
Date: 21 Apr 2003 11:41:27 -0400

> Is that because of the IETF bureaucracy or stubbornness of the code writers?

Even if the IETF were a rubber stamp and the code writers were
infinitely fast, people don't upgrade their server software very often. 
So you'd put new adopters of your application in the position of asking
their DNS administrators to take a software upgrade and add records of a
type they don't understand.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 21 Apr 2003 16:20:52 -0000

Greg Hudson writes:
> leaving aside operational issues associated with caches
> and secondary servers which don't do the right thing with new RR types

You're talking about most versions of BIND deployed on the Internet. The
bug wasn't fixed until 9.1. See http://cr.yp.to/djbdns/newtypes.html.

> calling gethostbyname() and comparing to a few IP addresses.

Actually, the RBLs provided TXT records from the beginning (although the
big ones that use BIND have dropped the TXT records to avoid some BIND
performance problems), and most of the initial client implementations
used those records.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Apr 2003 17:23:18 +0000

> Why do the application writers of this software opt to use an existing RR
> in a manner not intended?  Why are they unwilling to define a new RR?

the biggest single reason is that bind was broken for many years in its
handling of unknown resource record types.  on the one hand we couldn't
transfer or cache them if we didn't know their interior structure, and
on another hand we compressed the interior structure in variance with the
dictates of rfc1035.  this pretty much made new rr types impossible to
roll out, and although several did make it through, it took a decade for
them to be widely usable.

now that bind isn't broken in this way, and now that there are other widely
deployed implementations (both open source and not), it's reasonable to
consider putting more rrtypes into the field.  however, institutional memory
means we have some cultural inertia to overcome before this can happen.

--------

another reason, which you aluded to, is that the ietf makes new rrtypes
hard.  again this is cultural -- our work is done in an environment where
any single loudmouth bozo can so polarize the debate on any given issue
that there will be no clear consensus.

since ietf is open to all comers, there's apparently no fix for this other
than to wait for people to move on to some other area.

(this isn't iesg's fault, they'll approve anything that's technically
reasonable and has WG consensus... and remember that our area director
found some embarrassing glitches in the last thing he was asked to approve,
and it became clear that not very many of us had actually read the thing
that we claimed to have come to consensus on.)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Apr 2003 17:34:49 +0000

> infinitely fast, people don't upgrade their server software very often. 

upgrades of that kind for this reason are no longer nec'y.  the need was
due to errors in old versions of bind, which are no longer the majority
and need not be coddled.  current bind8 and bind9, and as far as i know
current djbdns and mswin, are all capable of both caching and transferring
rrtypes which were unknown at the time of the software's release, and all
of them avoid compressing any rdata which was did not exist before rfc2181
(even though by law, this should apply to all rdatas after rfc1035.)

> type they don't understand.

not any more.  and for bind's part in having made it once so, i apologize.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 22 Apr 2003 11:29:16 +0200 (CEST)

> performance problems), and most of the initial client implementations

Its worth noting that these RBL-client implementations merely checked for
the existence of a record at the appropriate spot, and if it was a TXT
record, quoted said TXT record in the rejection message.  They didn't
actually parse the TXT record that I'm aware of.

This is more ontopic for spamtools or spam-L though, not namedroppers.

--==--
Bruce.

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 22 Apr 2003 11:07:10 -0400

> talk of a "next-generation DNS," but it would be one hell of a

No, I don't think DNS needs to be completely reconceived as an XMLish
text-based protocol, however, it *is* too difficult to introduce new
RR types, and we should do something about it, IMO. Perhaps an XMLish
protocol extension should be a fallback. E.g. if a resolver doesn't
understand a particular RR type that it receives, it could make a special
meta-query to the source of those RR's for the schema of the RR type, so
that it knows how to store and forward the RR type properly. The extra
resources consumed by these metaqueries would give operators an incentive
to upgrade their software to versions that understand the new RR
type(s) natively.

-Kevin

---

From: Greg Hudson <[email-masked]>
Date: 22 Apr 2003 11:26:15 -0400

> to upgrade their software to versions that understand the new RR

This sounds easy enough to do within DNS, thus taking advantage of DNS
caching.

  35.rrtype.arpa RRTYPE "NAPTR" "22sssd"

The trick, of course, is designing a schema language rich enough to
describe the most complicated of existing records (probably SIG and KEY)
as well as the most complicated of future records we hope to support. 
And an API which can take advantage of the schemas--easier in some
programming languages than others.

Well, it's an idea.  I don't plan to take it any farther than that.

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 22 Apr 2003 09:14:38 -0700 (PDT)

Kevin Darcy writes:
> that it knows how to store and forward the RR type properly.

You don't actually need a schema just to store and forward RRs of a
new or unknown type; they can be handled as opaque data as described
in draft-ietf-dnsext-unknown-rrs-05.txt.  A standardized and published
schema could be useful as a way of enabling human-readable entry and
display of such RRs, but we should not make the operation of the core
DNS protocol depend on it.
-- 
Andreas Gustafsson, [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 22 Apr 2003 12:50:44 -0400

> DNS protocol depend on it.

Right, but treating unknown RRs opaquely has serious limitations, as you've
noted in your draft. You don't know if the RR type causes Additional Section
processing. You don't know how to do duplicate elimination properly (maybe one
of the subfields of the RDATA is a name which should be compared
case-insensitively, or maybe not). You don't know whether there are names in
the RDATA which are forbidden to point to aliases. You don't know whether the
RR type is a "singleton" or not. When treating the RRsets as opaque data, you
must make very conservative assumptions, which might impair your ability to
serve your RR-type-knowledgeable clients to the fullest extent that they may
expect. A schema-based extension would at least provide a middle ground
between full knowledge of the RR type (contingent on software upgrade), and
the lowest-common-denominator "opaque data" solution you outline in your
draft.

I wouldn't make the "core DNS protocol" dependent on any such extension,
however. If the resolver can't get the schema for a particular unknown RR
type, the next fallback after that would be to treat it as opaque data.

- Kevin