0

I want to use basic tool available without installing anything to solve an IP into it's FQDN. I know the domain in which I can solve this IP.
The command line or the tool should be available on any minimal debian or rhel based system which exclude :

  • /usr/bin/host
  • /usr/bin/nslookup
  • /usr/bin/dig

I'm trying with getent but to no end for now.

My resolvctl config looks like this:

nameserver 127.0.0.53 search dom2.lan dom1.lan 

What I want is to get the FQDN of IP 10.1.1.1 in dom3.lan (not in resolvconf) without any package installed but the one on a Ubuntu server minimal image for example.

getent hosts 10.1.1.1 does not return anything.
host 10.1.1.1 dom3.lan return the hostname I want.

So how can I achieve this without installing bind9-tools just with standard systemctl or basic linux package available in any linux distro that is less than 3 years old.

Edit 1 : The solution I'm looking for need to be available to any user. I consider that python3 is available.

Edit 2: I may be confused or dumb or may mis-explain what I mean. If I do the following nslookup request here's the result:

Without domain appened:

nslookup srv1 ;; Got SERVFAIL reply from 127.0.0.53 Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find srv1: SERVFAIL 

With domain happen

nslookup srv1.dom3.lan Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: Name: srv1.dom3.lan Address: 10.1.1.1 

Now I know my local DNS can solve dom3.lan. BUT I don't want to add it in my default search in /etc/resolf.conf because it's not my choice and the choice make sense in our context.
BUT I'd like to be able to do reverse lookup like nslookup 10.1.1.1 and using a different search than the one set in /etc/resolv.conf.
AND at the moment I realize that I don't even manage to do such a request from dig or host or nslookup while if I edit my /etc/resolv.conf without changing any other DNS settings it works.

So my question is : is there a way to set a search for a reverse DNS lookup with any tool and if possible not an installed one.

nslookup set q=A set domain=dom3.lan 10.1.1.1 no result 

with dig

dig @127.0.0.53 +norecurse +domain=dom3.lan. -x 10.1.1.1 No result either. 

I'm not even sure this question makes sense but there's definitely strange stuff happening on my system. If changing my /etc/resolv.conf search works I feel like a tool like dig or nslookup should work as well.

11
  • getent hosts is going to look in /etc/hosts. Is systemd-resolved available (sometimes resolvectl)? Commented Oct 18, 2024 at 11:57
  • 3
    "I want you to cut this piece of wood but you're not allowed to use a saw" Commented Oct 18, 2024 at 12:24
  • 1
    You're expected to install tools on a minimal image as necessary Commented Oct 18, 2024 at 12:37
  • 2
    This makes no sense, they are in the same network. Why not use search lan? Commented Oct 21, 2024 at 7:51
  • 1
    We cannot answer the question if your example doesn't show your problem. With systemd-resolved you can set different DNS servers and search domains for different networks. If you have three names and three IPs, add them to your hosts file. Commented Oct 21, 2024 at 13:34

2 Answers 2

0

Since python3 is accepted:

reverse_dns_request.py:

#!/usr/bin/env python3 import socket import sys print(socket.gethostbyaddr(sys.argv[1])) 

