LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices


Reply
  Search this Thread
Old 04-01-2010, 09:06 AM   #1
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Rep: Reputation: 36
Reversed DNS-lookup do not work on delegated zone.


Hi guys.
I'm having this problem that's driving me nuts.
Basically I've set up 2 virtual DNS servers.
1. Master on fictive domain "domain.xx".
2. Master of fictive domain "sub.domain.xx"

DNS 1 delegated sub. zone-space to the DNS 2.

Everything works except for reverse lookup on sub-domain.

For instance. 172.16.0.101 should resolve to my fictive mail.sub.domain.xx

If I try to resolve it with 'host 172.16.0.101' from domain.xx I get:
Host 101.0.16.172.in-addr.arpa not found: 2(SERVFAIL)

If I do the same from the actual sub.domain.xx I get:
Host 101.0.16.172.in-addr.arpa. not found: 3(NXDOMAIN).

If I, on the other hand, try to resolve a hostname both from domain.xx or sub.domain.xx with 'host mail.sub.domain.xx' I get the proper address as the answer: 172.16.0.101

I've delegated the in-addr.arpa space to sub.domain.xx dns-server according to RFC 2317 specification, at least I think...


Please note this is a virtual network address 172.16.0.0/24
Here are the excerpts of the in-arpa-files on both domain.xx and the sub.domain.xx server.


domain.xx server in-addr.arpa zone:

Code:
$TTL 12h
$ORIGIN 0.16.172.IN-ADDR.ARPA.
@       IN      SOA     @                         root (
                                2010033101      ;       serial num
                                5m              ;       refresh
                                15m             ;       retry
                                3w              ;       expiry
                                2h20m           ;       minimum
                                )
                        IN      NS      centos-server1.domain.xx.

10                      IN      PTR     centos-server1.domain.xx.
11                      IN      PTR     mail.domain.xx.


; delegated space bellow. We use 172.16.0.0/26 subnetting and 
; sub.domain.xx will get 172.16.0.64/26 network space.

64/26                  IN      NS  centos-server2.sub.domain.xx.

100                    IN      CNAME   100.64/26
101                    IN      CNAME   101.64/26
On the master for the delegated zone, sub.domain.xx, named.conf and in-addr.arpa zone looks like this:

Code:
zone "64/26.0.16.172.IN-ADDR.ARPA" in {
        type master;
        file "sub.domain.xx.rev";
};
Code:
$TTL 12h
$ORIGIN 64/26.0.16.172.in-addr.arpa.
@       IN      SOA     centos-server2.sub.domain.xx.  root.sub.domain.xx. (
                                2010033005      ;       serial num
                                5m              ;       refresh
                                15m             ;       retry
                                3w              ;       expiry
                                2h20m           ;       minimum
                                )

                        IN      NS      centos-server2.sub.domain.xx.
        
100                     IN              PTR     centos-server2.sub.domain.xx.
101                     IN              PTR     mail.sub.domain.xx.
This has been driving me nuts for two days now. Reversed lookup simply won't work from either end, for sub.domain.xx . I get no error messages in logs / or when running named-checkzone/checkconfig.

Any feedback is appreciated!

Thanks in advance!
M.

Last edited by MheAd; 04-01-2010 at 09:50 AM.
 
Old 04-01-2010, 09:43 AM   #2
bathory
LQ Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 13,168
Blog Entries: 1

Rep: Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038
Hi,

