Salut, Kurt,
On Wed, 26 Mar 2008 15:03:40 +0100, Kurt A. Schumacher wrote:
What about the most stupid wanabe Spam-fighter which are very unhappy as in place (e.g. the third-party service provider systems acting with some SC subsidiaries...) which high rate valid messages if certain brain-dead conditions like PTR not matching MX don't match?
2 points about this.
1. it is highly unlikely that these stupid wannabe SPAM filters get the response containing so many PTR records right. It is most likely that either the software blows up or that it only ever considers the entry it receives first.
(Most likely the software blowing up will not even be remarked but instead the mail will be rejected silently.)
2. Since a lot of people use personalized domains now in their mail addresses (me@first.lastname.ch, bla@pascual.garnier.name, whatever), the people who use such a setup will be strongly discouraged very quickly and be forced to drop it, since they want to still be able to send mail, most likely. We should not make such stupid moves just to encourage them to adopt such a setup.
Under the line, it is likely not a DNS issue, but the inability by some mail or AS systems resolving lists. Suspect my servers will fail, too. Xaver, pls send private reply for a test from that system, anytime.
It is also a DNS issue, depending on the number of results returned; the size of a DNS/UDP response is limited to 1 UDP packet, which again is limited in size. Not everyone uses DNS over TCP, and it is unlikely to be adapted just because of such a stupid and useless SPAM filtering measure.
Tonnerre
On the Wed, Mar 26, 2008 at 02:42:36PM +0100, Tonnerre Lombard blubbered:
Hoi.
- it is highly unlikely that these stupid wannabe SPAM filters get the response containing so many PTR records right. It is most likely that either the software blows up or that it only ever considers the entry it receives first.
Most mailservers just check if there is a PTR record at all and if there is none, reject the mail with a 5xx DSN.
(Most likely the software blowing up will not even be remarked but instead the mail will be rejected silently.)
Clever spamfilters will just add another score point to the spam score and not just pass or discard a mail based on a single criteria.
Under the line, it is likely not a DNS issue, but the inability by some mail or AS systems resolving lists. Suspect my servers will fail, too. Xaver, pls send private reply for a test from that system, anytime.
It is also a DNS issue, depending on the number of results returned; the size of a DNS/UDP response is limited to 1 UDP packet, which again is limited in size. Not everyone uses DNS over TCP, and it is unlikely to be adapted just because of such a stupid and useless SPAM filtering measure.
While Xari's Setup with tons of PTR records is plain stupid. Xari, you should have a read about MX records. =:-)
But DNS uses UDP and TCP as I just checked. RFC 1035, Chapter 4.2 says: "The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal)."
CU, Venty
On Wed, Mar 26, 2008 at 06:42:57PM +0100, Martin Ebnoether wrote:
On the Wed, Mar 26, 2008 at 02:42:36PM +0100, Tonnerre Lombard blubbered:
...
It is also a DNS issue, depending on the number of results returned; the size of a DNS/UDP response is limited to 1 UDP packet, which again is limited in size. Not everyone uses DNS over TCP, and it is unlikely to be adapted just because of such a stupid and useless SPAM filtering measure.
While Xari's Setup with tons of PTR records is plain stupid. Xari, you should have a read about MX records. =:-)
But DNS uses UDP and TCP as I just checked. RFC 1035, Chapter 4.2 says: "The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal)."
Until recently only AXFR was using tcp, normaly resolver queries had to be udp. This rule was a bit relaxed because of the increased space needed for IPv6 but many authorative dns servers will only listen to UDP port 53 requests..
Claudio Jeker writes:
Until recently only AXFR was using tcp,
If you look at the original DNS specs, i.e. RFC 1035, RFC 1123, etc, you will find that the protocol always specified that any DNS queries can be performed over TCP. In particular, this is the normal fallback method when a query over UDP results in a truncated (TC) response.
Actually, in the olden days there were even resolver implementations that *only* supported TCP for DNS queries, cf. http://www.ops.ietf.org/lists/namedroppers/namedroppers.199x/msg01855.html (I'm not saying this was a good idea :-)
Then people stopped listening to Jon Postel's (may he rest in peace) advice to "be liberal in what you expect, conservative in what you send". Instead, concerns of "security" and short-term optimization and punishing people with "stupid" (= unexpected) configurations became more important. So IT people and their consultants and ISPs started to block DNS over TCP in many places, often leaving it open only for zone transfers, and felt good about it. Thus the new (you call it old, maybe I'm just an old fart) "rule" was born:
normaly resolver queries had to be udp.
Some people tried to evolve the DNS to carry other information, such as IPv6 addresses, digital signatures (actually meta-information to make DNS information more trustable), mail policy information. And some zones (such as the root) wanted to have many nameservers for robustness.
So suddenly, the 512 byte (yes, 512 bytes!) limit became a real issue, as fallback to TCP would very often just Not Work.
This rule was a bit relaxed because of the increased space needed for IPv6 but many authorative dns servers will only listen to UDP port 53 requests..
I would say, the "new rule" ("if you use TCP for DNS queries other than AXFRs, then you are stupid/up to no good, so I will block you") proved to harm the long-term evolution of the DNS protocol - as is quite often the case with these kinds of "security best practices" that violate transparency and other design principles. But since such rules are/were "best practices", you can never really get rid of them.
So what happened instead is that the DNS protocol was extended to support larger-than-512-byte queries over UDP (EDNS0, RFC 2671). While "dig" doesn't use EDNS0 by default (but see the example below), modern recursive nameservers should normally make use of this, so that fallback to TCP isn't necessary that often.
The fact that EDNS0 was added to the DNS is probably a good thing. But I think it would also be good if DNS over TCP generally worked. Although TCP does have higher overhead than UDP for typical DNS usage, it has some security advantage, e.g. it is much harder to spoof requests.
So to me this is another example of short-sighted and badly thought-out "security" thinking that has harmed progress and brought dubious security improvements at best.
Note that some people consider EDNS0 a security risk, because it facilitates "reflection" attacks with UDP DNS requests from spoofed (victim) source addresses that result in very large responses to be sent to the victim.
-
Claudio Jeker -
Martin Ebnoether -
Simon Leinen -
Tonnerre Lombard