I would like to know how to point mydomain.it to my dedicated server.
I explain my situation:
I have a Dedicated server on SingleHop.
I have the domain "mydomain.it" on Siteground.
I created on my Dedicated server the nameserver:
ns1.mydomain.it with IP 1.2.3.4 and
ns2.mydomain.it. with IP 1.2.3.5
Now, I wish to control all DNS settings on my dedicated server because of SPF record and DKIM record and SSL Certification, but I can't tell Siteground to point the IP 1.2.3.4 and 1.2.3.5 on my nameservers, because there is only space for the nameservers text (ns1.mydomain.it and ns2.mydomain.it) and there is not space for the IP field.
Without the IP, the domain's nameservers can't point to my dedicated server, and I can't manage DNS settings. So I ask myself what I could do for make sense to this story.
There is a way to do this?
Please help me,
Thank you.
Michele
When the DNS system was first conceived there were two addressing mechanisms that were used. The 32 bit IP Address, and the 16 bit octal Chaos Address. To make these systems easier to administer the NS record is specified as being a name rather than an address. (otherwise you would need different names for each protocol)
As it turned out, that wasn't needed as Chaos quickly died out (at least as an addressing scheme) but the original idea of having a name that then needs to be resolved to an address remains.
For this reason you can only specify a fully qualified domain name in the NS record. There are mechanisms that you can use if the domain name is on the domain you wish to create the record for (glue records) but that is quite a complicated aspect of DNS.
Aside from that though, I would say that it is very rarely a good idea to run your own name server. It is an extremely complicated - and expensive - thing to do correctly.
Weighing that against the simplicity and negligible cost of using a service to host your domain name. Who will invariably provide a global DNS infrastructure to ensure that your domain is constantly available.
Finally the majority of DNS Services all offer easy configuration of DKIM and SPF (SSL isn't something that is provided at the DNS level, it is merely part of the lookup to validate it)
Related
I'm trying to get all the domains linked to a record like here
http://viewdns.info/reverseip/?host=23.227.38.68&t=1 but I'm getting no luck with dig 23.227.38.68 or nslookup 23.227.38.68. Any idea what I'm doing wrong?
The design of DNS does not support discovering every domain associated with a certain IP address. You may be able to retrieve one or more DNS names associated with the IP address through reverse IP lookup (PTR records), but does not necessarily give you all domains. In fact, it rarely will.
This is because the information you seek is scattered throughout the global DNS network and there is no single authoritative node in the network that has this information. If you think about it, you can point the DNS A record of your own domain to the IP of stackoverflow.com and that's perfectly valid, but anyone seeking to know this would have to find your DNS servers to figure this out. DNS does not provide any pointers for this, though.
Yet, certain "passive DNS" services (probably including viewdns.info) seem to overcome this limitation. These services all work by aggregating DNS data seen in the wild one way or another. At least one of these services works by monitoring DNS traffic passing through major DNS resolvers, building a database from DNS queries. For instance, if someone looks up yourdomain.com that points to 1.2.3.4 and the DNS query happens to pass through the monitored resolver, they take note of that. If a query for anotherdomain.com is seen later and it also resolves to 1.2.3.4, now they have two domains associated with 1.2.3.4, and so on. Note that due to the above, none of the passive DNS services are complete or real-time (they can get pretty close to either, though).
German Mail Providers like GMX or T-Online are blocking my emails. A support guy from GMX said the a-record for mail would be missing. I added it.
Now I checked this site and got 5 warnings http://mxtoolbox.com/domain/x-invest.net/ I also added a SPF record, but there are still problems with some providers. From some providers I even did not get any mailer daemons.
My IP adress or domain is not blacklisted by any of those providers.
I am worried about doing the DNS setup wrong on my apache server, but actually it should be a copy of my setup, I used with another server before.
Here is a screenshot of all I have at this time:
Maybe you could help me out, if I was missing something important or even have wrong dns record.
PS. Sorry, hope the screenshot is okay for the moderation. I was not able to copy the records - It was not my intention to spam my domain.
Clicking your link, the only ones I'd be real concerned are (in my order of priority):
Primary Name Server Not Listed At Parent
Name Servers are on the Same Subnet
The Certificate is invalid
First one indicates that your nameserver listed in the SOA record is not included at the level above you:
x-invest.net. 86400 IN SOA ns1.secureserver.net. info.s50-62-56-203.secureserver.net. 2015061806 86400 7200 3600000 86400
Which means that the server you listed as the authority for your domain does not match what the internet says is the authority.
Second one is more an issue if you have any sort of fault tolerance worries. If the ISP drops your subnet or circuit for some reason, your sites will not resolve.
Third one is only an issue if you have customers that are concerned about the security of their connection. The big red X in the browser address bar is very discouraging to customers and their credit cards.
EDIT (answer comment):
An authoritative DNS server is one that actually contains the information being requested: reference
DNS being a hierarchical structure, so it follows that the chain to get to your domain needs to be complete from the top down in most cases. You can bypass that structure in some circumstances, like private DNS domains being hosted by internal corporate servers. Internal machines point to the internal DNS servers, which host domains that may not be accessible to the outside, but will also do recursive queries out to the internet as an example.
Ive been reading alot about nameserver the last days. For our websites we want to optimize the waiting time of the visitors that is caused by our namserver. I will have some questions about IP Anycast and the general function of the DNS. Let me start by explaining what I understood the DNS works from user side:
User X wants to visit www.example.com, the following steps happen to get the IP address:
1.Step: User X sends request to the Nameserver of his ISP or nameserver by choice.(recursive nameserver)
2.Step: If the adress is not found, the recursive nameserver will send a request to one of the 13 root nameserver to get the nameserver for the .com TLD
3.Step: Query the .com nameserver to get the auhorative nameserver
4.Step: Query the auhorative nameserver to get the ip-address for www.example.com
First I realized that as a owner of a website you can only optimize Step number 4 and all other steps are not in our hands.
I came across IP Anycast nameserver (what is also used for the 13root nameservers) and totally understand the concept of distributed machines. But what I dont understand is where the decision logic, to which of the distributed machines the user will be send, according to his "position",is implemented? I mean when i buy an anycast nameserver, the logic should be implemented on the .com nameserver (Step 3), so that this nameserver decides to which machine of my anycast nameserver the user will be send.
For me thats really hard to understand and im asking myself if it really works that way? I hope someone can help me with these understanding questions.
Beside of that i found out, that another small method to gain some speed for the user, is to only use A Records and no CName Records anymore.
Are there some more ways to optimize a nameserver?
Thanks in advance!
Your question is not really related to programming, but more to operations, and is also a little too vague ("Are there some more ways to optimize a nameserver?").
But let us try to give you pointers.
User X wants to visit www.example.com, the following steps happen to get the IP address:
Your following description is then mostly correct. Note that at each step, by default until very recently, a recursive nameserver will send the whole name queried to each nameserver. Recently, QNAME Minimization appeared as a standard and now recursive nameservers can send to each authoritativ nameservers only the labels it neeeds to reply. This enhances privacy without changes to the protocol, but is not widespread today because some authoritative nameservers do not work correctly when queried that way.
As a domain name owner you can indeed only have an impact at the last step. But remember that recursive nameservers have caches, so the list of root nameservers as well as the list of .COM nameservers for example are so "hot" (so often needed) that they surely sit always in resolvers' caches, so basically step 1 and 2 happens do not happen often (at start when cache is empty typicaly).
I came across IP Anycast nameserver (what is also used for the 13root nameservers) and totally understand the concept of distributed machines. But what I dont understand is where the decision logic, to which of the distributed machines the user will be send, according to his "position",is implemented?
First things first, IP anycasting is not specific to the DNS, it is just hugely popular here because
it solves the load balancing/fail over problem that all big TLDs have
it works specially well with DNS over UDP which is a simple one query one reply protocol.
So any service can theoretically be anycasted. It means that a given IP address just appears at different locations in the world.
To summarize very broadly, Internet traffic between providers (AS numbers) is exchanged at peering points, where they interconnect and each provider says "I know about IP block 192.0.2.0/24, please send me all traffic for it", etc. for each blocks
(again this is a summary. Blocks are allocated by RIRs, and yes by default this is not very much authenticated so BGP hijacks happen when another provider also says "give me this traffic" when it shouldn't - and it happens because of malicious goals or just simple human errors).
For a normal (technical term: "unicast") IP address, only a single provider (AS) will announce it somewhere (technically: announce its block not just a single IP) and everything will be configured in such a way that wherever the start of the exchange is, for this single IP as destination, it will arrive at the exact same box.
On the contrary, for an anycast IP address, either a single provider or multiple ones (that is multiple Autonomous Systems) will announce this IP at various locations (peering points) in the globe. At each peering point, traffic for this IP will get taken by the provider announcing it there and then it will route this traffic to a specific server "nearby". Announcements of the same IP at peering point A and peering point B, will drive corresponding traffic on one side in datacentre X and the other for datacentre Y.
For the client, when everything works, it does not change anything, as long as all the replying servers react the same way to the same query. The client does not (and sometimes can not) even know the IP is anycasted or that it want to location X when another client doing the same thing will instead hit location Y.
So in short nameservers "decide" nothing in this regard. At each point of the DNS resolution, when they need to contact nameserver NS1 they know its IP address is IP1 and they just open an UDP (or sometimes TCP) connection to this IP, absolutely normally. It is the underlying IP and BGP protocols that will, if anycast is in action, make the response come from the appropriate "close" server.
Note that anycasting in this way, for DNS, achieve both:
fail-over : if one server dies, with appropriate monitoring, its provider withdraws its IP announcement, that is this local copy kind of disappear and the traffic will automatically (in order of seconds) shift to any other instance where the same IP is announced
load-balancing : rougly speaking, if you anycast one IP on 2 locations, each should receive 50% of traffic. It is not true in practice, and is very complicated (read: impossible) to predict or even monitor, because it all depends on the peering points, the agreements between the providers and various other policies (simple example: if you peer at two points where on first there is only one provider sending you trafic, and at other point you have 100 providers with whom you exchange traffic, then you may get more connections going to the second instance... except of course if single provider at first peering point is an ISP with millions of clients, where the other 100 providers are single small organizations...)
So, some nameservers are anycasted. Nowadays all the root ones are (but this was not true 16 months ago, see https://b.root-servers.org/news/2017/04/17/anycast.html as b.root-servers.org was the last one to board the anycast wagon) as well as all big TLDs, sometimes even with more that one "Anycast DNS providers".
For any domain name, you can get some providers that will give you a DNS service for it, based on a "cloud" of anycasted nameservers.
See for example:
https://www.pch.net/services/dns_anycast
https://www.netnod.se/dns/netnod-dns-services
https://dyn.com/dns/network-map/
http://www.cdns.net/anycast.html
https://www.rcodezero.at/en/home/
https://aws.amazon.com/route53/
https://cloud.google.com/dns/
and many others.
Now following on a totally different topic:
Beside of that i found out, that another small method to gain some speed for the user, is to only use A Records and no CName Records anymore.
This is not really something you gain things with, and CNAME records are useful in many other cases.
Again, you need to remember that there are caches.
So even if your configuration is:
www.mywebsite.example CNAME www.mywebsite.example.somegreatCDN.example
www.mywebsite.example.somegreatCDN.example A 192.0.2.128
it is true that this means on paper two DNS requests to finally be able to do an HTTP query, but in practice things will be cached (even more so today with big public open resolvers such as 1.1.1.1 or 8.8.8.8 or 9.9.9.9, that are anycasted too in fact), so the difference will be negligible (and only impacts the first time, never again until it is in cache) ... especially in the case of HTTP and everything that happens later that is opening, frequently, dozens of connections to download javscript source codes, CSS files, fonts, etc. that may be hosted elsewhere.
A lot of websites use CNAME records without negative impact. See www.amazon.com for example, right now:
;; ANSWER SECTION:
www.amazon.com. 730 IN CNAME www.cdn.amazon.com.
www.cdn.amazon.com. 11 IN CNAME d3ag4hukkh62yn.cloudfront.net.
d3ag4hukkh62yn.cloudfront.net. 11 IN A 54.239.172.122
You may however argue that some names will be more popular than others and hence stay longer in cache, which is certainly the case.
And finally:
Are there some more ways to optimize a nameserver?
Based on what? We touched various subjects above, all are compromises, you sacrifice something (it may be just "money") to gain something else (redundancy, etc.). There is no generic rule to declare when this compromise makes sense or not, it will depend a lot on your situation and what you are trying to do.
You are right, and should be congratulated about that, that you should invest some time around DNS setup, both for security and performance reasons. While a lot of money is often invested in huge HTTP setup to sustain various problems or spikes of activity (but even the best fail sometimes, see the recent Amazon Prime Day opening that was a gigantic failure), but often people forget about the DNS because it is on the infrastructure level so not well known nor understood (using UDP makes it already stand out from all other known protocols, as this is rare).
For example there is another completely different thing (it is orthogonal to anycasting, so it can work with or without it, the goals are different) that is related: "geo-DNS" means when a nameserver will reply differently based from where the client asks. This is meant to give, for example, a different IP for a webserver, one that is closer to client (so in that case the webserver itself is probably not anycasted). This is done by just looking at the source IP from the DNS packet, but it is often not good enough because the authoritative nameservers only see as source IP the one from the recursive nameserver and not the real end client one and nowadays with big open public recursive nameservers the location should be far off, so you also have a specific DNS option called EDNS Client Subnet that can be passed between recursive and authoritative nameservers so that they get the end client real IP address (in fact a block not a single IP for privacy reasons) and can act upon it.
Short answer is: you are right. The NameServers is where you can optimize and all "IP Anycast" products I have seen is just a NameServer setup that has a lot of locations.
They use the same system as the "root servers of the internet" but this does not mean that they have the same function. The IP Anycast is simply a method for multiple servers in different locations to serve the same IP address.
From WIKIPEDIA (http://en.wikipedia.org/wiki/Anycast)
On the Internet, anycast is usually implemented by using Border Gateway Protocol to simultaneously announce the same destination IP address range from many different places on the Internet. This results in packets addressed to destination addresses in this range being routed to the "nearest" point on the net announcing the given destination IP address.
If you are using a big ISP like ASCIO or someone using ULTRADNS you probably do not have to worry about this step too much, but if the NS is a local ISP it is worth considering. Make sure you have NS where your visitors are.
I assume this is where you came into contact with "IP Anycast" products. None that I have seen offers anything to attack step 1-2-3 but rather offers a large setup of NameServers allowing them to reduce resolving time due to closeness of networks.
Let me know if you are of the understanding that the offer is for a root NameServer setup, because I would like to see this.
The specific query that led me to try and unpick this process was:
Will a DNS lookup for a subdomain, such as assets.example.com, be faster if the parent domain, example.com, has already been resolved?
By my (naive) understanding, the basic process for translating a domain name into an IP address is quite simple. The addresses of the thirteen root servers, who know how to resolve top-level domains like com and net, are hard coded in network hardware. In the case of a lookup for example.com, our local DNS server, probably our router, asks one of these root servers where to find a top-level nameserver for com. It then asks the resultant nameserver if it knows how to resolve example. If it does, we're done, if not, we're passed to another server. Each nameserver in this process may well be caching, so that for a time our local router will now know offhand where to look for com and example, and the com server will know where to look for example.
Still, I don't really get it.
I know there are other intermediate DNS servers, such as those provided by ISPs. At what point are they queried?
If the com TLD nameserver does not know how to resolve example, how does it work out what other nameservers to check? Or would this simply mean that example.com cannot be resolved?
When I register a domain and configure nameservers, am I in effect editing a group of NS records for my subdomain of a particular TLD in the database used by the nameservers for that TLD?
Wikipedia explains that some DNS servers combine caching with a recursive query implementation which allows them to serve cache hits and reliably resolve cache misses. I don't understand how these servers come to be queried, or how (even broadly) the resolving algorithm works.
Looking back at my initial question, I might take a stab at "no", assuming the A records are both on the same nameserver. Is this accurate?
First, the misconceptions:
The root hints (names and IP addresses of the 13 root servers) are hardly ever "hard coded in network hardware". Network hardware such as a router, may sometimes have a built in DNS resolver if it happens to also have a DHCP server, but if it does, it's usually just a forwarding resolver that passes the query along to an upstream nameserver (obtained from an ISP) if it doesn't know the answer.
nameservers provided by ISPs don't usually act as "intermediate DNS servers". Either you use your own nameservers (e.g. corporate nameservers, or you installed BIND on your computer) or you use the ones provided by your ISP. In either case, whichever nameserver you choose will take care of the recursive resolution process from beginning to end. The exception is the aforementioned forwarding nameservers.
If the com TLD nameserver does not know how to resolve example, it does not work out what other nameservers to check. It is itself the nameserver to check. It either knows about example, or example doesn't exist.
The answer to your question is yes. If a nameserver has already resolved example.com (and that result is still valid in its cache), then it will be able to resolve assets.example.com more quickly.
The recursive resolution process is much as you described it: First find out the nameservers for . (the root), then find out the nameservers for com, etc... Only the recursive resolver does not actually ask for the nameservers for . and com and example.com. It actually asks for assets.example.com each time. The root servers won't give it the answer to that question (they don't know anything about assets.example.com) but they can at least offer a referral to the nameservers for com. Similarily, the nameservers for com won't answer the question (they don't know either) but they can offer a referral to the nameservers for example.com. The nameservers for example.com may or may not know the answer to the question depending on whether assets.example.com is delegated further to other nameservers or provisioned in the same zone as example.com. Accordingly, the recursive resolver will receive either a final answer or another referral.
If I just want to know if a domain name is reserved; is it sufficient to use this command and see if any domain name servers turn up, in which case it's reserved?
host -t NS example.com
It's a lot faster than visiting http://www.internic.net/whois.html and typing example.com to get much more detailed results, which I'm not interested in anyway.
Absolutely not.
A past employer registered theirname.biz solely for use on the internal network: it had DNS entries on the inward-facing network DNS server, but nowhere on the internet.
I'm not sure the trick was particularly essential, but "imap.theirname.biz" has the advantage over just "imap" that it's unambiguous if you're connected simultaneously to multiple networks (in the absence of deliberate foul play, of course), so you can just use all their internal DNS resolvers. Also the advantage over "imap.theirname.com" that once you know the convention, it's immediately obvious that it's a private server, and hence the reason you can't connect to it is that you forgot to connect VPN. There may have been other benefits to which I was not privy: I'm a coder, not an IT tech...
Various TLDs have differing requirements for whether name servers are provisioned or not. For example ".de" does require that name servers are up and running and correctly configured before they'll allow the domain registration to proceed.
The technical standards for DNS don't require it though, in fact there's nothing in the core DNS specifications to link together the registration of a name with its subsequent operation in the DNS.
Therefore, using whois is probably the most reliable method, with the caveat that you'll need a whois client that's clever enough to figure out which server to talk to for the domain in question.
That said, checking for the appropriate NS record is a very good shortcut to check that a domain is registered, you just can't use the absence of such a record to prove that it isn't!
NS records are not necessarily required for registered domains. The whois service is your most reliable option.
Note that most Unix systems and Mac OS X have a "whois" command line program that is really quick to use:
whois stackoverflow.com
I don't believe that you have to have a DNS pointing to your domain. Even if you had to have a DNS set up, there is no assurance that the box acting as the DNS server isn't down.