Reversed DNS-lookup do not work on delegated zone.
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Yes it goes out to ask for the ip.
Could you post the named.conf of server2?
What is the query line in the log?
Also what's in /etc/resolv.conf?
Of course I could post - I really appreciate YOU taking YOUR time to help me out!
How is that "query" supposed to look like?
I'm not able to find anything in the log (severity level debug).
resolv.conf of the server2 is configured so it uses itself for queries, the DNS-master of sub.domain.xx it is.
search sub.domain.xx
address 172.16.0.100 (IP address that server2 DNS listens on)
named.conf of server2.
It's nothing fancy, really...I just need this simple setup for some DNSSec-experiments that I will be implementing as soon as I've solved this issue
Code:
options {
directory "/var/named";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";
listen-on { 172.16.0.100; };
};
logging {
channel logfile {
file "/var/log/logfile" versions 3 size 10m;
print-time yes;
print-severity yes;
print-category yes;
severity debug;
};
category default {logfile;};
};
zone "." in {
type hint;
file "named.root";
};
zone "localhost" in {
type master;
file "localhost";
};
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "localhost.rev";
};
zone "sub.domain.xx" in {
type master;
file "sub.domain.xx.master";
};
zone "64/26.0.16.172.IN-ADDR.ARPA" in {
type master;
file "sub.domain.xx.rev";
};
Increase the serial for 64/26.0.16.172.IN-ADDR.ARPA (it's a master server after all), because NXDOMAIN means that there is no 172.16.0.101. The fact is to know which dns gives that response.
For this it's better use dig instead of host and (optionally) use your dns IP:
It obviously queries ROOT servers which makes me think that this is the only way it does the things and since this is virtual environment, with private addresses, it cannot be done. I mean, if it must query for the server that is authoritative for the entire 172.16.0.0/24 range, it cannot possibly know of existance of the domain.xx which is one level above itself - thus the reason why it queries the ROOT-section for the answer.
It's the default for a private address if it cannot be resolved. I get the same answer and I don't have a dns for the 172.16.0.0 network.
Sorry I've to leave for a couple of hours, so I'll look to it later.
Ok, have a nice day and thanks for all your effort so far - I'll keep digging into it until I hear again from you (or manage to solve the problem myself).
I've done the same setup as you for my 192.168.0.0/24 network and it worked as expected.
Maybe there is another typo. I've looked very carefully the files you've posted and I didn't find anything, but you should take a look also.
Also are you sure that centos-server1.domain.xx can resolve centos-server2.sub.domain.xx IP address?
I've done the same setup as you for my 192.168.0.0/24 network and it worked as expected.
Maybe there is another typo. I've looked very carefully the files you've posted and I didn't find anything, but you should take a look also.
Also are you sure that centos-server1.domain.xx can resolve centos-server2.sub.domain.xx IP address?
Hi again!
I'm not finding any typos.
Yes, centos-server1.domain.xx can resolve centos-server2.sub.domain.xx and anything else inside of that subdomain.
Only hosts in the actual sub.domain.xx cannot do reversed lookups on anything.
Because of the setup, I was aware that the sub.domain.xx was unable to resolve anything from domain.xx (because it doesn't know of its existance, and it cannot find domain.xx via ROOT servers as the domain is fake - to be able to do this, I would need to add centos-server1.domain.xx as forwarder for that zone, inside of server2, named.conf) but I was expecting them to be able to resolve (reversed) addresses inside its own domain thanks to the PTR records of the actual sub.domain.xx server. Yet it goes out to ROOT servers and do the lookup and then fails, of course.
I'll need to read more about delegation-theory.
If one of your previous statements is correct (about delegation) then queries to ROOT servers are necessary too, from delegated zones point of view, when a reversed lookup is done - and then I wont be able to do this in virtual environment and you shouldn't be able either, with your setup, unless there is a missunderstanding here between my problem and your solution.
Because of the setup, I was aware that the sub.domain.xx was unable to resolve anything from domain.xx (because it doesn't know of its existance, and it cannot find domain.xx via ROOT servers as the domain is fake - to be able to do this, I would need to add centos-server1.domain.xx as forwarder for that zone, inside of server2, named.conf) but I was expecting them to be able to resolve (reversed) addresses inside its own domain thanks to the PTR records of the actual sub.domain.xx server. Yet it goes out to ROOT servers and do the lookup and then fails, of course.
So, if I understand correct server2.sub.domain.xx cannot resolve hosts of domain.xx (like centos-server1.domain.xx).
When some client tries to resolve 172.16.0.101, the query goes to server1, that in turns finds out that this subnet is delegated to server2.subdomain, gives this response to client, the client asks server2.subdomain and server2.subdomainas tries to ask server1 that is authoritative for the 172.16.0.0 network, but it cannot resolve server1 IP (am I correct?) and goes to ROOT server to find out.
I think that you have 2 possibilities to go:
You can use IPs instead of host names in the NS records of the zone files, or add forwarders for domain.xx (you said...).
So, if I understand correct server2.sub.domain.xx cannot resolve hosts of domain.xx (like centos-server1.domain.xx).
When some client tries to resolve 172.16.0.101, the query goes to server1, that in turns finds out that this subnet is delegated to server2.subdomain, gives this response to client, the client asks server2.subdomain and server2.subdomainas tries to ask server1 that is authoritative for the 172.16.0.0 network, but it cannot resolve server1 IP (am I correct?) and goes to ROOT server to find out.
I think that you have 2 possibilities to go:
You can use IPs instead of host names in the NS records of the zone files, or add forwarders for domain.xx (you said...).
Pretty much so, yeah. But I was aware of the limitation of sub.domain.xx not being able to resolve anything in domain.xx unless consulting the ROOT (which will result in failure due obvious reasons) or by using forwarder. I'm surprised, however, that it must do this to resolve its own reversed addresses. I mean, it's got its own ARPA-zone file with PTR records, why would it need to look first for the server that delegated it. It doesn't do that when it resolves hostnames to addresses. If I query mail.sub.domain.xx on sub.domain.xx it will use the DNS zone info on sub.domain.xx and return the 172.16.0.101 address. It's the other way around that doesn't work - reversed resolving. That's why I need to read more about the theory of delegating in-arpa to be 100% certain. Meanwhile, I'm curious how you got it working, as you wrote last night that you did an identical setup - and it worked.
Well, I've solved the problem by adding following forwarder on my server2 (sub.domain.xx) - which goes out to server1. It is used for reversed queries - when sub.domain.xx tries to do reversed resolving on the delegated ARPA-addresses, on 172.16.0.64/26 subnet. This forces the server to go to the delegating server directly instead of querying the root zones of ARPA on the internet.
zone "0.16.172.IN-ADDR.ARPA" in {
type forward;
forward only;
forwarders { 172.16.0.10;};
};
This way, it doesn't go out on the Internet to resolve the addresses. This is very "ugly" and odd, but the only way I could make it work. I will be still reading on the ARPA-subject to fully understand this behaviour. I always thought that a DNS, that is a master over a delegated sub-domain, just like it uses its own zone-files to resolve the hosts in the domain - does the same with ARPA-addresses as well. Apparently not, and since this is virtual environment with no registrated addresses - this rule was necessary to make it work.
Anyway, I appreciate a lot for all your efforts to try to help me out, mate.
Yesterday I've left my domain name that can be resolved from ROOT servers. Now I've also used domain.xx and here is the answer from my server2 (192.168.0.77):
It looks that we were posting at the same time...
Anyway I've used no forwarders, or any other hack
In that case, I get even more frustrated.
Why did it work at your end and not at mine?
Would you mind posting your entire configuration (zones + named.conf of both servers), if it's not too much trouble for you?
PS.
I get same results just like yourself (although I'm doing it on 172.16.0.101 address in my case) but it works only with the forwarder hack (from server2 point of view - i never had problems doing this from domain above - server1).
So please post your conf. I would really appreciate it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
