In google cloud dns, we can create two zones with different names but the same dns names. Why is this necessary? How can dns names be the same?
In what cases may this be necessary?
A DNS zone can contain multiple subdomains of a particular domain (which you can create by adding record sets in your zone). In many circumstances, there's uneven traffic on different subdomains of a domain. Some high traffic prone subdomains of a domain are hosted in different zones than other subdomains, in order to provide separate management overhead to them. This way, multiple zones have to be created even when their domain names are the same.
For further reading on DNS zones, refer to this.
Related
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 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.
Simply put:
I have a domain called erik.com, two azure websites (east and west), and one traffic manager that is setup to manage the two azure websites.
When I take east offline (by throwing a non-2** status code) erik.com goes offline. This should not be the case! Right?
However, when I add a sub domain to the two azure websites (www.erik.com) then it works! I take one or the other offline and the traffic manager resolves to the available website.
I'm hearing/reading things that tell me that Traffic manager doesn't work with root domains like that... Say what?! Why?
As explained in the FAQs at https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#faq , Traffic Manager does not support 'naked' / apex domain names.
*Can I use Traffic Manager with a ‘naked’ (www-less) domain name?
Not currently.
The DNS CNAME record type is used to create a mapping from one DNS name to another name. As explained in the Traffic Manager example, Traffic Manager requires a DNS CNAME record to map the vanity DNS name (e.g. www.contoso.com) to the Traffic Manager profile DNS name (e.g. contoso.trafficmanager.net). In addition the Traffic Manager profile itself returns a second DNS CNAME to indicate which endpoint the client should connect to.
The DNS standards do not permit CNAMEs to co-exist with other DNS records of the same type. Since the apex (or root) of a DNS zone always contains two pre-existing DNS records (the SOA and the authoritative NS records), this means a CNAME record cannot be created at the zone apex without violating the DNS standards.
To work around this issue, we recommend that services using a naked (www-less) domain that want to use Traffic Manager should use an HTTP re-direct to direct traffic from the naked domain to a different URL, which can then use Traffic Manager. For example, the naked domain ‘contoso.com’ can re-direct users to ‘www.contoso.com’ which can then use Traffic Manager.
Full support for naked domains in Traffic Manager is tracked in our feature backlog. If you are interested in this feature please register your support by voting for it on our community feedback site.*
I am working with a company, developing and managing a web site for them.
I have control over the web servers, but the company is managing DNS for the domain.
Due to their security policy, the web servers are prohibited from issuing outbound email - they won't add the appropriate SPF/DKIM records to DNS to permit this. Instead, I've been told that they will "delegate" the authority of the domain to me by forwarding traffic to nameservers (of my choice), where I am responsible for creating new DNS records to handle that traffic. In these new DNS records, I would add in the appropriate SPF/DKIM records.
It is like I am managing the DNS, but the company still owns it.
The problem is very strange to me, and I am not familiar with the inner workings of nameservers. Is the relationship of a zone file to a domain name one-to-one? Would I need a second zone file registered somewhere to hold these new DNS records? Do I need direct control over the nameservers, or can I work with nameservers provided by a third-party hosting company?
Sorry for the lack of direction - this is new territory for me in a world that I'm already not that well-versed in.
Thanks in advance
The delegation is a DNS server owning a zone (ie. example.com) and announcing to everyone that a part of this zone (say deleg.example.com) is delegated to another DNS server which can define its own records as long as they are in the deleg.example.com zone.
In your case, it means that you will maintain a subdomain that will hold your NS and SPF/DKIM records. This subdomain behaves in a similar way as the main domain thus you will need a second DNS zone file (and another DNS server).
This is similar to what root servers do with top level domains (they own the com / net / whatever zones) and subdomains sold to companies / people (ie. google.com handles whatever lies in the google.com zone but does not affect the "com" zone).
How do I configure Bind to use multiple subdomains and multiple top level domains.
what am trying to do is this .example. and point this to my ipaddress.So that I can have many subdomains with as many top level domain, pointing to same server(example.com,example.org,example.net,example.de,example.fr) and on any of them i can have any numbers of subdomain.
if the internal ipaddress of the system bind9 is install on is 192.168.1.5
how do i configure this.
Thanks.
Multiple TLDs are managed by bind just as multiple 2nd level domains: add them to your master configuratoin, and have a zone file for each. What ip addresses you add A records for, and how often you use the same ip address, the nameserver doesn't care.
I'm assuming you want to introduce your own, privately uses TLDs.
For hosting domains delegated to your nameservers, you won't deal with top level domains. You will only deal with the domains which are delegated to your servers. Those are subzones of TLDs.
But in fact, in terms of configuration that makes hardly any difference.