spf-discuss
[Top] [All Lists]

DNS matters & Wildcards

2005-05-06 17:30:59

On Fri, 6 May 2005, David MacQuigg wrote:

Alan,  I appreciate your comments, and apologize for my rash statements.
The Subject line was intended to be humorous, not rude.

Thank you for explaining that. In that case you would not mind that I cut
subject a bit - as a user of wildcards it was kind of insulting.

Sorry for stating my opinion so bluntly. The IAB paper is indeed more cautious in its recommendations, and you are right, it takes user error to get some of the worst consequences they describe. I'll try to be more clear when I am stating an opinion, not an assertion of fact. Still, I find it outrageous that a parent domain would redirect any emails with mis-spelled addresses to itself.

A parent domain has full control over any child domains and could implement such a function entirely within dns software not basing
it on wildcards.

I'll note that the ability to handle requests for "child" zone (or rather
"child" URL) is used very widely with HTTP with cgi, php, asp and others.
All modern CMS systems in reality have only few scripts and they handle
requests automatically for entire website and create content on the fly.
Wildcards can provide somewhat similar function with dns.

What are the benefits of wildcards, other than a smaller zone file?

I answered you privately already. I don't claim to know every use of wildcards though, if you want try to do more searches on this subject.

Knowing what we do now, would wildcards be added to DNS?

Not only is the answer yes, but almost certain that the wildcards would
have been more comprehensive and more specialized and be able to cover
non-existent type records (when different record type and hence te host
exist) and be able to cover situations like a.*.example.com. This subject
is still being investigated though and future dns extensions ae possible.

The problem is not that 1 in 1000 chance that an email goes to an incorrectly typed, but valid address. The problem is 1000 times worse, because *any* misspelled address will go to the wildcard MX.

You're still angry from when Verisign tried to put wildcard in .com/.net zones - that is not exactly correct use of wildcards. You have to be careful what you use them for and how and make certain that administrator
of parent domain has full right to make decisions for ANY child subdomains
(no matter wildcarded or not).

It seems that some top-level-domains are actually using wildcard A and MX records without the consent of their delegated domains!

Yes, bad bad idea, can cause breaks with trust boundary.

I have never managed a network, but I feel that I don't need that experience to understand that misdirected emails are a serious problem.

