Score:0

nslookup, dig, and host only return half of my TXT records

ng flag

nslookup, dig, and host only return half of my TXT records:

host -t txt machelpnashville.com 8.8.8.8

nslookup -type=txt machelpnashville.com 8.8.8.8

dig machelpnashville.com TXT 8.8.8.8

They return the four records that have the name @ but they ignore the other four records that are there. is there a way to pull ALL TXT records using a wildcard?

Maximillian Laumeister avatar
cn flag
Are you looking for a way to pull in all the TXT records for both `machelpnashville.com` and every subdomain of `machelpnashville.com`? Any records besides the ones for `@` are not applied to `machelpnashville.com` directly but to its subdomains, and generally are expected to be queried separately.
anx avatar
fr flag
anx
see also [How to list all CNAME records for a given domain?](https://serverfault.com/questions/16101/how-to-list-all-cname-records-for-a-given-domain) and [List all DNS records in a domain using dig?](https://serverfault.com/questions/138949/list-all-dns-records-in-a-domain-using-dig)
ng flag
I have 8 TXT records the ones I’m looking for I know but want to know how to pull ALL TXT records for a domain default._bimi _dmarc unknown DKIM the whole shebang
Patrick Mevzek avatar
cn flag
And for the part that no one touched: no you can not use a wildcard in a query, it won't work the way you expect it based on your description. The DNS just does not work the way you think it does. It is a name=>data API and each name in the zone is separate so no single DNS query can resolve multiple names in one go.
Score:1
cn flag

It is not possible to do what you're asking for for a domain you do not own.

By design and due to privacy considerations, you can't list the TXT records of all subdomains unless you have special permission within the DNS server to do a zone transfer (AXFR) lookup. Unless you have this zone transfer permission, all records that are not under the @ (apex) domain need to be queried by each individual subdomain they reside on.

This prevents people from discovering subdomains and DNS records that are not intended to be public.

If you do control the domain, your DNS provider should have instructions for allowing zone transfers to a particular IP address. If you enter your IP address there, then you should be able to use dig's axfr mode to list all the DNS records - but by the point you log into your DNS provider, you may as well just view the records from their web interface, unless you are trying to automate something.

Patrick Mevzek avatar
cn flag
"This prevents people from discovering subdomains and DNS records that are not intended to be public." The DNS was not designed specifically in that regard, it is just a consequence. But the "protection" is slim: as given in example in comment the other records are in "default" names, so easy to find out. Plus there are a ton of ways to find them out, from passive DNS, to search engines, to using DNSSEC NSEC/NSEC3 mechanisms, etc.
Patrick Mevzek avatar
cn flag
"If you do control the domain" ... then by design you should know what is in the zone because you put it there yourself in the first place, so normally no need of AXFR and the like, the DNS provider UI and/or API should give all data needed, that is the list of records.
Patrick Mevzek avatar
cn flag
"By design and due to security considerations" It is only "by design". When RFC1034/1035 there were certainly no security discussions as we have today. The DNS is just a name=>data API, and each name is separate so "apex" aka @ aka zone name is one name, you can query for it, but them `default._bimi._dmarc` or whatever is **another** name completely separate, besides being in the zone. So each DNS query gives results for one name or the other, a single DNS query can not give data for both names at once.
Maximillian Laumeister avatar
cn flag
@PatrickMevzek According to [rfc5936](https://datatracker.ietf.org/doc/html/rfc5936#page-22), "Restrictions on AXFR could be for various reasons including a desire (or in some instances, having a legal requirement) to keep the bulk version of the zone concealed [...] It has been argued that these reasons are questionable, but this document, driven by the desire to leverage the interoperable practice that has evolved since RFC 1035, acknowledges the factual requirement to provide mechanisms to restrict AXFR."
Patrick Mevzek avatar
cn flag
An RFC doesn't dictate policies, but describe technical mechanisms.
Maximillian Laumeister avatar
cn flag
@PatrickMevzek If there are "a ton of" ways to list these records, then I encourage you to share one of these methods in an answer. It would be helpful both to solve the original poster's question and for my own education - as I am also unfamiliar with using passive DNS or DNSSEC to list out an entire zone, and I would be very curious to learn.
Patrick Mevzek avatar
cn flag
Noted, but I don't think it is the place, the OP is just confused on how the DNS works (and the question might be even offtopic here), and even AXFR might really not be the solution needed for him, or certainly not the only recourse (as you wrote, the DNS provider UI should be 1st solution). Passive DNS = you have logs of a big recursive DNS server, hence you see what is requested and can "reconstruct". content of a zone (imperfectly of course). As for DNSSEC NSEC it is a record chaining names so allowing to iterate over the zone. NSEC3 is more complicated due to hashing. Needs DNSSEC ofcourse
ng flag
I guess I will clarify my usage. I do know how to pull DMARC and SPF and BIMI one at a time by nslookup -type=txt _dmarc.machelpnashville.com 8.8.8.8 for example. Many times we help clients clean up their DNS records and the first preliminary looksups I do are before we have logged into the domain registrant to give the client an idea of what all we would need to do...
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.