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.
Related
I am getting a bit into protecting my website but someone keeps posting the origin-ip of my website. I've found out that this website is exposing it: http://www.crimeflare.org:82/cfs.html
after some extra research I found that this site has been online for a couple years but no info on how it is made or what technique it uses. Does anyone have a clue how this website gets the direct-connection IP address? Thanks in advance.
I can answer this question. It's really all due to domain history in a nutshell. In order to avoid domain history fetching websites, so-called CloudFlare resolvers and Crimeflare, you need to change your origin IP while under the banner of CloudFlare. Then to stay hidden you MUST not use the email services from your domain otherwise a simple MX record lookup will expose your origin IP. So this means you now need to use third-party email services. If you are using a VPS or bare metal you need to setup IPtables so that ALL IPs are blocked and just allow CloudFlare's IPs. This way IP scanners like Censys can't find your origin IP either since all IPs would be blocked except CloudFlare's forcing all connections to go through CloudFlare. Thankfully CloudFlare IPs don't change that often and they do publish the IP list at their website.
If you are using a shared account you'll want to make sure your shared account uses a shared IP and not a unique IP. With a shared IP your website is mixed with others and these CloudFlare resolver websites can't distinguish between who's who to get your origin IP.
There are some other very minor trivial things to also consider. One trivial possible vector for origin IP exposure is allowing remote content to be published via the website. Be it a remote avatar or file. The link used from this remote content has the possibility of resolving your origin IP behind CloudFlare.
If you are using a shared account you can help block direct IP connections and keep all connections going through CloudFlare in one of two ways. In an Apache or Litespeed SAPI, add the following to your htaccess file:
RewriteCond %{HTTP:CF-IPCountry} ^$
RewriteRule ^ - [F,L]
What that code does is check for the CloudFlare Geo location header in the request from CloudFlare and if not present the user gets a 403. Thus all connections must go through CloudFlare. In order for this to work, the IP Geo Location option has to be turned on in your CloudFlare dashboard under Network.
The other really unique and awesome way of doing this is by using CloudFlare Workers. You can read about that here: https://community.cloudflare.com/t/stop-cloudflare-bypassing-on-shared-hosting/91203
I use all of these methods myself with my websites minus the fact of not using a VPS. So far my origin IP is not shown in Crimeflare or other websites.
Best of luck.
They very much explain it on that very site:
There are sites on the web that specialize in collecting registration and nameserver data. [..] CloudFlare maintains around 391 nameservers, and customers must change the nameservers on their registration in order to use most services. Each customer's domain is assigned two nameservers. This makes it easier to verify which domains depend on CloudFlare, and helps us keep our domain lists relatively current.
In other words, they look at public nameserver data and filter out the domains that have their nameservers pointed at one of CloudFlare's nameservers.
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.
This issue came up as a result of SEO concerns, but having done some further research, it seems Google feels that IP/hosting location are now a weak signal for ranking, at best. So now I'm just curious, as I'm only familiar with networking on a basic level.
I have several sites hosted in the europe-west-1 region. Each site is on a compute engine instance with an external static IP assigned. I can ping the domains/IPs and then have my colleague in the UK ping the same and based on response time it's clear that the IP is ultimately resolving in Europe (probably Dublin, Ireland where it should be). But a DNS lookup of the same domain/IP lists the IP in Mountain View, CA? It always comes out like this: xxx.xxx.xxx.xxx.bc.googleusercontent.com. Is this Google acting like an ISP, and then the routing to Europe is behind the scenes? Why do none of the IPs show as resolving in the data center where the instances are hosted?
It sounds like you are conflating three concepts:
The domain registration for the googleusercontent.com reverse DNS
The SWIP record for the subnet
The routing decision to reach an IP
All three are independent. All GCE instance IP addresses have a reverse DNS entry that maps to xxx.xxx.xxx.xxx.bc.googleusercontent.com. This domain is under Google's control and therefore registered to the HQ in Mountain View.
The SWIP record / WHOIS entry denotes the administrative ownership of an IP address resp. its subnet. It's therefore also registered to the HQ in Mountain View.
Both of these do not reflect anything about physical location of the machine answering packets to an IP address nor the decisions on how packets are routed to the destination.
Google has a global network. Packets to a GCE instance will cross over to Google's network relatively close to the client. Since Google maintains a lot of peerings with ISPs worldwide, most of the time your packets will end up on Google's network directly from your ISP.
If you run a traceroute to your instance, you might see hops with airport codes in their reverse DNS names, especially when traversing peering points. The hops internal to Google usually do not hint any further at geographical location.
And finally, when the "proximity" or location of an IP address is discussed, most of the time the relevant metric is the latency or network distance to the host - not the geographical distance. (Although geographical distance sets a lower bound for latency as packets cannot go faster than the speed of light)
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.
We have several servers on AWS VPC, but all have a 'public' face via DNS, handled with Route53. The problem is that when one server looks up the address of another server via DNS, if the entry is an 'A' record, it gets the public IP, not the AWS 'private' IP, and transfers go via the external network address.
If on the other hand I configure the domain as a CNAME pointing the the AWS public DNS name, like this:
CNAME super.domain.com ec2-1-2-3-4.compute-1.amazonaws.com
then lookups from 'outside' the VPC get the real external IP address, and lookups from 'inside' get the local 10.x.x.x address. This is exactly as I want it. Now the problem comes that these servers need to send mail, and pretty much everyone (mailgun, mandrill, etc.) requires SPF and DKIM records. But you can't mix those TXT records with a CNAME.
I know I could use /etc/hosts files on the servers to pre-empt the DNS lookup and use A records, but there are 14 servers and growing, and every time one of them is restarted, I'd have to update all the hosts files - seems like a recipe for messing things up.
My question is this: Is there a way to set up AWS Route53 so I can take advantage of the automatic internal/external resolution of the Amazon public DNS name, and still provide effective SPF and DKIM records? I did ask this on the AWS forum, but didn't get any help there...
Mailgun is probably closest, in that you can use a subdomain for the SPK/DKIM records (e.g. mg.super.domain.com), which then doesn't clash with the CNAME records. But then you hit this problem, the solution to which appears to be an A record, and I'm back to having to maintain many records when the instance IP addresses change!