Re: Classless PTR query issue
On Tuesday, May 7, 2013 9:06:53 PM UTC-4, Doug Barton wrote: On 05/07/2013 01:50 PM, Matus UHLAR - fantomas wrote: On 07.05.13 11:06, Michael Varre wrote: So interestingly they did give me their setup and this is their response, and my warm and fuzzy feeling continues to go out the window: They use SimpleDNS Record Name: 65.246.59.108.in-addr.arpa DNS Server (FQDN): dns1.kishmish.com. TTL: 1 Hour I'd imagine this is wrong since 65 is my starting IP rather than my network IP, which is 64. they use that sucking djbdns-like way of delegating zones. Instead of creating one zone and pointing 16 CNAMEs into it, they want you to create 16 zones. Advise them to read RFC 2317 and do things right way. https://dougbarton.us/DNS/2317.html I sent them the RFC yesterday and even sent them the KB article from SimpleDNS.com but I think they still have something done incorrectly. It's amazing how large hosts take proper DNS administration for granted these days. I don't have time to teach them how to do this anymore, so unfortunately I think I'm going to throw in the towel and just have them create the PTR records for me...right now I just need them to resolve! Thanks everyone for your input. I will reference this thread for them in the next few weeks if I'm able to fine someone able to make the proper changes. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Classless PTR query issue
I'm setting up a new zone, similar to the many I've created successfully on
other ISPs to answer with PTR records for a /26 the ISP has sub-delegated to my
dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external: query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried setting
up reverse dns to be setup by a cpanel server, but I'm not sure this is
relevant. It creates two views, internal and external. This is getting
serviced out of the external view, which really is just setup to answer any
question for which it has an answer. So i _really_ don't think it's relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Classless PTR query issue
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
In article mailman.240.1367938655.20661.bind-us...@lists.isc.org,
Michael Varre mva...@gmail.com wrote:
I'm setting up a new zone, similar to the many I've created successfully on
other ISPs to answer with PTR records for a /26 the ISP has sub-delegated
to
my dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external:
query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried
setting up reverse dns to be setup by a cpanel server, but I'm not sure
this
is relevant. It creates two views, internal and external. This is getting
serviced out of the external view, which really is just setup to answer any
question for which it has an answer. So i _really_ don't think it's
relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
If you're getting queries for 90.1.1.1.in-addr.arpa from outside
clients, it means that the ISP has not set up the proper classless
reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
of 64-26.1.1.1.in-addr.arpa.
But the client IP appears to be one of your own addresses. They should
be pointing to your caching server, not the authoritative server. It
should then follow the ISP's delegation. If you're using the same
server for auth and caching, you need to put the local IPs in the
allow-query ACL.
--
Barry Margolin
Arlington, MA
Thanks for the response Barry. First, I have a hunch they don't know how to
delegate classlessly. They seemed very confused at first.
Why would you think that queries for 90.1.1.1.in-addr.arpa from outside would
point to it being setup wrong by the ISP? .90 is one of my assigned IP's
withing my /26. My GW IP address is .65. Maybe that is where I've gone wrong?
I think my example may have confused things a bit. The 1.1.1.1 was just a
random number (one of the downfalls of obfuscating IP's on a mailing list).
consider that really 9.9.9.9, and that it is NOT one of my IP's - just a client
on the internet.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Classless PTR query issue
On Tuesday, May 7, 2013 12:04:10 PM UTC-4, Justin T Pryzby wrote: I recommend dig +trace -x on one of your assigned IPs. Compare with the result from a known-good sub-24 rev dns delegation. The ISP should be returning something like: 162.48.168.205.in-addr.arpa. 43200 IN CNAME 162.160-175.48.168.205.in-addr.arpa. 160-175.48.168.205.in-addr.arpa. 43200 IN NSns.norchemlab.com. 160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.norchemlab.com. and your NS should respond for the 160-175 zone. The particular naming convention doesn't matter, but has to be consistent between you and your ISP. The filename of the zone doesn't need to match the zone name, although that seems to be a popular misconception.. Slashes (as in 160/28.48.168.205.in-addr.arpa) are mildly inconvenient convention since, if the filename and zone DO match, they imply use of a subdirectory. Good luck, Justin Thanks Justin, I've been testing with dig and that's how I got the failed results posted previously. My digs lead me to believe their zones are named the same as mine, with -'s instead of /'s. dig -x 1.1.1.90 +trace snipped ;; Received 180 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 89 ms 1.1.1.in-addr.arpa. 86400 IN NS NS1.myisp.COM. 1.1.1.in-addr.arpa. 86400 IN NS NS2.myisp.COM. ;; Received 89 bytes from 199.180.180.63#53(r.arin.net) in 55 ms 90.1.1.1.in-addr.arpa. 3600 IN NS dns1.myns.com. ;; Received 75 bytes from 13.13.13.13#53(NS1.myisp.COM) in 84 ms ;; Received 44 bytes from 1.1.1.90#53(dns1.myns.com) in 80 ms end I've requested they confirm their setup, but I don't know how forthcoming they'll be. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Classless PTR query issue
On Tuesday, May 7, 2013 12:04:10 PM UTC-4, Justin T Pryzby wrote:
I recommend dig +trace -x on one of your assigned IPs. Compare with
the result from a known-good sub-24 rev dns delegation. The ISP
should be returning something like:
162.48.168.205.in-addr.arpa. 43200 IN CNAME
162.160-175.48.168.205.in-addr.arpa.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns.norchemlab.com.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.norchemlab.com.
and your NS should respond for the 160-175 zone. The particular
naming convention doesn't matter, but has to be consistent between you
and your ISP. The filename of the zone doesn't need to match the zone
name, although that seems to be a popular misconception.. Slashes (as
in 160/28.48.168.205.in-addr.arpa) are mildly inconvenient convention
since, if the filename and zone DO match, they imply use of a
subdirectory.
Good luck,
Justin
On Tue, May 07, 2013 at 08:45:49AM -0700, Michael Varre wrote:
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
In article mailman.240.1367938655.20661.bind-us...@lists.isc.org,
Michael Varre mva...@gmail.com wrote:
I'm setting up a new zone, similar to the many I've created
successfully on
other ISPs to answer with PTR records for a /26 the ISP has
sub-delegated to
my dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external:
query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial
Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried
setting up reverse dns to be setup by a cpanel server, but I'm not sure
this
is relevant. It creates two views, internal and external. This is
getting
serviced out of the external view, which really is just setup to answer
any
question for which it has an answer. So i _really_ don't think it's
relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
If you're getting queries for 90.1.1.1.in-addr.arpa from outside
clients, it means that the ISP has not set up the proper classless
reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
of 64-26.1.1.1.in-addr.arpa.
But the client IP appears to be one of your own addresses. They should
be pointing to your caching server, not the authoritative server. It
should then follow the ISP's delegation. If you're using the same
server for auth and caching, you need to put the local IPs in the
allow-query ACL.
--
Barry Margolin
Arlington, MA
Thanks for the response Barry. First, I have a hunch they don't know how
to delegate classlessly. They seemed very confused at first.
Why would you think that queries for 90.1.1.1.in-addr.arpa from outside
would point to it being setup wrong by the ISP? .90 is one of my assigned
IP's withing my /26. My GW IP address is .65. Maybe that is where I've gone
wrong?
I think my example may have confused things a bit. The 1.1.1.1 was just a
random number (one of the downfalls of obfuscating IP's on a mailing list).
consider that really 9.9.9.9, and that it is NOT one of my IP's - just a
client on the internet.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
So interestingly they did give me
Re: Classless PTR query issue
and so much for keeping my ip's and hosts private :) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: zone propagation
I'm sure there are other ways but I use webmin to handle all of it for me. I used to do it all manually on the command line, logging into each server and manually adding new zones but webmin has cut the time it takes for me to make dns MACs down to about 10% of what it used to be. On 12/24/08, wes b...@the-wes.com wrote: Can I configure a pair of bind9 servers, one master and one slave, so that when I create a new zone on the master, it is also created on the slave? I already have slaving of existing zones working well. thanks, -wes -- Sent from my mobile device mv 315.952.5753 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
