Quantcast

ot: troubleshhoting MX issue (?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ot: troubleshhoting MX issue (?)

Voytek
I'm unable to send an email to "[hidden email]", getting
"domain not found".

it seems to me they're misconfigured and, don't have MX set correctly?

or am i misinterpreting this, mxtoolbox find MX ?

fwiw, web surfacetreatment.be redirects to surfacetreatment.nl

thanks for help, explanation and any pointers

Mar  1 08:58:53 emu postfix/smtpd[22849]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 450 4.1.2 <[hidden email]>: Recipient
address rejected: Domain not found; from=<[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<sbt.net.au>


# dig -t MX surfacetreatment.be

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> -t MX
surfacetreatment.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25122
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;surfacetreatment.be.           IN      MX

;; Query time: 226 msec
;; SERVER: 45.65.12.7#53(45.65.12.7)
;; WHEN: Wed Mar  1 10:53:22 2017
;; MSG SIZE  rcvd: 37


mxtoolbox says:

mx:surfacetreatment.be   Find Problems    mx
Pref Hostname IP Address TTL
10 remote.surfacetreatment.be 91.183.126.148 5 min Blacklist Check    
SMTP Test
dns lookup dns check whois lookup spf lookup dns propagation
Reported by ns1.skynet.be on 2/28/2017 at 11:53:37 PM (UTC 0), just for
you.  (History)  Transcript
smtp:91.183.126.148   Monitor This    smtp

220 remote.surfacetreatment.be Microsoft ESMTP MAIL Service ready at Tue,
28 Feb 2017 22:59:45 +0100

Test Result
        SMTP Transaction Time 8.767 seconds - Not good! on Transaction Time More
Info
        SMTP Reverse DNS Mismatch OK - 91.183.126.148 resolves to
remote.surfacetreatment.be
        SMTP Valid Hostname OK - Reverse DNS is a valid Hostname
        SMTP Banner Check OK - Reverse DNS matches SMTP Banner
        SMTP TLS OK - Supports TLS.
        SMTP Connection Time 0.859 seconds - Good on Connection time
        SMTP Open Relay OK - Not an open relay.
Session Transcript:
Connecting to 91.183.126.148

220 remote.surfacetreatment.be Microsoft ESMTP MAIL Service ready at Tue,
28 Feb 2017 22:59:45 +0100 [672 ms]
EHLO PWS3.mxtoolbox.com
250-remote.surfacetreatment.be Hello [192.168.0.1]
250-SIZE 30720000
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250 BINARYMIME [953 ms]
MAIL FROM:<[hidden email]>
250 2.1.0 Sender OK [734 ms]
RCPT TO:<[hidden email]>
550 5.7.1 Unable to relay [5735 ms]

PWS3v2 9986ms


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ot: troubleshhoting MX issue (?)

Viktor Dukhovni

> On Feb 28, 2017, at 7:05 PM, Voytek <[hidden email]> wrote:
>
> dig -t MX surfacetreatment.be
>
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> -t MX
> surfacetreatment.be
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25122
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;surfacetreatment.be.           IN      MX
>
> ;; Query time: 226 msec
> ;; SERVER: 45.65.12.7#53(45.65.12.7)
> ;; WHEN: Wed Mar  1 10:53:22 2017
> ;; MSG SIZE  rcvd: 37

That resolver is having problems that I don't see:

$ dig +nocd -t mx surfacetreatment.be
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23879
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2
;surfacetreatment.be.   IN MX
surfacetreatment.be.    MX      10 remote.surfacetreatment.be.
surfacetreatment.be.    NS      ns4.skynet.be.
surfacetreatment.be.    NS      ns1.skynet.be.
surfacetreatment.be.    NS      ns3.skynet.be.
surfacetreatment.be.    NS      ns2.skynet.be.

And posttls-finger connects to the domain:

$ posttls-finger -l may -Lsummary -c surfacetreatment.be
posttls-finger: Untrusted TLS connection established to remote.surfacetreatment.be[91.183.126.148]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)

The problem may be on your end.  The report from dnsviz.net also shows
no problems (ignore the errors for a non-responding root namerver):

http://dnsviz.net/d/surfacetreatment.be/dnssec/

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ot: troubleshhoting MX issue (?)

Andrew Sullivan
On Tue, Feb 28, 2017 at 07:13:33PM -0500, Viktor Dukhovni wrote:

>
> > On Feb 28, 2017, at 7:05 PM, Voytek <[hidden email]> wrote:
> >
> > dig -t MX surfacetreatment.be
> >
> > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> -t MX
> > surfacetreatment.be
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25122
                                           ^^^^^^^^
                                           
> The problem may be on your end.  The report from dnsviz.net also shows
> no problems (ignore the errors for a non-responding root namerver):
>
> http://dnsviz.net/d/surfacetreatment.be/dnssec/

When I look, I see problems in dnsviz regarding DNSSEC.  The root key
is in the middle of a roll, and I wonder whether there might be a
problem resulting from that.  If the resolver is validating and can't
prove the insecure delegation, it might return SERVFAIL.  (But I agree
I can see the records there.)  The SERVFAIL could also be a broken
recursive or a cache failure of some kind.

A

--
Andrew Sullivan
[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ot: troubleshhoting MX issue (?)

Voytek
In reply to this post by Viktor Dukhovni
On Wed, March 1, 2017 11:13 am, Viktor Dukhovni wrote:

> That resolver is having problems that I don't see:
>
>
> $ dig +nocd -t mx surfacetreatment.be
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23879
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2
> ;surfacetreatment.be.   IN MX
> surfacetreatment.be.    MX      10 remote.surfacetreatment.be.
> surfacetreatment.be.    NS      ns4.skynet.be. surfacetreatment.be.    NS
> ns1.skynet.be. surfacetreatment.be.    NS      ns3.skynet.be.
> surfacetreatment.be.    NS      ns2.skynet.be.
>
> And posttls-finger connects to the domain:
>
>
> $ posttls-finger -l may -Lsummary -c surfacetreatment.be
> posttls-finger: Untrusted TLS connection established to
> remote.surfacetreatment.be[91.183.126.148]:25: TLSv1.2 with cipher
> ECDHE-RSA-AES128-SHA (128/128 bits)
>
>
> The problem may be on your end.  The report from dnsviz.net also shows
> no problems (ignore the errors for a non-responding root namerver):

Viktor,

thanks, I think I found my problems, or, a part of, I'm getting MX now:

BUT, I'm not getting BOTH MX and NS, like in your dig, though, get them
individually with 't' option

so, not sure if it's a difference in dig, or, am I still missing something
(found problems in resolver name server, fwiw)

# dig +nocd -t mx surfacetreatment.be

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> +nocd -t mx
surfacetreatment.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6676
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;surfacetreatment.be.           IN      MX

;; Query time: 1 msec
;; SERVER: 45.65.12.7#53(45.65.12.7)
;; WHEN: Wed Mar  1 21:38:46 2017
;; MSG SIZE  rcvd: 37

# dig +nocd -t ns  surfacetreatment.be

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> +nocd -t ns
surfacetreatment.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5186
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;surfacetreatment.be.           IN      NS

;; ANSWER SECTION:
surfacetreatment.be.    86273   IN      NS      ns3.skynet.be.
surfacetreatment.be.    86273   IN      NS      ns2.skynet.be.
surfacetreatment.be.    86273   IN      NS      ns1.skynet.be.
surfacetreatment.be.    86273   IN      NS      ns4.skynet.be.

;; Query time: 1 msec
;; SERVER: 45.65.12.7#53(45.65.12.7)
;; WHEN: Wed Mar  1 21:39:33 2017
;; MSG SIZE  rcvd: 116


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ot: troubleshhoting MX issue (?)

Andrew Sullivan
On Wed, Mar 01, 2017 at 09:50:55PM +1100, Voytek wrote:
> BUT, I'm not getting BOTH MX and NS, like in your dig, though, get them
> individually with 't' option

Name servers may include or not, according to various local policy
settings, the Authority section appropriate to an answer.  When you
use dig for the explicit lookup of the NS records, you get the answer
appropriate in the Answer section instead.  You don't actually need
the NS records as part of the response to the MX query, as long as you
get the Answer with the MX.

Why are you setting +nocd?

It looks like you're still seeing a SERVFAIL for the MX record, at
least in what you posted.  SERVFAIL means something is wrong, possibly
with the resolver (also called "recursive" or "recursive server")
itself.  That's not the answer you need.

Best regards,

A

--
Andrew Sullivan
[hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ot: troubleshhoting MX issue (?)

Voytek
On Wed, March 1, 2017 10:45 pm, Andrew Sullivan wrote:
> On Wed, Mar 01, 2017 at 09:50:55PM +1100, Voytek wrote:

Andrew,

> Why are you setting +nocd?

ahmm, I saw it in Viktor's post, and, copied it..oops

> It looks like you're still seeing a SERVFAIL for the MX record, at
> least in what you posted.  SERVFAIL means something is wrong, possibly with
> the resolver (also called "recursive" or "recursive server") itself.
> That's not the answer you need.

I found different name servers in an old resolv.conf, and, these seem to
resolve OK, I'll use these pending confirmation from hosting

now getting this[1]:

Andrew, Viktor, thanks for your help, much appreciated.

[1]
# dig -t mx surfacetreatment.be

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> -t mx
surfacetreatment.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27982
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;surfacetreatment.be.           IN      MX

;; ANSWER SECTION:
surfacetreatment.be.    300     IN      MX      10
remote.surfacetreatment.be.

;; Query time: 334 msec
;; SERVER: 103.15.178.250#53(103.15.178.250)
;; WHEN: Thu Mar  2 15:51:30 2017
;; MSG SIZE  rcvd: 60





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ot: troubleshhoting MX issue (?)

chaouche yacine
As long as you're getting a SERVAIL you are having a problem with your resolver. This assumption can be verified if you check with public resolvers like 8.8.8.8 and 8.8.4.4 (dig -t mx surfacetreatment.be @8.8.8.8)

-- Yassine.


On Thursday, March 2, 2017 5:56 AM, Voytek <[hidden email]> wrote:


On Wed, March 1, 2017 10:45 pm, Andrew Sullivan wrote:
> On Wed, Mar 01, 2017 at 09:50:55PM +1100, Voytek wrote:

Andrew,

> Why are you setting +nocd?

ahmm, I saw it in Viktor's post, and, copied it..oops

> It looks like you're still seeing a SERVFAIL for the MX record, at
> least in what you posted.  SERVFAIL means something is wrong, possibly with
> the resolver (also called "recursive" or "recursive server") itself.
> That's not the answer you need.

I found different name servers in an old resolv.conf, and, these seem to
resolve OK, I'll use these pending confirmation from hosting

now getting this[1]:

Andrew, Viktor, thanks for your help, much appreciated.


[1]

# dig -t mx surfacetreatment.be

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> -t mx
surfacetreatment.be
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27982
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;surfacetreatment.be.          IN      MX

;; ANSWER SECTION:
surfacetreatment.be.    300    IN      MX      10
remote.surfacetreatment.be.

;; Query time: 334 msec
;; SERVER: 103.15.178.250#53(103.15.178.250)
;; WHEN: Thu Mar  2 15:51:30 2017
;; MSG SIZE  rcvd: 60








Loading...