mysqlstudent at gmail.com
Mon Sep 3 01:54:57 UTC 2018
> > When trying to resolve any of these manually, it just returns
> > NXDOMAIN.
> What does
> dig -4 188.8.131.52.hostkarma.junkemailfilter.com +trace +nodnssec
> show, and it is consistently NXDOMAIN? That ends here with:
> 184.108.40.206.hostkarma.junkemailfilter.com. 2100 IN A 127.0.0.3
> 220.127.116.11.hostkarma.junkemailfilter.com. 2100 IN A 127.0.1.1
> ;; Received 93 bytes from 18.104.22.168#53(rbl1.junkemailfilter.com)
> in 20 ms
It shows the same here now, at least for the ones which resolve.
Others still return NXDOMAIN. I was previously just using "host", but
I suppose it's also possible that's one I didn't do. It's also
possible they're no longer blacklisted by these RBLs.
My point was that none of them returned SERVFAIL. I thought using dig
or host to try and resolve the hosts would return the same SERVFAIL
when run manually as they did by the bind resolver. What could be
different that resulted in what appeared to be the majority of queries
to return SERVFAIL in the named.debug.log at the time the mail was
Would high network utilization cause that? I assume that would cause
the timeout, but how can I be sure? Isn't ethernet designed to
communicate that at the lower levels to prevent that kind of thing
Is there a bind configuration that would make it more resilient?
> > I also isolated a packet with the "server failure" information, but
> > I'm unable to figure out what the data means. Would someone be
> > interested in evaluating it for me? It's a 146-byte pcap file.
> > https://drive.google.com/open?id=1Ui893Lg61psZCR8I_9SJtNqs-Sil_br
> That is just the reply from bind to some other process running on the
> same machine, reporting the server failure.
Oh, right, because it's over loopback. This is probably from postfix's
postscreen that's doing the querying.
This is not the same as one of the SERVFAIL entries from named.debug.log?
Do you have any other ideas on how I can isolate this problem?
More information about the bind-users