intodns.com Open in urlscan Pro
93.113.174.225  Public Scan

Form analysis
1 forms found in the DOM

GET /check/

<form action="/check/" method="get">
  <input name="domain" type="text" value="whatsappbusinesapi.com" class="inps"> <input type="submit" value="Report" class="inpBtn">
</form>

Text Content

Work in progress!





Follow IntoDNS on Twitter




Category Status Test name Information send feedback Parent Domain NS records
Nameserver records returned by the parent servers are:

peyton.ns.cloudflare.com.   ['108.162.193.221', '172.64.33.221',
'173.245.59.221']   [TTL=172800]
carrera.ns.cloudflare.com.   ['108.162.194.231', '162.159.38.231',
'172.64.34.231']   [TTL=172800]

l.gtld-servers.net was kind enough to give us that information.





TLD Parent Check Good. l.gtld-servers.net, the parent server I interrogated, has
information for your TLD. This is a good thing as there are some other domain
extensions like "co.us" for example that are missing a direct check. Your
nameservers are listed Good. The parent server l.gtld-servers.net 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. DNS Parent sent
Glue Good. The parent nameserver sent GLUE, meaning he sent your nameservers as
well as the IPs of your nameservers. Glue records are A records that are
associated with NS records to provide "bootstrapping" information to the
nameserver.(see RFC 1912 section 2.3) Nameservers A records Good. Every
nameserver listed has A records. This is a must if you want to be found. NS NS
records from your nameserversNS records got from your nameservers listed at the
parent NS are:

carrera.ns.cloudflare.com  ['162.159.38.231', '108.162.194.231',
'172.64.34.231']   [TTL=86400]
peyton.ns.cloudflare.com  ['173.245.59.221', '108.162.193.221', '172.64.33.221']
  [TTL=86400]

Recursive Queries Good. Your nameservers (the ones reported by the parent
server) do not report that they allow recursive queries for anyone. 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! Glue for NS
records INFO: GLUE was not sent when I asked your nameservers for your NS
records.This is ok but you should know that in this case an extra A record
lookup is required in order to get the IPs of your NS records. The nameservers
without glue are:
172.64.34.231
173.245.59.221
You can fix this for example by adding A records to your nameservers for the
zones listed above. Mismatched NS records OK. The NS records at all your
nameservers are identical. DNS servers responded Good. All nameservers listed at
the parent server responded. Name of nameservers are valid OK. All of the NS
records that your nameservers report seem valid. 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.
Nameservers are lame OK. All the nameservers listed at the parent servers answer
authoritatively for your domain. Missing nameservers reported by parent OK. All
NS records are the same at the parent and at your nameservers. Missing
nameservers reported by your nameservers OK. All nameservers returned by the
parent server l.gtld-servers.net are the same as the ones reported by your
nameservers. 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. 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. Different subnets OK. Looks like you have
nameservers on different subnets! 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 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. 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. Stealth NS records sent Ok. No
stealth ns records are sent SOA SOA recordThe SOA record is:
Primary nameserver: carrera.ns.cloudflare.com
Hostmaster E-mail address: dns.cloudflare.com
Serial #: 2344463472
Refresh: 10000
Retry: 2400
Expire: 604800   1 weeks
Default TTL: 1800
NSs have same SOA serial OK. All your nameservers agree that your SOA serial
number is 2344463472. SOA MNAME entry OK. carrera.ns.cloudflare.com That server
is listed at the parent servers. SOA Serial Your SOA serial number is:
2344463472. This can be ok if you know what you are doing. SOA REFRESH OK. Your
SOA REFRESH interval is: 10000. That is OK SOA RETRY Your SOA RETRY value is:
2400. Looks ok SOA EXPIRE Your SOA EXPIRE number is: 604800.Looks ok SOA MINIMUM
TTL Your SOA MINIMUM TTL is: 1800. 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 1800 is OK. MX MX RecordsYour MX
records that were reported by your nameservers are:

0   mail.whatsappbusinesapi.com   107.172.58.10

[These are all the MX records that I found. If there are some non common MX
records at your nameservers you should see them below. ] 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 MX
name validity Good. I did not detect any invalid hostnames for your MX records.
MX IPs are public OK. All of your MX records appear to use public IPs. MX CNAME
Check OK. No problems here. MX A request returns CNAME OK. No CNAMEs returned
for A records lookups. MX is not IP OK. All of your MX records are host names.
Number of MX records OK. Looks like you only have one MX record at your
nameservers. You should be careful about what you are doing since you have a
single point of failure that can lead to mail being lost if the server is down
for a long time. Mismatched MX A OK. I did not detect differing IPs for your MX
records. Duplicate MX A records OK. I have not found duplicate IP(s) for your MX
records. This is a good thing. Reverse MX A records (PTR) Your reverse (PTR)
record:
10.58.172.107.in-addr.arpa ->  107-172-58-10-host.colocrossing.com
You have reverse (PTR) records for all your IPs, that is a good thing. WWW WWW A
Record Your www.whatsappbusinesapi.com A record is:
www.whatsappbusinesapi.com  [104.21.32.128]  [172.67.151.250]  IPs are public
OK. All of your WWW IPs appear to be public IPs. WWW CNAME OK. No CNAME

Processed in 0.158 seconds.

© Hosterion - web hosting | VPS hosting by IntoVPS
Made with Python, Django & jQuery