Subnet reverse delagation, RFC 2317

Thu Jul 29 12:43:02 UTC 2010

Please everybody just forget the 62.142.220.0/24 network and 
62.142.220.5 address, the problem is not about them. It was just to 
inform that our servers are doing regular /24 reverse DNS just fine.

The problem is we are trying to set up and administer reverse DNS for 
62.142.217.128/25 IP network.

29.7.2010 15:10, Sami Kerola kirjoitti:
> On 07/29/2010 01:38 PM, bind-users-request at lists.isc.org wrote:
>> Date: Thu, 29 Jul 2010 14:38:20 +0300
>> From: Jukka Pakkanen<jukka.pakkanen at qnet.fi>
>> Subject: Re: Subnet reverse delagation, RFC 2317
>> To:bind-users at lists.isc.org
>> Message-ID:<4C51682C.3080903 at qnet.fi>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> 29.7.2010 14:26, Niobos kirjoitti:
>>> >  On 2010-07-29 09:58, Jukka Pakkanen wrote
>>> >
>>>> >>  Recursion is only allowed for the local networks, but why the 
>>>> server
>>>> >>  thinks recursion is needed in the first place?
>>>> >>
>>> >  Because it is: dig -x looks for 200.217.142.62.in-addr.arpa.
>>> >  Your server is not a master for this zone; instead it's master for
>>> >  128/25.217.142.62.in-addr.arpa.
>>> >
>>> >  The original request (200.217.142.62.in-addr.arpa.) is mapped via a
>>> >  CNAME to a name inside your zone, but this mapping is done by the
>>> >  ns3.sci.fi. nameserver; hence recursion is needed.
>>> >
>> Ok, this makes sense to me too.  But what is the fix, I can't allow
>> general recursion for the world?
>>
>> Is it possible to allow recursion for this zone only?  (sorry being
>> lazy, I'm sure this is in the ARM..).
>
> I cannot understand why you need RFC 2317 delegation when you have two 
> c-classes? But that's not an answer to problem.
>
> # whois 62.142.220.5
> [snip]
> inetnum:      62.142.220.0 - 62.142.221.255
> netname:      Q-NET
>
> I see right that there's delegation & data on ns6.sci.fi. name server...
>
> # dig +trace -x 62.142.220.5
> [snip]
> 142.62.in-addr.arpa.    172800  IN      NS      ns3.sci.fi.
> 142.62.in-addr.arpa.    172800  IN      NS      ns6.sci.fi.
> 142.62.in-addr.arpa.    172800  IN      NS      ns5.sci.fi.
> 142.62.in-addr.arpa.    172800  IN      NS      ns.ripe.net.
> ;; Received 172 bytes from 192.134.0.49#53(NS3.NIC.FR) in 206 ms
>
> 220.142.62.in-addr.arpa. 14400  IN      NS      ns3.sci.fi.
> 220.142.62.in-addr.arpa. 14400  IN      NS      ns5.sci.fi.
> 220.142.62.in-addr.arpa. 14400  IN      NS      ns6.sci.fi.
> ;; Received 151 bytes from 195.74.0.10#53(ns3.sci.fi) in 217 ms
>
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     qntsrv2.qnet.fi.
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     ns1.qnet.fi.
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     qnet.fi.
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns3.qnet.fi.
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns1.qnet.fi.
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns2.qnet.fi.
> ;; Received 154 bytes from 195.74.0.59#53(ns6.sci.fi) in 224 ms
>
>
> ...and further investigation is indicating...
>
> # dig +norecurse @ns3.sci.fi. -x 62.142.220.5
> ; <<>> DiG 9.6.1 <<>> +norecurse @ns3.sci.fi. -x 62.142.220.5
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16475
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
>
> ;; QUESTION SECTION:
> ;5.220.142.62.in-addr.arpa.     IN      PTR
>
> ;; AUTHORITY SECTION:
> 220.142.62.in-addr.arpa. 14400  IN      NS      ns5.sci.fi.
> 220.142.62.in-addr.arpa. 14400  IN      NS      ns6.sci.fi.
> 220.142.62.in-addr.arpa. 14400  IN      NS      ns3.sci.fi.
>
> ;; ADDITIONAL SECTION:
> ns3.sci.fi.             14400   IN      A       195.74.0.10
> ns5.sci.fi.             14400   IN      A       213.192.189.2
> ns6.sci.fi.             14400   IN      A       195.74.0.59
>
> ;; Query time: 375 msec
> ;; SERVER: 195.74.0.10#53(195.74.0.10)
> ;; WHEN: Thu Jul 29 14:07:38 2010
> ;; MSG SIZE  rcvd: 151
>
> # dig +norecurse @ns5.sci.fi. -x 62.142.220.5
>
> ; <<>> DiG 9.6.1 <<>> +norecurse @ns5.sci.fi. -x 62.142.220.5
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26753
> ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;5.220.142.62.in-addr.arpa.     IN      PTR
>
> ;; ANSWER SECTION:
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     qnet.fi.
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     qntsrv2.qnet.fi.
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     ns1.qnet.fi.
>
> ;; AUTHORITY SECTION:
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns3.qnet.fi.
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns2.qnet.fi.
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns1.qnet.fi.
>
> ;; Query time: 422 msec
> ;; SERVER: 213.192.189.2#53(213.192.189.2)
> ;; WHEN: Thu Jul 29 14:07:47 2010
> ;; MSG SIZE  rcvd: 154
>
> # dig +norecurse @ns6.sci.fi. -x 62.142.220.5
>
> ; <<>> DiG 9.6.1 <<>> +norecurse @ns6.sci.fi. -x 62.142.220.5
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38750
> ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;5.220.142.62.in-addr.arpa.     IN      PTR
>
> ;; ANSWER SECTION:
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     qnet.fi.
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     qntsrv2.qnet.fi.
> 5.220.142.62.in-addr.arpa. 86400 IN     PTR     ns1.qnet.fi.
>
> ;; AUTHORITY SECTION:
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns1.qnet.fi.
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns3.qnet.fi.
> 220.142.62.in-addr.arpa. 86400  IN      NS      ns2.qnet.fi.
>
> ;; Query time: 303 msec
> ;; SERVER: 195.74.0.59#53(195.74.0.59)
> ;; WHEN: Thu Jul 29 14:07:51 2010
>
>
> ...that 2 out of 3 name servers on delegation level are answering to 
> requests. I would make sure that sci.fi. name servers stop answering 
> to queries which they are supposed to delegate.
>