Re: Classless PTR query issue
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 ___ 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 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. -- 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) ___ 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
In article , Justin T Pryzby wrote: > It appears they may have manually added NS records for each of 64 IPs. > That's messy and inelegant for them, and doesn't work right either. > The ISP is responding with NS for 90.1.1.1, which means that the next > query must ask a quesion *below* that: something.90.1.1.1. That's why > a CNAME is needed, with an additional, "artificial" subzone, allowing > proper delegation. Otherwise, it's a so-called "horizontal" referal. Actually, this kind of referral works OK -- it's how you find the SOA of a subdomain, for instance. The strictly legal way to implement this in the subdomain's server is to have separate zones for each IP: zone "65.1.1.1.in-addr.arpa" { type master; filename "1.1.1.65.rev"; }; zone "66.1.1.1.in-addr.arpa" { type master; filename "1.1.1.66.rev"; }; ... Each of these reverse zone files should then contain a PTR record at the apex: @ IN SOA ... IN NS dns1.yourdomain.com. IN PTR hostname.yourdomain.com. In practice, though, what people often do in this case is create a 1.1.1.in-addr.arpa zone. The problem with this is that the responses will claim authority for the /24, even though the ISP is supposed to be authoritative. This may cause some servers to reject the responses (or worse, cache these authority records and lose the ability to do reverse lookups in the rest of the /24). But you really should point them to RFC2317, and get them to do it right. -- Barry Margolin Arlington, MA ___ 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
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: Classless PTR query issue
On Tue, May 07, 2013 at 09:52:16AM -0700, Michael Varre wrote: > 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 > > > I've requested they confirm their setup, but I don't know how forthcoming > they'll be. I don't see any "-" (or "/") in your dig output, which indicates that the ISP delegation isn't using RFC2317-style delegation with CNAMES. It appears they may have manually added NS records for each of 64 IPs. That's messy and inelegant for them, and doesn't work right either. The ISP is responding with NS for 90.1.1.1, which means that the next query must ask a quesion *below* that: something.90.1.1.1. That's why a CNAME is needed, with an additional, "artificial" subzone, allowing proper delegation. Otherwise, it's a so-called "horizontal" referal. In the past, when I've requested RFC2317/sub-24 delegation of rev dns, I've included/suggested BIND syntax (but it's still sometimes taken multiple attempts to be correctly implemented). $ORIGIN 196.185.205.in-addr.arpa. 32-47 NS ns.norchemlab.com. 32-47 NS ns1.norchemlab.com. $GENERATE 32-47 $ CNAME $.32-47 Justin ___ 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 , > > > > > > > > Michael Varre 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 j
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 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
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 , > > > > Michael Varre 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 > ___ 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 , > > Michael Varre 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
In article , Michael Varre 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 ___ 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