rfc2317 - testing ISP setup?
Chris Buxton
cbuxton at menandmice.com
Mon Jun 4 14:28:44 UTC 2001
There isn't any one single query you can send to find out the state
of things. You need to send several iterative (non-recursive) queries
to see the whole delegation. Below is the output of several queries I
sent for one of your addresses, using dig instead of my usual DNS
query tool for instructive purposes, with irrelevant headers and
footers removed.
____________________________________________________________________
% dig @f.root-servers.net PTR -x 213.253.143.225 +norecurse
;; AUTHORITY SECTION:
213.in-addr.arpa. 4D IN NS NS.RIPE.NET.
213.in-addr.arpa. 4D IN NS NS.EU.NET.
213.in-addr.arpa. 4D IN NS AUTH00.NS.UU.NET.
213.in-addr.arpa. 4D IN NS NS3.NIC.FR.
213.in-addr.arpa. 4D IN NS SUNIC.SUNET.SE.
213.in-addr.arpa. 4D IN NS MUNNARI.OZ.AU.
213.in-addr.arpa. 4D IN NS NS.APNIC.NET.
213.in-addr.arpa. 4D IN NS SVC00.APNIC.NET.
;; ADDITIONAL SECTION:
NS.RIPE.NET. 2D IN A 193.0.0.193
NS.EU.NET. 2D IN A 192.16.202.11
AUTH00.NS.UU.NET. 1D IN A 198.6.1.65
NS3.NIC.FR. 2D IN A 192.134.0.49
SUNIC.SUNET.SE. 2D IN A 192.36.125.2
MUNNARI.OZ.AU. 2D IN A 128.250.1.21
NS.APNIC.NET. 2D IN A 203.37.255.97
SVC00.APNIC.NET. 2D IN A 202.12.28.131
____________________________________________________________________
% dig @ns.eu.net PTR -x 213.253.143.225 +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2562
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; AUTHORITY SECTION:
213.in-addr.arpa. 2H IN SOA ns.ripe.net. ops.ripe.net. (
2001060102 ; serial
12H ; refresh
2H ; retry
2W ; expiry
2H ) ; minimum
____________________________________________________________________
Notice I've included some of the headers, as they are important.
Here's what relevant information can be gleaned from the above:
- The status is set to NXDOMAIN, or "no such domain".
- The aa flag is present, indicating an authoritative answer.
- The name of the SOA record indicates that nothing is delegated past
the class A subnet's reverse zone.
- The primary master server is set to ns.ripe.net.
Therefore, someone (either your ISP or their NSP, most likely) should
discuss with RIPE the possibility of getting the reverse records for
their netblock delegated to them. Until then, nothing you do on your
server with regard to reverse records will have any effect.
However, let's see what your provider's server says, since you've
given us its address:
____________________________________________________________________
% dig @193.243.233.10 PTR -x 213.253.143.225 +norecurse
;; ANSWER SECTION:
225.143.253.213.in-addr.arpa. 1D IN CNAME
225.224-255.143.253.213.in-addr.arpa.
;; AUTHORITY SECTION:
224-255.143.253.213.in-addr.arpa. 1D IN NS ns0.emtex.com.
;; ADDITIONAL SECTION:
ns0.emtex.com. 12H IN A 193.243.232.67
____________________________________________________________________
Now let's ask ns0.emtex.com about this "canonical name":
____________________________________________________________________
% dig @ns0.emtex.com 225.224-255.143.253.213.in-addr.arpa PTR +norecurse
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
____________________________________________________________________
We should have seen the aa flag here; since we didn't, the answer
your server gives is cached, and is therefore not relevant to the
discussion.
From the way your phrased the question, I get the feeling you've used
a different zone name. Let's query your server for that:
____________________________________________________________________
% dig @ns0.emtex.com 225.224/27.143.253.213.in-addr.arpa PTR +norecurse
;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
____________________________________________________________________
This time, the aa flag is present. (You're not delegating anything,
so the response is once again irrelevant.)
You need to rename your zone from "224/27.143.253.213.in-addr.arpa"
to "224-255.143.253.213.in-addr.arpa" to conform to the way your
provider has set up the delegation. RFC 2317 describes a method, but
the particular details it uses are (even in the RFC itself) described
as only one way to do it. The canonical name (the data portion of the
CNAME record in your ISP's reverse zone) is entirely arbitrary; it
doesn't even have to end in "in-addr.arpa".
If you're curious about what I usually use for DNS queries, it's in my sig.
____________________________________________________________________
Chris Buxton <cbuxton at menandmice.com>
Men & Mice <http://www.menandmice.com/> provides:
- DNS training, including Active Directory
- QuickDNS, a DNS management system for servers on Linux & Mac OS
(Solaris support coming soon!)
- DNS Expert, a DNS analysis and troubleshooting utility
____________________________________________________________________
At 1:14 PM +0000 6/4/01, billd wrote:
>Hi,
>
>I'm trying to get my ISP to allow me to reverse map
>my own DNS for my small home network... I had
>some difficulty persuading them, however in the end
>they said they did what needs doing... I have set
>everything up on my end as per the RFC2317 but
>it still doesn't work and as far as I can tell, requests
>are not being forwarded to my name server. Is there any
>way that I can check that they have done things
>correctly as it isn't working... the vitals are:
>
>my network address space is:
>
>213.253.143.224 and netmask of 255.255.255.224
>
>Their name server is
>
>193.243.233.10
>
>I am trying to figure out how dig works... but learning
>very slowly... I'd appreciate if someone could tell me
>a dig statement that would show me who's server would
>be looked up for reverse DNS for this network space...
>...
>
>thanks
>Bill
More information about the bind-users
mailing list