Show DNS Resolution
Opened this issue · 10 comments
There should be a section for DNS resolution. As some people might change DNS, it would be great to see what IP address is being queried as well as the DNS resolvers being used.
Lastly, allow choosing of Google or Cloudflare DNS resolver ;) You can clear Google's DNS resolver cache via https://developers.google.com/speed/public-dns/cache
@jordantrizz , interesting idea. At the moment, the DNS resolution is based on whatever the underlying server is set up with. If I understand correctly, you would like to get the origin IP address if possible?
Well, you should probably use something like Google or Cloudflare for resolution versus the underlying server to avoid cache issues. Just a thought.
If you're talking about the origin IP from Cloudflare, then no.
Showing a DNS resolution section would just show how the domain was resolved, what IPs it was using. That's all, it helps with potential troubleshooting. Also, if there are multiple IP's you should be querying all of them.
I'll keep that in mind. Ideally, I'd like to move to some managed LAMP/LAMP stack to execute PHP so that I can make the API scalable and redundant across services.
It's true that getting the origin IP could be of help. I thought that it was not super-obvious since many services like CF are designed to hide the IP, but if there's a demand for it, why not!
Awesome! Containers would be the best bet. Start and stop as many instances as you need. You should reach out to Simon from snapshooter.com smart dude. I also think you could build an API that is not in PHP that is more performant.
I'm not talking about the origin IP for Cloudflare. I'm talking about simple DNS tracing like this tool https://simpledns.plus/lookup-dg
- Check name servers for the domain name and display them to the user. This is a good check, some people just don't know if they pointed their domains correctly.
- Query the domain name @ each name server and show each response. It's possible one name server lags behind another, although rare. But another issue that might affect caching. If both your name servers point to different IP's you're getting a different response from each.
- Make note of all IP's returned and run a test on each and provide the results. This is important to see if one or more servers are showing different information.
A couple of other ideas.
- If someone puts in an http:// URL and there is a redirect, you're not following it. Instead output the redirect with headers and then following the redirect up to a maximum of 5 redirects.
- Entering in the full URL isn't a good idea. Only ask for the URL without the URL scheme (http:// or https://). This would help with your overall code. See https://www.ssllabs.com/ssltest/
- Once a URL has been tested, it should be cached and then an option to re-test. Similar to GTMetrix. Stops abuse :)
- Allow listing listing of domain names and URL's that are tested like https://www.ssllabs.com/ssltest/
Also, this repository should be renamed to ismypagecacheddotcom versus ismysitecached :) Little confusing.
BYE!
DNS resolution: If you try the DNS tracing on http://ismypagecached.com/ it cannot find the real IP address because CF masks it. The A-records it sends back are CF's IPs, and not the server's IP. The main worry I'm having with the DNS lookup is that it can make the request execution much slower, and clobber concurrency (1000s of req/mn).
PHP: true, the project started as PHP, but if there's a need I could even rewrite it to work as Cloudflare workers or something more efficient. But for now, it'll do and the cool thing with APIs is that the back-end can be overhauled completely.
Redirect: yes, there's a possibility that the URL gets a 301 or something like that (perhaps root redirected to www). For now, the 301 is detected and visible in the headers, but the tool returns a 200 + destination caching info. Optionally, could return 301 + caching info. I will check with users and it's possible to update the API silently.
Potential abuse: absolutely. Any test or "workload" can be cached at several levels. For the public rollout, the API Gateway will be responsible for this, counting spent calls, sending back remaining calls, etc. It could be as simple as NGINX SR Cache, CF, or Fastly for the www site. For now, people have been reasonable.
listing of domain names: why?
DNS resolution: I think you're misunderstanding the statement. Just return the IPS in DNS, there is no need to find the origin. Are you not using threads? Sending requests to be processed and then checking back when they're done? If you want to scale then moving to threads and queue system will be your best bet. If it's not DNS slowing you down, it's bad domains or hung web servers.
PHP: Nodejs or Go :)
Redirect: it's detected and then stops, it doesn't proceed to the redirection :)
Potential Abuse: I shouldn't have said cache. SSL Labs doesn't "cache" the test. It stores the test for 12 hours and you can re-submit the test via a click of a button during the 12 hours. Once the 12 hours lapse the test is discarded.
- I'm not sure what the use case is if the IP is not recognizable to the user? If you want, show me an example of what you'd like to see from one of your sites.
- For threading, I could use GuzzleHttp (maybe) if it came to it. For now, it's not part of the core needs. For now, a simple timeout works.
- Redirect: thanks for your feedback. I'll see what happens in the real world before changing the current behavior.
- Cache: oh, You'd like to be able to save the test with a random URL like
test.ismypagecached.com/tests/dwikuyfgwuerygf/? If yes, I did think of it and it's definitely possible to store all the data in a DB and re-display it for sharing purposes, etc. For now, you're the first one who asked for it, but that's definitely under consideration as I thought these records could be used for development/debug/sharing purposes. In the real world though I've never seen the need for that, yet.
project was been renamed! ^^
The use case would be troubleshooting. The more information the better :) Just like Chrome's web developer tool, being able to dig deeper helps :)
Queues -> https://laravel.com/docs/8.x/queues#connections-vs-queues
Of course. Can't argue against that. I'll mark this as a feature request so it stays on the radar.