spf-discuss
[Top] [All Lists]

Re: DNS RRtypes: changing PI

2003-10-18 21:06:33
Synopsis:
1) Yes, keep the underscore domain
2) No, don't put records in the in-addr.arpa. reverse DNS domain

Details (probably too many...):
---
First: I'm indifferent to the underscore, but I like the extra subdomain part, "_smtp_client". This allows the information for this whole protocol to be neatly tucked away.

I think DNS TXT records should be used for all sorts of things, but if so, and no one put things under subdomains, then we'd have several problems: 1) any service that needs to fetch something out of TXT records for the domain is going to get records for all the other protocols that use it too - I realize that caching will mitigate the net load, but each server is going to get all those records on each query and have to sift through them. 2) there is no agreed upon standard for ensuring TXT record formats are siftable - will every future TXT format for other protocols start with "v=foobar3"? Who is doling out the identifiers?

I vote for putting ALL SPF records under a subdomain. "_smtp_client" is just fine with me, and isn't very likely to collide with anyone's existing DNS architecture. Of course "smtp_client" is also okay with me, with just a wee bit more chance of collision. Worrying about the aesthetics of the underscore (yes, I think they're ugly, yes they are a bit harder to type), is really minor compared to the two issues above.

In fact, I don't like the current write-up where the main SPF record goes directory with the domain name. I like the version that was in an earlier write up: policy._smtp_client.mydomain.com. This neatly puts all the SPF records under one nice sub-domain.

Question: Why '_smtp_client'?  Why not '_spf' ?
---
Second, please DO NOT require a domain to put records in it's reverse DNS domain. While I have control over my reverse DNS domain (even though I'm on a CIDR sub-net), many many many domains either can't or won't edit the reverse DNS. I know this from experience: One of the best SPAM filters we use is simply refusing to accept mail from machines that don't have proper reverse DNS. However, there are plenty of legit mail hosts that don't and I have to put in a few exceptions to our filter every month. I used to write to all these sys admins and explain that their reverse DNS is wrong or missing, and reference the relevant RFCs, etc.... generally to no avail - the vast majority of the time, the upstream ISP wouldn't let them edit the reverse DNS! Yes, I've heard stories of ISPs that won't delegate even whole C blocks, and most ISPs are just too clueless to due reverse DNS for CIDR blocks.

There is a second, though fading reason not use the in-addr.arpa. domain for anything: To this day, at least one resolver in the GNU libraries (there are several) is broken with respect to CNAME records in in-addr.arpa. Alas, this resolver (the DNS resolver that part the nsswitch resolver library), is the default resolver in many Linux distributions. (Yes, I submitted detailed bug information about this to the development team in 1997! - I just found my posting to comp.os.linux.networking - thank you Google!) This resolver can't handle CNAME records during a PTR query - and therefore these machines can't handle CIDR networks with reverse IP.

        - Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
markl(_at_)glyphic(_dot_)com

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡


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