On Wed, 15 Sep 2004, Tony Finch wrote:
On Wed, 15 Sep 2004, william(at)elan.net wrote:
There are also some issues with RFC2317 (which is in my opinion just a
bad RFC that instead of proposing to do futher reverse subdelegation
with NS, tried to get by with CNAMEs - bad, that means it will only work
for PTR records and not anything else that might be in in-addr).
What makes you think that? To extend an example from RFC 2317:
1. Answering as to why I think RFC2317 is bad will take quite a number of
bits and is probably absolutely off-topic to this list. If you're
interested I'll answer answer in private.
2. RFC2317 may well be depreciated in the future and replaced with DNAME
for dns forwarding of reverse dns zones. RFC2317 style delegation is
not widely used today anyway.
3. The CNAME from PTR did not work on some of the servers I have.
The problem is resolevers and not strictly standard, it appear some
resolvers will simply not do query on txt when asked about ip address -
but you can still force it manually by asking txt on
reverse-ip.in-addr.arpa. Its not a big deal.
4. The point I made back is no longer important because, by May 04,
I came up with idea to not bother putting TXT records directly
in IN-ADDR zone but to put them in forward zone of PTR dns name
pointed from IN-ADDR zone (see example later in this post):
That works much better as far as deployment is concerned:
1. Most mail servers already look up PTR name of incoming client
2. If there is no PTR name, why bother asking for TXT
3. ISPs are relactant to give its customers access to INADDR and
most ISPs are unwilling to do redeligation like RFC2317 suggests
(I can explain why, but it would take quite a bit of text).
But at the same time ISPs are usually willing to set inaddr to
to dns names that their dedicated-level customers want; once
this is done customer has full control of what to enter for
mail policy record (like SPF) and does not need to bother
contacting ISP if he needs to make changes to the policy.
4. For many mail servers, reverse dns points to the correct forward
name of the mail server which is very often also used for EHLO
As such for many systems, one policy record can cover both
EHLO and PTR scopes
For reference here is example of how PTR record can be entered:
$ORIGIN 2.0.192.in-addr.arpa.
1 PTR mail1.example.com.
$ORIGIN example.com.
mail1 CNAME "v=spf1 ptr -all"
mail1 CNAME "SPF2.0/PTR ptr -all"
mail1 A 192.0.2.1
The CNAME refers to the whole RR set, not any particular RR type.
In fact strictly speaking you're not supposed to be able to enter any
other type of dns record for host if you enter CNAME there.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/