I am using a websocket connection with an ip address like ws://172.168.41.61. It is working fine. Now I want use the same service from an Android/IOS application, so I purchased a domain say, mydomain.example. Now I linked the above ip to this url: api.mydomain.example. But when I tried to use ws://api.mydomain.example it is not working as a replacement for the above IP address.
I have following 2 concerns:
Is it safe to deploy IP address (172.168.41.61) directly in the app for any API or websocket connection. (I guess no, because IP may be difficult to manage or bad practice, offcourse IP will be static)
Although I have tested the domain (api.mydomain.example) to IP conversion and the IP address is same as expected, then why can't I use the domain like ws://api.mydomain.example as a replacement for ws://172.168.41.61?
This the site from where I check the domain to IP conversion:
https://ipinfo.info/html/ip_checker.php
It is working now. There may be 2-3 issues because of which it was not working earlier:
Domain pointing takes some time. (But I waited for atleast 1-2 hour after pointing the domain and still it didn't work). May be it take more than that, sometimes.
May due to cache issue, when I tried the first time, the no response thing is cached and it continued to show the same thing even after 2-3 hour.
Although I confirmed the domain to IP is converting fine, still the cache in the my system was preventing me to access the original resource.
Thanks
Related
So I'm trying to deploy a Ghost blog into a Google Cloud vm instance and I can't get it to work. Part of the problem, I think, is that I haven't set up the DNS correctly. I bought farodefe.org via Google Domains and I tried to configure it following this tutorial, and it worked... partially. I used DIG in Ubuntu to try and verify that my DNS configuration. Here are the results:
enter image description here
As seen in the image above, when I do:
dig farodefe.org
and/or
dig www.farodefe.org
I do receive an answer to my query.
But then I do dig http://www.farodefe.org and I receive nothing.
enter image description here
Why is this happening and how can I fix it?
Thanks in advance!
But then I do dig http://www.farodefe.org
But this does not mean anything, or at least certainly not what you think. The DNS has no concept of URLs, only names.
So you are doing here a query for the name http://www.farodefe.org (which is possible in the DNS, but not just for an A record type which is the default one used by dig), which is certainly not what you had in mind.
Part of the problem, I think, is that I haven't set up the DNS correctly.
Don't think, test. If you are not familiar with DNS, use good online troubleshooting tools, like DNSViz. If you see any red things in the output, your DNS configuration needs to be fixed. Alternatively, your DNS provider should be able to help you.
DNS wise, you first need to understand the difference between authoritative and recursive nameservers and service, and hence when doing tests you need to first send your queries to the authoritative nameservers (which is what DNSViz does) and only when that is ok and you still have problems, then you query recursive nameservers as needed.
If you want to understand more, also learn about the OSI/Internet layers, and how HTTP is layered on top of TCP and IP, which are some protocols among others, and how the DNS (a service itself using TCP and UDP) is used to map data, and in a web setting, to map a given hostname (website) to one or more IPv4 or IPv6 addresses, for an HTTP client (like a browser) to be able to initiate its TCP/IP connection.
My client has a website that is showing some strange behavior. The site is built in ASP.Net and used to be hosted on their internal network. It's now been moved to a different server outside their network. They have other sites hosted on the same server, some built using DotNetNuke, and some classic ASP. All these sites are hosted on one application server, with a database (SQL Server 2008) on a separate server (which is on the same network as the application server). They share the application server, and the database server.
Now that this site has been moved to the outside server, they can't access it. I can, and so can others that I work with (from different IPs, across the country). But the client can't from their network. They can access the landing page subsite.clientdomain.com (no db access), but nothing else. So, for instance, there's a link to subsite.clientdomain.com/folder. When they click that link, the URL changes to subsite.com/folder, which does not work. For myself and others not at the client site, the URL does not change and opens with no problems.
I didn't write the site, and didn't even know it existed before this problem cropped up, so I know very little more than this. Any help is appreciated.
I'm going to go with Martijn B's answer. There's a DNS issue on the internal network. Somewhere on of the DNS servers is a definition that maps http://companywebsite to an ip address like 192.168.1.20 or whatever.
I would open a command prompt on your PC and type
ping new_website_name.com
Take a look at the IP address that comes back. You can also do an nslookup on new_website_name.com that will give you more information. If you (person A) gets one IP address and Person B (inside the network) gets a different IP address....there is definitely a DNS issue on the internal network.
You're going to have to do some network tracing to determine exactly where any redirection is occurring. Given that the problem is only manifested in certain locations, it is likely that it is a function of network configuration in that location (as previously suggested). Without understanding exactly what redirection is occurring, it would be unwise to make configuration changes that might make the problem worse or introduce new issues.
A DNS server cannot AFAIK redirect to a different URL. So something is redirecting from subsite.clientdomain.com/folder to subsite.com/folder, which could be caused by a HTTP redirect. This can be triggered by the software/website itself or by IIS.
I have an ASP.NET application that I use to read the contents of a web page by a HttpWebRequest frequently. There's no problem with the remote address and my application is always working fine.
While I don't change anything, sometimes (about once a day) I get this error:
the remote name could not be resolved.
Why a previously resolved DNS name sometimes fails to be resolved?
The intermittent nature of this is going to be extremely difficult to resolve and it's going to take a configuration change instead of a code solution. (hint: read everything ;)
I would guess that the remote servers DNS is set to expire pretty often. Probably daily or maybe even every 12 hours or so. This is the TTL (time to live) setting. Admins sometimes set this to an artificially low level if they need the ability to quickly move the site to a new server.
You can determine how often it expires by going to a command prompt and running:
nslookup
set debug
www.theserverdomain.com
At the top of this will be a section that says "AUTHORITY RECORDS:" with an item under it that says "ttl".
Now, (and I'm making an educated guess here), what's probably happening when you query your DNS server to resolve that host name your server will have this value cached.
However, once it expires the your server will have to contact another server upstream to get the ip address resolution, called DNS forwarding. If there are a lot of hops between yours and the remote server OR if one of the DNS servers between the sites is overloaded then it could timeout and send back the message you are receiving.
If this is true then the ONLY thing you can do is hardcode the DNS and IP address combination in your web servers hosts file. This is usually at C:\Windows\System32\drivers\etc and is a file named "hosts". There is an example on how to properly edit this within the file itself.
Once you create the host mapping in that file, your web server will no longer have to contact the DNS server to perform name resolution and it won't matter what the TTL is set to.
The only danger here is if they move the web site to a new IP address. At which point you could simply update your hosts file again...
The first thing I would check is if DNS is no longer correctly configured or malfunctioning.
Try (from a Windows command line)
nslookup MyDnsNameHere
and see if you get the IP you would expect.
I'm developing a network application which should be capable of contact DNS servers.
I was wondering what would be the best way to do it. And browsers came to my mind.
For example, how Firefox or Chrome resolve the Domain names i put in the URL bar?
I mean, i type http://www.google.com, how does it know that has to make a TCP request to the IP 209.85.195.104?
Thanks!
In the simplest scenario, browsers would use a function such as gethostbyname() to resolve names to addresses. However, this function is not always implemented in such a way that's convenient for a browser (it usually blocks until it gets an answer).
Browsers today are starting to use "DNS prefetch", where the browser will send DNS requests directly to a DNS server as the page is loading, to resolve addresses before the user clicks on the next link. That way, the user doesn't have to wait for name resolution when they click, and the browsing experience appears faster.
Web browser send request to DNS server. Server send list of associate addresses (if domain name record do have, several IP addresses - example is cnn.com with several IPv4 and IPv6 addresses).I am not sure if this addresses store browser or Operating systems but if browser use first address and don t get answer he will use another address from list. I read somewhere that it waits max 30 seconds until he use another address from list.
I have a web application that should behave differently for internal users than external ones. The web application is available over the Internet, and therefore obviously to the internal users as well.
All the users are anonymous, not authenticated, but the page should render differently for internal users than external. What I'm doing in my code is use Request.UserHostName and then Dns.GetHostEntry. The result is then compared to a setting in my web.config (that holds something like *.mydomain.local) . If the comparison gives a positive result then I render the HTML that the internal user should see otherwise I render the HTML the external user should see.
However, my problem is that I don't always get the expected value from Request.UserHostName. on the development site I get the IP-number (?) of the machine running the browser but on the customer site I don't get the IP-number of the user machine, I get some other IP-number. The browsers don't have any proxies set or anything like that.
Should I be using something else than Request.UserHostName?
I recommend using IP addresses as well. I'm dealing with this exact same situation setting up an authentication system right now as well and the conditions described by Epso and Robin M are exactly what is happening. External users coming to the site give me their actual IP address while all internal users provide the IP of the gateway machine(router) on to the private subnet the webservers sit on.
To deal with it I just check for that one IP. If I get the IP of the gateway, I provide the internal access. If I get anything else they get the external one which requires additional authentication in my case. In yours, it would just mean a different interface.
Try Request.UserHostAddress, which returns the client's IP address. Assuming your internal network uses IP addresses reserved for LANs, it should be relatively simple to check if an IP is internal or external.
There might be a firewall that is doing some sort of NAT, to enable inside clients to use the external dns-name to reach the server.
Is the IP-number you get on customer site the same at the external customer-server ip? In that case you can hard code for that one IP-address. All internal computers behind that firewall will appear to have to same ip-address and you can classify them as "internal".
It looks like you're being returned a public facing IP Address. Get the user to go to http://www.myipaddress.com . If this is the same as the IP Address returned to your software, then this is definitely the case.
The only solution I can see to get around this is to either get them to connect to the machine holding the asp.net application via a VPN, or to use some other kind of authentication. The latter is probably the best option.
It does sound like there is a proxy between users and the server on the customer site (it doesn't need to be configured in the browser). It may be an internal or external proxy depending on your network configuration.
I would avoid using the UserHostName for what is effectively authentication as it is presented by the browser duing the request and would be easy to spoof. IP address would be much more effective as it's difficult to spoof an IP address in a TCP/IP connection (and maintain a connection). It's still weak authentication but may be sufficient in this scenario.
Even if you are using IP address, if there's a NAT proxy between client and server, you may have to accept that anything coming through that proxy is trusted (I'm assuming that external/untrusted clients don't come through that proxy).
If that isn't acceptable, you're back to other methods of authentication. Rather than requiring a logon or VPN connection, you might consider a permanent cookie or client certificates and only give those to internal clients but you would need some way of delivering those to the client. You could certainly deliver a permanent cookie based on a one-time logon. Cookies can be spoofed in a similar way in that the UserHostName can be however you've got a better opportunity to create a cookie value that is less guessable than a domain name.