Cloudapp net doing dns check

Discussion in 'Installation/Configuration' started by vk3heg, Jul 7, 2016.

  1. vk3heg

    vk3heg Member

    Hello,
    I've just had a client contact me with email that's bouncing from the cloudapp.net servers. There isn't anything special in the dns, except for the MX records have my providers inbound spamfilter system as the 10/20 mx.

    They also tried sending from anther provider and got the same error message.
    Is there something that the cloudapp.net system looks for in the DNS? Reverse dns has been set for my server since day one.


    DNS:
    A clientdomain.com.au. 103.4.x.x 0 3600
    A
    www 103.4.x.x 0 3600
    MX
    clientdomain.com.au. mx02.exigent.com.au. 20 3600
    MX
    clientdomain.com.au. mx01.exigent.com.au. 10 3600
    NS
    clientdomain.com.au. ns1.mydomain.com.au. 0 3600
    NS
    clientdomain.com.au. ns2.mydomain.com.au. 0 3600
    TXT
    clientdomain.com.au. v=spf1 a ip4:103.4.x.x a:server.mydomain.com.au ~all 0 3600

    Mail log:

    Jul 7 13:39:03 server amavis[19003]: (19003-17) Passed CLEAN {RelayedInbound}, [59.100.244.142]:52439 [59.100.244.142] <[email protected]> -> <[email protected]>, Queue-ID: B583A3C717B, Message-ID: <[email protected]>, mail_id: GYMWvfM4jB5n, Hits: -0.389, size: 71511, queued_as: 19D2B3C7185, 1277 ms

    Jul 7 13:39:03 server postfix/smtp[7762]: B583A3C717B: to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.4, delays=0.14/0/0/1.3, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 19D2B3C7185)

    Jul 7 13:39:35 server postfix/smtp[7839]: 19D2B3C7185: to=<[email protected]>, relay=sid-filter-02.cloudapp.net[104.210.109.1]:25, delay=33, delays=0.05/0.01/0.61/32, dsn=5.7.1, status=bounced (host sid-filter-02.cloudapp.net[104.210.109.1] said: 550 5.7.1 Sender domain failed DNS checks (59c826af-43f4-11e6-aefa-000d3ad02223) (in reply to end of DATA command))
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Did you check the dns setup of the client domain at intodns dot com?
     
  3. vk3heg

    vk3heg Member

    HI Till,

    Passes without any red flags. (Can send real names via pm if you want)..

    Thanks.
    Stephen


    Status Test name Result
    Parent done Domain NS records Nameserver records returned by the parent servers are:

    ns1.mydomain.net.au ['103.4.x.x'] (NO GLUE) [TTL=59 minutes 59 seconds]
    ns2.mydomain.net.au ['103.4.x.x'] (NO GLUE) [TTL=59 minutes 59 seconds]

    a.au. was kind enough to give us that information.
    warning TLD Parent Check WARNING: Looks like the parent servers do not have information for your TLD when asked. This is ok but can be confusing.
    done Your nameservers are listed Good. The parent server a.au. has your nameservers listed. This is a must if you want to be found as anyone that does not know your DNS servers will first ask the parent nameservers.
    add_alert DNS Parent sent Glue The parent nameserver a.au. is not sending out GLUE for every nameservers listed, meaning he is sending out your nameservers host names without sending the A records of those nameservers. It's ok but you have to know that this will require an extra A lookup that can delay a little the connections to your site. This happens a lot if you have nameservers on different TLD (domain.com for example with nameserver ns.domain.org.)
    done Nameservers A records Good. Every nameserver listed has A records. This is a must if you want to be found.
    NS done NS records from your nameservers NS records got from your nameservers listed at the parent NS are:

    ns1.mydomain.net.au ['103.4.x.x'] [TTL=1 hours]
    ns2.mydomain.net.au ['163.47.x.x'] [TTL=1 hours]

    done Recursive Queries Good. Your nameservers (the ones reported by the parent server) do not report that they allow recursive queries for anyone.
    done Same Glue The A records (the GLUE) got from the parent zone check are the same as the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do according to the RFC. This tests only nameservers that are common at the parent and at your nameservers. If there are any missing or stealth nameservers you should see them below!
    done Glue for NS records OK. When I asked your nameservers for your NS records they also returned the A records for the NS records. This is a good thing as it will spare an extra A lookup needed to find those A records.
    done Mismatched NS records OK. The NS records at all your nameservers are identical.
    done DNS servers responded Good. All nameservers listed at the parent server responded.
    done Name of nameservers are valid OK. The nameservers reported by the parent send out nothing as shown above. I can't check nothing so it's a green!
    done Multiple Nameservers Good. You have multiple nameservers According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me.
    done Nameservers are lame OK. All the nameservers listed at the parent servers answer authoritatively for your domain.
    done Missing nameservers reported by parent OK. All NS records are the same at the parent and at your nameservers.
    done Missing nameservers reported by your nameservers OK. All nameservers returned by the parent server a.au. are the same as the ones reported by your nameservers.
    done Domain CNAMEs OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
    done NSs CNAME check OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
    done Different subnets OK. Looks like you have nameservers on different subnets!
    done IPs of nameservers are public Ok. Looks like the IP addresses of your nameservers are public. This is a good thing because it will prevent DNS delays and other problems like
    done DNS servers allow TCP connection OK. Seems all your DNS servers allow TCP connections. This is a good thing and useful even if UDP connections are used by default.
    done Different autonomous systems OK. It seems you are safe from a single point of failure. You must be careful about this and try to have nameservers on different locations as it can prevent a lot of problems if one nameserver goes down.
    done Stealth NS records sent Ok. No stealth ns records are sent
    SOA add_alert SOA record The SOA record is:
    Primary nameserver: ns1.mydomain.net.au
    Hostmaster E-mail address: [email protected]
    Serial #: 2016070603
    Refresh: 2 hours
    Retry: 9 minutes
    Expire: 7 days
    Default TTL: 1 hours
    done NSs have same SOA serial OK. All your nameservers agree that your SOA serial number is 2016070603.
    done SOA MNAME entry OK. ns1.mydomain.net.au That server is listed at the parent servers.
    done SOA Serial Your SOA serial number is: 2016070603 . This appears to be in the recommended format of YYYYMMDDnn.
    done SOA REFRESH OK. Your SOA REFRESH interval is: 7200 . That is OK But recomended range is 1200-43200
    done SOA RETRY Your SOA RETRY value is: 540 . Looks ok
    warning SOA EXPIRE Your SOA EXPIRE number is: 604800 seconds.Looks ok But recomended range is 1209600-2419200 seconds
    done SOA MINIMUM TTL Your SOA MINIMUM TTL is: 3600 seconds. This value was used to serve as a default TTL for records without a given TTL value and now is used for negative caching (indicates how long a resolver may cache the negative answer). RFC2308 recommends a value of 1-3 hours. Your value of 3600 seconds is OK.
    MX done MX Records Your MX records that were reported by your nameservers are:

    10 mx01.exigent.com.au [103.4.16.213] [TTL: 1 hours]
    20 mx02.exigent.com.au [103.4.18.213] [TTL: 1 hours]

    [These are all the MX records that I found. ]
    done Different MX records at nameservers Good. Looks like all your nameservers have the same set of MX records. This tests to see if there are any MX records not reported by all your nameservers and also MX records that have the same hostname but different IPs
    done MX name validity Good. I did not detect any invalid hostnames for your MX records.
    done MX IPs are public OK. All of your MX records appear to use public IPs.
    done MX CNAME Check OK. No problems here.
    done MX A request returns CNAME OK. No problems here.
    done MX is not IP OK. All of your MX records are host names.
    done Number of MX records OK. Looks like you have multiple MX records. However some of your MX records are not common at all your nameservers.
    This seems bad but if you know what are you doing it's ok.
    done Mismatched MX A OK. I did not detect differing IPs for your MX records.
    done Duplicate MX A records OK. I have not found duplicate IP(s) for your MX records. This is a good thing.
    done Reverse MX A records (PTR) Your reverse (PTR) record:
    213.16.4.103.in-addr.arpa -> semx01.v-dc.net.au
    213.18.4.103.in-addr.arpa -> semx02.v-dc.net.au
    You have reverse (PTR) records for all your IPs, that is a good thing.
    WWW add_alert WWW A Record Your www.carpetgallery.com.au A record is:
    clientdomain.com.au ->[103.4.x.x] [TTL:1 hours]
    done IPs are public OK. All of your WWW IPs appear to be public IPs.
    done WWW CNAME OK. No CNAME
    TXT done TXT Record
    • v=spf1 a ip4:103.4.x.x a:myserver.mydomain.net.au ~all
    SRV done SRV Record Click To check SRV Record
    Processed in (9.49 sec)
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    So dns is ok. Then you should consider to contact cloudapp.net (or search at google or if available, their knowledge base) what the reason if the issue can be.
     
  5. vk3heg

    vk3heg Member

    Hello Till,
    my googling sofar hasn't resulted in any worthwhile results. Using the right terms might be the issue.
    I have done a dig on the domain, and it comes back as a microsoft dns/system. (azuredns), it also dosn't help that the cloudapp.net website in black and come back with a 403 forbidden error.

    Stephen
     
  6. vk3heg

    vk3heg Member

    I'm now getting more of these messages, and need to find a solution. The only thing in common is the cloudapp.net server for the mx for each of the listed domains. Could the issue be that our inbound MX is a spamfilter system from my upstream provider, yet my server sends out email directly?

    I have also installed the DKIM patch for all the domains on my server and still get this bounce.

    3 Bounced (remote) ------------------------------------------------------------------------
    3 5.7.1: Permanent failure: Security/policy status: Delivery not authorized, message ...
    1 bstgroup.com.au
    1 accountspayable
    1 191.239.178.218 sid-filter-01.cloudapp.net
    1 550 5.7.1 Sender domain failed DNS checks (3d5ab6a7-4751-11e6-919f-000d...
    1 eurekatool.com.au
    1 liana
    1 191.239.178.218 sid-filter-01.cloudapp.net
    1 550 5.7.1 Sender domain failed DNS checks (612ec9ec-46f8-11e6-919f-000d...
    1 hensleypark.com.au
    1 ellie
    1 191.239.178.218 sid-filter-01.cloudapp.net
    1 550 5.7.1 Sender domain failed DNS checks (1a1f3cfc-4749-11e6-942f-000d...
     

Share This Page