socket and sys are built-in modules (https://docs.python.org/3/py-modindex.html).

$ reverse_dns_request.py 8.8.8.8 ('dns.google', [], ['8.8.8.8']) 

This answer the question. But It won't fix your issue I guess.


So how can I achieve this without installing bind9-tools just with standard systemctl or basic linux package available in any linux distro that is less than 3 years old.

systemd is not universal to every Linux distro. Even python3 and getent are not basic linux packages for every Linux distro.


So my question is : is there a way to set a search for a reverse DNS lookup with any tool and if possible not an installed one.

I'm not even sure this question makes sense but there's definitely strange stuff happening on my system. If changing my /etc/resolv.conf search works I feel like a tool like dig or nslookup should work as well.

So you want a universal tool that would perform DNS request in every Linux distro without installing any packages BUT you also want it to work with your own specific network configuration which is not standard because there is no standard way to configure name services.

systemd-resolved can have multiple different configurations. And the underlying Linux system can also have multiple different configurations for name services. The DNS server you are querying can also have multiple different configurations. Which means hundreds of different use cases possible.

As @ctx answered, with systemd-resolved you can configure per-link DNS server, and you can also configure per-link domain. Combined with systemd-networkd, systemd-resolved can have part of its configuration done through DHCP.


The short answer to your issue is that there is no universal tool to perform all DNS queries the way you would want every time in every use cases automatically.

Name resolution is a clusterf***. It is a patchwork of fixes to adapt it to the current ways of doing things and to fix many security issues (some are considered like design flaws now).

3
  • Your solution only uses system parameter in /etc/resolv.conf or any underlying middleware it will not work. The point being how can ones run a reverse DNS in search zone that are not in search Commented Oct 24, 2024 at 12:34
  • So you asking something generic, telling you don't want to install anything, but you are running unbound!!! This is not generic at all. Commented Oct 26, 2024 at 1:04
  • Is rebind protection disable on unbound? Because, you can pretty much reverse DNS any domain, as long as the record exist and the query hits the correct DNS servers. But if rebind protection is enabled, some DNS responses are blocked. You don't meed the zone in search to be able to query it (unless you want to just query hostname wihout the FQDN. Commented Oct 26, 2024 at 1:06
0

systemd-resolved cannot answer reverse lookups when the reverse lookup routing is not configured correctly:

$ nslookup -type=ptr 10.1.1.23 Server: 127.0.0.53 Address: 127.0.0.53#53 ** server can't find 23.1.1.10.in-addr.arpa: NXDOMAIN 

If you skip systemd-resolved the query works:

$ nslookup -type=ptr 10.1.1.23 10.1.1.1 Server: 10.1.1.1 Address: 10.1.1.1#53 Non-authoritative answer: 23.1.1.10.in-addr.arpa name = host.name.with.tld. 

You can also tell systemd-resolved to use the DNS server on a specific interface:

$ resolvectl -i tun1 query 10.1.1.23 10.1.1.23: host.name.with.tld -- link: tun1 

Use resolvectl status to see the DNS servers configured for each interface. The search domains dom1.lan, dom2.lan and dom3.lan have no effect on reverse lookups. You need to set e.g. ~1.10.in-addr.arpa as additional search domain for the specific interface:

resolvectl domain tun1 ~1.10.in-addr.arpa other.search.domains 

Then you can do the reverse lookup without specifying the DNS server by using the stub resolver:

$ nslookup -type=ptr 10.1.1.23 Server: 127.0.0.53 Address: 127.0.0.53#53 Non-authoritative answer: 23.1.1.10.in-addr.arpa name = host.name.with.tld. 
8
  • Thank you for trying. I must have explained it terribly wrong and I must admit I'm a bit baffled by my inability to explain it. I want to reverse DNS in a zone not in my /etc/resolv.conf search settings but that my DNS server has access to and is set up properly. Commented Oct 24, 2024 at 12:42
  • Try nslookup -type=ptr 8.8.8.8. The domain dns.google is certainly not in your /etc/resolv.conf but your local stub resolver (systemd-networkd under the address 127.0.0.53) knows which DNS server to ask, because it's in the default route. For this query it really doesn't matter what's in the search field of your /etc/resolv.conf. Commented Oct 24, 2024 at 13:16
  • The DNS server that has access tho the authoritative DNS server is on your local machine but you did not configure it to route these queries to the correct autoritative DNS server. Commented Oct 24, 2024 at 13:19
  • There is a mistake in my first comment: It's systemd-resolved instead of systemd-networkd. Commented Oct 24, 2024 at 13:31
  • 1
    You did not demonstrate in your question that this really works. It makes no sense but I don't know what ubound might does. Why didn't you tell us that you use ubound? I don't konw ubound but you should be able to understand your ubound problem from my answer. Commented Oct 24, 2024 at 13:48

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.