3 ms·

I know this is a case of using the wrong tool for the job, but about once every 3 months or so, I find myself using dig to troubleshoot an issue, only to find o

I know this is a case of using the wrong tool for the job, but about once every 3 months or so, I find myself using dig to troubleshoot an issue, only to find out I had a hosts file entry and that's why it was/wasn't working. I've been trying to force myself to use curl --resolve rather than using hosts file entries (where it's suitable) but for some reason I just can't seem to force myself to get into the habit of getent vs dig. What would save me wasted time is an asterisk next to an entry or a reminder at the bottom of the output (or in stderr) which indicates that there is a hosts file entry which matches, but it was "ignored" (and even what it's value is). I understand if it's not something you want to support, but it's definitely a pain point for myself and quite a few ops people I've shoulder surfed over the years.

kuon 6y ago
I agree: https://github.com/ogham/dog/issues/7 https://github.com/ogham/dog/issues/7
atomi 6y ago
I've started just editing an instance of unbound on my router for custom DNS records. I've gone as far as redirecting all my port 53 traffic to it using iptables on my router as well for those insidiously hard coded DNS servers on Google products.
pnutjam 6y ago
I use getent for passwd and groups, but didn't realize what else it could be used for, thanks! I found this page which has some good examples for getent, if anyone is interested: https://www.commandlinefu.com/commands/using/getent https://www.commandlinefu.com/commands/using/getent
rconti 6y ago
I've fought a number of resolver issues over the years, where, for various reasons, the application resolves differently from client tools, or client tools resolve differently from each other. Sometimes related to hosts file entries, but those are much easier to figure out than issues related to truncated replies related to EDNS or UDP vs TCP replies, or similar. (it's been awhile, so I forget details).
1vuio0pswjnm7 6y ago
To use a single third party utility like dig that would retrieve entries from both /etc/hosts and from zone files, one could use a program like pdns_recursor with the "--export-etc-hosts=on" option. https://doc.powerdns.com/recursor/manpages/pdns_recursor.1.html https://doc.powerdns.com/recursor/manpages/pdns_recursor.1.h... Assuming for example, one had HOSTS entries 127.0.0.1 localhost 93.184.216.34 example.com pdns_recursor is listening on 127.0.0.1 and /etc/resolv.conf contains namserver 127.0.0.1, then dig ns example.com should return "localhost" as the NS RR for example.com so we know the A RR came from /etc/hosts not a.iana-servers.net Additionally, adding the "--trace=on" option will output debugging info that will tell whether the answer came from "local auth storage", e.g., /etc/hosts

kuon 6y ago

I agree: https://github.com/ogham/dog/issues/7 https://github.com/ogham/dog/issues/7

atomi 6y ago

I've started just editing an instance of unbound on my router for custom DNS records. I've gone as far as redirecting all my port 53 traffic to it using iptables on my router as well for those insidiously hard coded DNS servers on Google products.

pnutjam 6y ago

I use getent for passwd and groups, but didn't realize what else it could be used for, thanks! I found this page which has some good examples for getent, if anyone is interested: https://www.commandlinefu.com/commands/using/getent https://www.commandlinefu.com/commands/using/getent

rconti 6y ago

I've fought a number of resolver issues over the years, where, for various reasons, the application resolves differently from client tools, or client tools resolve differently from each other. Sometimes related to hosts file entries, but those are much easier to figure out than issues related to truncated replies related to EDNS or UDP vs TCP replies, or similar. (it's been awhile, so I forget details).

1vuio0pswjnm7 6y ago

To use a single third party utility like dig that would retrieve entries from both /etc/hosts and from zone files, one could use a program like pdns_recursor with the "--export-etc-hosts=on" option. https://doc.powerdns.com/recursor/manpages/pdns_recursor.1.html https://doc.powerdns.com/recursor/manpages/pdns_recursor.1.h... Assuming for example, one had HOSTS entries 127.0.0.1 localhost 93.184.216.34 example.com pdns_recursor is listening on 127.0.0.1 and /etc/resolv.conf contains namserver 127.0.0.1, then dig ns example.com should return "localhost" as the NS RR for example.com so we know the A RR came from /etc/hosts not a.iana-servers.net Additionally, adding the "--trace=on" option will output debugging info that will tell whether the answer came from "local auth storage", e.g., /etc/hosts