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
Re: [swinog] Has Bluewin a DNS Problem
Hi Martin, > I may be wrong, but doesn't DNS use TCP if the answer to a query > exceeds a certain length? Yes. If the resolver receives a truncated response (TC bit set) it is supposed to re-do the query via TCP. You are out of luck if your resolver thinks: 'What the hell is a TC bit?! I'll just try to parse the response and pretend that there was no TC bit set. Harr harr..' This works (somewhat) if the response came from BIND: $ dig -x 195.141.232.78 +short +ignore @cns1.bluewin.ch |grep -vc '^;;' 14 But it fails if dnscache sent the response: $ dig -x 195.141.232.78 +short +ignore @fdad:ecad:e0fb:adf0::f00 |grep -vc '^;;' 0 (dnscache does not include a 'stripped down' response: http://cr.yp.to/djbdns/notes.html => Truncation) 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
Salut, Venty, On Wed, 26 Mar 2008 18:31:19 +0100, Martin Ebnoether wrote: > I may be wrong, but doesn't DNS use TCP if the answer to a query > exceeds a certain length? The use of DNS over TCP allows the answers to exceed a certain length, but the use of NFS over TCP depends soleily on the type of request made. If an UDP request has been made, there is no way to respond via TCP, obviously. Tonnerre signature.asc Description: PGP signature ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
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.. -- :wq Claudio ___ 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
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
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
Salut, Tobias, On Wed, 26 Mar 2008 15:52:04 +0100, Tobias Göller wrote: > 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... This is an entirely different question. The question here is: 1. is there an A record for the host advertised in HELO/EHLO? (sensible question) 2. Is there an A record for the PTR which matches the A record? (Questionable) 3. Potentially even: is the domain of the PTR record the one we're sending mail for? (WRONG! See e.g. the large hosteurope mail setups for lots of virtual sites, etc. pp.) 4. Is the sender an MX for the domain? (WRONG! Especially in large setups, it is a very bad idea to use the same servers for submission and receiving, especially due to the entirely different requirements. Even hatemail does not do this. If you want to do such checks, there is SPF.) There are more sensible ways to waste our mail servers' time than to check PTR records for bizarre requirements which are never met. Tonnerre signature.asc Description: PGP signature ___ 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
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 ([EMAIL PROTECTED], [EMAIL PROTECTED], 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 signature.asc Description: PGP signature ___ 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
> When I must have for everery Domain an IP for the reverse of Bluewin is a > big Problem... You don't have to: The lengthy PTR record just triggered a bug in our MTA Software. Anyway: Such a multi-ptr record is of no use: - It does not scale - There is no need for it. A single record (matching $myhostname) would be enough. 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
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
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
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
>> 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
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
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
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
Yes, This is the IP of our Mailserver Greetings Xaver - Original Message - From: "Adrian Ulrich" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 26, 2008 8:57 AM Subject: Re: [swinog] Has Bluewin a DNS Problem 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 ___ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Has Bluewin a DNS Problem
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