You're not correct. You need experience and understanding about network
management to be able to fully understand this subject. Consider this
in other aspects of what you write about as well please. And if you don't
know the subject well, it really is best that you don't write about it
(in that I don't mean don't participate in discussions or ask questions,
but I mean don't write guides and make definitive recommendations for those who are even less aware of the subject) and let other people handle it until you have gained experienced and understanding.

I'm an expert in IC design. If someone said one of my designs was bad because it burned out in some likely circumstance, I would not defend the design by asking the person if they have ever designed an IC before.

I don't think asking that would necessarily be bad and doing it would have
saved you a lot of time and allowed to decide on the correct questions
to be asked from the person who said your design has problems.

An alternative would be to put your outgoing mail server records in their own zone file. (If I understand DNS correctly, the scope of wildcards is limited to the zone in which they occur.)

Zones is rather tricky subject in dns. While your statement is correct, I'm not sure what its meaning is really understood by many. For example most people would not recognize that a.b.c.example.com could be in the same zone as f.g.h.example.com but not necessarily same zone as k.b.c.example.com.

I typically see names like 'smtp.mail.yahoo.com' and 'pop.mail.yahoo.com'. Is there any need for wildcard MX records in 'smtp.mail.yahoo.com'?

I can't answer for yahoo, but I imagine they could be of some use if
they had number of different mail servers and all of a sudden decided
to change it to just one. Other applications are also possible.

I agree SPF should not tell people they shouldn't use wildcards anywhere in their domain, but where they interact with SPF, and cause the SPF records to be more complex than they would otherwise be, as in the example above, then we should say something. Perhaps we could suggest some alternatives, like separate zones.

No. If somebody knows how to use wildcard and wants to do it, then SPF is not going to create any more problems for them that they are not already aware about.

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.

I don't know if you read the earlier thread when this first came up, but to summarize, what I said was I think DNS is a remarkably good design for such an old protocol, but it has a few flaws. I would not point out these flaws except for their relevance to what I am trying to do. I would also not say anything if I felt I already knew it all, case closed.

While I totally agree with above, I'll note that if you ever come to
group of ietf dns designers, be careful how you talk to them and try
not to mention "flaws" (namedroppers may well have been the biggest flamewar arena on the ietf; but its been remarkably good and quite lately, just don't disturb it unnecessarily).

I know I should be more careful when I criticize the work of others, but I get in a hurry and sometimes get too short. I hope my explanations here will make it more clear what I really think of DNS.

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

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'm very surprised when I see apathy among the "DNS folks". Instead of just shooting SPF down, why don't they jump in and say "Great idea. Now if you just change this and that ...". I guess from their point of view, the "SPF folks" aren't listening.

In their perspective the statement you made above (about dns being best
way for email authentication) may not be correct, nor is SPF design.

There are very very smart people involved with dns design who know the
subject of multi-network distributed dns database with multiple trust
boundaries and how to keep such system stable rather well, so don't just
dismiss what they say.

And I happen to agree with them somewhat because SPF seems to have been
put together out of plaster of multiple pieces in a way as to make it
most convenient and most marketable to users. This is not necessarily the best way to create a security infrastructure, in fact if you look at Microsoft which often has used same principles with their extensions and programming in Windows, you'll see that such marketing and user-convenience principles can later lead to wide-ranging security implications and that can become a problem that is very hard to manage when such design is widely used by everyone and then the problem can effect 100s of millions of internet users and take long time to fix.

The question really is if they are overestimating the problems in spf1 too much or not (they probably are - dns designers are extremely cautious).

The proposal I'm working on will be (SPF3 I hope) the ultimate efficient use of DNS for email authentication. One query to a known server, and bingo, you get everything you need for authentication and domain-rating for all the mail servers in an entire domain. Zero worry of DNS loading. This is not a difficult technical problem. I believe A DNS expert could write this proposal much better than I can. Why aren't they motivated?

I'll provide smaller proposal that can satisfy folks who want pki
records with spf within next couple months, it may satisfy some who
want it (even if I do not necessarily agree with this apprach, this
would make some things and some lookup easier and faster).

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.

Without going into details, I can already tell you that almost certainly your current proposal will probably never be accepted for spfX. This does not mean its bad for you to propose it and in doing so it should cause you to do more research more on the subject and then you would be better prepared for constructive dialog and design that will really be necessary for SPFx. Note that work in this area will have to satisfy multiple parties here that will have to participate in such a design.

I have gotten some good advice (offline) from a DNS expert who is unwilling to participate in these mailing list discussions. It is really a shame that there is such hostility that experts and people with good ideas don't feel welcome.

I don't think this is so, this list is actually a less hostile then number
of dns specific mail lists and more open to new ideas then what I have seen
on other anti-spam lists that are specific to their own subjects.

I'm unsure as to why dns experts did not want to participate more (I know that Paul Vixie is unhappy that his mail-from draft was not considered, but likes RMX ideas in general, don't know reasons of others) but on MARID we did have advise of Ed Lewis (who is the author of the mentioned wildcard draft) and David Blacka. Both of them I know well primarily from
areas not-directly dealing with dns (whois and domain registration
protocols), but they are very smart folks as far as dns goes as well.

It is true that on this list, I'm probably the only person who ever had
to implement dns protocol on lower level (i.e. writing dns resolver) and
the number of people who acually did it is remarkebaly low (couple hundred at most eventhough lots of people are using dns in general or doing administration) and that makes me closest you go to dns expect eventhough I'm not really and have not been involved in dns protocol design.

And if you don't know I was also very very actively against (almost the
only one here) adding support zone-wildcarding in spf-classic-00 draft
and unfortunetly Wayne did not listen to me then and the issue had to be taken to namedroppers and after fury of comments there is now going to
be removed from -01 draft. Hopefully next time, my word on this subject
could have more weight. I also continue to be against having SPF records directly at the domain root (but I was not involved in original decision about it made on this list, it was before my participation here which started about time of MARID) and have proposed doing it SRV style as "_smtp._tcp.example.com. IN SPF ..." but it is way way too late to change it now.

I still wish someone could explain the fundamental benefits of wildcards. The best I have so far is that some admins feel a need to "hide" the names of their MX hosts from the outside world. Does that help avoid a DoS attack or something? I'm still talking with the DNS expert offline.

This is not a right place to ask about it. DNS lists, like bind-users or dnsop are. As I told you various people use it for various staff and
its not all the same.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net


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