I have got one firewall, with a public IP (dynamic) provided by my ISP.
As the IP is dynamic, I registered a domain in the service NO-IP as not to worry whether the IP changes anymore.
The problem:
Looks like my ISP is also giving a name for that IP, so when I resolve it (standard DNS configured, such 8.8.8.8) it would resolve the name in favour of my ISP.
The key point:
¿Is there any way to "OVERRIDE" the name given by the ISP with the one registered in NO-IP, in order to ALWAYS resolve to the no-ip name?
Thanks!
Whatever you did with NO-IP/DDNS, it will have no effect on Reverse DNS lookup. Reverse DNS is controlled by whoever "owns" the IP address, usually your ISP, so they would have to change the record according to your request (or sub-delegate it to your DNS servers) which they will almost certainly not do since you have dynamic IP address.
Related
I'm serving an app that I want to be accessible from different devices in the same network. From what I've seen, I can do that by accessing the server's private IP. But the other devices have no way of knowing that. Is there a way to setup something like an internal domain?
For the purposes of this answer I'll refer to HTTP as the protocol, which is by far the widest and most frequently used. If it's something else, the principles are the same.
The first option to consider is 'just' using the IP address. https://192.168.0.3/ isn't so bad to remember; IPv6 is worse, being longer. You could email, chat, or otherwise link your users to the address so you wouldn't have to remember it. Most home networks use DHCP by default, but usually give the same address to the same MAC address unless there's so much device turnover that the ip pool is depleted, so the addresses rarely change in practice. Additionally, most routers leave IP space that is not part of the DHCP pool and you can statically configure that on your server to take any IP changes out of the equation.
The appeal of the IP address method is that it's low investment. It's ready to work now. The downside is that if your IP address does change, your clients now can't reach the service as currently configured. Enter DNS. DNS comes into the equation when the DHCP-provided DNS servers are used by clients to query for the record of names such as stackoverflow.com.
The DNS servers on a home network are usually ones provided by the ISP (or hopefully, because ISPs are typically bad at providing good DNS, you'd point at cloudflare (1.1.1.1) or Google (8.8.8.8, 8.8.4.4) or some other decent DNS provider for public DNS. Either way, the point is, your currently configured DNS servers are probably not able to be configured to serve records of your devising.
That leaves you with 4 options: public DNS, private DNS server, "borrowed" DNS domains, or /etc/hosts.
Public DNS can serve a private IP address, and this is probably the next easiest solution. You'll have to pay to register a domain and buy dns hosting (many dns registrars provide dns service for free). You can then own a name like myhouse.net and add an "A" (address) record for app.myhouse.net with a value of your local IP address. Any public query for the name will look up to your internal IP address, but that's not much of a disclosure (they knew you were on one of the RFC 1918 address spaces) and they could spearfish and xss you just as easily with a domain name, so for home use, I'd call publishing a private ipv4 address to public DNS can essentially be done with impunity. Note these address spaces are non routable - they can't be accessed from the internet and conflict with many other folks' home network IP space as well.
Private DNS. As we've discussed, you probably don't have a DNS server in your network, or you wouldn't be asking this question. You're using public DNS servers for resolution. So there's nowhere for you to define a domain and records like app.myhouse.local. The first step to private DNS would be to create or acquire a server which you can provide via DHCP to your local clients, and can be configured with your private domain records. This server would be configured to also do public queries recursively, so it could be used for all DNS traffic on the network. This way, you get to "invent" your own "private" domain that's not part of public knowledge. This is obviously heavy touch. You might be able to find some sort of service that would allow you to do a thing like this online, otherwise you'll need to install software like Bind or equivalent. On the plus side, it's free, and knowing more about DNS is always a good investment.
"Borowed" DNS - by this I refer to services like https://www.noip.com/ which will allow you to create a host record under one of their domains. They often also include software and an API by means of which you can update the record to point to your dynamic IP address. I do not know whether you could store a private IP address in these services. The domain name would be one of theirs, not one of your choosing (something like myhouse.noip.com) But they're often cheap or free, and they do solve the immediate problem of creating a DNS record. Again, the record would be a private address in public dns and could be queried from anywhere in the world.
/etc/hosts: this file (which also exists in windows, interestingly enough) provides a local system an alternative name resolution system to DNS. It typically takes precedence over DNS (ie it's checked first) and could be used to define a record on most of your hosts. I don't know how you'd do it on tablets or phones, and it's obviously something you'd have to set up in advance - not a great fit for your use case.
Looking at these options, I'd recommend you consider one of the borrowed dns domain providers first. IF that seems good, you're done. If you can't justify putting your private IP address into public DNS, that will force you to go that route. Maybe just using the IP address will work fine.
I am now just starting to understand Httpcontexts and server side logic. Total beginner.
I have understood how to read the http requests from a client and get the remote IP etc.
I came across the hostname property.
I believe hostname and domain are completely different.
My undersanding is that stackoverflow is the domain name.
Given its widespread reach, stackoverflow can have multiple servers and hence multiple ip addresses.
So is there a way to determine to which server a client is requesting to in asp.net core 2.0?
You are correct that stackoverflow.com is a domain name. A domain name points to an IP address. That's called DNS. stackoverflow.com points to one single IP address not multiple. There's probably a load balancer at that IP address which then points you to an available server, which is internal you can't see that, but that's another story.
If you ping stackoverflow.com you get:
The whole point of DNS is to not use IP address but a domain name.
I'm not sure why you would want to see the IP. Maybe this stackoverflow question can help: Resolve HostName to IP
So I am setting up my at home server, and I am setting up my static ip address. I noticed that I need to input my ISP's DNS servers. Why? It does not seem to list a DNS server for DHCP. If I truly have a static ip address (which RCN, my ISP, claims that I have), then why do I need a DNS? What is being resolved at the DNS? Thank you in advance.
As you said you need DNS server/s to resolve hostnames to IP addresses. If you do not use a DNS server your PC/router wouldn't know what's the IP of the sites you want to visit (unless you hardcode all the addresses, of course). This are resolving/recursive DNS servers, not authoritative DNS servers.
When you do not use DHCP these servers are not automatically obtained, that is why you need to manually put them.
I am logging every user's IP when they access the company's page.
There are two ways to access the page from inside the local network:
http://company/webpage
and
https://webpage.company.com
What bugs me is that even when the users use the https global IP, their accesses are still recorded on database with their IP as 10.50.1.12 or 10.50.1.100.
Does that means that the browser or something else is redirecting the https://webpage.company.com to company/webpage? Or does that mean that I'm using a flawed method to log the users IP?
Another way to ask my question (just to make sure I'm being clear): if I'm accessing my Internet web page from inside the LAN network, am I effectively going outside my network and then back? If not, where am I going wrong with my logging?
Code used to log user's IP:
user.LastIP = HttpContext.Current.Request.UserHostAddress;
I'm curious about this because I want to make sure the users inside the company will access the page using exclusively the LAN Network. The goal is to save bandwidth usage, which is scarce.
Edit:
Pinging the https://webpage.company.com from inside the LAN network will result in a reply from a global IP address like 194.xxx.xxx.xxx. So I'm clearly getting the user's IP wrongly. What would be the ideal way of retrieving the IP from the page accessing entity?
Access to http://company/webpage will result in a DNS lookup of the host name "company". To resolve this, DNS will need a fully qualified domain name (fqdn), so it will add a top level domain (according to the configured search list in the client). In this example, it seems fair to assume that the fqdn will be "company.com". This, in turn, may very well resolve to the same IP address as the "webpage.company.com". You can check this by using dns lookup utilities like 'nslookup' and 'dig', or simply by using 'ping company' and 'ping webpage.company.com'.
The users IP addresses you mention, 10.50.1.12 and 10.50.1.100, seems to be the local IP addresses of the client hosts. I base this assumption on the fact that these IP addresses come from the RFC-1918 address range which is used for internal addresses. My guess is that these are the correct IP addresses, and that your logging works fine.
The users IP address you will log from accessing 'http://company/webpage' and 'https://webpage.company.com' should in most cases be the same. You can see it this way: it doesn't matter what the target URL is, traffic is still coming from the same host, the same IP address.
In any case, you most probably don't need to worry about any traffic leaving your local network.
I'm working with Microchip's TCP/IP stack and the host name of my device is not being broadcasted, although I can access it using its DHCP assigned IP.
So the question is, what is the protocol that a network device uses to broadcast its host name, so that when I see a list of devices in a network I can identify it by name?
Is it the NetBIOS name service or something else? Thanks in advance.
The most network-agnostic way to specify a hostname for a host on the network is through DNS, which your device itself cannot control, but all is not lost.
In most environments, the DHCP and DNS servers are tied (AD in Windows networks, DNSMasq on linux, etc...) so your best option is to rely on this behaviour. When you request an IP using DHCP, the DHCP protocol allows you to specify the hostname you'd like to use and if the network is set up to allow DNS entries to be created and maintained by the DNS server, the hostname you send during your DHCP request will typically be used.
The DHCP parameter is called 'Hostname'. The Network protocol documentation for this parameter is located in RFC 2132, and explained here.
There is WINS (based on NetBIOS) that supports this functionality.
There is ZeroConf/Bonjour that offer a "service advertisement" protocol but I am guessing that's not what you are after here.
In "normal" IP based networks, name resolution would go through a DNS layer: the DNS servers propagate their databases (if instructed too of course) but there is no concept of "broadcasting" at this layer.
I guess you've solved this by now but I modified the dchp.c file in the Microchip stack and added the following to the options part of _DHCPSend().
// host name
i = strlen(AppConfig.NetBIOSName);
UDPPut(12); //host name code
UDPPut(i); //length
UDPPutString(AppConfig.NetBIOSName);
This worked for me.