At 12:51 PM 5/6/2005 -0500, Wayne wrote:
In <5(_dot_)2(_dot_)1(_dot_)1(_dot_)0(_dot_)20050506040731(_dot_)0421dea8(_at_)pop(_dot_)mail(_dot_)yahoo(_dot_)com> David MacQuigg
writes:
>> >>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.
This is a good suggestion. It seems harmless, but it also isn't near as
useful as an arbitrary name. Basically, we have a number of "registers" in
which we can put a record (e.g. reg00 ... reg99 ).
If I were going to use these in my record syntax, I would need to replace
meaningful names like SPF1 with one of these arbitrary numbered
registers. That would require a table somewhere relating SPF1 to reg05,
etc. The records would not be as readable. Here is a before and after of
a typical record:
svc=S1:A,M2:A,H1+:B dmn=QR1,SPF1+5,DK2
QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
+4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
svc=01:A,02:A,03+:B dmn=04,05+5,06
04=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
+4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
06=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
> 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.
This is what we want, a simple convention that distinguishes _names from
anything that might conflict with a real hostname.
Maybe the web interface should pop a warning, when you enter a _name:
"Warning: Underscore not allowed in a hostname. OK if this is not a
hostname." The instructions for updating the authentication records
should also emphasize, "We don't want a real hostname for this record. Add
a leading _underscore to make the record name distinct from any hostname."
--
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 *
************************************************************ *