I have a doubt regarding Domain name resolution.We can do address resolution from DNS to ip-address format by using the function getaddrinfo() or by the procedure of NAPTR query,SRV record query and A/AAAA record.
1. Does the function use getaddrinfo() use the NAPTR query technique internally ?
2. What is the advantage of using the function getaddrinfo() over the other procedure ?
getaddrinfo() does not query NAPTR or SRV records, or indeed any type of record except A and AAAA. getaddrinfo() is an interface to libc's hostname resolution service which is modelled as a simple mapping between names and addresses. To see how this is the case, consider that this resolution service may consult /etc/hosts or, more rarely, NIS+, LDAP, relational databases, and so on, as per its configuration file /etc/nsswitch.conf. Notice how none of these NSS backends understand anything about NAPTR or SRV records.
Only DNS implements NAPTR and SRV records, and if you want to query them, you will have to use an API to query DNS directly (see res_init() and related functions, or more interesting third-party libraries like c-ares that support non-blocking operations). You can't use the libc hostname resolution service to do it.
As to your second question, the advantages of using getaddrinfo() are (1) it's a lot easier to use, and (2) you'll locate entries which users may have inserted into /etc/hosts, which you'll miss if you query DNS directly.
getaddrinfo gives back ipv6 address as well. Also you have option of providing hint. There is one more variation getaddrinfo_a - this API provides results in async way. This is sometimes useful to avoid program getting blocked at one place.
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).
I'm creating my own DNS server using Windows Server and other users will use my DNS server and thought that if it will go down I should have a backup how about if users set my DNS as Primary and Secondary can be something like google public dns? How will it will work? If it can't resolve using my DNS it will try google's? It will try it every request?
Since you mention Google's public DNS server, I assume you're talking about a nameserver to be used as a recursive resolver (not as an authoritative server containing zones).
DNS doesn't distinguish between "primary" and "secondary" nameservers. What actually happens is up to the client.
Some clients may query nameservers in order, so they will query yours first, and then query Google's only if they don't get a response from yours. Other clients may choose a random server from the list for each query, so they will sometimes query yours and sometimes query Google's. Still others might track statistics on each nameserver and prefer the one that usually gives a faster response. This last options requires a stateful client and it's something another nameserver acting as a forwarder might do.
In practice it will not matter because your recursive resolver and Google's public recursive resolver should give the same response for every query.
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.
So, I'm on day 3...
I am running an Ubuntu.64-based distribution on a VirtualBox. I have the need to access both external ISP DNS servers, as well as "internal" DNS servers through an OpenVPN connection. At times I need to query the external DNS(#host example.com) through the eth0 interface; sometimes I need to query the VPN "internal" DNS (#host internal.local) through the tap0 interface.
My question is: how do I configure my system to query the correct nameserver-- the ISP DNS or the VPN DNS (for attempting zone transfers, for example)?
I've tried editing resolv.conf to include both external and internal nameservers/domains, with no luck (obviously). I've also tried mitigating the situation with dnsmasq. That got me close (I think).
I realize I can use dig to set the [#server] based on individual queries, but I would appreciate a systemic resolution.
Any help would be appreciated.
I've used the PowerDNS recursor for exactly this situation before; it is in the package pdns-recursor, if you wish to try it. You'll want to set your /etc/resolv.conf to query only 127.0.0.1 should you choose to try this approach.
The forward-zones directive lets you specify which servers to contact for which zones:
forward-zones= ds9a.nl=213.244.168.210, powerdns.com=127.0.0.1
It does look a little strange, since it is one configuration setting that takes multiple values, but you do get to specify exactly which servers are going to provide answers for which domains.
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.