0

If I run dig gmail.com A I get

; <<>> DiG 9.16.1 <<>> gmail.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34113
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gmail.com.         IN  A

;; ANSWER SECTION:
gmail.com.      198 IN  A   216.58.208.101

;; Query time: 16 msec
;; SERVER: 62.179.104.196#53(62.179.104.196)
;; WHEN: Sun Nov 15 11:41:30 CET 2020
;; MSG SIZE  rcvd: 54

If I run dig gmail.com MX

; <<>> DiG 9.16.1 <<>> gmail.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2168
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;gmail.com.         IN  MX

;; ANSWER SECTION:
gmail.com.      3600    IN  MX  40 alt4.gmail-smtp-in.l.google.com.
gmail.com.      3600    IN  MX  10 alt1.gmail-smtp-in.l.google.com.
gmail.com.      3600    IN  MX  20 alt2.gmail-smtp-in.l.google.com.
gmail.com.      3600    IN  MX  5 gmail-smtp-in.l.google.com.
gmail.com.      3600    IN  MX  30 alt3.gmail-smtp-in.l.google.com.

;; Query time: 116 msec
;; SERVER: 62.179.104.196#53(62.179.104.196)
;; WHEN: Sun Nov 15 11:41:55 CET 2020
;; MSG SIZE  rcvd: 161

Without trial and error is there a way, a command to run that shows the other records that are available (apart from A and MX records)?

Improve this question
1
  • You can't do that fully, for many reasons. What about delegations in the zone? What about "dynamic" low level "underscore" names, such as those used for DKIM? Then there are workarounds. If the zone uses DNSSEC and NSEC. records (not NSEC3) you can follow the chain and hence retrieve all records. But for that exact reason zones may prefer NSEC3. If NSEC is used often (at least at TLD level) the zonefile are available publicly anyway. – Patrick Mevzek Nov 16 '20 at 1:43
2

If the domain you are asking for allows "zone transfers", which nearly all of them don't do, you can get all of its registers with:

dig axfr @your.dnsserver.example

However, if you try that command with some domain which isn't yours you'll get something like this:

$ dig axfr google.com @8.8.8.8

; <<>> DiG 9.10.3-P4-Ubuntu <<>> axfr google.com @8.8.8.8
;; global options: +cmd
; Transfer failed.

The data contained in a DNS zone may be sensitive from an operational security aspect. This is because information such as server hostnames may become public knowledge, which can be used to discover information about an organization and even provide a larger attack surface. That's why zone transfer are forbidden.

You can check here what a zone transfer is: https://en.wikipedia.org/wiki/DNS_zone_transfer

On the other hand, there are some tools which provide you valuable information about a domain such as:

Improve this answer
5
  • "may be sensitive " also in some jurisdiction DNS data can be considered personnally private information, and hence not to be shared to everyone without need of it. – Patrick Mevzek Nov 16 '20 at 1:45
  • @PatrickMevzek: DNS data is public and never PII... – Esa Jokinen Nov 16 '20 at 5:48
  • @EsaJokinen This is only your interpretation. An IP address can be considered PII, and it is published in the DNS, hence... – Patrick Mevzek Nov 16 '20 at 14:37
  • In some use cases IP addresses can be PII, but public DNS zones is not one of them by any means. – Esa Jokinen Nov 16 '20 at 17:21
  • 1
    Although PII is not a matter of the question, I agree with @EsaJokinen. An IP could be PII but only if you can link it with a person. DNS doesn't allow to bind an IP to a human being. IPs given by Internet providers to their customers logged by email or web servers are a different matter. In this case, the provider could bind the IP and its customer, so the IP is PII and should be protected. – Jesús Ángel Nov 17 '20 at 8:22
0

There was QTYPE ANY (or * per RFC 1035, 3.2.3), but it's fading away, because it's replaced with Minimal-Sized Responses in RFC 8482. The section 2 describes the reasons:

ANY queries are frequently used to exploit the amplification potential of DNS servers and resolvers using spoofed source addresses and UDP transport (see [RFC5358]). Having the ability to return small responses to such queries makes DNS servers less attractive amplifiers.

ANY queries are sometimes used to help mine authoritative-only DNS servers for zone data, since they are expected to return all RRsets for a particular query name. If DNS operators prefer to reduce the potential for information leaks, they might choose not to send large ANY responses.

Some authoritative-only DNS server implementations require additional processing in order to send a conventional ANY response; avoiding that processing expense might be desirable.

Marek Majkowski discusses this in more detail in Cloudflare's blog: RFC8482 - Saying goodbye to ANY.

 

Improve this answer
2
  • DNS ANY was a "meta-query" - think of it as a similar thing to the common A, AAAA, MX or SRV query types, but the question was about getting all the names for a DNS zone, not all the registries for just one name. – Jesús Ángel Nov 15 '20 at 23:29
  • 1
    Even if it existed in the past it was never used correctly as people believed ANY meant ALL which was never the case. For a recursive nameserver ANY was just to get the cache content of this resolver, which has absolutely 0 guarantee to contain absolutely all records (for that zone it contains only the records that have been requested before their TTL made them disappear from the cache). There was no good reasons for authoritative nameservers also, it was abused to try doing A + AAAA at the same time. – Patrick Mevzek Nov 16 '20 at 1:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.