Subnet reverse delagation, RFC 2317
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
Recursion is only allowed for the local networks, but why the server
thinks recursion is needed in the first place?
Server ns1.qnet.fi, BIND 9.7.1-P1 W2K3
named.conf:
zone 128/25.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.25-128;
};
;
;File: named.62.142.217.25-128
;
$TTL 86400
$ORIGIN 128/25.217.142.62.IN-ADDR.ARPA.
@IN SOAns1.qnet.fi. xxx.qnet.fi. (
201007281 ; serial number
28800 ; refresh every 12 hours
7200 ; retry after 2 hours
604800 ; expire after 2 weeks
86400) ; default ttl is 2 days
;
@IN NSns1.qnet.fi.
IN NSns2.qnet.fi.
IN NSns3.qnet.fi.
200 IN PTR x200.qnet.fi.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 07/29/2010 08:58 AM, Jukka Pakkanen wrote: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work It doesn't look like the reverse is deleted to you: $ dig +comm +nocmd +noques +nostat @ns6.sci.fi 25.217.142.62.in-addr.arpa ptr ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35109 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600 IN SOA ns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 i.e. no CNAME records for the sub-/24. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 11:29, Phil Mayers kirjoitti: On 07/29/2010 08:58 AM, Jukka Pakkanen wrote: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work It doesn't look like the reverse is deleted to you: $ dig +comm +nocmd +noques +nostat @ns6.sci.fi 25.217.142.62.in-addr.arpa ptr ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35109 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600INSOAns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 i.e. no CNAME records for the sub-/24. What kind of output should I see in that query above? The subnet we should have delegated to us is 62.142.217.128/25. Jukka ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 29/07/10 10:00, Jukka Pakkanen wrote: 29.7.2010 11:29, Phil Mayers kirjoitti: On 07/29/2010 08:58 AM, Jukka Pakkanen wrote: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work It doesn't look like the reverse is deleted to you: $ dig +comm +nocmd +noques +nostat @ns6.sci.fi 25.217.142.62.in-addr.arpa ptr ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35109 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600INSOAns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 i.e. no CNAME records for the sub-/24. What kind of output should I see in that query above? The subnet we should have delegated to us is 62.142.217.128/25. Sorry, I'm being slightly dumb and getting confused. The zone is delegated fine. As you've spotted, two of the 5 servers are responding (ns5.sci.fi and ns3.sci.fi) but the three others (ns[1,2,3].qnet.fi) return recursion needed Presumably those servers aren't actually serving the zone correctly. Are you using views? If so, do you have the zone statement in all the applicable views? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 13:45, Phil Mayers kirjoitti:
On 29/07/10 10:00, Jukka Pakkanen wrote:
29.7.2010 11:29, Phil Mayers kirjoitti:
On 07/29/2010 08:58 AM, Jukka Pakkanen wrote:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
Sorry, I'm being slightly dumb and getting confused. The zone is
delegated fine.
As you've spotted, two of the 5 servers are responding (ns5.sci.fi and
ns3.sci.fi) but the three others (ns[1,2,3].qnet.fi) return recursion
needed
Presumably those servers aren't actually serving the zone correctly.
Are you using views? If so, do you have the zone statement in all the
applicable views?
No views on place, here's yet the whole named.conf from ns1.qnet.fi,
only irrelevant zones removed.
acl qnet {62.142.220.0/24; 62.142.221.0/24; 62.142.217.128/25;
217.152.62.176/29; 80.248.251.173/32; };
acl qnetservers {62.142.220.5/32; 62.142.220.6/32; 62.142.217.134/32;
213.192.189.2/32; 195.74.0.10; };
acl admin {62.142.220.0/28; 62.142.217.128/29; };
acl bogusnets {0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24;
224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
options {
directory C:\windows\system32\dns\etc\namedb;
pid-file named.pid;
allow-query { any; };
allow-recursion { qnet; };
allow-transfer { qnetservers; };
blackhole { bogusnets; };
version Enttententten...;
statistics-file named_stats.txt;
max-cache-size 128M;
};
key rndc-key {
algorithm hmac-md5;
secret xxx;
};
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
inet 62.142.220.5 port 953 allow { admin; } keys { rndc-key; };
};
logging {
category lame-servers { null; };
category edns-disabled { null; };
};
zone . { type hint; file root.hint; };
.
zone 64/27.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.27-64;
};
zone 128/25.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.25-128;
};
zone 220.142.62.in-addr.arpa {
type master;
file named.62.142.220;
};
zone 221.142.62.in-addr.arpa {
type master;
file named.62.142.221;
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
In message 4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
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. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 14:23, Mark Andrews kirjoitti: In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. Uuh... NOW I'm confused :) There's definitely something wrong somewhere, because reverse-DNS for 62.142.217.128/25 is not working as it should. ns1.qnet.fi should be the authoritive reverse DNS server for that IP range, but it's not serving. Getting recursion requested but not available. While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. 62.142.220.0/24 has been delegated to out servers (qnet servers) and have been working fine for years. And are working at them moment. Mentioning 62.142.220.5 was just to inform that with similar configuration, this /24 reverse dns works ok. The problem is the 62.142.217.128/25 network, which should be delegated to out servers, but for some reason they respond with recursion needed. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. 62.142.217.5 is NOT supposed to be delegated to our servers. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. I'm not asking that. If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. If it's a slave, how can I administer the zone? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
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..). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 29/07/10 12:34, Jukka Pakkanen wrote:
29.7.2010 14:23, Mark Andrews kirjoitti:
In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
There is NOTHING wrong here. You are not testing the servers properly.
Uuh... NOW I'm confused :)
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.
No - Mark is right (apologies for my confusing posts). Assume an example
IP of 62.142.217.200. Your server is authoritative for:
200.128/25.217.142.62.in-addr.arpa.
...not:
200.217.142.62.in-addr.arpa.
ns{3,5}.sci.fi have CNAMEs linking the two because they own the parent
zone, so can answer a dig -x THEIP directly.
$ dig @ns3.sci.fi 200.217.142.62.in-addr.arpa ptr
;; QUESTION SECTION:
;200.217.142.62.in-addr.arpa. IN PTR
;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 14400 IN CNAME
200.128/25.217.142.62.in-addr.arpa.
200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 14:50, Phil Mayers kirjoitti:
On 29/07/10 12:34, Jukka Pakkanen wrote:
29.7.2010 14:23, Mark Andrews kirjoitti:
In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
There is NOTHING wrong here. You are not testing the servers properly.
Uuh... NOW I'm confused :)
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.
No - Mark is right (apologies for my confusing posts). Assume an
example IP of 62.142.217.200. Your server is authoritative for:
200.128/25.217.142.62.in-addr.arpa.
...not:
200.217.142.62.in-addr.arpa.
ns{3,5}.sci.fi have CNAMEs linking the two because they own the parent
zone, so can answer a dig -x THEIP directly.
$ dig @ns3.sci.fi 200.217.142.62.in-addr.arpa ptr
;; QUESTION SECTION:
;200.217.142.62.in-addr.arpa.INPTR
;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 14400 INCNAME
200.128/25.217.142.62.in-addr.arpa.
200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.
___
Yeah, this makes sense. But my question still is, what is wrong in our
setup, since the goal is we can administer the 62.142.217.128/25 reverse
DNS, without asking our upstream provider sci.fi for changes to the zone?
I also understand the requirement for the recursion, but I don't believe
the cure is to allow recursion to any in the global options. I'm just
browsing the net for zone specific recursion options, but haven't found
anything yet...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
In message 4c516756.5060...@qnet.fi, Jukka Pakkanen writes: 29.7.2010 14:23, Mark Andrews kirjoitti: In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. Uuh... NOW I'm confused :) You were confused before but didn't know it. :-) You were asking the wrong question to the wrong server. When you ask the right questions to the right servers it works. There's definitely something wrong somewhere, because reverse-DNS for 62.142.217.128/25 is not working as it should. The only thing wrong is your understanding of what should be happening. ns1.qnet.fi should be the authoritive reverse DNS server for that IP range, but it's not serving. Getting recursion requested but not available. DNS servers are authoritative for namespaces NOT address spaces. Reverse zone use a specific mapping from address space to namespace (i.e. reverse the decimal values of the octets and append IN-ADDR.ARPA). RFC 2317 the maps from the reverse namespace (x.x.x.x.in-addr.arpa) to a second namespace using CNAME records (in this case x.128/25.x.x.x.in-addr.arpa). While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. 62.142.220.0/24 has been delegated to out servers (qnet servers) and have been working fine for years. And are working at them moment. Mentioning 62.142.220.5 was just to inform that with similar configuration, this /24 reverse dns works ok. The problem is the 62.142.217.128/25 network, which should be delegated to out servers, but for some reason they respond with recursion needed. No. 128/25.217.142.62.IN-ADDR.ARPA has been delegated to your servers. If 62.142.217.128/25 was delegated to you servers you would have 128 zones, 128.217.142.62.IN-ADDR.ARPA ... 255.217.142.62.IN-ADDR.ARPA. The reverses for 62.142.217.128/25 is still served by the servers for 217.142.62.IN-ADDR.ARPA. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARP A then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. 62.142.217.5 is NOT supposed to be delegated to our servers. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. I'm not asking that. But you are. Please read the question section of the answers you get back. ; DiG 9.3.6-P1 @ns1.qnet.fi -x 62.142.220.5 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. If it's a slave, how can I administer the zone? You don't. You just have a copy of the zone locally. The administrator for 217.142.62.IN-ADDR.ARPA changes it. RFC 2317 states that servers for the parent should serve the slave zone. The reverse is also true but is not stated. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 07/29/2010 01:38 PM, bind-users-requ...@lists.isc.org wrote: Date: Thu, 29 Jul 2010 14:38:20 +0300 From: Jukka Pakkanenjukka.pakka...@qnet.fi Subject: Re: Subnet reverse delagation, RFC 2317 To:bind-users@lists.isc.org Message-ID:4c51682c.3080...@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
Re: Subnet reverse delagation, RFC 2317
In message 4c516d09.7080...@qnet.fi, Jukka Pakkanen writes:
29.7.2010 14:50, Phil Mayers kirjoitti:
On 29/07/10 12:34, Jukka Pakkanen wrote:
29.7.2010 14:23, Mark Andrews kirjoitti:
In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
There is NOTHING wrong here. You are not testing the servers properly.
Uuh... NOW I'm confused :)
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.
No - Mark is right (apologies for my confusing posts). Assume an
example IP of 62.142.217.200. Your server is authoritative for:
200.128/25.217.142.62.in-addr.arpa.
...not:
200.217.142.62.in-addr.arpa.
ns{3,5}.sci.fi have CNAMEs linking the two because they own the parent
zone, so can answer a dig -x THEIP directly.
$ dig @ns3.sci.fi 200.217.142.62.in-addr.arpa ptr
;; QUESTION SECTION:
;200.217.142.62.in-addr.arpa.INPTR
;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 14400 INCNAME
200.128/25.217.142.62.in-addr.arpa.
200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.
___
Yeah, this makes sense. But my question still is, what is wrong in our
setup,
!!! NOTHING
since the goal is we can administer the 62.142.217.128/25 reverse
DNS, without asking our upstream provider sci.fi for changes to the zone?
You update 128/25.217.142.62.in-addr.arpa. SCI.FI doesn't need to do
anything more. They have done the one time changes required to make
this work.
I also understand the requirement for the recursion, but I don't believe
the cure is to allow recursion to any in the global options. I'm just
browsing the net for zone specific recursion options, but haven't found
anything yet...
The rest of the world won't ask your servers about 217.142.62.in-addr.arpa
because the zone is NOT delegated to them. They will be asked about
128/25.217.142.62.in-addr.arpa because that zone is delegated to them.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 15:10, Mark Andrews kirjoitti: In message4c516756.5060...@qnet.fi, Jukka Pakkanen writes: 29.7.2010 14:23, Mark Andrews kirjoitti: In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. Uuh... NOW I'm confused :) You were confused before but didn't know it. :-) I knew it, but after your message I was more confused... You were asking the wrong question to the wrong server. When you ask the right questions to the right servers it works. Well, the goal is to be able to administer the reverse DNS of that zone, and at the moment it's not happening. So there is still something wrong. Somewhere. I have to think about this from the endusers point of view as well, and for them the reverse DNS is broken. There's definitely something wrong somewhere, because reverse-DNS for 62.142.217.128/25 is not working as it should. The only thing wrong is your understanding of what should be happening. I can't agree with that. Reverse DNS for IP address range 62.142.217.128-254 is not working as we wish. So something is wrong somewhere. Maybe my terminology about address spaces name spaces is off, but I suppose everybody at the list understands what I'm after. ns1.qnet.fi should be the authoritive reverse DNS server for that IP range, but it's not serving. Getting recursion requested but not available. While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. 62.142.220.0/24 has been delegated to out servers (qnet servers) and have been working fine for years. And are working at them moment. Mentioning 62.142.220.5 was just to inform that with similar configuration, this /24 reverse dns works ok. The problem is the 62.142.217.128/25 network, which should be delegated to out servers, but for some reason they respond with recursion needed. No. 128/25.217.142.62.IN-ADDR.ARPA has been delegated to your servers. If 62.142.217.128/25 was delegated to you servers you would have 128 zones, 128.217.142.62.IN-ADDR.ARPA ... 255.217.142.62.IN-ADDR.ARPA. The reverses for 62.142.217.128/25 is still served by the servers for 217.142.62.IN-ADDR.ARPA. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA I think you have missed the difference between the two cases/networks, one network of IP address is 62.142.217.128/25, the other one on 62.142.220.0/24, otherwise I don't understand where you get the number 5 in the messages refering to this problem? then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. 62.142.217.5 is NOT supposed to be delegated to our servers. Like said, this IP has nothing to do with us. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. I'm not asking that. But you are. No I'm not :) Please read the question section of the answers you get back. ; DiG 9.3.6-P1 @ns1.qnet.fi -x 62.142.220.5 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR This is not the 62.142.217.128/25 network, where I have this problem. This is 62.142.220.0/24 network. Which works fine, regarding the reverse DNS. If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. If it's a slave, how can I administer the zone? You don't. You just have a copy of the zone locally. The administrator for 217.142.62.IN-ADDR.ARPA changes it. So we gat back to my original problem again, how can I administer the zone on our server? What needs to be done, in addition or differently of what's been done now. Of course I could have asked how can I have reverse DNS delegated and working for IP addresses 62.142.217.128-254 to our Bind servers so that we can administer the reverse DNS of these IP addresses, but instead I tried to be more specific, tell what's been done, and what happens. And asked we I'm doing wrong when
Re: Subnet reverse delagation, RFC 2317
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-requ...@lists.isc.org wrote: Date: Thu, 29 Jul 2010 14:38:20 +0300 From: Jukka Pakkanenjukka.pakka...@qnet.fi Subject: Re: Subnet reverse delagation, RFC 2317 To:bind-users@lists.isc.org Message-ID:4c51682c.3080...@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
Re: Subnet reverse delagation, RFC 2317
29.7.2010 15:21, Mark Andrews kirjoitti: Yeah, this makes sense. But my question still is, what is wrong in our setup, !!! NOTHING Well, then everything is good and I can go to my vacation... hopefully the clients whose IP addresses are NOT server correctly in the reverse DNS agree with this :o ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 15:43, Jukka Pakkanen kirjoitti: 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. An update, now it seems to be working. dig -x 62.142.217.200 from non-local network returns correct answer. Don't know if the upstream provider did something, ttl expired or something. Anyway we also have 62.142.217.64/27 IP network (you know what I mean) which should be delegated to our servers, but that still doesn't work. But it's probably a delegation problem. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
Sorry about using 5 instead of something from 128 to 255 in the examples. That said there is nothing wrong here. The rest of the world will get the correct answers without recursion being enabled on that server and it will NEVER be asked the question you were testing with in normal operation. ; DiG 9.3.6-P1 -x 62.142.217.128 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 29681 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;128.217.142.62.in-addr.arpa. IN PTR ;; ANSWER SECTION: 128.217.142.62.in-addr.arpa. 13978 IN CNAME 128.128/25.217.142.62.in-addr.arpa. ;; AUTHORITY SECTION: 128/25.217.142.62.in-addr.arpa. 10378 IN SOAns1.qnet.fi. helpdesk.qnet.fi. 201007292 28800 7200 604800 86400 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 22:56:55 2010 ;; MSG SIZE rcvd: 126 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 16:00, Mark Andrews kirjoitti: Sorry about using 5 instead of something from 128 to 255 in the examples. That said there is nothing wrong here. Now I can agree :) However earlier our servers only answered to the local queries about those IP addresses, started working during this afternoon from non-local networks as well. My wild guess is there's a ttl in the original reverse DNS server for that (or parent) zone, which messed things?? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 2010-07-29 15:00, Jukka Pakkanen wrote: Anyway we also have 62.142.217.64/27 IP network (you know what I mean) which should be delegated to our servers, but that still doesn't work. But it's probably a delegation problem. From my point of view, 62.142.217.64 is served by ns3.sci.fi (and its slaves) and is not delegated to you (ns1.qnet.fi). ; DiG 9.7.0-P1 64.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 5200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;64.217.142.62.in-addr.arpa.IN A ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600 IN SOA ns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 ;; Query time: 64 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 16:04:12 2010 ;; MSG SIZE rcvd: 101 ; DiG 9.7.0-P1 128.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 20252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;128.217.142.62.in-addr.arpa. IN A ;; ANSWER SECTION: 128.217.142.62.in-addr.arpa. 14400 IN CNAME 128.128/25.217.142.62.in-addr.arpa. ;; AUTHORITY SECTION: 128/25.217.142.62.in-addr.arpa. 10800 IN SOAns1.qnet.fi. helpdesk.qnet.fi. 201007292 28800 7200 604800 86400 ;; Query time: 1172 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 16:05:36 2010 ;; MSG SIZE rcvd: 126 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 17:06, Niobos kirjoitti: On 2010-07-29 15:00, Jukka Pakkanen wrote: Anyway we also have 62.142.217.64/27 IP network (you know what I mean) which should be delegated to our servers, but that still doesn't work. But it's probably a delegation problem. From my point of view, 62.142.217.64 is served by ns3.sci.fi (and its slaves) and is not delegated to you (ns1.qnet.fi). ; DiG 9.7.0-P1 64.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 5200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;64.217.142.62.in-addr.arpa.IN A ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600 IN SOA ns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 Thanks, looks the same here. Already contacted sci.fi hostmaster about this. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
