On Wed, 29 Sep 2004, Greg Connor wrote:
Hello all. Some of this is review from older stuff on this list and on
MARID, but there's nothing really wrong with that. Here's my 2 cents :)
The prefixing supporters were pretty vocal on MARID but in the end the
group consensus was to not use them.
Decisions on consensus done at MARID were not so much reflecting the
overall consensus of the group as they were the discussions done in
private by chairs with main participants ... See
http://www.imc.org/ietf-mxcomp/mail-archive/msg05138.html
(be prepared to read between the lines in above answer by WG Chair)
There were just about equal number of people who were for and against
prefix at MARID and majority of those against prefix were doing it
because their DNS web interface can not handle "_" and this is really
not a very strong argument against prefixes.
Prefixing is a cheap way to reuse TXT records without conflicting with
the other more legitimate uses of TXT.
Correct.
But, I didn't like it for a few reasons.
1. There aren't really any "more legitimate" uses of TXT.
That is the point of TXT - to be a extra text commentary record. We dont
expect comment fields to have "legitimate use".
SPF is currently the #1 consumer of TXT records and other uses pale in
comparison. TXT was originally defined as a place for human-readable
text, but no real applications other than SPF have emerged.
Doesn't mean it will not especially after SPF gave such a bad example...
2. If the eventual goal is to get an IN SPF type allocated for us, that
negates the need for a prefix.
No it does not. I actually think SPF has possiblity of use beyond that of
email (for things like instant messaging and possibly for other protocols)
and that it makes sense to use convention similar to SRV records to
distinguish between different protocol uses including right now.
If we go with no-prefix TXT, there's less
conversion work and confusion later... the records will just work
the same and the name we look up is the same.
That is appropriate remark as far as keeping things compatible between
SPF classic and SPF2.0. Again this all depends on if we want to keep
things compatible and if record syntax allows for it, etc.
3. Underscore is legal for domain names but not host names (A records).
So they are fair game, and they have the clever feature of never
conflicting with existing host names. But, the underscore tends to throw
people because people are used to underscore being illegal. Some people
still have old DNS servers that think underscore is illegal and won't let
them load the zone file.
These old dns servers are all likely to be vulnerable to buffer overflow
attacks. They are seriously better off upgrading them ASAP.
4. Wildcards. Prefixing doesn't really conflict with wildcards, it's
just that they each sort of cancel out the gains of the other. Wildcards
let you cover large areas with the same data (splat a value for any name
that people can come up with), while prefixes let you be more specific and
separate (fine-tune which TXT records to give out in which situation). If
you really need wildcards, you can use them, and the answer will be the
same for x.com and _spf.x.com.
That is mostly correctly, however I previously did show that use of
prefixes make it possible to have the same record for x.com and *.x.com
in one line in DNS zone file instead of two, i.e. instead of
*.x.com. IN SPF "v=spf1 mx -all"
x.com. IN SPF "v=spf1 mx -all"
With default on prefix lookup, its enough to just have:
*.x.com. IN SPF "v=spf1 mx -all"
Wildcards don't really do what most people want anyway... if you have www
IN A 10.2.3.4 and * IN TXT "blah" then the * doesn't return any TXT for
www, and you still have to have TXT for any A or MX records you have.
Really all a wildcard TXT is good for is if you already have a wildcard A
or MX ;)
Correct. But that does not mean there is no legitimate use of wildcards.
5. System Admins are grownups.
Ahhhh... I have to disagree with you here. Having done dedicated servers
for various customers for a while, I can tell you that many of them are
not grownups at all (some are literally 14 years old, although they'll try
to hide it...). Its just so tiresome to have to explain to them what they
did wrong or having to fix their dns records...
If a site really wants to publish both
SPF TXT records and some other kind of TXT, that site can easily take
responsibility for making sure the combined answer is small enough to be
served correctly. Requiring a prefix makes more work for everyone, while
requiring people who have conflicting TXT records to work it out on their
own somehow makes more work only for them, and acceptable workarounds do
exist. Most SPF records are small enough to share space in the packet with
other TXT records, so SPF is not really consuming all of a scarce resource.
Why do I continue to hear MOST? Doesnt it seem like that if we do have a
even a few that will not be complaint and solution that will make such
problem disappear that it makes sense to use the solution?
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net