|
|
 |
|
DNS Lameness FAQ
- Definition of lameness.
- Why is lameness bad?
- Why am I being contacted?
- What can I do to fix my lame server?
- How do I test my name server is (no longer) lame?
- My name server(s) are no longer lame, what should I do next?
- How can I easily check my zone?
- I need some more help to fix my server.
DNS lameness errors
- No response
- Unable to resolve name server address(es)
- Answer not authoritative
- Answer from wrong IP [got "xxx.xxx.xxx.xxx" expected "yyy.yyy.yyy.yyy"]
- No SOA record returned
- Multiple SOA records returned
- Server returned status code SERVFAIL (or REFUSED, NXDOMAIN)
- Missing RNAME in SOA record
-
Definition of lameness
A server is defined as lame when a name server (NS) resource record (RR) in a zone points to it, but is the server does not answer correctly, or is not authoritative for its own name. For the purposes of these tests a server will be classified as lame when it does not satisfy the following criteria:
- The target of an NS RR must resolve into at least one address record RR (A or AAAA RR).
- A standard DNS UDP query, with RD=0 for a Start Of Authority (SOA) RR in the IN class and QNAME=<zonename>, must result in an authoritative response, sent from the same address the queries were targeted at with a single SOA RR for the QNAME in the answer section.
- This testing will be network layer protocol independent.
-
Why is lameness bad?
A lame server causes unnecessary network traffic, both to the lame server and to the DNS root servers. Because of this the RIPE community has requested that the RIPE NCC test those DNS servers to which space is being delegated.
-
Why am I being contacted?
Your e-mail address is listed as administrative contact in the SOA RNAME, or you are listed as the maintainer for the relevant domain object in the RIPE Database.
-
What can I do to fix my lame server?
Either your DNS server is misconfigured for your in-addr.arpa zone, or your nserver records in the RIPE Database do not match what you have in the SOA record for your zone. If your name server is misconfigured please change the SOA record in your zone to match what is listed in the relevant reverse DNS object. If the nserver records in your object are incorrect, please update your object. Also please make sure that all the name servers listed give an authoritative answer for your zone, from the same address as listed in the SOA record.
It is also possible that your secondary servers cannot transfer the zone from your server. In this case, you need to allow all your secondary servers to do this. This must be allowed in both your DNS software Access Control List (ACL) and your firewall.
Either your dns server is misconfigured for your in-addr.arpa zone, or
your nserver records in the RIPE Whois Database do not match what you
have in the SOA record for your zone.
-
How do I test if my name server is (no longer) lame?
There are many tools for this purpose. For this example we will describe the command line tool "dig". To query the name server ns-pri.ripe.net for the zone 1.0.193.in-addr.arpa you should issue the following command:
dig @ns-pri.ripe.net 1.0.193.in-addr.arpa soa +norec
The answer from this dig should contain no errors, and should have the 'aa' flag set in the "flags" section. When run for a secondary server for your zone, the answer should be similar. A correct answer would look something like this (note the 'aa' flag set in bold):
# dig @ns-pri.ripe.net 95.in-addr.arpa soa +norec
; <<>> DiG 9.3.1 <<>> @ns-pri.ripe.net 95.in-addr.arpa soa +norec
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29239
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0
;; QUESTION SECTION:
;95.in-addr.arpa. IN SOA
;; ANSWER SECTION:
95.in-addr.arpa. 172800 IN SOA ns-pri.ripe.net. dns-help.ripe.net. 2008071861 3600 7200 1209600 7200
;; AUTHORITY SECTION:
95.in-addr.arpa. 172800 IN NS ns.lacnic.net.
95.in-addr.arpa. 172800 IN NS sec1.apnic.net.
95.in-addr.arpa. 172800 IN NS sec3.apnic.net.
95.in-addr.arpa. 172800 IN NS ns-pri.ripe.net.
95.in-addr.arpa. 172800 IN NS tinnie.arin.net.
;; Query time: 2 msec
;; SERVER: 193.0.0.195#53(193.0.0.195)
;; WHEN: Fri Jul 18 16:28:52 2008
;; MSG SIZE rcvd: 201
-
My name server(s) are no longer lame, what should I do next?
You do not need to do anything. If your name servers are configured correctly you will not receive any further e-mail messages about this issue. Please keep in mind that we run these tests on a monthly basis, so it might take a month to make sure your server(s) are passing all our tests.
-
How can I easily check my zone?
Many of the most common mistakes can be detected by our Zone Delegation Checker. For more information, please see:
RIPE NCC Zone Delegation Checker.
-
I need some more help to fix my server.
If you are not able to fix the problem with your nameserver(s) and you have read all the explantions
on this page, you can write an email to dns-help(at)ripe.net with your questions. Please include what
nameservers you are having problems with, and what the errors listed in the email you received from us
are.
DNS Lameness Errors
-
No response
When we queried your name server we received no response. This may be caused by firewalls, the server being offline, DNS service not running on your server, or many other issues. It is recommended to try to query your name servers from a different Internet connection than the one your servers are on and see if you get the response you expect. It is possible to use a dig looking glass for this.
-
Unable to resolve name server
When we tried to query the name server you listed, it was not possible to resolve the name into an IP address to send the query to. Please make sure that the entries in the whois database are correct and that you have set up entries for these servers.
-
Answer not authoritative
Your server responded to the query, but it did not respond as being an authoritative server for the zone. You can check this by querying your server, and checking that the "aa" flag is set in the "flags" section of the response. See question 5 for an example.
-
Answer from wrong IP [got "xxx.xxx.xxx.xxx" expected "yyy.yyy.yyy.yyy"]
We sent a DNS query to your server, which was resolved into IP address "xxx.xxx.xxx.xxx", but the reply that was received came from "yyy.yyy.yyy.yyy". The most likely cause is that your DNS server has more than one IP address, and is responding via the wrong network interface.
-
No SOA records returned
Your server responded, but the response did not contain a SOA (Start Of Authority) record. The SOA record might be missing from the zone file on the server.
-
Multiple SOA records returned
Your server responded, but returned more then one SOA record. The SOA might be incorrect or entered multiple times in the zone file on the server.
-
Server returned status code SERVFAIL (or REFUSED, NXDOMAIN)
Your server responded with a status code that indicates an error. The status code itsself explains
what problem was encountered. The status codes that are most commonly returned are:
- SERVFAIL (Server Failure)
- NXDOMAIN (Non-Existent Domain)
- REFUSED (Query refused)
These status codes usually mean that the zone is not configured, or the zone is configured but a
policy restriction is preventing the server from answering.
Please note that this list is not complete, if the code you encountered is not listed please see
RFC2929 Section 2.3 for RCODE assignments.
-
Missing RNAME in SOA record
Your server responded but the SOA record did not contain a (valid) RNAME. The RNAME is part
of the SOA record and defines the email address of the person responsible for the zone. In
this e-mail address the @ is replaced with a dot. For example the RNAME in the example given
in faq no.5 is "dns-help.ripe.net".
|
|
|
|
| |
|
