Rant about DNS and TCP [was: Re: [swinog] Has Bluewin a DNS Problem]
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. -- Simon. $ dig @www.multipop.ch. +edns=0 ptr -x 195.141.232.78 ; DiG 9.5.0a6 @www.multipop.ch. +edns=0 ptr -x 195.141.232.78 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 895 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 30, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;78.232.141.195.in-addr.arpa. IN PTR ;; ANSWER SECTION: 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.spacebbs.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.amigaland.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.augsauger.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.begegnung.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satvision.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.hackernews.ch.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.natel-news.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satanlagen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.satantennen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.wiso-schoch.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.xariffusion.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.sat-receiver.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.estherundpetr.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.luisenstrasse.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.arthurandersen.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.elektronik-news.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.zuerichsee-gastro.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.pop.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.rtv.ch. 78.232.141.195.in-addr.arpa. 38400 IN PTR mailhost.dsng.ch.
Re: [swinog] Has Bluewin a DNS Problem
Hi Xaver, I had a similar problem when I set up the mail server on my virtual server and wanted to send mail to domains that are hosted by zoneedit.com. After searching a while, I think this is the way how it works: Step 1: == Bluewin does a reverse DNS lookup on your IP (195.141.232.78), which returns the following: # nslookup 195.141.232.78 ;; Truncated, retrying in TCP mode. Server: www.multipop.ch. Address:195.141.232.253#53 78.232.141.195.in-addr.arpa name = mailhost.aa795.ch. 78.232.141.195.in-addr.arpa name = mailhost.aerni.net. 78.232.141.195.in-addr.arpa name = mailhost.bar16.ch. 78.232.141.195.in-addr.arpa name = mailhost.sysop.ch. 78.232.141.195.in-addr.arpa name = mailhost.zingg.org. 78.232.141.195.in-addr.arpa name = mailhost.satshop.cc. 78.232.141.195.in-addr.arpa name = mailhost.aquacare.ch. 78.232.141.195.in-addr.arpa name = mailhost.glaettli.cc. 78.232.141.195.in-addr.arpa name = mailhost.multipop.ch. 78.232.141.195.in-addr.arpa name = mailhost.satshops.ch. 78.232.141.195.in-addr.arpa name = mailhost.spacebbs.ch. 78.232.141.195.in-addr.arpa name = mailhost.amigaland.ch. 78.232.141.195.in-addr.arpa name = mailhost.augsauger.ch. 78.232.141.195.in-addr.arpa name = mailhost.begegnung.ch. 78.232.141.195.in-addr.arpa name = mailhost.satvision.ch. 78.232.141.195.in-addr.arpa name = mailhost.hackernews.ch.ch. 78.232.141.195.in-addr.arpa name = mailhost.natel-news.ch. 78.232.141.195.in-addr.arpa name = mailhost.satanlagen.ch. 78.232.141.195.in-addr.arpa name = mailhost.satantennen.ch. 78.232.141.195.in-addr.arpa name = mailhost.wiso-schoch.ch. 78.232.141.195.in-addr.arpa name = mailhost.xariffusion.ch. 78.232.141.195.in-addr.arpa name = mailhost.sat-receiver.ch. 78.232.141.195.in-addr.arpa name = mailhost.estherundpetr.ch. 78.232.141.195.in-addr.arpa name = mailhost.luisenstrasse.ch. 78.232.141.195.in-addr.arpa name = mailhost.arthurandersen.ch. 78.232.141.195.in-addr.arpa name = mailhost.elektronik-news.ch. 78.232.141.195.in-addr.arpa name = mailhost.zuerichsee-gastro.ch. 78.232.141.195.in-addr.arpa name = mailhost.pop.ch. 78.232.141.195.in-addr.arpa name = mailhost.rtv.ch. 78.232.141.195.in-addr.arpa name = mailhost.dsng.ch. Step 2: == Bluewin does a normal forward DNS lookup, using the result from the above query. The forward (A) query has to match your IP address, otherwise Bluewin will complain about the PTR record. However, the above query returned more than one value, so I am not sure which host is used for the lookup - I guess that just the first host is taken. Since the order is random, you cannot say anything reliable about which host will be used for the lookup. Maybe it even fails directly if the response is not unique - I don't know. When I tried the lookup the first time, mailhost.aquacare.ch was used for the query. However, mailhost.aquacare.ch does not exist (even the domain does not exist), so the lookup fails and rightly so Bluewin complains about your PTR record. I think the purpose of this reverse and forward DNS lookup procedure is to prevent spam, since most spam comes from hacked machines (mostly from dynamic IP address ranges) which do not have correct PTR records - just as it is the case with your machine ;-) Gruass, Franco Adrian Ulrich wrote: Good Morning, Is your source ip 195.141.232.78 ? Regards, Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog Xaver Aerni wrote: Our System receive ex. This MSG The original message was received at Tue, 25 Mar 2008 16:20:47 +0100 from localhost [127.0.0.1] - Transcript of session follows - ... while talking to mxbw.bluewin.ch.: 451 No thanks. (How about PTR records?) ... while talking to mxzhh.bluewin.ch.: QUIT 451 No thanks. (How about PTR records?) ... while talking to mxzhb.bluewin.ch.: QUIT 451 No thanks. (How about PTR records?) [EMAIL PROTECTED]... Deferred: 451 No thanks. (How about PTR records?) Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old ** Xaver Aerni Zürichstrasse 10a 8340 Hinwil Tel. 001 707 361 68 39 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
Hi, Bluewin does a reverse DNS lookup on your IP (195.141.232.78), ..yes Bluewin does a normal forward DNS lookup, using the result from the above query. we don't. The resolver implementation of our MTA software appears to have a problem with truncated UDP responses. (Btw: Why do you have such a lenghty PTR record for 195.141.232.78 ?) I'm about to implement a workaround for this issue. Regards, Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
Franco Hug wrote: Step 1: == Bluewin does a reverse DNS lookup on your IP (195.141.232.78), which returns the following: # nslookup 195.141.232.78 ;; Truncated, retrying in TCP mode. Server: www.multipop.ch. Address:195.141.232.253#53 78.232.141.195.in-addr.arpa name = mailhost.aa795.ch. 78.232.141.195.in-addr.arpa name = mailhost.aerni.net. plus another 20 hosts This is a silly reverse setup. A reverse lookup should only return one hostname, not 20. /Per Jessen, Herrliberg ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
RE: [swinog] Has Bluewin a DNS Problem
Step 1: == Bluewin does a reverse DNS lookup on your IP (195.141.232.78), which returns the following: # nslookup 195.141.232.78 ;; Truncated, retrying in TCP mode. Server: www.multipop.ch. Address:195.141.232.253#53 78.232.141.195.in-addr.arpa name = mailhost.aa795.ch. 78.232.141.195.in-addr.arpa name = mailhost.aerni.net. plus another 20 hosts This is a silly reverse setup. A reverse lookup should only return one hostname, not 20. /Per Jessen, Herrliberg Yes, I agree. This is really a bad design and has nothing to do with DNS problems on the bluewin side, even if the bluewin DNS might have troubles resolving truncated requests, IMHO. Cheers, Florian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
The Problem is we have on this IP 30 Domains... When I must have for everery Domain an IP for the reverse of Bluewin is a big Problem... I must have in future an A Net... I think Bluewin must fix this. Greetings X. Aerni - Original Message - From: Franco Hug [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 26, 2008 1:29 PM Subject: Re: [swinog] Has Bluewin a DNS Problem Hi Xaver, I had a similar problem when I set up the mail server on my virtual server and wanted to send mail to domains that are hosted by zoneedit.com. After searching a while, I think this is the way how it works: Step 1: == Bluewin does a reverse DNS lookup on your IP (195.141.232.78), which returns the following: # nslookup 195.141.232.78 ;; Truncated, retrying in TCP mode. Server: www.multipop.ch. Address:195.141.232.253#53 78.232.141.195.in-addr.arpa name = mailhost.aa795.ch. 78.232.141.195.in-addr.arpa name = mailhost.aerni.net. 78.232.141.195.in-addr.arpa name = mailhost.bar16.ch. 78.232.141.195.in-addr.arpa name = mailhost.sysop.ch. 78.232.141.195.in-addr.arpa name = mailhost.zingg.org. 78.232.141.195.in-addr.arpa name = mailhost.satshop.cc. 78.232.141.195.in-addr.arpa name = mailhost.aquacare.ch. 78.232.141.195.in-addr.arpa name = mailhost.glaettli.cc. 78.232.141.195.in-addr.arpa name = mailhost.multipop.ch. 78.232.141.195.in-addr.arpa name = mailhost.satshops.ch. 78.232.141.195.in-addr.arpa name = mailhost.spacebbs.ch. 78.232.141.195.in-addr.arpa name = mailhost.amigaland.ch. 78.232.141.195.in-addr.arpa name = mailhost.augsauger.ch. 78.232.141.195.in-addr.arpa name = mailhost.begegnung.ch. 78.232.141.195.in-addr.arpa name = mailhost.satvision.ch. 78.232.141.195.in-addr.arpa name = mailhost.hackernews.ch.ch. 78.232.141.195.in-addr.arpa name = mailhost.natel-news.ch. 78.232.141.195.in-addr.arpa name = mailhost.satanlagen.ch. 78.232.141.195.in-addr.arpa name = mailhost.satantennen.ch. 78.232.141.195.in-addr.arpa name = mailhost.wiso-schoch.ch. 78.232.141.195.in-addr.arpa name = mailhost.xariffusion.ch. 78.232.141.195.in-addr.arpa name = mailhost.sat-receiver.ch. 78.232.141.195.in-addr.arpa name = mailhost.estherundpetr.ch. 78.232.141.195.in-addr.arpa name = mailhost.luisenstrasse.ch. 78.232.141.195.in-addr.arpa name = mailhost.arthurandersen.ch. 78.232.141.195.in-addr.arpa name = mailhost.elektronik-news.ch. 78.232.141.195.in-addr.arpa name = mailhost.zuerichsee-gastro.ch. 78.232.141.195.in-addr.arpa name = mailhost.pop.ch. 78.232.141.195.in-addr.arpa name = mailhost.rtv.ch. 78.232.141.195.in-addr.arpa name = mailhost.dsng.ch. Step 2: == Bluewin does a normal forward DNS lookup, using the result from the above query. The forward (A) query has to match your IP address, otherwise Bluewin will complain about the PTR record. However, the above query returned more than one value, so I am not sure which host is used for the lookup - I guess that just the first host is taken. Since the order is random, you cannot say anything reliable about which host will be used for the lookup. Maybe it even fails directly if the response is not unique - I don't know. When I tried the lookup the first time, mailhost.aquacare.ch was used for the query. However, mailhost.aquacare.ch does not exist (even the domain does not exist), so the lookup fails and rightly so Bluewin complains about your PTR record. I think the purpose of this reverse and forward DNS lookup procedure is to prevent spam, since most spam comes from hacked machines (mostly from dynamic IP address ranges) which do not have correct PTR records - just as it is the case with your machine ;-) Gruass, Franco Adrian Ulrich wrote: Good Morning, Is your source ip 195.141.232.78 ? Regards, Adrian ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog Xaver Aerni wrote: Our System receive ex. This MSG The original message was received at Tue, 25 Mar 2008 16:20:47 +0100 from localhost [127.0.0.1] - Transcript of session follows - ... while talking to mxbw.bluewin.ch.: 451 No thanks. (How about PTR records?) ... while talking to mxzhh.bluewin.ch.: QUIT 451 No thanks. (How about PTR records?) ... while talking to mxzhb.bluewin.ch.: QUIT 451 No thanks. (How about PTR records?) [EMAIL PROTECTED]... Deferred: 451 No thanks. (How about PTR records?) Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old ** Xaver Aerni Zürichstrasse 10a 8340 Hinwil Tel. 001 707 361 68 39 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog ___ swinog mailing list swinog@lists.swinog.ch
Re: [swinog] Has Bluewin a DNS Problem
you can just take another name for the mailserver of these domains - only one for all so you have one PTR Record, pointing to mailserver.domain then you can use the same domainname for mailserver on the others 29 Domains. this fixes this problem Silvan Am 26.03.2008 um 13:45 schrieb Xaver Aerni: The Problem is we have on this IP 30 Domains... When I must have for everery Domain an IP for the reverse of Bluewin is a big Problem... I must have in future an A Net... I think Bluewin must fix this. Greetings X. Aerni ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
RE: [swinog] Has Bluewin a DNS Problem
... This is a silly reverse setup. A reverse lookup should only return one hostname, not 20. ... Well, tend to agree. 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? If this approach works out, it could be considered. It is not illegal. It's just against what we are used to over the last 20+ years. Just like the A records on second level domain names - depreciated some years ago, tough more and more common. 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. Regards, -Kurt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Per Jessen Sent: Wednesday, March 26, 2008 2:26 PM To: swinog@lists.swinog.ch Subject: Re: [swinog] Has Bluewin a DNS Problem ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
Hi Kurt, On 26.03.2008, at 15:03, Kurt A. Schumacher wrote: ... This is a silly reverse setup. A reverse lookup should only return one hostname, not 20. ... 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? There are a lot of E-Mail Providers (i.e. gmx) behaving like this already. If A, PTR, MX and HELO are not exactly the same (all four) the message is marked as SPAM. There are pro's and cons for this... I would not rate E-Mails solely because of those four points, but that's only me CU Tobias ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
RE: [swinog] Has Bluewin a DNS Problem
Kurt A. Schumacher wrote: ... This is a silly reverse setup. A reverse lookup should only return one hostname, not 20. ... Well, tend to agree. 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? Trying to work around them with a dodgy DNS setup is not the right course of action, IMHO. If this approach works out, it could be considered. It is not illegal. Correct - it's just silly and it doesn't work as expected. 1) a properly working resolver library will return multiple records rotated once for every lookup, so you're never guaranteed to get the same answer to a reverse lookup. 2) most applications, e.g. mail-servers, that do reverse lookups do not expect more than one reply, and will always only process the first one. It's just against what we are used to over the last 20+ years. Plus it doesn't work. /Per Jessen, Herrliberg -- http://www.spamchek.com/ - your spam is our business. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
On the Wed, Mar 26, 2008 at 01:57:46PM +0100, Adrian Ulrich blubbered: Hoi. The resolver implementation of our MTA software appears to have a problem with truncated UDP responses. (Btw: Why do you have such a lenghty PTR record for 195.141.232.78 ?) I may be wrong, but doesn't DNS use TCP if the answer to a query exceeds a certain length? CU, Venty -- Wo Informationen fehlen, da entstehen Geruechte. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
On the Wed, Mar 26, 2008 at 02:42:36PM +0100, Tonnerre Lombard blubbered: Hoi. 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 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 -- Wo Informationen fehlen, da entstehen Geruechte. ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
