I've only recently begun scratching the surface of hosting my own DNS, but I'm looking to do so in the hopes that I can facilitate my own reverse lookups.
My idea being that if I can manage my own DNS, I can give it tables I've complied about IP / FQDN relations so I can do a reverse lookups on dynamic ips (of which I know the FQDN of) without my ISP's support; I'd pair the return of something like an nslookup somewhere within my own hosted DNS then have that DNS server facilitate reverse DNS lookups for some programs that require the function (like for a CFEngine Hub)
Near as I can tell, the 'PRT' record is what I want to spoof; Right?
I'm wondering if there are better resources out in the wild to use. This and this are the best I've found about hosting DNS in this manner.
Any pitfalls I'm not seeing about trying to pursue this convoluted solution?
Reverse lookup requires the IP address owner to delegate reverse lookup DNS to you. Note that the owner here is not the DHCP recipient, but whoever assigns the IP address.
For a completely internal network, it would be possible to configure your own PTR records since you control the IP addresses being assigned.
On third party networks, the third party (who assigns IP addresses to you) would need to delegate reverse lookup for those IPs to you. In a dynamic IP situation, this delegation is unlikely because your IP comes out of a pool that is used for assigning IP addresses to many customers, not just you. Some ISPs allow allow programmatic access to configure reverse lookups, but this again seems unlikely for dynamic DNS for the same reason as delegation -- the addresses are part of pool assigned to any customer using it, not just you.
It might be possible to hack ("shadow"?) it by requiring your users / clients to use your DNS server and populating "fake" (since you don't actually have ownership of the IPs) PTR records.
Article on reverse lookup sequence and info.
http://www.dnsstuff.com/reverse-dns-faq
A way around this might be to create your own tool for looking through your forward lookup table for a specific IP address. However, this would be a custom tool separate from the usual DNS lookup tools like nslookup and dig.
Related
My understanding is that when querying a domain's DNS records, the response can vary depending on the client's IP address. Is there a simple way to obtain all DNS records for all possible IP addresses?
You can not.
The response can vary on many factors.
You can not from remote discover the business policies of a nameserver, or in fact any server. It can decide to reply 192.0.2.1 for odd hours and 192.0.2.11 for even ones, or any other non trivial business rule.
A more realistic one: there can be a service on 3 IP addresses. A nameserver may be programmed to reply with the IP address of the box being currently less loaded. Hence you will never be able to see those details remotely.
is there any possible way to prevent Joe Public from accessing the entire catalog of domain names on my web server, using a reverse nameserver lookup? Other than ghosting my nameservers. I use branded nameservers, so it's quite easy to reverse them, but is there a way I can stop this revealing how many and exactly which domains are hosted on those nameservers?
As a rule of thumb, DNS data is public. Anyone can build reverse and forward mapping databases which are independent of the public DNS (but use data from it). For example, Microsoft built such a reverse lookup service into its Bing search engine:
Bing reverse lookup for 151.101.1.69
At the time of writing, 151.101.1.69 was one of the IP addresses used by StackOverflow, and the search results reflect that.
In the Bing case, their DNS database probably was built from the activities of their web crawlers. Other databases use various zone file transfer programs as a starting point to look for domain names. Others use passive DNS replication.
There is no way to avoid this level of scrutiny once a service is offer to the public over the Internet.
I am curious, I am analyzing the DNS section for the website imgur.com. My doubt is that when I run "dig imgur.com" dig only returns an IP address, if I run again the same command dig returns another IP address or sometimes the same.
Another question:
By using dig www.imgur.com get a CNAME to another domain, is this normal?, Can someone explain to me?
Thanks
You should check Round-robin DNS.
Round Robin DNS is a technique of load distribution, load balancing,
or fault-tolerance provisioning multiple, redundant Internet Protocol
service hosts, e.g., Web server, FTP servers, by managing the Domain
Name System's (DNS) responses to address requests from client
computers according to an appropriate statistical model.
In its simplest implementation, Round-robin DNS works by responding to
DNS requests not only with a single potential IP address, but with one
out of a list of potential IP addresses corresponding to several
servers that host identical services. The order in which IP addresses
from the list are returned is the basis for the term round robin. With
each DNS response, the IP address sequence in the list is permuted.
Usually, basic IP clients attempt connections with the first address
returned from a DNS query, so that on different connection attempts,
clients would receive service from different providers, thus
distributing the overall load among servers.
I would like set DNS records visible from instances inside the Google cloud.
For example if I query DNS from my PC I'll get one IP; however if I query DNS from the instance I'll get another IP. (A record to be exact)
Ideally I'd like doing this in most sane/convenient way possible; since I can install caching DNS server on every instance and setup authorative results; and forward caching for the rest (I guess bind9 can do that, never tried it before). But this is configuration sync mess; and it's not elegant. I kinda assume there might exist a better way.
One solution is to use totally different zones for different sets of machines and use the DNS search path to select.
So for example you could set up
server1.internal.yourdomain.com IN A 1.2.3.4
server1.external.yourdomain.com IN A 5.6.7.8
Then set up your machines with resolv.conf containing either
search internal.yourdomain.com
or
search external.yourdomain.com
And then when you lookup server1 on such a machine it will return the address from the appropriate zone. This scheme means you don't need to rely complex routing or IP detection. You will be immune to incidents where internal or external IPs get leaked into each others result.
Of course this does mean that you aren't keeping any IP addresses secret, so make sure you have other security layers in place (you probably shouldn't rely on secret IPs for security anyway)
Assuming you want your VM instances to be able to query other instances by name, and retrieve the desired instance’s private IP, this is already baked into GCP.
Google Cloud Platform (GCP) Virtual Private Cloud (VPC) networks have an internal DNS service that allows you to use instance names instead of instance IP addresses to refer to Compute Engine virtual machine (VM) instances.
Each instance has a metadata server that also acts as a DNS resolver for that instance. DNS lookups are performed for instance names. The metadata server itself stores all DNS information for the local network and queries Google's public DNS servers for any addresses outside of the local network.
[snip]
An internal fully qualified domain name (FQDN) for an instance looks like this:
hostName.c.[PROJECT_ID].internal
You can always connect from one instance to another using this FQDN.
Otherwise, if you want to serve up entirely arbitrary records to a set of machines, you’ll need to serve those records yourself (perhaps using Cloud DNS). In this case, you’d need to reconfigure the resolv.conf file on those instances appropriately (although you can’t just change the file as you see fit). Note that you can't restrict queries to only your own machines, but as David also mentioned, security through obscurity isn't security at all.
Google Cloud DNS Private DNS was just announced to beta and does exactly what you need
I am new to Google Cloud DNS service. While still trying to understand the features of this service, a question popped up that though Google doesn't allow a user to create duplicate DNS A records, but how does it ensures that any other user or same user for other project is also not able to create a duplicate record?
For example. My DNS record
mywebsite.example.com may point to I.P 192.168.0.1
What will happen if another user who is also using Google cloud DNS service, creates a similar record for his project with either a different i.p address or different domain address?
For example:
mywebsite.example.com --> 192.168.0.2
or
diffwebsite.example.com --> 192.168.0.1
How will DNS lookup resolve in either case since the domain (example.com) is registered with a common registrar? Please help.
There is always one entity (person, organization, something like that) that controls a zone in DNS. If Google has control of example.org (do not use mydomain.org as your example, it is a perfectly valid existing domain that belongs to someone else), Google can fill it with whatever information they want. If they want to let their customers add exactly one A record per name in it, that's a choice they can make. It's up to Google to make sure that they don't allow creation of records that cause problems for their customers.
If you own example.org, you can put whatever you feel like in it. If you chose to have 42 A record for a name, you can. Someone looking up that name will pick one of the records more or less at random. Nobody will police what IP addresses you put in your A records. You can have records containing absolutely any IP address at all. Nobody will police what names in the zone you create (within technical constraints). You can have an entire dictionary of foul language, if you want.
If someone you have no relationship with owns example.org, you have no influence on what names and records exist in that zone. It would not be a very good idea to rely on anything in it.
Possibly something here answers your question. Possibly not. Your question is a bit confused, to be honest.
I believe the key here is the difference between a 'Registrar' and a DNS. In Registrar you set the DNS to be publicly used on the rest of the internet for your domain. You can do this only when you are the owner of that domain. DNS is the translator from a domain name to an IP.
Having in account this concepts, you can have two situations:
1) You are a domain owner: You will have your domain setup on 'Registrar' and your site will be accessible from the internet. If you use it on a Cloud DNS zone you will be able also to use all the provided features. No one will be able to modify that information to redirect traffic to other IP but the owner itself.
2) You are not the domain owner: You can configure zones using domains that might be owned by other person, but they will not be publicly accessible by domain name, this zones will only work on internal bases.
Every Cloud DNS resource lives within a Google Cloud Platform project, therefore the possible overlapping of domains is controlled internally by Google Cloud on a Project permission bases, meaning that even if someone has a zone using a domain exactly as yours, it won't be able to modify it as it doesn't have access to your project, and if you are the domain owner the traffic will only go to the name servers ( not Cloud DNS) defined on Registrar that will redirect the requests to the right IP.