Hot answers tagged


Yes, the number there is the number of seconds left until that record expires (providing we're not querying the authoritative nameserver). Obviously with a CNAME there's a level of redirection, so the TTL for the A record it points to in this case may be important as well. If you wait a couple of seconds and run dig again on your local nameserver, you ...


The short answer is to your specific question of listing CNAMEs is that you can't without permission to do zone transfers (see How to list all CNAME records for a given domain?). That said, you can use dig to list the other records by doing: dig +nocmd any +multiline +noall +answer


You can use the @ syntax to look up the domain from a particular server. If the DNS server is authoritative for that domain, the response will not be a cached result. dig You can find the authoritative servers by asking for the NS records for a domain: dig NS


Try: dig -tAXFR This may or may not work. Many DNS servers will deny a DNS Zone Transfer like this. For more information, see How the AXFR protocol works


A much easier command to remember (and more informative) is: > dig ANY Which returns the following: ; <<>> DiG 9.8.3-P1 <<>> ANY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31013 ;; flags: qr rd ra; QUERY: 1, ANSWER: 22, AUTHORITY: 0, ADDITIONAL: 3 ...


If you happen to be stuck on a windows box and only have access to nslookup: nslookup -qa=A -debug


This is obviously a staged Q&A, but this tends to confuse people often and I can't find a canonical question covering the topic. dig +trace is a great diagnostic tool, but one aspect of its design is widely misunderstood: the IP of every server that will be queried is obtained from your resolver library. This is very easily overlooked and often only ...


Use sed -e "s/[[:space:]]\+/ /g" Here's an explanation: [ # start of character class [:space:] # The POSIX character class for whitespace characters. It's # functionally identical to [ \t\r\n\v\f] which matches a space, # tab, carriage return, newline, vertical tab, or form feed. See #


You can also use host DNS lookup utility with -l switch: host -l Of course you need DNS zone transfer rights for this to work.


It's the default behaviour of dig not to use the search-option. From the manual page: +[no]search Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not used by default. Edit: Just add +search to make it work, like dig +search myhost.


Is the value '43200' the TTL for this DNS record? Yes - as reported to you by the server that answered your query (if you're asking a caching server it will return the remaining time in its cache). To see the TTL set on the actual record query the authoritative nameserver (dig @some.dns.server - The authoritative DNS servers will be listed ...


The timeout value is per try so setting a +time=5 would result in a 15 seconds delay as the default for +tries is 3. If you set +tries=1 then your command will timeout in 5 seconds e.g. time dig +time=5 ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5_7.1 <<>> +time=5 ; (1 server found) ;; global ...


Your query is incorrect, or to put it differently - no, there is no entry for Dig is telling you about the problem. The domain works in the browser, because it will helpfully try and add the www. prefix, and lo and behold: dig ... 1783 IN CNAME kochi-9186.herokussl....


You can get a full list of entries in a zone with a zone transfer; you'd need to allow this for authorized systems in your DNS server. Once that's done, you can run the transfer and grep the result: dig axfr | grep -i miller


To get authoritative information using dig you usually use a combination of +trace and @server. For example, if I want authorative information about I would do it like this: # dig +trace NS ; <<>> DiG 9.4.2-P2 <<>> +trace NS ;; global options: printcmd . 3600000 IN NS ...


There's a hint about this on In other words, an instance of the resolver still queries the first name server in resolv.conf first, but for the next domain name it looks up, it queries the second name server first, and so on. Note that many programs can't take advantage of this since most ...


I am not sure why you are getting comments in the output. That is the correct set of options for the behaviour you want. Here are the same options with the same version of dig: $ dig -version DiG 9.7.3 $ dig +noall +answer 55 IN A 55 IN A 55 IN A 173.194.44....


Use dig(1) with the +short flag instead: $ host -t txt descriptive text "v=spf1 ip4: ip4: ~all" $ dig -t txt +short "v=spf1 ip4: ip4: ~all" If you want to remove the quotes, just filter the output through sed: $ ...


On the CentOS box I have to hand dig +short If you only want one address then dig +short | head -1 or dig +short | tail -1


Another way of tracing DNS resolution without using the local resolver for anything except finding the root nameservers, is using dnsgraph (Full disclosure: I wrote this). It has a command line tool and a web version, of which you can find an instance at Example for, which actually has a DNS problem right now:


Dig reports the time left until the TTL expires rather than the actual TTL value. If the number varies, it is most likely that you're querying different DNS servers (for example, round robin) which have the record cached for different amounts of time, and therefore have different expiry times. If you run the same query against the same DNS server, you will ...


I'm not sure i get the whole picture but since you are writing about websites i think you are using a tool that is not exactly suitable for the task. imho you are looking for that information (the visited domain name) at the wrong level: you should have a proxy and analyze its logs to gather that info. A proxy is 'near' the client and has the exact and ...


The dig command is simple: % dig +dnssec ; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49304 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, ...


RFC 1035 says: MNAME The of the name server that was the original or primary source of data for this zone. although in practise this MNAME field in the SOA is mostly unused these days. However if you're using DNS dynamic updates then it must refer to the name of the DNS server which is to receive the dynamic update messages. See also this (...


dig wants the '-x' flag for reverse lookups on an IP. Alternately, you can use the full form, 'dig PTR'


You probably need to open port 53 in your firewall to allow DNS traffic into your server. As you are using CentOS 5 iptables -I RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT iptables -I RH-Firewall-1-INPUT -p tcp -m tcp --dport 53 -j ACCEPT Should get you going. If this works then service iptables save Will save your current firewall ...


This happens in dual stack IPv4/IPv6 environments where the machine doing a DNS lookup sends requests for AAAA and A records on the same socket, expecting to receive two replies back. This is default behavior for relatively recent versions of glibc. The Juniper firewall, however, drops the connection after the first reply comes back. The Juniper knowledge ...


You can only ask a DNS-Server if it has a specific record. So, no there will be no such tool for DNS. Edit Zonetransfer is of course a possibility if it is available.


A name server will not, by design, let you search a zone or query what zones it is authoritative for. Beyond the obvious reason of reducing attack vectors (you can't make a HTTP/1.1 request to a host if you don't know its name), there is a very good reason for this: a zone can contain wildcards itself, so asking for every host in such a zone is like dividing ...


The zone is delegated in much the same way as other zones: by using delegation NS records. Accordingly, suppose you were curious as to who had the authoritative DNS server for This subnet mask is divisible by 8, and so you can do: dig in ns Your answer will contain a list of nameservers serving the rDNS ...

Only top voted, non community-wiki answers of a minimum length are eligible