Query denied errors on PTR records for delegated zone
Geoff Sweet
I have an on-going problem that has totally stumped me. I have a CentOS 5.3 server that I am using the builtin Bind (9.3) to serve our zones. Our ISP has provisioned us a block of IP's and has delegated our name servers as authoritative for the reverse zone info for that block. Name resolution for A records works perfect. What has me totally baffled at this point is that I can not get PTR records to work. All queries to my reverse zone are answered with denied errors:
Feb 22 04:10:14 ns1 named[19789]: client 72.247.123.69#52683: query (cache) '14.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 05:15:26 ns1 named[19789]: client 72.247.123.69#61264: query (cache) '50.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 10:12:03 ns1 named[19789]: client 72.246.192.167#52219: query (cache) '39.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 11:05:11 ns1 named[19789]: client 96.17.73.207#61038: query (cache) '24.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 11:33:23 ns1 named[19789]: client 72.247.123.69#61049: query (cache) '55.173.150.66.in-addr.arpa/PTR/IN' denied
Feb 22 13:41:45 ns1 named[19789]: client 96.17.166.181#60054: query (cache) '31.173.150.66.in-addr.arpa/PTR/IN' denied
Ect...
I have tried several different attempts to make this work, and the only change that works is to set in the options allow-query{any;};. However the problem with that is that it then permits anyone to make any query against my nameservers and I don't want that. Can anyone here offer me some advice as to what I am doing wrong? For reference here is my config file:
acl wemadenets { 66.150.173.0/26; };
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; localnets; wemadenets; };
allow-recursion { wemadenets; };
};
include "/etc/rndc.key";
include "/etc/named.rfc1912.zones";
zone "chaps.co.kr" {
type master;
file "masters/chaps.co.kr.zone";
allow-transfer { 66.150.173.2; };
allow-query { any; };
allow-update { none; };
};
zone "digimonbattle.com" {
type master;
file "masters/digimonbattle.com.zone";
allow-transfer { 66.150.173.2; };
allow-query { any; };
allow-update { none; };
};
zone "wemade.net" {
type master;
file "masters/wemade.net.zone";
allow-transfer { 66.150.173.2; };
allow-query { any; };
allow-update { none; };
};
zone "wemadeusa.com" {
type master;
file "masters/wemadeusa.com.zone";
allow-transfer { 66.150.173.2; };
allow-query { any; };
allow-update { none; };
};
zone "0-59.173.150.66.in-addr.arpa" {
type master;
file "masters/0-59.173.150.66.in-addr.arpa.zone";
allow-transfer { 66.150.173.2; };
allow-query { any; };
allow-update { none; };
};
And here is the 0-59.173.150.66.in-addr.arpa.zone file (I have deleted some of the name information for security):
$TTL 3600
@ IN SOA ns1.wemadeusa.com. hostmaster.wemadeusa.com. (
2010021501 ; serial
600 ; refresh after 10 minutes
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
IN NS ns1.wemadeusa.com
IN NS ns2.wemadeusa.com
1 IN PTR mail1.wemadeusa.com.
2 IN PTR mail2.wemadeusa.com.
3 IN PTR www.wemadeusa.com.
4 IN PTR download.wemadeusa.com.
5 IN PTR lostparadise.wemadeusa.com.
{snip}
59 IN PTR 66.150.173.59.wemadeusa.com.
Thank you!
Geoff Sweet
Robert Spangler
> I have tried several different attempts to make this work, and the only
> change that works is to set in the options allow-query{any;};. However the
> problem with that is that it then permits anyone to make any query against
> my nameservers and I don't want that.
That the purpose of having a public DNS server? So others can get your public
DNS information? You want them to be able to query your server for your
information but not allow recursion. By only allowing localhost, localnets
and wemadenets, everyone else is blocked thus they cannot get your
information.
> Can anyone here offer me some advice as to what I am doing wrong? For
reference here is my config file:
>
> acl wemadenets { 66.150.173.0/26; };
>
> options {
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { localhost; localnets; wemadenets; };
> allow-recursion { wemadenets; };
> };
Edit allow-query and allow any. Then everyone can get your information and
still not use your server for recursion
I take it you are working off some sort of how-to for this.
--
Regards
Robert
Linux User #296285
http://counter.li.org
Geoff Sweet
options {
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
allow-recursion { wemadenets; };
};
Allows anyone to make recursive requests for any name against my server. I don't want that. By leaving the options list to " allow-query { localhost; localnets; wemadenets; };" I prevent any ole recursive query (www.google.com for instance) except from my network while still allowing queries to the zones that I host. However that brings me back to my original problem... it refuses queries for the reverse zone for my IP block.
-Geoff
--
Regards
Robert
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Barry Margolin
Geoff Sweet <geoff...@wemadeusa.com> wrote:
> The problem is that editing the options list to:
>
> options {
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { any; };
> allow-recursion { wemadenets; };
> };
>
> Allows anyone to make recursive requests for any name against my server. I
> don't want that. By leaving the options list to " allow-query {
> localhost; localnets; wemadenets; };" I prevent any ole recursive query
> (www.google.com for instance) except from my network while still allowing
> queries to the zones that I host. However that brings me back to my original
> problem... it refuses queries for the reverse zone for my IP block.
Since you have "allow-query {wemadenets;};", clients outside that
network will NOT be allowed to make recursive requests against your
server.
But if you really don't want to change the allow-query option, you can
put "allow-query {any;};" within all the zone stanzas. That will just
allow public queries for those zones, not for recursive or cached data.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Geoff Sweet
Thank-you for the suggestion, however if you look at the zone config that I included in my original email you will see that what you have suggested is exactly what I have done originally. Each zone has an "allow-query { any; };" setting including the reverse zone that currently doesn't work for some strange reason.
-Geoff
-----Original Message-----
From: bind-users-bounces+geoff.sweet=wemade...@lists.isc.org [mailto:bind-users-bounces+geoff.sweet=wemade...@lists.isc.org] On Behalf Of Barry Margolin
Sent: Monday, February 22, 2010 17:41
To: comp-protoc...@isc.org
Subject: Re: Query denied errors on PTR records for delegated zone
In article <mailman.523.1266888...@lists.isc.org>,
Geoff Sweet <geoff...@wemadeusa.com> wrote:
> The problem is that editing the options list to:
>
> options {
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { any; };
> allow-recursion { wemadenets; };
> };
>
> Allows anyone to make recursive requests for any name against my server. I
> don't want that. By leaving the options list to " allow-query {
> localhost; localnets; wemadenets; };" I prevent any ole recursive query
> (www.google.com for instance) except from my network while still allowing
> queries to the zones that I host. However that brings me back to my original
> problem... it refuses queries for the reverse zone for my IP block.
Since you have "allow-query {wemadenets;};", clients outside that
network will NOT be allowed to make recursive requests against your
server.
But if you really don't want to change the allow-query option, you can
put "allow-query {any;};" within all the zone stanzas. That will just
allow public queries for those zones, not for recursive or cached data.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Geoff Sweet
Thank-you for the suggestion, however if you look at the zone config that I included in my original email you will see that what you have suggested is exactly what I have done originally. Each zone has an "allow-query { any; };" setting including the reverse zone that currently doesn't work for some strange reason.
-Geoff
-----Original Message-----
From: bind-users-bounces+geoff.sweet=wemade...@lists.isc.org [mailto:bind-users-bounces+geoff.sweet=wemade...@lists.isc.org] On Behalf Of Barry Margolin
Sent: Monday, February 22, 2010 17:41
To: comp-protoc...@isc.org
Subject: Re: Query denied errors on PTR records for delegated zone
In article <mailman.523.1266888...@lists.isc.org>,
Geoff Sweet <geoff...@wemadeusa.com> wrote:
> The problem is that editing the options list to:
>
> options {
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { any; };
> allow-recursion { wemadenets; };
> };
>
> Allows anyone to make recursive requests for any name against my server. I
> don't want that. By leaving the options list to " allow-query {
> localhost; localnets; wemadenets; };" I prevent any ole recursive query
> (www.google.com for instance) except from my network while still allowing
> queries to the zones that I host. However that brings me back to my original
> problem... it refuses queries for the reverse zone for my IP block.
Since you have "allow-query {wemadenets;};", clients outside that
network will NOT be allowed to make recursive requests against your
server.
But if you really don't want to change the allow-query option, you can
put "allow-query {any;};" within all the zone stanzas. That will just
allow public queries for those zones, not for recursive or cached data.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
Matus UHLAR - fantomas
> The problem is that editing the options list to:
>
> options {
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { any; };
> allow-recursion { wemadenets; };
> };
>
> Allows anyone to make recursive requests for any name against my server.
> I don't want that.
You want anyone not to send you recursive? Well, call them by phone and ask
them not to do so.
You want the recursive requests not to reach your server? Put a DNS
inspecting firewall in front of your server...
You want the recursive requests not to be resolved? That is exactly the
options above say. Anyone can query, but recursive requests will be answered
only if they come from wemadenets.
> By leaving the options list to " allow-query {
> localhost; localnets; wemadenets; };" I prevent any ole recursive query
> (www.google.com for instance) except from my network while still allowing
> queries to the zones that I host.
No, you prevent ALL queries to be responded this way.
Read the docs, you apparently do not understand the difference between
allow-query and allow-recursion.
And, btw. bind 9.3 will send answers from cache to anyone who has
allow-query enabled. It won't do the recursion, but will answer if it's
cached. Maybe this is what made you think the above.
bind 9.4 and later has new option allow-query-cache that allows tune this
behaviour too and the default is same as allow-recursion.
(actually they cross-inherit each other, if either is not set)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
Matus UHLAR - fantomas
> I have an on-going problem that has totally stumped me. I have a CentOS
> 5.3 server that I am using the builtin Bind (9.3) to serve our zones. Our
> ISP has provisioned us a block of IP's and has delegated our name servers
> as authoritative for the reverse zone info for that block. Name
> resolution for A records works perfect. What has me totally baffled at
> this point is that I can not get PTR records to work. All queries to my
> reverse zone are answered with denied errors:
>
> Feb 22 04:10:14 ns1 named[19789]: client 72.247.123.69#52683: query (cache) '14.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 05:15:26 ns1 named[19789]: client 72.247.123.69#61264: query (cache) '50.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 10:12:03 ns1 named[19789]: client 72.246.192.167#52219: query (cache) '39.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 11:05:11 ns1 named[19789]: client 96.17.73.207#61038: query (cache) '24.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 11:33:23 ns1 named[19789]: client 72.247.123.69#61049: query (cache) '55.173.150.66.in-addr.arpa/PTR/IN' denied
> Feb 22 13:41:45 ns1 named[19789]: client 96.17.166.181#60054: query (cache) '31.173.150.66.in-addr.arpa/PTR/IN' denied
> zone "0-59.173.150.66.in-addr.arpa" {
they are not asking for your zone. They are asking for zone
"173.150.66.in-addr.arpa" which I don't see on your nameserver.
All those IPs are from akamai and they should not even go to your server, if
you are watching at ns1.wemadeusa.com. or ns2.wemadeusa.com.
either akamai has broken dns clients, or someone (you?) has been asking them
to query your servers directly for reverse zone you don't provide.
> And here is the 0-59.173.150.66.in-addr.arpa.zone file (I have deleted some of the name information for security):
>
>
> $TTL 3600
> @ IN SOA ns1.wemadeusa.com. hostmaster.wemadeusa.com. (
> 2010021501 ; serial
> 600 ; refresh after 10 minutes
> 3600 ; retry after 1 hour
> 604800 ; expire after 1 week
> 86400 ) ; minimum TTL of 1 day
>
> IN NS ns1.wemadeusa.com
> IN NS ns2.wemadeusa.com
You are missing trailing dots here. Note that without them the current
$ORIGIN is appended, which results in:
0-59.173.150.66.in-addr.arpa. 3600 IN NS ns2.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
0-59.173.150.66.in-addr.arpa. 3600 IN NS ns1.wemadeusa.com.0-59.173.150.66.in-addr.arpa.
Try fixing this first, maybe this is your real problem.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...
Lightner, Jeff
My options are:
options {
directory "/var/named";
query-source address 10.0.0.3;
allow-query { internaldns; externaldns; dswadnsalias; };
allow-recursion { internaldns; externaldns; };
blackhole { blackhats; };
version none;
};
In each of my zones including arpa zones I have
allow-query { any; };
This works fine for blocking recursion for sites such as google from
outside my network yet still allowing lookups of my zones from outside
and sounds like what the OP says he is intending to do.
The above worked before I upgraded from 5.3 to 5.4 so should work on
CentOS as well since it is a binary compile of RHEL source.
I did run into some oddities in setting up arpa zones to be able to
query them inside my network and outside my network so I have things
like:
# Special notation required for internet delegation (e.g. dig -x ...)
#
zone "192/27.84.44.12.IN-ADDR.ARPA" {
type master;
file "arpa.12.44.84";
allow-query { any; };
};
# Standard notation required for direct lookups (e.g. dig @dswands1 -x
...)
#
zone "84.44.12.IN-ADDR.ARPA" {
type master;
file "arpa.12.44.84";
allow-query { any; };
};
Note this is not the difference in views but difference in how I get to
the server. I later implemented views which probably obviated the
above since I'd only see one or the other depending on where I came
from. However, I note it as originally I was pulling my hair out trying
to figure out why digs directly to my DNS server via the internal facing
interface wouldn't resolve like the ones on the external facing
interface.
-----Original Message-----
From: bind-users-bounces+jlightner=wate...@lists.isc.org
[mailto:bind-users-bounces+jlightner=wate...@lists.isc.org] On Behalf
Of Matus UHLAR - fantomas
Sent: Tuesday, February 23, 2010 4:19 AM
To: bind-...@lists.isc.org
Subject: Re: Query denied errors on PTR records for delegated zone
> zone "0-59.173.150.66.in-addr.arpa" {
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------
Matus UHLAR - fantomas
> I'm running 9.3 on RHEL 5.4.
>
> My options are:
>
> options {
> directory "/var/named";
> query-source address 10.0.0.3;
> allow-query { internaldns; externaldns; dswadnsalias; };
> allow-recursion { internaldns; externaldns; };
> blackhole { blackhats; };
> version none;
> };
>
> In each of my zones including arpa zones I have
>
> allow-query { any; };
>
> This works fine for blocking recursion for sites such as google from
> outside my network yet still allowing lookups of my zones from outside
> and sounds like what the OP says he is intending to do.
bind 9.4 and later can do that all by simply allowing recursion for your
ranges. Yes, for 9.3 you may need to do this stuff for preventing others to
access your cache (it still blocked recursion!)
> I did run into some oddities in setting up arpa zones to be able to
> query them inside my network and outside my network so I have things
> like:
>
> # Special notation required for internet delegation (e.g. dig -x ...)
> #
> zone "192/27.84.44.12.IN-ADDR.ARPA" {
> type master;
> file "arpa.12.44.84";
> allow-query { any; };
> };
>
> # Standard notation required for direct lookups (e.g. dig @dswands1 -x
> ...)
> #
> zone "84.44.12.IN-ADDR.ARPA" {
> type master;
> file "arpa.12.44.84";
> allow-query { any; };
> };
you should better ask your ISP for allowing transfering of the real, public
84.44.12.IN-ADDR.ARPA. Using the above, you can't access reverse names for
IPs witnin your /24, outside your /27.
> Note this is not the difference in views but difference in how I get to
> the server. I later implemented views which probably obviated the
> above since I'd only see one or the other depending on where I came
> from. However, I note it as originally I was pulling my hair out trying
> to figure out why digs directly to my DNS server via the internal facing
> interface wouldn't resolve like the ones on the external facing
> interface.
mostly because you provide fake version of 84.44.12.IN-ADDR.ARPA.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Lightner, Jeff
carriers a few years back and also explains why I had to put my kluge
in.
However, I wonder how easy it is in practice to get a company the size
of AT&T to do individual delegations for dozens or hundreds of IPs?
You mention it as if it is a non-issue but I suspect they'd balk at such
a request.
-----Original Message-----
From: Jonathan de Boyne Pollard
[mailto:J.deBoynePoll...@NTLWorld.COM]
Sent: Wednesday, February 24, 2010 4:36 AM
To: Lightner, Jeff; BIND users mailing list
Subject: Re: Query denied errors on PTR records for delegated zone
I did run into some oddities in setting up arpa zones to be able
to query them inside my network and outside my network [...]
You've hit one of the several reasons that RFC 2317 style delegation
should be avoided
<http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/avoid-rfc-231
7-delegation.html> : Your lookup tools require a specific structure for
reverse-lookup domain names, but your delegation scheme imposes a
different structure. RFC 2317 style delegation broke the convenience
features of your lookup tools.
I note it as originally I was pulling my hair out trying to
figure out why digs directly to my DNS server via the internal facing
interface wouldn't resolve like the ones on the external facing
interface.
You're wishing that you'd read the aforelinked Frequently Given Answer
ages ago, now, aren't you? (-:
Matus UHLAR - fantomas
> From: "Lightner, Jeff" <jlig...@water.com>
> Date: Wed, 24 Feb 2010 08:31:44 -0500
> Subject: RE: Query denied errors on PTR records for delegated zone
> To: Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM>,
> BIND users mailing list <bind-...@lists.isc.org>
>
> Nice write up. It explains WHY we had the weird delegation on switching
> carriers a few years back and also explains why I had to put my kluge
> in.
>
> However, I wonder how easy it is in practice to get a company the size
> of AT&T to do individual delegations for dozens or hundreds of IPs?
> You mention it as if it is a non-issue but I suspect they'd balk at such
> a request.
>
> -----Original Message-----
> From: Jonathan de Boyne Pollard
> [mailto:J.deBoynePoll...@NTLWorld.COM]
> Sent: Wednesday, February 24, 2010 4:36 AM
> To: Lightner, Jeff; BIND users mailing list
>
>
> You've hit one of the several reasons that RFC 2317 style delegation
> should be avoided
> <http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/avoid-rfc-231
> 7-delegation.html> : Your lookup tools require a specific structure for
> reverse-lookup domain names, but your delegation scheme imposes a
> different structure. RFC 2317 style delegation broke the convenience
> features of your lookup tools.
>
>
> figure out why digs directly to my DNS server via the internal facing
> interface wouldn't resolve like the ones on the external facing
> interface.
>
> ages ago, now, aren't you? (-:
>
>
> Please consider our environment before printing this e-mail or attachments.
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
> ----------------------------------
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.
Matus UHLAR - fantomas
On 24.02.10 08:31, Lightner, Jeff wrote:
> Nice write up. It explains WHY we had the weird delegation on switching
> carriers a few years back and also explains why I had to put my kluge
> in.
>
> However, I wonder how easy it is in practice to get a company the size
> of AT&T to do individual delegations for dozens or hundreds of IPs?
> You mention it as if it is a non-issue but I suspect they'd balk at such
> a request.
>
> -----Original Message-----
> From: Jonathan de Boyne Pollard
> [mailto:J.deBoynePoll...@NTLWorld.COM]
> Sent: Wednesday, February 24, 2010 4:36 AM
> To: Lightner, Jeff; BIND users mailing list
> Subject: Re: Query denied errors on PTR records for delegated zone
>
> I did run into some oddities in setting up arpa zones to be able
> to query them inside my network and outside my network [...]
>
> You've hit one of the several reasons that RFC 2317 style delegation
> should be avoided
> <http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/avoid-rfc-231
> 7-delegation.html> : Your lookup tools require a specific structure for
> reverse-lookup domain names, but your delegation scheme imposes a
> different structure. RFC 2317 style delegation broke the convenience
> features of your lookup tools.
This is imho bad:
By delegating the djbdns' way, you are creating bunch of NS records for each
one PTR, instead of bunch NS records for a zone and one CNAME for each PTR.
I've been solving problems where a record was delegated to other
servers (load balancers) via NS records, when those didn't reply by anything
but A (in this case it would be PTR). That caused troubles and my
recommentation was to create full zone for the delegation.
Creating full zones for 128 IPs in /25 delegation would be, ehm, bloated.
Those tools and nameservers should be fixed imho.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)