I want to manually set/resolve DNS with specific DNS server, would that be possible somehow with <link> tags? my guessing is no, but why can't it be done?
I know there is this rel="dns-prefetch" href="https://example.com"
but why can't I manually set it and use something like:
<!-- use a specific server for example.com -->
<link rel="dns-resolve" href="example.com" value="31.139.62.106">
or with ajax do the following:
fetch('https://31.139.62.106/api/', {
headers: {
Host: 'example.com'
}
})
host is listed as one of the forbidden request header names at MDN. But why is it forbidden? What harm could it do?
For me it's just one of those historical reasoning made up in the 90s that I can't find the answer to... or I'm too stupid to figure out why... 🤷♂️
Not being able to specify it seems to do more harm to my own privacy.
Reason / background: I built a service today and used one of those public available WebSocket trackers built by some supporting WebTorrent developers out there.
(all doe it's completely unrelated to torrent stuff. Just used theres websocket trackers to match WebRTC peers for something other totally legit I have built).
I decided to try it out on a public municipality wifi hotspot today and found out that tracker.example.com was blocked by my ISP or some Router config. It must have been based on the domain name and not by ip address cuz later i found out that example.com was working and tracker.example.com did not. Both top & sub domain had the same ip address but I could surf to example.com but not tracker.example.com (same applied to 3 other public trackers)
To me it indicates that they are just snooping around at what I'm doing on there wifi and blocking any domain that starts with tracker. The message i got was something in lines with "blocked b/c copyright/privacy reason bla bla bla" - i can understand why but that is just so annoying!
After that i started lookin into dns over https - got to try it if that might solve it for the next time I visit the public wifi next week.
Related
My website suddenly stopped working.
When I search for the domain name in WHOIS websites it is showing the correct server ip address and correct DNS IP address.
I can reach the website by its IP address but somehow when I am trying the domain name in browser its not working and its showing "This site can’t be reached"!
There is no error in my server log.
I tried different browsers and different systems and it is same issue.
I am really confused. Even when I am sending GET requests with Postman to my domain, it not reachable but sending request to IP is working!
whois and DNS resolution are two separate things and one does not imply anything for the other, so in short, except in very specific cases, if you have a DNS resolution problem you should use DNS troubleshooting tools, not the whois and especially not web-based whois (the only relevant whois is the registry one).
Now you are giving so few details that noone can really help.
Among the possible ideas to check and probable problems:
you forgot to renew the domain, your registrar put it on hold or worse deleted it (that you can see in whois)
you did a change in the DNS resolution and now it does not work anymore, use online troubleshooting tools like Zonemaster or DNSViz; alternatively your registrar and/or webhosting company should be able to help (since you are neither giving here the domain name nor details about the troubleshooting you do: for DNS problems, the browser is not the first tool to use, look instead at dig).
in appear that the problem was DNS on our local system. we changed it to 8.8.8.8 and then we could access to our domain!
it's usually because you use an addon domain, not the main domain for hosting orders that are set up on cpanel whm
In I/O 2018 Google announced their new .app TLD and they said that it will be HTTPS only.
I thought that DNS just maps domain names to IP's.
How are they forcing HTTPS?
(a little offtopic here)
It is called HSTS Preloading, see https://hstspreload.org/
HSTS (HTTP Strict Transport Security) is a way for servers to reply to clients: please contact me over HTTPS only (see https://www.troyhunt.com/the-6-step-happy-path-to-https/ for examples). It enhances security but still does not solve one case: the first connection to a given server can happen over HTTP before the browser learns it should have done an HTTPS instead.
Hence come the "preloading" of HSTS.
Basically this is an hardcoded list embarked in all major browsers code
(see https://caniuse.com/#feat=stricttransportsecurity for compatibility depending on browser and version, or see at bottom for links to code[1]) that says which domains/TLD are HSTS enabled, which means no HTTP connection allowed to them at all.
Note that:
Anyone can submit names to this list by following some requirements, see https://hstspreload.org/#submission-requirements
Google (as it started with Chrome but it is now spread among browsers) welcome inclusion of TLDs and not only hostnames, see end of document at https://hstspreload.org/ ("TLD Preloading")
They already did add .DEV in the past (the TLD by itself is not live yet, but Google will launch it "soon") which broke many developers setup where they used (wrongly) a .DEV domain name to name their local resources and as soon as their browsers were updated with the newer HSTS preloading list, they refused to connect to their local .DEV host without HTTPS. You can find here and elsewhere (ex: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/) many horror stories of developers up in arms against that and also may people offering bad solutions for that (like disabling HSTS preloading which is a very bad idea).
Also when you buy a .APP domain name (and it will be same for .DEV), Google (as registry of .APP) made sure contractually with all registrars that they will, during checkout of a .APP domain name buy, display a prominent message saying something along the line of: ".APP is a secure TLD and websites will only work with an SSL certificate(sic); make sure to buy an SSL certificate" (SSL certificate is straight out of Google documentation and this is very sad to read out of them since it is a doubly wrong term, it should have been an "X.509 certificate" or, in order not to frighten anyone, at least a "certificate used for TLS communications", noone should use SSL anymore nowadays...).
By the way, .APP opened for the public at standard prices yesterday, May 8th.
Of course all of that is only related to web browsing. You could set any other kind of service, like email, on top of a .APP domain name, without any mandatory TLS (which of course is not a good idea nowadays but nothing will refrain you from doing that). For email, there is ongoing discussion to have basically HSTS but for MTAs, see https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/
[1] see some source codes with the HSTS preloading list:
https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsSTSPreloadList.inc
or you can use the API at https://hstspreload.com/ to learn if a name is on the list
It's just a policy. A domain name is a domain name, and DNS only cares about how the name is translated to other resources, like for example an IP address. Technically any IP address can be used together with any IP protocol (there are 256 to choose from, one of which is TCP) and when applicable, any port number (there are 65536 to choose from, two of which are HTTP and HTTPS respectively). There is no way to place restrictions on this via DNS, but of course the TLD registrar can attempt to do this via policy rules.
By trial and error I easily found an .app domain where HTTPS is not enforced:
curl -v -L http://foo.app/
This results in a couple of redirects, but none of them redirect to HTTPS, and the final response is a HTTP response from a GoDaddy address.
here is the situation,
we have a domain, let's say example.com
I have added a subdomain to the dns, chat.example.com
I have modified the Caddyfile inserting http://chat.example.com (it works fine)
However, rocket.chat is hosted on our local server, and it is behind the router provided by our ISP, which apparently is programmed to return its own home page if an address is typed that resolves to its external ip address. In other words, if a computer located inside our local network types http://chat.example.com, it gets the router home page (the one where you can configure it).
I have solved it by modifying the hosts file, but I would prefer a cleaner solution. Is there anything that I can do on the Caddyfile, perhaps allow him to reply on 2 interfaces (http://chat.example.com and http://192.168.1.x), or something else that I have not thought yet?
Thank you!
I have a Rails 3.0.x app, which displays a page containing the Yahoo Web Player. The player plays an audio file served by the Rails app, the controller that handles the file request uses send_data to send the mp3 file:
send_data content, :filename=>dsLabel, :type=>mimeType, :disposition => 'attachment'
(*) I've also tried disposition inline
This works fine on Safari, IE, and FF. However, in Opera you click the play button and the audio never plays, Yahoo's code is minified and a bit difficult to tell exactly what's wrong, but I've concluded this isn't javascript problem as far as I can tell.
One thing to note about the site is that when I'm locally on the same network at work, our DNS server resolves the site to a 10.x.x.x LAN IP, otherwise it resolves to a public IP.
In Opera if I open Preferences and add the hostname under Trusted Websites->Secure Internal Hosts then reload the page the audio plays fine. If I change my DNS to OpenDNS it also plays fine. I seem to be hitting a Opera security policy issue that I don't fully understand.
It seems to me that although internally my host resolves to a LAN IP, once loaded Opera thinks its a public site, and so the MP3 won't download, however it too resolves to the LAN IP so it doesn't seem like a public/private divergence.
I was hoping someone in the Stackoverflow community with better understanding of Opera security could explain the policy I'm seeing enforced here.
You may have ran into a "network type pinning" policy. Basically Opera will try to remember whether some site first resolved to a public or private IP.
This policy is meant to guard against attack where a site first sends you some code, then later re-configures itself to claim its IP address is internal. Say, attack.example.com serves a page that links to attack.example.com/intranet/menu.js , later when you re-visit attack.example.com pretends its IP is 10.0.0.1 where your intranet is running, and your intranet also happens to reference an /intranet/menu.js file. If menu.js now runs from cache it can do whatever it wants to on the intranet site. Attack completed.
Hence, Opera may not be applying the security policy according to what IP you're currently connecting to, but according to what IP it first saw the hostname resolve to. Sorry that this is a pretty obscure piece of state, but you're in a pretty small minority when you have some hostname that might resolve either to a private or a public address ;-)
I am facing a strange thing when i open some URL. The URL is (www.jobserve.com)
When i open this URL from my home, it opens some web page. Same url if i open from my office network, i get a entirely differnt URL, which is what i want.
Both, my home and office are in same city in India(3 Km. apart!) but somehow from my home network, i get served a entirely different page which is not what i am trying to open.(The page opening up in the office one is desired one. Office network has proxy/firewall which could be shielding the IP address for opening to outside world!).
My question is why is it happening so, because both accesses are happening from same country/city(but different ISPs though!), so there cannot be a country/IP specific host/content served differently than the global content of the same server.
So what could be happening here?
This raised another question in my mind(when i tried to find ip of the server using nslookup and domain name which returned error - "can't find www.jobserve.com/: Non-existent domain"):-
How can i find IP address of the web server using the domain name other than nslookup which is not working for this particular domain/url?
I recall there were some sites which find geographical location of server and show that pictorially, but i am not able to recall the url for that? Does anyone know?
Thanks,
-AD.
Some sites look at the incoming IP address, lookup where it's coming from and then take various actions they think relevant to you - usually, redirecting you to a more-local site.
Of course, lots of sites react if they think they've "seen you before." For example, there may be cookies that tell them something about you. Or, they may be reacting to your browser.
Sometimes, organizations look at the source IP address and if it's coming from a business they may respond differently than if it's from a non-business ("home") IP.
And, sometimes companies intercept IP traffic and edit it in various ways. This is not normally done to web pages, but if your employer isn't happy with your watching porn at work ( -smile- ), they may do something about it! ...China is well known for doing this type of interception...
I work for an UK based company and all my regional settings are UK based. Moreover the internet is itself from UK so all websites act as if I am from UK.
Google.com goes to google.co.uk
virgin, T mobile ads every where
Does this give any idea about why you are getting a different website in office?
For finding the IP address: don't use a slash. Just
nslookup www.jobserve.com
Alternatively, you can use a website like http://www.domaintools.com/ (there are many others, that's just the first one that comes to my mind).