On 7 Apr 2007, at 20:08, Don Drake wrote:
I don't get it.
I just upgraded to 1.24 (more emails on that later), and I'm still getting
ENODNS from @returns.bulk.yahoo.com. I just commented out my SmartDNSHost
setting and cleared dnscache and it's still occurring. Now that I'm
grasping
It looks like returns.bulk.yahoo.com has ONLY MX records, no A records...
; DiG 9.3.4 returns.bulk.yahoo.com IN A
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 33585
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION
I have the same ENODNS with xmail 1.21
Interestingly, dnsreport.com for returns.bulk.yahoo.com says:
I was unable to get an answer from the parent servers [bulk.yahoo.com], when I
tried to find the NS records for returns.bulk.yahoo.com.
Could that be the problem?
Dave
- Original Message
On Sun, 8 Apr 2007, Dave Taylor wrote:
I have the same ENODNS with xmail 1.21
Interestingly, dnsreport.com for returns.bulk.yahoo.com says:
I was unable to get an answer from the parent servers [bulk.yahoo.com], when
I
tried to find the NS records for returns.bulk.yahoo.com.
Could that
On Sun, 8 Apr 2007, Davide Libenzi wrote:
On Sun, 8 Apr 2007, Dave Taylor wrote:
I have the same ENODNS with xmail 1.21
Interestingly, dnsreport.com for returns.bulk.yahoo.com says:
I was unable to get an answer from the parent servers [bulk.yahoo.com],
when I
tried to find the NS
It SHOULD check at the nameservers for yahoo.com, if they return the
requested record (MX), the resolver has its answer (which is the case!), if
it does not return the requested record type, it should retry at the
returned NS records.
The DNS IS NOT broken.Sorry, Davide, it really looks like a
On Sun, 8 Apr 2007, Ivo Smits wrote:
It SHOULD check at the nameservers for yahoo.com, if they return the
requested record (MX), the resolver has its answer (which is the case!), if
it does not return the requested record type, it should retry at the
returned NS records.
It does. It tries
On Sun, 8 Apr 2007, Davide Libenzi wrote:
On Sun, 8 Apr 2007, Ivo Smits wrote:
It SHOULD check at the nameservers for yahoo.com, if they return the
requested record (MX), the resolver has its answer (which is the case!), if
it does not return the requested record type, it should retry
Davide Libenzi wrote:
It SHOULD check at the nameservers for yahoo.com, if they return the
requested record (MX), the resolver has its answer (which is the case!), if
it does not return the requested record type, it should retry at the
returned NS records.
It does. It tries to go the
I've just noticed named is throwing up an error each time a
connection is made from xmailserver.org.
unexpected RCODE (SERVFAIL) resolving
'xmailserver.org.blackhole.securitysage.com/A/IN'
Looking back through logs I see this started on April 4.
Any ideas what this is due to?
I'll try to
Ivo, I totally agree with your method.
What is strange is that even with SmartDNSHost enabled with servers that can
recurse, I still have this problem, which to me means there might be a
problem with the Xmail code.
Davide, the buck stops with you, what is your opinion?
Thanks.
-Don
On 8 Apr 2007, at 23:09, David Lord wrote:
I've just noticed named is throwing up an error each time a
connection is made from xmailserver.org.
unexpected RCODE (SERVFAIL) resolving
'xmailserver.org.blackhole.securitysage.com/A/IN'
Looking back through logs I see this started on April
12 matches
Mail list logo
