There are people (even in IETF DNSOP) that think revDNS is obsolete
and if not for IPv4 it will be at least for IPv6 ;-)
If there is a value it can be implemented. Given the rate of IPv6 progress I
would not worry overmuch about it at this point, the principal of mapping
addresses still holds, the difference is that you probably use a lot of
wildcards and possibly even synthesized responses.
Currently we tend to a more structured approach like
_perm._smtp._tcp.8.0.30.195.in-addr.arpa IN TXT "1"
_perm._smtp._tcp.1.0.30.195.in-addr.arpa IN TXT "0"
or like
_smtp._tcp.8.0.30.195.in-addr.arpa IN PERM 1
_smtp._tcp.1.0.30.195.in-addr.arpa IN PERM 0
I would suggest that what is going on here is that you have a lookup
application and that should be your primary key. Within the lookup
application you have a specific protocol, transport and port. Then there is
information about the lookup.
This suggests to me that the ordering should be something like
_perm.8.0.30.195.in-addr.arp The permission
application
_xxx.8.0.30.195.in-addr.arp Some other
application
_smtp._tcp._perm.8.0.30.195.in-addr.arp Permission data relating to
smtp
Now one issue to consider here is that we are talking about a reverse
lookup. I do not think that the _smtp._tcp labelling is necessarily the
right one. It is right for SRV which goes in the forward direction and could
involve port swapping.
I think that our application is the reverse, we receive a stimulus on an IP
address, Port, Protocol tuple and want to look it up
_80._tcp._perm.8.0.30.195.in-addr.arp Permission data for TCP port
80
*._perm.8.0.30.195.in-addr.arp Permission data for all
protocols
OK that is the search term, lets look at the right hand side.
I dislike the binary approach suggested. The types of applications I am
concerned about go beyond spam, I am also concerned about attacks on my root
servers.
I would want to be able to include contact information into the reverse DNS
to be able to perform remediation. So an ISP can add into the rDNS a NAPTR
pointer to its contact desk. That looks like a different application.
From the spam side I would like to be able to broaden the problem. I do not
want to express permission, I want to describe the port and address. If it
is a question of Permission it should be enforced at the router. What we are
talking about here is DESCRIPtion.
_80._tcp._descrip.8.0.30.195.in-addr.arp ? "TBS"
My discussion with Mark Kosters on TXT versus new record type was somewhat
surprising. I mentioned TXT and got back the response, Oh thats OK that will
work.
This begs the question of the advantage of a new record type. The only
advantage in the DNS protocol is that a record type is a search term. But it
is already clear that we need additional search terms to be included here
and from a management point of view the _descrip term is pretty nice to
have. Go back to my hypothetical contact desk application. It is quite
likely I would want to be able to separate management of the two data sets
for the different applications by delegating to different resolvers. The
DESCRIPtion resolver might well be some synthetic resolver working on the
DHCP box. I can imaging my contact resolver being very different.
I would like to have more description terms and to be able to impose some
sort of taxonomy on them. It should be possible to combine search terms and
for new terms to be defined independently of the specification.
I see the search terms being expressed syntactically as a TXT record with a
string of XML QName like terms:
One A:Two B:Three
If a prefix is specified it is defined by means of a URI in the same manner
as XML namespaces. This may seem overly complex but DO NOT DISCOUNT
EXTENSIBILITY, my experience is that if a protocol is to remain simple and
relevant it should have the extension mechanism designed in. People always
attack the extension mechanisms, particularly if they are unconstrained and
do not involve a council of the great and the good handing out numbers like
IANA does.
The basic terms I think we need are:
NotAllocated The address has not been allocated by a
local registry
NotInService The address has been allocated but is not in
service
Prohibited The address is prohibited from using the speicifed
port
Restricted The address is associated with a restricted service
Annonymous The address is associated with annoynmous service,
beware.
Annonymous service is what I might provide to people who happened to be
passing by and needed some 802.11b service ex gracia.
Within Restricted and Annonymous I think there are some sub terms
Pooled The address is allocated on a pooled basis,
this would
usually correspond to a dial up modem
Fixed The address is allocated on a long term
basis so that
a single user is associated with the
connection
The point here is that there is no need to prohibit the use of Pooled or
Fixed restricted connections to send mail provided that the receiver is
warned and can take appropriate spam control measures.
Since these are mutually exclusive they can be tied to the master term,
something like Restricted.Pooled
A solution to that would be to make the RHS not a boolean but e.g.
a 64 bit integer and give it a meaning:
0 dont allow connections
1 allow unauthenticated connections (aka outgoing MTA)
2 allow only authenticated connections
3 allow only authenticated connections with ciphered passwords
The same could of course also be achieved with TXT records.
TXT is much more extensible. Even if we do not have namespaces.
One question raised today was:
Why is this useful at all? MTA MARK could also be accomplished much
more effective by a firewall rule.
This is IMHO a good and valid question ;-)
I would like to avoid closing down port 25 just because someone is working
from a mass market connection. What do we do when it is no longer possible
to get T1 connections to a house because the cable company has driven the
competition out? If a service
An answer might be that firewalls rules are expensive, the more rules
a firewall has to check the more expensive they get. So with large
networks MTA MARK (or a more generalized form) could be a alternative.
Firewall rules are a blunt instrument and encourage people to work arround.
If port 25 starts being shut down everywhere there are going to be a lot of
people setting up servers that accept email under submit - and many will end
up being open.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg