Those are in the same universe as a naming standard for dynamically
assigned IP addresses, but not the same thing. I think a dynamic-IP
RDNS naming standard would be a positive thing. It wouldn't
necessarily cure anything, but a reasonable BCP recommendation for
this would encourage providers to adhere to a well-known naming system
for this one specific thing rather than everyone coming up with
something different; and this practice would help others (such
as filter users).
I think the string needs to be a little more formally specified than
just including the substring "dynamic" though-- that's too much of a
common word. If it specifically matched the IP number in some way,
the name could be tested against the IP number to give an assurance
that one has found a self-declared dynamic IP address. e.g., something
like: for any IPv4 IP address canonically represented by a.b.c.d, the
leftmost part of the RDNS name shall match the string "a-b-c-d-dynamic."
Actually I've been thinking about this for a while as well as testing
various forms and records in rdns. Take a look the following idea given
in example manner:
------------------------------------
$ nslookup -query=ANY -silent 216.151.192.3
3.192.151.216.in-addr.arpa name = rdns1.elan.net.
3.192.151.216.in-addr.arpa name =
_smtp._tcp._sir.maintest.192.151.216.in-addr.arpa.
$ nslookup -query=ANY -silent _smtp._tcp._sir.maintest.192.151.216.in-addr.arpa.
Name: _smtp._sir.maintest.192.151.216.in-addr.arpa
Address: 127.0.0.2
_smtp._tcp._sir.maintest.192.151.216.in-addr.arpa text = "v=spf1 -all"
------------------------------------
In this case the idea is to specify additional dns pointer record (but not
primary one - there are very good reasons why ISP may want to use its own
specific naming convention for its reverse ips, its bad idea to specially
say you must name it that way) in a special way. I preliminary called it
"service information record pointer" which provides pointer on where
additional information maybe obtained regarding outgoing service
connections that may (or may not) be expected from that ip. That service
maybe provided by SRV or similar future protocol or maybe through some
form of dns authorization protocol (SPF is used in my example).
Additionally specific meaning is given to "A" record for such PTR record
which may be 127.0.0.1 meaning such connections are to be expected from
that ip (which is default) or 127.0.0.2 which indicates that ip would
not make outgoing connections like that and if you see it, you can safely
deny it (i.e. expect that either ip is not authorized to do what it does
or that the actual ip packet is forged, though this might have more meaning
for udp services).
Now the good thing about this is that doing it as above requires 0 changes
to network infrastracture and pretty easy to implement at the SMTP server
level to check for such records and connections can be rejected before SMTP
session even starts, it does however require additional dns lookup (i.e.
when you see a pointer with _sir, it thereafter must be resolved).
Another option I played around with is here:
--------------
$ nslookup -query=ANY -silent 2.192.151.216.in-addr.arpa.
2.192.151.216.in-addr.arpa name = unix.elan.net.
2.192.151.216.in-addr.arpa text = "v=spf1 ptr -all"
Name: 2.192.151.216.in-addr.arpa
Address: 127.0.0.5
--------------
In this case TXT and A records are entered directly in addition to PTR to
specific IN-ADDR record. The good thing about this is that it requires
no additional dns lookups since doing query on "ANY" record will provide
all of it and many mail servers already do lookup on PTR record of
incoming ip address. However at the same time it can be noted that ANY
lookup for in-addr is unusual and most dns resolver libraries would
interpret lookup on ip address (i.e. 216.151.192.2 in this example) as
lookup of PTR on in-addr of that ip address:
--------------
$ nslookup -query=ANY -silent 216.151.192.2
Server: 216.151.192.1
Address: 216.151.192.1#53
2.192.151.216.in-addr.arpa name = unix.elan.net.
--------------
Such interpretation means additional records (TXT and A) would not be
checked and mail servers must be modified to do its own conversion of ip
address into inaddr form for lookup. It also means quite a number of
basicly the same kind of records may have to be entered as you can't
provide cname redirection, which btw also breaks RFC2317 (not that I
support this badly thought of RFC). But at the same time, the PRO to this
direct approach is that there no necessity to do extra dns lookup
(but as people from SPF community will tell you, dns lookups are "cheap",
spf seems to be designed to cause dozen of extra lookups in some cases)
Anyway I'm the point that I actually started working on draft on the first
PTR procedure (very slow so far, this has been low priority among many
research and public projects I get involved in). I guess I'm asking to
know if you think this is actually worth doing because there seems to be
so little support for MTA-MARK like proposals from anti-spam and marid
community which contines to be focused on rmx and dmp methods.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg