DNS problem ?

[Kebold]

Hi all,

I have two server (sles 10) running in the same subnet.
The first one is a dns server properly configured, but there is some strange problem with ptr records.
in the dns server I set an A record ie:
example.com A 123.123.123.456
And I set the relative PTR record in the 123.123.123.in-addr.arpa. configuration file.
.456 IN PTR example.com

If from the second server (in the same subnet of the dns server) I search:
$> host 123.123.123.456
It answer with:
456.123.123.123.in-addr.arpa domain name pointer example.com

If I do the same test from an external pc in another subnet that use another dns server.
pc> host 123.123.123.456
It answer with:
host 456.123.123.123.in-addr.arpa not found: 3 (NXDOMAIN)

Where is the problem?

Thanks

[vigour]

The problem is that nobody in the world knows that your configured DNS server actually holds the zone.

Which means.. there is no NS record for that zone in the root DNS servers.

If you are the owner of 123.123.123.0/24 for an example and you wish to control the reverse DNS records, you should define the addresses of your NS servers in the regional registrar. Which means RIPE in Europe, ARIN in America, APNIC in Asia, etc...

And if you are not the owner of that ip range, you cannot control the reverse dns records.

[Kebold]

Hi Vigour,
Thanks for the answer.

In my example I suppose that I am the owner of my ip range and domain.
I've already defined a NS server in my regional registrar, so all should be work properly, but there is this problem with PTR querys, and I don't know why!

I also check my firewall configuration and all is ok. dns querys (port 53 tcp udp) are able to pass through the firewall.

[vigour]

If your name servers are listed as record holders at the DNS root servers and your port 53 is open (not only UDP traffic allowed, but also an open TCP port) and your zone file is configured properly, you should experience no problems.

I would suggest you a few steps.

1. Check with one of the root servers if your NS servers are listed for the given zones.

host -t ns 123.123.123.in.addr-arpa a.root-servers.net

Because all the octets you give here are the same, I'll put a little clarification.

If your network is: 1.2.3.0/24, your zone should look like: 3.2.1.in-addr.arpa.

So Anyway.. if you confirm that your NSes are added after step 1, move to step 2

2. Check whether your 53 port is truly accessible. Try to query your DNS server directly from an outside machine.

It it doesn't respond, you should investigate a network problem. Maybe a firewall.

If it responds correctly, check whether you can verify your reverse dns record correctly. If it doesn't give you a correct answer, check the log messages for an error.

[Kebold]

Sorry but I don't understand.

I'll try to explain better my problem:

I have a primary dns server (for example myDNSserver.it with 1.2.3.3 public IP).
I've registered a domain (to my regional registar) I've configured a master zone file (in myDNSserver.it) with the NS records and an A record:

(/var/lib/named/master/mydomain)
mydomain.it IN NS myDNSserver.it
mydomain.it IN NS thesecondarydns
www IN A 1.2.3.4 (this is the public IP)

Now from an outside machine I ping www .mydomain.it and it answer with the correct ip 1.2.3.4

Finally I would like to set up a PTR record for www . mydomain.it so I edit my 3.2.1.zone in the /var/lib/named/3.2.1.zone.

3.2.1.in-addr.arpa. IN NS localhost.
1 IN PTR localhost.
3 IN PTR myDNSserver.it.
4 IN PTR www .mydomain.it.

Now if I check for my NS server using an italian bestknow dns (dns2.interbusiness.it) (yes I'm italian):

dig @dns2.interbusiness.it mydomain.it NS

it respond me with

; <<>> DiG 9.3.2 <<>> @dns2.interbusiness.it mydomain.it NS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49531
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.it.                    IN      NS

;; ANSWER SECTION:
mydomain.it.             172354  IN      NS      myDNSserver.it
mydomain.it.             172354  IN      NS    secondaryDNSserver.it

;; Query time: 67 msec
;; SERVER: 151.99.125.3#53(151.99.125.3)
;; WHEN: Wed Jan  9 19:12:20 2008
;; MSG SIZE  rcvd: 76

But if I check for the PTR record from an outside machine:

host 1.2.3.4 dns2.interbusiness.it

It answer with:

Using domain server:
Name: dns2.interbusiness.it
Address: 151.99.125.3#53
Aliases:

Host 4.3.2.1.in-addr.arpa not found: 3(NXDOMAIN)

Now I check for PTR record using an outside machine but using my dns server:

 host 1.2.3.4 myDNSserver.it

The answer is:

Using domain server:
Name: myDNSserver.it
Address: 1.2.3.3#53
Aliases:

Host 4.3.2.1.in-addr.arpa not found: 2(SERVFAIL)

I don't know why I got this error

[vigour]

Aha.. so you've got a SERVFAIL when you ask your own DNS server.

Take a look at your /var/log/messages (if RH based) or wherever your DNS keeps the log files to check for any warnings/errors.

Something is definitely wrong with the setup. It might be a read permission to the zone file (the named's user is not allowed to read the zone file) or there is some mistake in the zone file itself. Or in the named.conf

[Kebold]

Ok There was a mistake in my zone file.

But Now I have another question.

The normal name resolution works without problem, but the reverse name resolution still have some problems.

host 1.2.3.4 myDNSserver.it

Using domain server:
Name: myDNSserver.it
Address: 1.2.3.3#53
Aliases:

4.3.2.1.in-addr.arpa domain name pointer www .mydomain.it.

This is ok, but

host 1.2.3.4 dns2.interbusiness.it

Using domain server:
Name: dns2.interbusiness.it
Address: 151.99.125.3#53
Aliases:

Host 4.3.2.1.in-addr.arpa not found: 3(NXDOMAIN)

Why?

[vigour]

As you are an Italian, RIPE is serving your IP address pool.

Please type the following:

whois 3.2.1.in-addr.arpa -h whois.ripe.net

Do you see any records for that zone? And if so.. make sure that your NS servers are listed under the nsserver fields.

If you do not see any records. e.g.

%ERROR:101: no entries found
%
% No entries found in the selected source(s).

Then you must use the RIPE database update tools to create a NS records in the RIPE's database.

On a second hand, if everything is normal with RIPE, try querying a different external NS server. The one you are trying now may have cached the information for your zone and may need a few hours to refresh it.

[Kebold]

Ok thank you very much

Kebold