spf-discuss
[Top] [All Lists]

Re: DNS matters & Wildcards

2005-05-07 09:49:35
At 11:49 PM 5/6/2005 -0700, william(at)elan.net wrote:
On Fri, 6 May 2005, David MacQuigg wrote:

Original context:
Wildcards aren't incompatible with SPF, they just make SPF more complicated and prone to error. The other methods (CSV and DomainKeys) actually are incompatible, because they use the _namehack.

That statement is not correct. Neither CSV nor DK any more or less incompatible with DNS. And it would also be true that use of _namehack
does not make problem of wildcards any bigger or smaller then what
it is with SPF. I had a long post on this subject during MARID already,
don't have time to search archives, perhaps somebody else can.

As I understand it, a domain name like _client._smtp.*.mydomain.com is illegal in a zone file. This is what you would have to do to make CSV records apply to any name under mydomain.com. That's what I meant when I said wildcards were incompatible with CSV. Same for DomainKeys. SPF avoids the problem by putting its records under mydomain.com. Then *.mydomain.com is legal, and a query for SPF records on any name under mydomain.com should work.

Please insert AFAIK in front of every sentence above. I'm not pretending to be an expert. Just being brief. Corrections are welcome.

It seems significant to me that both CSV and DomainKeys are not worried about using _namehacks.

Next excerpt:
That statement is not correct. Neither CSV nor DK any more or less incompatible with DNS. And it would also be true that use of _namehack
does not make problem of wildcards any bigger or smaller then what
it is with SPF. I had a long post on this subject during MARID already,
don't have time to search archives, perhaps somebody else can.

As I understand it, a domain name like _client._smtp.*.mydomain.com is illegal in a zone file.

No, that is not true. This in fact has already been discussed on this list
before, you have misunderstanding due to not knowing the difference between hostnames and domains. I'll refer you to the real source however:
 http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00591.html

Then *.mydomain.com is legal, and a query for SPF records on any name under mydomain.com should work.

*.mydomain.com is legal hostname and carries no special meaning
* when applied to domain name specification has special meaning as wildcard

In other words you can query directly for '*' and it you get the answer on that specific record but for dns protocol its used expansion default record for use with unknown domain zones that are not specifically subdeligated from parent.

We're losing some important context here, so I copied it above. I think what you are saying is that a domain name like _client._smtp.*.mydomain.com is actually legal, but the '*' is treated as an ordinary character, not a wildcard. Then what I'm saying about the incompatibility of CSV with wildcards is still true. We don't get the desired effect. We can't make the CSV records in _client._smtp apply to any name under mydomain.com.

To me, this is an acceptable limitation. It would not stop me from using a _namehack to provide a unique location for a TXT record.


Don't be in such a hurry to post about subject unless you're already
well familiar with it to be able to do it. This will save you from unnecessary flames....

Then I will never learn anything. One hour of the right kind of discussion is worth ten hours of reading a book. Flames don't bother me, except that they very quickly make discussions unproductive.

There is a difference between posting and asking a question and posting as if you think that must/should be so. Also make clear when you're referring to your opinion on the matter or when you have technical knowledge about the subject.

Again, please let me know if I say something that's not true. I can't preface every sentence with AFAIK. I don't mean you need to find every literal mis-statement, and send me off to hours of unproductive reading. Try to be more constructive: I think what you mean is ... and then re-phrase the statement so it is technically correct, and helps us reach more quickly reach a conclusion. Don't assume the worst possible interpretation of everything I say.


DNS has worked remarkably well, and it really is the best way to provide an email authentication service.
I'm curious what you base such a statement on? Its not all clear to me
even though I've a have done considerable research on the subject by now.

I assume you are objecting to the second statement. Again, I'm not an expert in DNS, but I can't imagine a more efficient way to provide a packet of information about any domain on the planet. UDP instead of TCP. Record caching. Redundancy. Mature technology, already deployed.

Lets Compare to HTTP: redundancy, caching, mature technology. Ok, maybe its not UDP but you know there are limitations to UDP as well...

Are you serious?  What would be the advantage of HTTP?

There is no reason deployment should necessarily involve existing protocol, IETF has commented several times that such reasoning is
not convincing to overloading one protocol and that its better to
develop new protocol that maybe based on existing one but then goes
towards direction that specific protocol needs. That is what happened
to SIP which was originally based on HTTP. The IAB specifially said
they wait people stop using HTTP for everything they can think of and
make better architectural decisions:
 http://www.faqs.org/rfcs/rfc3426.html

And the above is especially true about DNS because of its importance
to the stability of the internet, there are a lot of other protocols
that depend on it and overloading of it may be more dangerous then HTTP.
That said again nothing stops you from building new protocol that is
UDP based and works similar to dns. In fact SES chose that and so did
SIQ proposal.

If you were to design a new system like DNS, but specifically for email authentication, what would you do different? Would the advantages of the new system overcome the cost of development, deployment, documentation and training, and correction of problems that are inevitable in any new system?

You mentioned the problem of overloading DNS. Is there a way we can remove that load entirely, with less cost than developing a whole new system? Such a solution could put a nice upper limit on cost if our worst nightmare scenario actually happens.


As far as widerange redesign for spf3, the reason we are not working on
it is because spf community still has not recovered from political chaos
caused by SID and MARID and SPF Council has been slow dealing with that
and finalizing push of spf1 through ietf. They have not provided directions
and there is yet no opportunity for open discussions for future spf version design yet. I was personally hoping we could get started on Unified SPF and spf version x (x>1) from this february if not earlier.

You gotta understand how bad this sounds to the non-techie politicians and lawyers at the FTC who are ready to kick butt. I just hope their next solution isn't as ineffective as CAN-SPAM. I'm hoping to get them focused an a simple neutral "standard" that will not require changing everything in SPF, but will allow the industry to move forward, even while we diddle with the details.

Its not good idea to work out technical problems under political pressure,
ends up byteing you in the xxx later and results are solution that is not the best you could have for the problem at hand and may even cause more
problems. I'm happy that politicans express interest in anti-spam matters,
but I think they should stand back for a little bit, especially from
techical matters - the issue is known and being worked on more seriously now.

I agree that development under pressure (political, commercial, whatever) is not the best technically. In the real world, we have to compromise with these pressures. We may not have another year to work out all the details. I believe the best solution to this problem (rapid deployment vs technical perfection) is a simple neutral standard that does not favor one or another authentication method, but will allow the whole email industry to move forward. Reputation services, spam-filter companies, forwarding services, ISPs, all should be working now on their part of the problem. We just need to let them know what an authentication header will look like. No, it won't be Received-SPF: Think of another, more neutral word.

I don't think the politicians are all bad. They can get things done. That problem with the web interface for DNS hosting services? Here's a million dollars. Fix it now.

I also have some hope that you might see spf forwarding and couple other
major problems resolved by with new proposals by end of the year for sure, in fact it might even happen a lot sooner.

The problem with forwarders goes away when forwarders do their own authentication. That will be a requirement for compliance with the standard. Think big. Think outside the box.

--
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        *
************************************************************ *


<Prev in Thread] Current Thread [Next in Thread>