reverse-zone and subnet

[Kevin Darcy]

Peter Pilsl wrote:

> On Fri, Jan 18, 2002 at 07:23:32PM +0000, Barry Margolin wrote:
> > In article <a29ljr$jkj at pub3.rc.vix.com>,
> > Peter Pilsl  <pilsl at goldfisch.at> wrote:
> > ># dig @localhost -x 213.229.42.97 +norecursion
> >
> > You need recursion, or your server won't go to the ISP's servers to look up
> > the CNAME records that link into this subdomain.
> >
>
> thnx a lot for your help, but my quest isnt over yet.
>
> Im not sure if I understand your answer
>
> For now I just want to check if my zone for the reverse lookup
> works (and then ask my ISP to delegate ...).
>  If I ask my nameserver for a zone that is owned by this
> nameserver it should not do deeper recursion. The answer should be
> given in the first step.
>  Why is this different for reverse lookup ? If I understood you right,
> a reverselookup in my case would involve four steps:
>  i) ask local nameserver that hints to root-server
>  ii) root-servers hints to my ISP
>  iii) my ISP hints to my local nameserver again (if the delegation for
> my subnet would be installed there)
>  iv) my local nameserver reveals the reverse lookup
>
> Why does my local nameserver doesnt give the answer in the first step
> ? This is what it does for non-reverse zones and for non-routable
> reverse-zones (ie. 0.10.168.192.in-addr-arpa.)
>
> # dig @localhost -x 192.168.0.1 +norecursive
>
> ; <<>> DiG 9.2.0rc3 <<>> @localhost -x 192.168.0.1 +norecursive
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7085
> ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;1.0.168.192.in-addr.arpa.      IN      PTR
>
> ;; ANSWER SECTION:
> 1.0.168.192.in-addr.arpa. 259200 IN     PTR     server.local.
>
> ;; AUTHORITY SECTION:
> 0.168.192.in-addr.arpa. 259200  IN      NS      ns2.local.
> 0.168.192.in-addr.arpa. 259200  IN      NS      ns1.local.
>
> ;; ADDITIONAL SECTION:
> ns1.local.              259200  IN      A       192.168.0.1
> ns2.local.              259200  IN      A       192.168.0.1
>
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(localhost)
> ;; WHEN: Sat Jan 19 00:23:05 2002
> ;; MSG SIZE  rcvd: 136

Peter,
          The reason that it is different is because the resolution of those
PTR names needs to take place through the CNAMEs in your provider's reverse
zone, and those CNAMEs don't exist yet. Read RFC 2317 for more details. You
should be able to resolve the PTR records if you use their explicit names, e.g.
dig -x 213.229.42.29/96.97, but you won't be able to resolve them via, e.g. dig
-x 213.229.42.97 until the CNAMEs are created.


- Kevin