On Sat, 4 Dec 2004, Henning Brauer wrote:
So if I want to check on 127.1.2.3, I first do lookup on _srv.3.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.2.1.127.IN-ADDR.ARPA if that does not give any answer, I'll have to do lookup on _srv.1.127.IN-ADDR.ARPA And if that does not work, I still have to do lookup on _srv.127.IN-ADDR.ARPA
that is how it works.
Is that how you expect it to work? If that is so, I do not like it because it forces to do these multiple lookups.
these lookups are cheap, and with increasing deployment I expect the the vast majority of lookups to have matches on /32 (1st query) or /24 (2nd query).
The problem is going to be for early adaptors - they have to do all 4 lookups because at the time nobody would have these records. There are also problems because sometimes in-addr tree deligation is not properly setup and lookups on it time out (and you have to wait for timeout for each of those lookups).
but anyway, these lookups are reasonably cheap.
There are some here who may disagree if they see this deployed (like say ARIN and other RIRs...) ---------------------------------------------------------------------- Earlier this year I proposed different way of doing above, which maybe better. It involves not checking directly in in-addr tree but instead checking SPF (or some other policy) record on the dns PTR name. So if somebody does not offer proper IN-ADDR support, there is no record there and we need not bother doing this check (and checking just PTR for SMTP connection is going to happen anyway). If PTR record does exist then that is checked and it may then specify that ip can or can not be an SMTP client. Now if somebody needs to enter this record for whole bunch of ips that are not in use (for example 127.1.2.0/24), they can do something like this: *.2.1.127.in-addr.arpa. IN PTR nomail.example.com. nomail.example.com. IN SRV TXT "v=spf1 -all" nomail.example.com. IN A 127.0.0.2 If they have legitimate mail server, the they would likely be wise to enter SPF1 record for such hostname anyway, so nothing new there. The somewhat troublesome situation is when this is a dialup/dsl ISP which has bunch of ips and they actually set each one of them in reverse, i.e. 1.2.1.127.in-addr.arpa. IN PTR dsl-127-1-2-1.example.com. 2.2.1.127.in-addr.arpa. IN PTR dsl-127-1-2-2.example.com. 3.2.1.127.in-addr.arpa. IN PTR dsl-127-1-2-3.example.com. ... And if they have properly setup dns (or otherwise their customers will begin to complain that they can't use irc :), they would also have: dsl-127-1-2-1.example.com. IN A 127.1.2.1 dsl-127-1-2-2.example.com. IN A 127.1.2.2 dsl-127-1-2-3.example.com. IN A 127.1.2.3 .... Now this does mean that you no have to enter an extra record for each one of these and as there is no way to do it with wildcards: dsl-127-1-2-1.example.com. IN A 127.1.2.1 dsl-127-1-2-1.example.com. IN TXT "v=spf1 -all" dsl-127-1-2-2.example.com. IN A 127.1.2.2 dsl-127-1-2-2.example.com. IN TXT "v=spf1 -all" dsl-127-1-2-3.example.com. IN A 127.1.2.3 dsl-127-1-2-3.example.com. IN TXT "v=spf1 -all" ... But I suspect that for most ISPs such dial/dsl zones are not generated by hand, but by some script and modifying such script to add such extra record is not a big deal. P.S. Instead of doing SPF another possibility is to use SRV, i.e. dsl-127-1-2-3.example.com. IN A 127.1.2.3 _client._smtp._tcp.dsl-127-1-2-3.example.com. IN SRV 0 0 0 . --- William Leibzon Elan Networks william@elan.net