Quote:
64/26 IN NS centos-server2.sub.domain.xx. <--missing dot
You miss the trailing dot (unless it's a typo).
 
Old 04-01-2010, 09:50 AM   #3
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
Thanks for the reply.
It was a typo in my post (edited the post now).
If that was the actual problem, only reverse lookup through domain.xx would be affected.

I'm experiencing reverse lookup problems even from the actual sub.domain.xx DNS. It must be something with the arpa-zone of the sub.domain.xx

Any other suggestion is appreciated.

Last edited by MheAd; 04-01-2010 at 09:55 AM.
 
Old 04-01-2010, 10:07 AM   #4
bathory
LQ Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 13,168
Blog Entries: 1

Rep: Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038
I thought it was the trailing dot because of the SERVFAIL message you get.
I guess the SERFAIL is because of the wrong SOA record.
Change the SOA from:
Quote:
@ IN SOA @ root (
to
Code:
@   IN    SOA    centos-server1.domain.xx.    root (
because the @ in this case is 0.16.172.IN-ADDR.ARPA., and see if it works
 
Old 04-01-2010, 10:13 AM   #5
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
It was all the same. It didn't change anything.

Please observe one more time. Let's try to isolate the error and stay focussed on the actual sub.domain.xx DNS before investigating the one for domain.xx.

When I try to do reverse host lookup from the actual sub.domain.xx DNS - I still get errors (like the example I wrote in my original post - Host 101.0.16.172.in-addr.arpa. not found: 3(NXDOMAIN) ).
When I'm doing this - the sub.domain.xx DNS (centos-server2.sub.domain.xx host) is doing doing a reversed lookup from its own zone-data - it's not using anything from domain.xx .
 
Old 04-01-2010, 10:37 AM   #6
bathory
LQ Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 13,168
Blog Entries: 1

Rep: Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038
This is not how classless delegation works.
When a client (in your case centos-server2.sub.domain.xx) tries to resolve an IP address it has to ask the authoritative dns for the whole 172.16.0.0/24 network. That in turn will reply with the address of the delegated dns for that subnet and the client (centos-server2..) will then ask it to resolve the ip.
So in your case you have to find out why the first gives the SERVFAIL message. There is something wrong in the configuration that I cannot spot right now. There should be something in the logs, and if not you could enable logging for more detailed logs.
 
Old 04-01-2010, 10:45 AM   #7
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
I can try to set the log level to debug to see if anything comes up.

However, I'm getting confused by your last statement.

Are you claiming that centos-server2.sub.domain.xx , which is authoritative for sub.domain.xx zone would need to ask centos-server1.domain.xx, "one level above" for anything? Isn't the purpose of this delegation from domain.xx point of view - to point external queries to a domain "one level below" - sub.domain.xx where its master is taking care of the rest? With other words, shouldn't only requests from external domains need to go through domain.xx to actually get down to sub.domain.xx? Why would resolver of the actual sub.domain.xx DNS need to query a server one level above for anything when it's already got zone data - that master of the zone it is? I don't understand...

Last edited by MheAd; 04-01-2010 at 11:08 AM.
 
Old 04-01-2010, 11:12 AM   #8
bathory
LQ Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 13,168
Blog Entries: 1

Rep: Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038
I don't know why, but this is how it works. Only the top level dns is authoritative for the whole class C network.
You can verify it using dig (when you solve the problem):
Code:
dig -x 172.16.0.101
dig -x 172.16.0.101 @172.16.0.10
(You'll note the aa in the flags of the answer you get)
I guess this is done as a convenience, so you can change PTR records in a subnet without having to ask the admins of the upstream dns.
 
Old 04-01-2010, 11:31 AM   #9
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
I solved the part of the problem (on the centos-server1.domain.xx). It was a tiny typo.
Now I can resolve addresses to hostnames that are delegated to sub.domain.xx

BUT, the problem for reversed queries directly from sub.domain.xx still persist!

The results of the commands you stated are also true.

However, if I, on centos-server1.domain.xx do a dig on the actual zone:

dig sub.domain.xx

it won't show aa flag.

On the other hand, executing this command from centos-server2.sub.domain.xx will show aa.

So could we say that centos-server1 is authoritative for the range of the addresses while server2 is authoritative for the actual sub-zone? (if it doesn't sound confusing).

BACK TO SUBJECT, now that I managed resolving IP > hostnames work via domain.xx DNS > sub.domain.xx , I'm wondering what I'm supposed to do with the sub.domain.xx DNS to make it work from the actual sub.domain.xx. The configuration file is very "clean" - I see nothing that possibly could be wrong.

Last edited by MheAd; 04-01-2010 at 11:48 AM.
 
Old 04-01-2010, 11:56 AM   #10
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
Also, if your previous statement (that a master dns of a zone that's been delegated by a domain above - needs to query the actual delegating server for reversed lookup) indeed is the true, then I'm suspecting it's impossible to do what I want to do - from sub.domain.xx point a view. In that case it means that sub.domain.xx server needs to "go out" to ROOT servers and search for 172.16.0.0/24 network (the one that domain.xx is authoritative for). Since this is internal network with private address range, and no of the domains are actually registrated - this cannot be done? Or is there a way to do it by "cheating", some kind of forward-option in the sub.domain.xx ?
 
Old 04-01-2010, 12:08 PM   #11
bathory
LQ Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 13,168
Blog Entries: 1

Rep: Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038
Yeah those tiny typos are always the more difficult to spot!
Quote:
So could we say that centos-server1 is authoritative for the range of the addresses while server2 is authoritative for the actual sub-zone? (if it doesn't sound confusing).
server1 is authoritative for the whole 172.16.0.0/24 network. Whenever a IP lookup is requested it forwards the query to server2, if it finds that server2 is the delegated dns for that IP, or just responds by itself. Technically server2 is more like a forwarder dns for server1.

Quote:
Either way, now that I managed resolving IP > hostnames work via domain.xx DNS > sub.domain.xx , I'm wondering what I'm supposed to do with the sub.domain.xx DNS to make it work from the actual sub.domain.xx. The configuration file is very "clean" - I see nothing that possibly could be wrong.
I don't understand what you mean? What is the problem with server2?
Do the clients of sub.domain.xx resolve hostnames/IPs for that domain/subnet as expected using server2?

Quote:
In that case it means that sub.domain.xx server needs to "go out" to ROOT servers and search for 172.16.0.0/24 network (the one that domain.xx is authoritative for). Since this is internal network with private address range, and no of the domains are actually registrated - this cannot be done? Or is there a way to do it by "cheating", some kind of forward-option in the sub.domain.xx ?
For 172.16.0.0/24 the ROOT server is server1. Again I cannot see what you are trying to do and how it fails. Could you be more specific, giving an example maybe?
 
Old 04-01-2010, 12:17 PM   #12
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
Ok, more specifically, ignore all my recent rant ( ) and consider only one remaining problem - the hosts on sub.domain.xx still experience the same problem with reverse lookups, even the actual sub.domain.xx DNS-server (centos-server2.sub.domain.xx).

For instance, when on sub.domain.xx network, and doing a 'host 172.16.0.101' will return the same error
Host 101.0.16.172.in-addr.arpa. not found: 3(NXDOMAIN).

That's why I'm starting to suspect that the actual DNS server is consulting the 'hint' zone - going out on the internet and querying the root-server (and of course not getting any hit since these domains are fake).
 
Old 04-01-2010, 12:42 PM   #13
bathory
LQ Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 13,168
Blog Entries: 1

Rep: Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038
I cannot see any error in the zone file of the 64/26.0.16.172.in-addr.arpa. zone.
Are you sure the answer you get is not cached? Note that you have a 12h ttl.
 
Old 04-01-2010, 01:01 PM   #14
MheAd
Member
 
Registered: Jun 2007
Distribution: Ubuntu 14.04
Posts: 186

Original Poster
Rep: Reputation: 36
I'm aware of that.
I've restarted the DNS, done rndc flush...usual stuff - still the same.
Here's a short bit of the log just when I execute 'host 172.16.0.101'. The severity is set to debug.
Please note a whole bunch of to-ROOT-servers queries.

Code:
01-Apr-2010 19:56:32.856 resolver: debug 1: createfetch: 101.0.16.172.in-addr.arpa PTR
01-Apr-2010 19:56:32.856 resolver: debug 1: createfetch: . NS
01-Apr-2010 19:56:32.857 lame-servers: info: network unreachable resolving '101.0.16.172.in-addr.arpa/PTR/IN': 2001:7fd::1#53
01-Apr-2010 19:56:32.857 lame-servers: info: network unreachable resolving '101.0.16.172.in-addr.arpa/PTR/IN': 2001:500:2f::f#53
01-Apr-2010 19:56:32.857 lame-servers: info: network unreachable resolving './NS/IN': 2001:dc3::35#53
01-Apr-2010 19:56:32.857 lame-servers: info: network unreachable resolving '101.0.16.172.in-addr.arpa/PTR/IN': 2001:dc3::35#53
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: U.ARIN.NET A
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: U.ARIN.NET AAAA
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: V.ARIN.NET A
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: V.ARIN.NET AAAA
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: W.ARIN.NET A
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: W.ARIN.NET AAAA
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: X.ARIN.NET A
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: X.ARIN.NET AAAA
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: Y.ARIN.NET A
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: Y.ARIN.NET AAAA
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: Z.ARIN.NET A
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: Z.ARIN.NET AAAA
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: DILL.ARIN.NET A
01-Apr-2010 19:56:32.915 resolver: debug 1: createfetch: DILL.ARIN.NET AAAA
01-Apr-2010 19:56:32.962 database: debug 1: no_references: delete from rbt: 0x971a7a0 c3.nstld.com
01-Apr-2010 19:56:32.962 database: debug 1: no_references: delete from rbt: 0x971a7a0 d3.nstld.com
01-Apr-2010 19:56:32.962 database: debug 1: no_references: delete from rbt: 0x971a7a0 m3.nstld.com
Also, please note the second row ( . NS ).
The dot (.) could mean it goes for ROOT-servers?
 
Old 04-01-2010, 01:31 PM   #15
bathory
LQ Guru
 
Registered: Jun 2004
Location: Piraeus
Distribution: Slackware
Posts: 13,168
Blog Entries: 1

Rep: Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038Reputation: 2038
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?
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
DNS lookup doesn't work, ping, firefox will not work properly lovemov Linux - Networking 2 04-23-2009 02:30 PM
DNS lookup failed: How does /etc/resolv.conf work? kenneho Linux - Server 2 01-20-2009 06:54 AM
classless non-delegated reverse DNS Berhanie Linux - Server 0 04-18-2008 05:20 PM
Traceroute, Ping, Domain Name Server (DNS) Lookup, WHOIS, and DNS Records Lookup netoknet General 1 05-09-2005 03:43 AM
DNS Lookup do not work for Firefox rpigna Mandriva 2 04-27-2005 01:17 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Server

All times are GMT -5. The time now is 05:40 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration