On Tue, Dec 02, 2003 at 05:36:40PM -0500, Yakov Shafranovich wrote:
Putting things in the reverse map has both advantages and disadvantages.
I used for a while ISP that marked their whole IP range as spam source,
and at the same time refusing to forward email that did not conform
to <user>@<isp>.net. So I do not trust ISP's to do the right thing
and most of them do not have egress filtering thus allowing spoofed
packets to leave their networks.
There is a contract bewteen an ISP and a customer. The contract
regulates rights and liabilities of both parties. If the ISP does
not conform to the contract one can terminate it at any time and
probably even sue the ISP for breach of a contract. This is nothing
that is related to trust. With the same arguments you could say HTTP
is bad, because the ISP does transparent proxy and they probably modify
the contents of the web pages.
If an ISP has a contract that clearly says: "you are not allowed to offer
services, this is a surf account only" they might as well block incoming
ports like smtp, http, ... they don't need to use something like MTA MARK.
TXT records are fine for experimentation a new record type is
the way to go if this is good approach but the cost of
backwards compatibility is high.
The argument that it is expensive to upgrade to a new type are
historic, most modern DNS software can handle unknown types [RFC3597].
RFC3597 was released Spetember 2003.
With up to 5% of installations running even bind-4.x how long do you
think it will take for rfc3597 to propagate? Even modern BIND servers
didn't get it right. How about DNS proxies in firewalls, stub resolvers, ...
While I agree that a new query type should be the way to go, it still is
expensive, even with RFC3597. And the IETF is sometimes sloooow. Spam is
hitting hard each day and we want a solution ASAP and not in some years
when all have approved the new QTYPE.
Many people have raised concerns about the fact that things like this
should not be present in the rDNS zone at all. I wanted to get your
feedback on that issue and the draft in general.
This is a issue that should be discussed in DNSOPS but my feeling
is reverse tree should be used better and this is as a good place as
any other for capability of a host.
There are people (even in IETF DNSOP) that think revDNS is obsolete
and if not for IPv4 it will be at least for IPv6 ;-)
The draft example seems to suffer from a common misunderstanding
that wildcard will match an existing name in a zone if the type
does not exist, this is false see:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-02.txt
We are/were aware of that. The warning about wildcards not being applied
to subdomains should probably be extended with a notice about that.
--------------------------------
Today I had a very valuable talk with Arnt Gulbrandsen who made some
good comments and suggestions.
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
The LHS used is derived from the hierarchy defined for SRV records
and is well defined. For TXT records the "_perm" is necessary to define
an object that is queried, aka a "question". If there is a special
QTYPE like PERM this is not needed. The IESG doesn't like non questions ;-)
It would also be possible to use another level of subdomains like
_send._smtp._tcp.8.0.30.195.in-addr.arpa IN PERM 1
as this provides more flexibility and could be extended to
_send._smtp._tcp.8.0.30.195.in-addr.arpa IN PERM 0
_send-crammd5._smtp._tcp.8.0.30.195.in-addr.arpa IN PERM 1
to indicate that one should allow only authenticated connections.
This could be used to transport company policies like "from this (sub-)net
accept only connections with ciphered passwords. we don't want that our
employees use plaintext passwords accross the Internet".
The drawback is that it uses a lot of DNS bandwidth and the server has
to do a lot of queries for all possible "options".
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.
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 ;-)
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.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg