I checked my domain in mxtoolbox and found following errors/warnings:
dmarc Missing or Invalid Record
https The Certificate is invalid
smtp Reverse DNS does not match SMTP Banner
dns At least one name server failed to respond in a timely manner
dns SOA Expire Value out of recommended range
I added a txt record in DNS zone for as "_dmarc" and checked it
nslookup -query=txt _dmarc.mydomain.com
its showing our server IP
Please advise how can I fix all these errors or warnings?
Best regards
#lifesaver That's a tall order without knowing what your domain is to evaluate.
But here's your general answers.
If you're missing a DMARC Record in DNS Add it. If it's invalid we need to know what you added
Why is the certificate invalid?
You need to make it match for smtp (Also it's a good idea to make it match for pop and imap
mxtoolbox has a small timeout window on DNS queries use a different tool
This is pretty subjective - but it's talking about the SOA TTL value in DNS is outside of their recommended range. Not sure what their recommended range is, but RFC 1912 recommends 14-28 days.
If you need answers to the questions above send an email to mailtest#unlocktheinbox.com - It will auto-respond and give you a lot more insight, to what's going on.
Related
When trying to refund a transaction on MySagePay (test mode, haven't tried live) I keep receiving the following error:
Failed refund attempt via My Sage Pay screens by [redacted]. Error returned was: 4020 : Information received from an Invalid IP address.
Since the information should be being received from Sage's IP addresses, I'm not sure why this is happening or how to fix it.
I've tried adding whitelisting the IP for test.sagepay.com and tried whitelisting my own computer's IP but neither worked.
Is this another case of Sage sending misleading error messages?
If so, what steps can I take to find out the real cause?
If not, what IP addresses do I need to whitelist to make their control panel work?
Found out the answer by looking at a different client's SagePay
For some reason, Sage didn't set its own IP addresses in the valid IPs when they set up the account
Adding the following solved the problem:
10.227.167.3
10.227.177.3
(Subnet Mask: 255.255.255.000)
Suppose that my computer is not compromised. If somebody is listening somewhere between my computer and the server (my ISP for example), what can they see of my HTTPS connection?
I assume they can see the domain (e.g. google.com).
But what about the specific site I'm browsing (e.g. /wiki/Privacy in https://en.wikipedia.org/wiki/Privacy)?
What about the subdomain (e.g. en in https://en.wikipedia.org/wiki/Privacy)?
What about GET parameters, everything after the '?' (e.g. https://www.google.com/search?q=privacy). Can they see what I search on google?
Please feel free to add more info in case I've missed to ask something relevant.
Example: https://www.google.com/search?q=privacy
They can see
The full domain (domain or subdomain, here "www.google.com")
The ip of the contacted domain
The approximate size of the exchanged data
The duration of the exchange(s)
They cannot see:
The path (the part of the url after the domain, here "/search")*
The GET or POST parameters (here "?q=privacy")
The content of the answer
The cookies
*After a bug in proxy discovery, the path and GET parameters may be transmitted in plain text (http://www.securitynewspaper.com/2016/08/01/proxy-pac-hack-allows-intercept-https-urls/).
And with the approximate size of the exchanged data, it may be possible to infer witch pages were visited.
I swear I googled this. I was wondering if there is any way to connect to a WebSocket service by resolving a SRV DNS query. In principle, this sounds reasonable to me, e.g., in a situation where the port where the service is going to be listening depends on the host and there is not a fixed port.
For example:
Server A listens with a WebSocket on port 1234.
Server B listens with a WebSocket on port 1235.
Server NS assigns a CNAME to A, and a CNAME to B. It also adds a SRV entry that points to A's and B's CNAMEs, and also points to each port.
When connecting, an user should then connect to something like srvws://websockethost rather than ws://aorbcname:aorbport.
Is it even possible to do such a thing? Is there any planning at all about this? Is there any alternative to solve this kind of problem, where I need to communicate ports along with the DNS query?
Update: looking around I found this draft: https://datatracker.ietf.org/doc/html/draft-ibc-websocket-dns-srv-02
But I am not really sure how to interpret this. Is this a standard? Was this even approved? Is this just a proposal?
In RFC 2782 A DNS RR for specifying the location of services (DNS SRV) it states
Currently, one must either know the exact address of a server to
contact it, or broadcast a question.
The SRV RR allows administrators to use several servers for a single
domain, to move services from host to host with little fuss, and to
designate some hosts as primary servers for a service and others as
backups.
The format of a SRV RR is
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
There is no technical reason that you couldn't use a SRV record to point to a WS. As you point out it has been the subject of an IETF draft. That doesn't appear to have gone any further, though the reasons aren't clear from its history it does appear to have been merged with RFC 6455 The WebSocket Protocol There is a discussion concerning the inclusion of IETF draft DNS SRV Resource Records for the WebSocket Protocol that has the following
SRV would be a perfect choice for many people
[...] It would be fully optional from the admin and user
perspective. The website owner could decide to use SRV or not. The
only requeriment, of course, os that WS clients support it
So while there is no technical specification, there is certainly no reason why you can't / shouldn't. The idea has been proposed and allowed to die because ultimately it is up to you if you want to use a SRV record to find a WS service that is perfectly within protocol.
And in my opinion, it would solve a number of problems.
Edited to add
After some more digging around on the IETF message boards. (curiosity as to why it wasn't implemented got the better of me) I found this message from the guy who proposed it
I was proposing it, but after long discussions in the maillist I've
understood that mandating DNS SRV in WS clients would break too much
assumptions in HTTP world (which commonly just sees above HTTP layer
and not below).
The existence of HTTP proxies is also a big handicap since those
proxies should be upgraded/modified in order to perform DNS SRV
resolution just in case the HTTP request is a WebSocket handshake.
This last argument is enough to not mandate SRV resolution.
So while it sounds a good idea, the people who really understand this stuff (and write the standards for it) found some issues that suggested simply using standard HTTP / A record look ups.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Does anyone have a complete list of all IP addresses used by the Apple Push Notification Service?
I know that Apple uses a content delivery network to spread out these requests, and DNS lookups will return servers close to the requestor's location - the problem I have is in locating all of these servers that handle content for the United States.
For example:
$ nslookup gateway.push.apple.com
Non-authoritative answer:
canonical name = gateway.push-apple.com.akadns.net.
Address: 17.172.238.216
Address: 17.172.238.224
Address: 17.172.238.226
etc.
This list changes every time I query DNS - but all of the addresses seem to be in the same 17.172.238.x range - but there's no guarantee that tomorrow or next week I'll see a different range.
For the test push server, however, I already get results in different subnets. Sometimes I get one set of addresses:
$ nslookup gateway.sandbox.push.apple.com
Non-authoritative answer:
canonical name = gateway.sandbox.push-apple.com.akadns.net.
Address: 17.149.34.66
Address: 17.149.34.65
and other times, I'll get these addresses:
Address: 17.172.233.65
Address: 17.172.233.66
My server that will use the Apple Push Notification Service will be behind a corporate firewall, and I'll need to open up ports 2195 and 2196 for the production and test gateways -- however, my firewall team requires specific IP Addresses instead of host names.
I'm worried that if I just ask the firewall team to allow the IP Addresses I've seen so far, then my server will simply stop working a day or a week from now when the DNS server decides to serve up a different range.
If anyone has a comprehensive list for both the production and test environments, I'd appreciate it.
Update: I've tried asking the firewall team to open Apple's entire IP block (17.0.0.0/8), but they won't do that for me -- I need to narrow down the addresses a little bit.
Final update - 10/16/2016
Even though this question is closed, I thought I'd add a note explaining my final solution - and it is not what anyone looking for an answer wants to hear. I could never get ahead of the constantly changing addresses used by the CDN, so I finally gave up and leased an external server from Rackspace. I got the smallest server possible, and the only thing running on it is a port-forwarder that listens on 2195 and 2916 and sends the connections to Apple.
I used a simple iptables configuration on the Rackspace server to only allow connections on 2195/2916 from my corporate gateway, and then had my firewall team open a path to the static IP address on the external server. The firewall team is happy, with implementing a single path, and the external server can connect to the entire 17.0.0.0/8 range used by Apple.
From Apple's documentation (emphasis on the interesting bit added):
Push providers, iOS devices, and Mac computers are often behind firewalls. To send notifications, you will need to have TCP port 2195 open. To reach the feedback service, you will need to have TCP port 2196 open. Devices and computers connecting to the push service over Wi-Fi will need to have TCP port 5223 open.
The IP address range for the push service is subject to change; the expectation is that providers will connect by hostname rather than IP address. The push service uses a load balancing scheme that yields a different IP address for the same hostname. However, the entire 17.0.0.0/8 address block is assigned to Apple, so you can specify that range in your firewall rules.
17.0.0.0/8 is CIDR notation for 17.0.0.1 to 17.255.255.254.
The official answer is, unfortunately, that there is no official answer :) -- unless you consider Apple's rather sloppy approach of simply allowing all traffic to 17.0.0.0/8. Apple developer support provided the same link to the documentation as vcsjones in the first answer.
For my particular situation, I have narrowed the IP addresses down to these ranges after checking DNS regularly for the last couple of weeks. Keep in mind that these are only valid for the midwest portion of the United States, since Apple's CDN will return a set of addresses closest to the server making the query.
For gateway.push.apple.com, I'm opening ports 2195 and 2196 on my firewall for:
17.149.35.0 / 24
17.172.238.0 / 24
For gateway.sandbox.push.apple.com, I'm opening ports 2195 and 2196 on my firewall for:
17.149.34.66
17.149.34.65
17.172.233.65
17.172.233.66
Since these addresses are obviously subject to change, I've built in some monitoring for my application to detect when the APNS servers are no longer reachable (and fall back to these address ranges instead of using DNS). It's not the ideal solution, but it will have work for now until I can work out a solution with my corporate network / firewall teams...
On our router we have the primary DNS set to a local IP, which is running Windows Server 2008 and the built in DNS server. We use this to resolve domains to local servers, if the domain is not founds locally we have forwarders set up to query external name servers.
The secondary DNS on the router is set to our ISP's primary DNS, incase the local DNS server is down.
The mac clients in our office pick up the DNS servers correctly from the router but it seems very random as to what DNS server it uses. For example, a local site would load up but some of the images would not. If I hard coded my DNS address to be the local DNS server everything would work fine.
So my question is, when would a mac client use the secondary DNS server? I though it'd only use it if the primary DNS was unavailable?
Thanks!
The general idea of a secondary DNS server was that in case the primary DNS server doesn't reply (e.g. it is offline, unreachable, restarting, etc.), the system can fall back to a secondary one, so it won't be unable to resolve DNS names during that time. Doesn't reply means "no reply at all", it will not ask the secondary when the primary one said that a name is unknown. Answering that a name is unknown is a reply.
The problem here is that DNS uses UDP and UDP is connectionless. So if a DNS server is offline, the system won't notice that other by not receiving a reply from it. As an UDP packet may as well get lost and the round-trip time (RTT) is unknown, it will have to resend the request a couple of times, every time waiting for several seconds, before it finally gets to the conclusion that this server is dead. This means it can take up to an entire minute and above to resolve a DNS name if the first DNS server dies.
As that seems unacceptable, different operating system developed different strategies to handle this in a better way. As both DNS servers are supposed to deliver the same result for the same domain (if not, your setup is actually flawed as the secondary should be a 1-to-1 replacement for the primary one), it shouldn't matter which one is being used. Some systems may send a request to the primary one but if no reply comes back within a few seconds, they don't resend to it but first try the secondary one (then they resend to the primary one and so on). Some may also query both at once, make the faster one win and then keep using that one for a while (until they start another race to see if it is still the faster one). Some may also prefer the primary one but do some kind of load balancing and switch to the secondary one if more than a certain amount of queries are currently pending on the primary one. Some will just alternate between them as a poor man's load balancing. All of this is actually allowed.
In your case, though, I'm afraid something is wrong with your primary server as by default, macOS will only use the primary one. If it constantly falls back to the secondary one, it may consider the primary one to be too slow. Every time that happens, the secondary server becomes the primary one, see this older knowlebase article. This cnet article explained how this can be disabled but I'm not sure this is still possible in current systems. I wasn't able to find any reference on this but IIRC from the very back of my head, Apple once mentioned on a WWDC that they are now more aggressive at DNS querying and may even try to contact multiple DNS servers at once with the fastest one winning in some cases but I might be wrong on this (maybe this was iOS only or so).
I googled this article which explains newer MacOS DNS search order. And this one which explains how to tweak it to obtain results that you desire.
Though the general idea is that it was never intended (in any OS) that first server is the one used and the second one is a backup. ( Even on windows, if first server for some reason doesn't answers very quickly, the second one will be queried.) It's wiser to regard server query order as unspecified.