spf-discuss
[Top] [All Lists]

virtual domains and TXT records; TXT labeling; TLS versus SPF

2004-05-14 01:30:47
bind 8 and 9 limit TXT data to 2KB. In fact my bind seems to barf at the older 256-byte limit. My main mailer serves some 316 FQ hosts. There is no way to fit all these in one TXT record.

First, "include:" should be shortened to "i:" as for "a:" to save space. But consecutive TXT records can't be used (or at least queried) for a host, and even with just "i:"
the TXT record can't list the domains the mailer might serve. What to do?

If for a given virtual(ly served) host foo.com I listed in its TXT record the server it uses for outbound, that works because I only have to modify all few hundred zone files,
but TXT records don't get overloaded.

Say I have a virtually-served domain "frog.com" and the server that handles its inbound
and outbound mail is "mail.green.com".
I don't get the distinction between

frog.com.   IN   TXT   "v=spf1 a ~all"
and
mail.green.com.   IN   TXT   "v=spf1 a mx include:frog.com ~all"

and, as I understand it, I need both anyway.

*****

I notice one other counterintuitive thing - evidently bind requires an explicit label on TXT records, and does Not inherit the most recent explicit label, as would happen for A and other records.

frog.com.    IN   SOA
                  IN   MX   mail.green.com.   (inherits frog.com.)
                  IN   A      1.2.3.4                  (inherits frog.com.)
                  IN   TXT   "v=spf1 a ~all"   ?? doesn't inherit anything

the TXT record is not served in this case; explicit
frog.com.   IN   TXT   "v=spf1 a ~all"
is required. This is a minor nuisance because I think the label on the TXT record /will/ be inherited, so one has to take care that the label is re-overridden by name or with $ORIGIN, depending what
else is going on in the zone file.

*****

In the course of all time it makes more sense for a server to authenticate itself to any peer. That is, if I'm running SSL/TLS I can make my users authenticate themselves or let them authenticate me; but what is needed is for mx1.aol.com to prove to my server that it is in fact mx1.aol.com, by the same mechanism, and then DNS fiddling is not required, and this can be done more naturally than
introducing a separate, foreign protocol.


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