I want to create an instance in Google Cloud Engine with a custom (private) hostname. For that reason, when creating the instance from the Console (or from an SDK) I supply the hostname, or example instance0.custom.hostname.
The instance is created and the search domain is set correctly in /etc/resolv.conf For Ubuntu in particular I have to set the hostname with hostnamectl but it is irrelevant to the question.
Forward DNS lookups work as normal for instance0.custom.hostname. The problem comes when I do a reverse lookup for the private IP address of the instace. In that case the answer I get is the GCE "long" name instead of my custom hostname.
How can I make the reverse lookup reply with my custom name instead of the GCE?
I know in Azure you can use a Private DNS Zone with VM auto-registration to handle the "custom hostnames". I tried using a private zone with Google Cloud DNS (PTR records) but with no luck.
After some serious digging I found a solution and tested it.
Reverse DNS works even without a "regular" DNS records for your custom.hostname domain.
To get reverse dns working lets assume your VM's in 10.128.0.0/24 network.
Their IP's are 24,27,54,55 as in my example.
I created a private dns zone and named it "my-reverse-dns-zone" - the name is just for information and can be anything.
"DNS name" field however is very important. Since my network address starts with 10 I want all the instances that are created in that network segment to be subject to reverse dns. So the DNS name has to be 10.in-addr.arpa in this case. If you're using 192.168.... or 172.16.... then adjust everything accordingly.
If you wanted just 10.128.0 then you can put 0.128.10.in-addr.arpa. Then you select the VPC networks zone has to be visible in and voila:
Then you add the PTR records that will allow this to work. I'm setting all TTL's to 1 minute to shorten the wait :)
After accepting wait a minute (literally) and test it:
dig -x 10.128.0.24
; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> -x 10.128.0.24
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35229
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;24.0.128.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
24.0.128.10.in-addr.arpa. 60 IN PTR instance0.custom.hostname.
;; Query time: 6 msec
;; SERVER: 169.254.169.254#53(169.254.169.254)
;; WHEN: Mon Jan 31 13:35:57 UTC 2022
;; MSG SIZE rcvd: 92
Done !
You can even put some completely other domain for one of the IP's. Have a look at my zone configuration:
dig -x 10.128.0.55 | grep PTR
;55.0.128.10.in-addr.arpa. IN PTR
55.0.128.10.in-addr.arpa. 60 IN PTR b2.example.com.
There's a similar question & answer here.
To have a better (technical) understanding of how this works have a look at PTR records in private zones documenation and about PTR records and how they work in the internal GCP's DNS.
I am using Centos 7 and I would like to modify zone records in php so that I can add and remove domain names programatically.
Unfortunately, when I type find / named.conf into a terminal I get 0 results and I do not have the folder /var/named.
How can I find the files I need to modify so that I am able to write a script to add and removed domains names?
After running mydomain.com as #Leo suggested, I received:
dig #8.8.8.8 mydomain.com -t NS
; <<>> DiG 9.13.4 <<>> #8.8.8.8 mydomain.com -t NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33602
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mydomain.com. IN NS
;; ANSWER SECTION:
mydomain.com. 21599 IN NS ns2.contabo.net.
mydomain.com. 21599 IN NS ns1.contabo.net.
mydomain.com. 21599 IN NS ns3.contabo.net.
;; Query time: 55 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 25 02:35:26 GMT 2018
;; MSG SIZE rcvd: 110
Where are the DNS Zone files located?
Somewhere internal to your hosting provider. You aren't operating the DNS server, so its zone files won't be on your server.
Your provider may offer an API to update your DNS records. If they do, use it. (I can't say for sure if they do, because you haven't mentioned who they are.)
If that isn't an option, there are plenty of third-party DNS providers available who do have an API. A couple of the bigger ones to consider are Cloudflare (free), AWS Route 53 (~$0.50/zone/month), and Google Cloud DNS (~$0.20/zone/month).
To get a hint of where to start searching, look at reality; try:
dig #8.8.8.8 your.host.name -t NS
or drill, or kdig or etc.
dig #ns1.contabo.net. version.bind CH TXT tells that ns1 (which speculative truly might be the primary) is using PowerDNS.
The most common use (of many other options) of PowerDNS is i.c.w. MySQL.
So my best guess is that your ISP offers an web interface, to their database that holds the zone data.
To answer your question "Where are the DNS Zone files located?":
the zone data resides in several rows of a database table.
It's unlikely (but not impossible) that there are static zones-files.
And if so, I highly doubt that they would collect them from your filesystem.
For real answers better ask support at your supplier.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
Is there any way I can list ALL DNS records for a domain?
I know about such things as dig and nslookup but they only go so far. For example, if I've got a subdomain A record as
test A somedomain.co.uk
then unless I specifically ask for it, eg.
dig any test.somedomain.co.uk
I can't see it.
Is there any way (other than looking at the records by going to the DNS manager) to see exactly what all the DNS records are?
The short answer is that it's usually not possible, unless you control the domain.
Option 1: ANY query
When you query for ANY, you will get a list of all records at that level but not below.
# try this
dig google.com any
This may return A records, TXT records, NS records, MX records, etc if the domain name is exactly "google.com". However, it will not return child records (e.g., www.google.com). More precisely, you MAY get these records if they exist.
The name server does not have to return these records if it chooses not to do so (for example, to reduce the size of the response). Most DNS servers reject ANY queries.
Option 2: AXFR query
An AXFR is a zone transfer, and is likely what you want. However, these are typically restricted and not available unless you control the zone. You'll usually conduct a zone transfer directly from the authoritative server (the #ns1.google.com below) and often from a name server that may not be published (a stealth name server).
# This will return "Transfer failed"
dig #ns1.google.com google.com axfr
If you have control of the zone, you can set it up to get transfers that are protected with a TSIG key. This is a shared secret the client can send to the server to authorize the transfer.
Option 3: Scrape with a script
Another option is to scrape all DNS records with a script. You'd have to iterate through all the DNS record types, and also through common subdomains, depending on your needs.
Option 4: Use specialized tooling
There are some online tools that enumerate subdomains, and online tools that list all DNS records for a DNS name. Note that subdomain enumeration is usually not exhaustive.
I've improved Josh's answer. I've noticed that dig only shows entries already present in the queried nameserver's cache, so it's better to pull an authoritative nameserver from the SOA (rather than rely on the default nameserver). I've also disabled the filtering of wildcard IPs because usually I'm usually more interested in the correctness of the setup.
The new script takes a -x argument for expanded output and a -s NS argument to choose a specific nameserver: dig -x example.com
#!/bin/bash
set -e; set -u
COMMON_SUBDOMAINS="www mail mx a.mx smtp pop imap blog en ftp ssh login"
EXTENDED=""
while :; do case "$1" in
--) shift; break ;;
-x) EXTENDED=y; shift ;;
-s) NS="$2"; shift 2 ;;
*) break ;;
esac; done
DOM="$1"; shift
TYPE="${1:-any}"
test "${NS:-}" || NS=$(dig +short SOA "$DOM" | awk '{print $1}')
test "$NS" && NS="#$NS"
if test "$EXTENDED"; then
dig +nocmd $NS "$DOM" +noall +answer "$TYPE"
wild_ips=$(dig +short "$NS" "*.$DOM" "$TYPE" | tr '\n' '|')
wild_ips="${wild_ips%|}"
for sub in $COMMON_SUBDOMAINS; do
dig +nocmd $NS "$sub.$DOM" +noall +answer "$TYPE"
done | cat #grep -vE "${wild_ips}"
dig +nocmd $NS "*.$DOM" +noall +answer "$TYPE"
else
dig +nocmd $NS "$DOM" +noall +answer "$TYPE"
fi
host -a works well, similar to dig any.
EG:
$ host -a google.com
Trying "google.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10403
;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN ANY
;; ANSWER SECTION:
google.com. 1165 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
google.com. 53965 IN SOA ns1.google.com. dns-admin.google.com. 2014112500 7200 1800 1209600 300
google.com. 231 IN A 173.194.115.73
google.com. 231 IN A 173.194.115.78
google.com. 231 IN A 173.194.115.64
google.com. 231 IN A 173.194.115.65
google.com. 231 IN A 173.194.115.66
google.com. 231 IN A 173.194.115.67
google.com. 231 IN A 173.194.115.68
google.com. 231 IN A 173.194.115.69
google.com. 231 IN A 173.194.115.70
google.com. 231 IN A 173.194.115.71
google.com. 231 IN A 173.194.115.72
google.com. 128 IN AAAA 2607:f8b0:4000:809::1001
google.com. 40766 IN NS ns3.google.com.
google.com. 40766 IN NS ns4.google.com.
google.com. 40766 IN NS ns1.google.com.
google.com. 40766 IN NS ns2.google.com.
In the absence of the ability to do zone transfers, I wrote this small bash script, dg:
#!/bin/bash
COMMON_SUBDOMAINS=(www mail smtp pop imap blog en ftp ssh login)
if [[ "$2" == "x" ]]; then
dig +nocmd "$1" +noall +answer "${3:-any}"
wild_ips="$(dig +short "*.$1" "${3:-any}" | tr '\n' '|')"
wild_ips="${wild_ips%|}"
for sub in "${COMMON_SUBDOMAINS[#]}"; do
dig +nocmd "$sub.$1" +noall +answer "${3:-any}"
done | grep -vE "${wild_ips}"
dig +nocmd "*.$1" +noall +answer "${3:-any}"
else
dig +nocmd "$1" +noall +answer "${2:-any}"
fi
Now I use dg example.com to get a nice, clean list of DNS records, or dg example.com x to include a bunch of other popular subdomains.
grep -vE "${wild_ips}" filters out records that could be the result of a wildcard DNS entry such as * 10800 IN A 1.38.216.82. Otherwise, a wildcard entry would make it appear as if there were records for each $COMMON_SUBDOMAN.
Note: This relies on ANY queries, which are blocked by some DNS providers such as CloudFlare.
For Windows:
You may find the need to check the status of your domains DNS records, or check the Name Servers to see which records the servers are pulling.
Launch Windows Command Prompt by navigating to Start > Command Prompt or via Run > CMD.
Type NSLOOKUP and hit Enter. The default Server is set to your local DNS, the Address will be your local IP.
Set the DNS Record type you wish to lookup by typing set type=## where ## is the record type, then hit Enter. You may use ANY, A, AAAA, A+AAAA, CNAME, MX, NS, PTR, SOA, or SRV as the record type.
Now enter the domain name you wish to query then hit Enter.. In this example, we will use Managed.com.
NSLOOKUP will now return the record entries for the domain you entered.
You can also change the Name Servers which you are querying. This is useful if you are checking the records before DNS has fully propagated. To change the Name Server type server [name server]. Replace [name server] with the Name Servers you wish to use. In this example, we will set these as NSA.managed.com.
Once changed, change the query type (Step 3) if needed then enter new a new domain (Step 4.)
For Linux:
1) Check DNS Records Using Dig Command
Dig stands for domain information groper is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than dig.
2) Check DNS Records Using NSlookup Command
Nslookup is a program to query Internet domain name servers. Nslookup has two modes interactive and non-interactive.
Interactive mode allows the user to query name servers for information about various hosts and domains or to print a list of hosts in a domain.
Non-interactive mode is used to print just the name and requested information for a host or domain. It’s network administration tool which will help them to check and troubleshoot DNS related issues.
3) Check DNS Records Using Host Command
host is a simple utility for performing DNS lookups. It is normally used to convert names to IP addresses and vice versa. When no arguments or options are given, host prints a short summary of its command line arguments and options.
A zone transfer is the only way to be sure you have all the subdomain records. If the DNS is correctly configured you should not normally be able to perform an external zone transfer.
The scans.io project has a database of DNS records that can be downloaded and searched for subdomains. This requires downloading the 87GB of DNS data, alternatively you can try the online search of the data at https://hackertarget.com/find-dns-host-records/
What you want is called a zone transfer. You can request a zone transfer using dig -t axfr.
A zone is a domain and all of the domains below it that are not delegated to another server.
Note that zone transfers are not always supported. They're not used in normal lookup, only in replicating DNS data between servers; but there are other protocols that can be used for that (such as rsync over ssh), there may be a security risk from exposing names, and zone transfer responses cost more to generate and send than usual DNS lookups.
Many DNS servers refuse ‘ANY’ queries. So the only way is to query for every type individually. Luckily there are sites that make this simpler. For example, https://www.nslookup.io shows the most popular record types by default, and has support for all existing record types.
There is no easy way to get all DNS records for a domain in one instance.
You can only view certain records for example, if you wanna see an A record for a certain domain you can use the command: dig a(type of record) domain.com. This is the same for all the other type of records you wanna see for that domain.
If your not familiar with the command line interface, you can also use a site like mxtoolbox.com. Wich is very handy tool for getting records of a domain.
I hope this answers your question.
dig #8.8.8.8 example.domain any
will list all the DNS records. Here 8.8.8.8 is Google's DNS.
I've been told that there is a problem with the DNS records for for the following domain: horoscope-feeds.com, but I'm not yet convinced there is a problem with it.
When I do
host -C -a horoscope-feeds.com
I get the response
Trying "horoscope-feeds.com"
Received 184 bytes from 127.0.0.1#53 in 46 ms
Trying "horoscope-feeds.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21074
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;horoscope-feeds.com. IN SOA
;; ANSWER SECTION:
horoscope-feeds.com. 86400 IN SOA ns.horoscope-feeds.com. peter.ward33.btopenworld.com. 1341590337 10800 3600 604800 10800
;; AUTHORITY SECTION:
horoscope-feeds.com. 86400 IN NS ns.horoscope-feeds.com.
;; ADDITIONAL SECTION:
ns.horoscope-feeds.com. 86400 IN A 109.228.2.80
Received 131 bytes from 109.228.2.80#53 in 44 ms
Which I understand as meaning that the authoritative name server for this domain is ns.horoscope-feeds.com. However a whois lookup for the domain yeilds two nameservers:
Nameserver: ns1.horoscope-feeds.com
Nameserver: ns2.horoscope-feeds.com
I thought that whois information is not guaranteed to be accurate and that domain information should not be taken from this source.
Can anyone tell me if the DNS set up for this domain is wrong in any way and if so how? Also where is the final authority on the DNS records for a domain and how do I get that information?
Thanks
The DNS setup inconsistent because the registry (".com" - managed by Verisign) says that the authoritative nameservers are ns1.horoscope-feeds.com and ns2.horoscope-feeds.com, but if you query one of these servers, they answer that the authoritative server is ns.horoscope-feeds.com (having the same IP as ns2).
This may sound confusing, but it's important to understand that the main record type that a resolving client jump from the root down to your domain is the NS resource record type. For any given delegated domain, such as "horoscope-feeds.com", there are two sets of such NS records -- one published by the parent zone (registry) and one published by the zone itself. These two sets should match:
Ask the registry for the set of nameservers authoritative for your domain:
$ dig +noall +authority +add #a.gtld-servers.net horoscope-feeds.com
horoscope-feeds.com. 172800 IN NS ns1.horoscope-feeds.com.
horoscope-feeds.com. 172800 IN NS ns2.horoscope-feeds.com.
ns1.horoscope-feeds.com. 172800 IN A 109.228.2.79
ns2.horoscope-feeds.com. 172800 IN A 109.228.2.80
Ask one of those nameservers:
$ dig +noall +answer +add #109.228.2.79 horoscope-feeds.com ns
horoscope-feeds.com. 86400 IN NS ns.horoscope-feeds.com.
ns.horoscope-feeds.com. 86400 IN A 109.228.2.80
A similar diagnosis can be seen here.
Generally, the information published by Whois also comes from the TLD registry (if you query the right whois server). However, there is a possibility that the registry whois database is out of sync with what is published at the DNS. Since we're dealing with DNS problems, it's best to query the DNS, i.e. ask one of dig com. NS for domains that end with ".com") :)
As for fixing this inconsistency, you should either edit your zone (at your DNS provider) to match the registry.
I received the following from my domain registry in Iceland:
The setup of zone gsap.is on its nameservers appears not to
be according to ISNIC's reqirements for .IS delegations.
ask your hosting provider to add a PTR record for the nameserver:
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.1.8.8.c.f.7.0.6.2.ip6.arpa. IN PTR A.NS.ZERIGO.NET.
Can you please tell me if you can help me with this?
They want your DNS server to have reverse mappings in the DNS pointing from its IP addresses back to its name. That is an unusual requirement, yet that's what they want to see.
Your name server has two IP addresses: 64.27.57.11 and 2607:fc88:1001:1::4.
The reverse mapping for 64.27.57.11 exists and points back to the correct name:
dig -x 64.27.57.11
(...)
;; ANSWER SECTION:
11.57.27.64.in-addr.arpa. 740 IN PTR a.ns.zerigo.net.
But the reverse mapping for 2607:fc88:1001:1::4 does not exist:
dig -x 2607:fc88:1001:1::4
; <<>> DiG 9.4.3-P3 <<>> -x 2607:fc88:1001:1::4
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19793
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.1.8.8.c.f.7.0.6.2.ip6.arpa. IN PTR
(note NXDOMAIN.)
I see that the reverse zone for the 2607:fc88::/32 prefix is hosted on nameservers ns1.wehostwebsites.com and ns2.wehostwebsites.com. You need to either:
Insert the reverse mapping into the zone file for this IP address block on the above nameservers. You would probably do this if 2607:fc88::/32 is your IP address block.
Get a smaller block like 2607:fc88:1001::/48 delegated to your nameservers, set them up to serve the reverse zone (1.0.0.1.8.8.c.f.7.0.6.2.ip6.arpa), and insert the reverse mapping for your nameserver into that zone. You would probably choose this option if you aren't responsible for the whole 2607:fc88::/32 block.
Either way, the reverse entry should be this one:
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.1.0.0.1.8.8.c.f.7.0.6.2.ip6.arpa. IN PTR a.ns.zerigo.net.
Some cTLD registries are pushing the limit on zone structure regulations. I'm a big fan of this, however in many cases the local registries are merely trying to clean up their own street-front in a big city where all other neighbors are freely emptying their trashcans on the same street.
It's highly unusual however that local registries also enforce RFC's on ipv6. In the case you don't need ipv6 resolution you probably can fix this by just removing your AAAA records.
Obviously if you need ipv6 you shouldn't follow my advice, but submit to your local registry demands.