Reverse DNS issue…Help Needed Please ..?

[redhat7012]

Hi,

We have configured reverse DNS  and asked the Network team to update the RIPE database.But we have got the reply from them saying that:

“This needs to be authorative first on the DNS servers before we can update RIPE.”

Can anybody tell me what does they mean by authorative first on the DNS?

Forward DNS is in Place :

=====================

carnap# nslookup mail1.reftec.se

Server:  dns1.o2.ie

Address:  62.40.32.33

Non-authoritative answer:

Name:    mail1.reftec.se

Address:  45.204.215.233

Reverse DNS is in Place :

===================

carnap# nslookup 45.204.215.233

Server:  dns1.o2.ie

Address:  62.40.32.33

Name:    mail1. reftec.se

Address:  45.204.215.233

Can anybody tell me what does they mean by authorative first on the DNS?

Regards,

Aparna.

P.S. This thread has been moved from HP-UX > System Administration to HP-UX > networking - HP Forums Moderator

[Matti_Kurkela]

The word should be "authoritative"; I guess "authorative" is a typo.

When you're about to have your server listed in a RIPE database, it should be ready to serve public queries immediately.

My DNS server cannot resolve mail1.reftec.se at all at this moment. Because your change has not yet been accepted by RIPE, this is as expected:

$ nslookup mail1.reftec.se
Server:         192.168.42.1
Address:        192.168.42.1#53

** server can't find mail1.reftec.se: NXDOMAIN

 But if dns1.o2.ie is the server that will be responsible for publishing the new DNS zone, and that the new zone in that server is supposed to be ready for RIPE registration, I should already be able to query it by directing my query to dns1.o2.ie explicitly. However, this does not seem to work:

$ nslookup mail1.reftec.se dns1.o2.ie
Server:         dns1.o2.ie
Address:        62.40.32.33#53

** server can't find mail1.reftec.se: NXDOMAIN

 So apparently the dns1.o2.ie DNS server answers to me (located outside your network) differently than it does to you (presumably located somewhere inside your network). This is the first thing you'll need to fix if you want to use dns1.o2.ie to serve public DNS information for reftec.se.

If dns1.o2.ie is not the server you are trying to register to RIPE database, the above analysis may not be applicable to your situation.In that case, please identify the actual server you are trying to register so that we can verify that it works correctly.

By the way, dig might be a better tool for testing DNS servers than the old nslookup.

In this case, if I use dig to query dns1.o2.ie about mail1.reftec.se with DNS recursion disabled (i.e. simulating the type of queries DNS servers use between each other, instead of what a DNS client sends to a DNS server), I get this response:

$ dig +norecurse mail1.reftec.se @dns1.o2.ie

; <<>> DiG 9.7.3 <<>> +norecurse mail1.reftec.se @dns1.o2.ie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52979
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;mail1.reftec.se.               IN      A

;; AUTHORITY SECTION:
reftec.se.              26523   IN      NS      ns3.chalmers.se.
reftec.se.              26523   IN      NS      ns2.chalmers.se.
reftec.se.              26523   IN      NS      ns1.chalmers.se.

;; ADDITIONAL SECTION:
ns1.chalmers.se.        108009  IN      A       129.16.2.40
ns1.chalmers.se.        108009  IN      AAAA    2001:6b0:2:10::1
ns3.chalmers.se.        108009  IN      A       192.36.120.11

;; Query time: 71 msec
;; SERVER: 62.40.32.33#53(62.40.32.33)
;; WHEN: Sun Oct 28 14:24:22 2012
;; MSG SIZE  rcvd: 156

 The AUTHORITY SECTION part does not include any SOA records at all. In effect, dns1.o2.ie is saying: "I have nothing at all to do with the reftec.se zone, and have no idea at all about mail1.reftec.se. But I happen to have some data in my cache that indicates these chalmers.se DNS servers are likely to know more."

Such an answer is unacceptable for RIPE registration: RIPE requires that the servers to be registered are authoritative for the respective zone or zones. An authoritative server is guaranteed to have a complete and up-to-date set of DNS records for the zone, so if someone sends it a query referring to that zone but there are no matching records, the authoritative server will never answer "I don't know." Instead, it says: "I am absolutely sure such a record does not exist in this zone at this time." This distinction is important, as negative answers can be cached to minimize the effect of repeated queries for non-existent information (e.g. because of a typo in application configuration somewhere).

In practical BIND configuration terms, if BIND is configured as either a master or slave server for a particular zone, it will be authoritative for that zone. (Master zone is the ultimate authority by definition; slaves are supposed to constantly maintain a complete and up-to-date replica of the master zone, or stop answering for that zone if their data is stale.)