Re: Secondary DNS question...
No, the box is hanging right off the internet on a static IP. Jeff On Jun 26, 2013, at 12:38 AM, Frank Bulk wrote: > Do you have a box such as a firewall or load-balancer sitting in front of > ns1? > > Frank > > -Original Message- > From: bind-users-bounces+frnkblk=iname@lists.isc.org > [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of SH > Development > Sent: Tuesday, June 25, 2013 8:35 PM > To: bind-users@lists.isc.org > Subject: Re: Secondary DNS question... > > All very interesting, but I'm afraid at my level of expertise on DNS, I'm > not following. If I'm broken, how do I attempt to fix? Someone mentioned > that our ns1.starionhost.net was not authoritative. How does one even > decide that? As far as I know I haven't had any issues until now... > > Jeff > > > On Jun 25, 2013, at 6:26 AM, Matus UHLAR - fantomas > wrote: > >>> On 24.06.13 07:41, Frank Bulk wrote: Interesting to note that querying for ANY does return an SOA. I can't explain that behavior. >> >> On 24.06.13 14:54, Matus UHLAR - fantomas wrote: >>> I can guess a kind of DNS filter/firewall. Some l3 switches or load >>> balancers tend to produce strange results too... >> >> aa! I am getting response packets but they are somehoe not accepted by > dig: >> >> % dig +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net >> >> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec +bufsize=4096 -t soa > starionline.com @ns1.starionhost.net >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached >> >> ... in the meantime: >> >> 13:21:38.837415 IP (tos 0x0, ttl 64, id 9452, offset 0, flags [none], > proto UDP (17), length 72) >> 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? > starionline.com. ar: . OPT UDPsize=4096 (44) >> 13:21:39.009098 IP (tos 0x10, ttl 50, id 15611, offset 0, flags [none], > proto UDP (17), length 196) >> 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] > 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA > ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 > 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. > [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, > ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) >> 13:21:43.837389 IP (tos 0x0, ttl 64, id 9453, offset 0, flags [none], > proto UDP (17), length 72) >> 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? > starionline.com. ar: . OPT UDPsize=4096 (44) >> 13:21:44.009780 IP (tos 0x10, ttl 50, id 4231, offset 0, flags [none], > proto UDP (17), length 196) >> 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] > 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA > ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 > 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. > [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, > ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) >> 13:21:48.837515 IP (tos 0x0, ttl 64, id 9454, offset 0, flags [none], > proto UDP (17), length 72) >> 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? > starionline.com. ar: . OPT UDPsize=4096 (44) >> 13:21:49.011060 IP (tos 0x10, ttl 50, id 38531, offset 0, flags [none], > proto UDP (17), length 196) >> 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xf531!] > 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA > ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 > 3600 ns: starionline.com. [1d] NS ns2.starionhost.net., starionline.com. > [1d] NS ns1.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, > ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) >> >> stariononline.com has two NSes listed, ns1.starionhost.net > [74.87.108.83] and ns2.starionhost.net [64.136.200.138]. But the first one does not > seem to want to respond (http://goo.gl/s41wN and http://dnscheck.iis.se/ and http://www.zonecut.net/dns/index.cgi are just a few examples) to a few > of the online checkers. I checked with some others and it looks like you > have no SOA set for for ns1.starionhost.net: >> >> -- >> 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. >> I don't have lysdexia. The Dog wouldn't allow that. >> ___ >> 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.i
Re: servfail response message question
I took out the ipv6 info in the zone DB file for this to work. I added it back into the file and it worked and then three queries later it gave the servfail response. It doesn't like the record. Thank you, Ryan On Jun 25, 2013, at 8:42 PM, Mark Andrews wrote: > > In message <1372206137.34187.yahoomail...@web161406.mail.bf1.yahoo.com>, RYAN > C > HERVENKA writes: >> >> I currently have a domain example.com authoritative on my Ubuntu server >> and it is delegating gslb.example.com to my load balancer. >> >> www.example.com is a CNAME for www.gslb.example.com >> Gslb.example.com has an NS record pointing to the LB >> >> Client sends query for www.example.com to Ubuntu DNS server. The Ubuntu >> DNS server sends a query to the load balancer for www.gslb.example.com >> and the LB responds to the Ubuntu DNS server with the right A record in >> the answer section. However, the Ubuntu server responds to the client >> with servfail. >> >> When I look at the pcap from the Ubuntu server, the LB is responding to >> it with the correct IP but the dig response from the Ubuntu server to the >> client shows "no servers could be reached" when I dig against the Ubuntu. >> I also see the same message in the dns response in the pcap (obviously). >> >> Ryans-MacBook-Pro:~ ryanc$ dig @10.10.1.50 www.example.com <-me querying >> the Ubuntu for www.example.com >> >> ; <<>> DiG 9.8.3-P1 <<>> @10.10.1.50 www.example.com >> ; (1 server found) >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached >> >> >> Do you have any ideas as to why this is happening? >> >> Ryan Chervenka > > Not without more details. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Secondary DNS question...
Do you have a box such as a firewall or load-balancer sitting in front of ns1? Frank -Original Message- From: bind-users-bounces+frnkblk=iname@lists.isc.org [mailto:bind-users-bounces+frnkblk=iname@lists.isc.org] On Behalf Of SH Development Sent: Tuesday, June 25, 2013 8:35 PM To: bind-users@lists.isc.org Subject: Re: Secondary DNS question... All very interesting, but I'm afraid at my level of expertise on DNS, I'm not following. If I'm broken, how do I attempt to fix? Someone mentioned that our ns1.starionhost.net was not authoritative. How does one even decide that? As far as I know I haven't had any issues until now... Jeff On Jun 25, 2013, at 6:26 AM, Matus UHLAR - fantomas wrote: >> On 24.06.13 07:41, Frank Bulk wrote: >>> Interesting to note that querying for ANY does return an SOA. I can't >>> explain that behavior. > > On 24.06.13 14:54, Matus UHLAR - fantomas wrote: >> I can guess a kind of DNS filter/firewall. Some l3 switches or load >> balancers tend to produce strange results too... > > aa! I am getting response packets but they are somehoe not accepted by dig: > > % dig +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > ... in the meantime: > > 13:21:38.837415 IP (tos 0x0, ttl 64, id 9452, offset 0, flags [none], proto UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:39.009098 IP (tos 0x10, ttl 50, id 15611, offset 0, flags [none], proto UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > 13:21:43.837389 IP (tos 0x0, ttl 64, id 9453, offset 0, flags [none], proto UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:44.009780 IP (tos 0x10, ttl 50, id 4231, offset 0, flags [none], proto UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > 13:21:48.837515 IP (tos 0x0, ttl 64, id 9454, offset 0, flags [none], proto UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:49.011060 IP (tos 0x10, ttl 50, id 38531, offset 0, flags [none], proto UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xf531!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns2.starionhost.net., starionline.com. [1d] NS ns1.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > > >>> stariononline.com has two NSes listed, ns1.starionhost.net [74.87.108.83] >>> and ns2.starionhost.net [64.136.200.138]. But the first one does not seem >>> to want to respond (http://goo.gl/s41wN and http://dnscheck.iis.se/ and >>> http://www.zonecut.net/dns/index.cgi are just a few examples) to a few of >>> the online checkers. I checked with some others and it looks like you have >>> no SOA set for for ns1.starionhost.net: > > -- > 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. > I don't have lysdexia. The Dog wouldn't allow that. > ___ > 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to
Re: Secondary DNS question...
All very interesting, but I'm afraid at my level of expertise on DNS, I'm not following. If I'm broken, how do I attempt to fix? Someone mentioned that our ns1.starionhost.net was not authoritative. How does one even decide that? As far as I know I haven't had any issues until now... Jeff On Jun 25, 2013, at 6:26 AM, Matus UHLAR - fantomas wrote: >> On 24.06.13 07:41, Frank Bulk wrote: >>> Interesting to note that querying for ANY does return an SOA. I can't >>> explain that behavior. > > On 24.06.13 14:54, Matus UHLAR - fantomas wrote: >> I can guess a kind of DNS filter/firewall. Some l3 switches or load >> balancers tend to produce strange results too... > > aa! I am getting response packets but they are somehoe not accepted by dig: > > % dig +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec +bufsize=4096 -t soa > starionline.com @ns1.starionhost.net > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > ... in the meantime: > > 13:21:38.837415 IP (tos 0x0, ttl 64, id 9452, offset 0, flags [none], proto > UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? > starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:39.009098 IP (tos 0x10, ttl 50, id 15611, offset 0, flags [none], proto > UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] > 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA > ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 > ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS > ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, > ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > 13:21:43.837389 IP (tos 0x0, ttl 64, id 9453, offset 0, flags [none], proto > UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? > starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:44.009780 IP (tos 0x10, ttl 50, id 4231, offset 0, flags [none], proto > UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] > 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA > ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 > ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS > ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, > ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > 13:21:48.837515 IP (tos 0x0, ttl 64, id 9454, offset 0, flags [none], proto > UDP (17), length 72) > 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? > starionline.com. ar: . OPT UDPsize=4096 (44) > 13:21:49.011060 IP (tos 0x10, ttl 50, id 38531, offset 0, flags [none], proto > UDP (17), length 196) > 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xf531!] > 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA > ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 > ns: starionline.com. [1d] NS ns2.starionhost.net., starionline.com. [1d] NS > ns1.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, > ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) > > >>> stariononline.com has two NSes listed, ns1.starionhost.net [74.87.108.83] >>> and ns2.starionhost.net [64.136.200.138]. But the first one does not seem >>> to want to respond (http://goo.gl/s41wN and http://dnscheck.iis.se/ and >>> http://www.zonecut.net/dns/index.cgi are just a few examples) to a few of >>> the online checkers. I checked with some others and it looks like you have >>> no SOA set for for ns1.starionhost.net: > > -- > 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. > I don't have lysdexia. The Dog wouldn't allow that. > ___ > 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: servfail response message question
In message <1372206137.34187.yahoomail...@web161406.mail.bf1.yahoo.com>, RYAN C HERVENKA writes: > > I currently have a domain example.com authoritative on my Ubuntu server > and it is delegating gslb.example.com to my load balancer. > > www.example.com is a CNAME for www.gslb.example.com > Gslb.example.com has an NS record pointing to the LB > > Client sends query for www.example.com to Ubuntu DNS server. The Ubuntu > DNS server sends a query to the load balancer for www.gslb.example.com > and the LB responds to the Ubuntu DNS server with the right A record in > the answer section. However, the Ubuntu server responds to the client > with servfail. > > When I look at the pcap from the Ubuntu server, the LB is responding to > it with the correct IP but the dig response from the Ubuntu server to the > client shows "no servers could be reached" when I dig against the Ubuntu. > I also see the same message in the dns response in the pcap (obviously). > > Ryans-MacBook-Pro:~ ryanc$ dig @10.10.1.50 www.example.com <-me querying > the Ubuntu for www.example.com > > ; <<>> DiG 9.8.3-P1 <<>> @10.10.1.50 www.example.com > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > > Do you have any ideas as to why this is happening? > > Ryan Chervenka Not without more details. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
servfail response message question
I currently have a domain example.com authoritative on my Ubuntu server and it is delegating gslb.example.com to my load balancer. www.example.com is a CNAME for www.gslb.example.com Gslb.example.com has an NS record pointing to the LB Client sends query for www.example.com to Ubuntu DNS server. The Ubuntu DNS server sends a query to the load balancer for www.gslb.example.com and the LB responds to the Ubuntu DNS server with the right A record in the answer section. However, the Ubuntu server responds to the client with servfail. When I look at the pcap from the Ubuntu server, the LB is responding to it with the correct IP but the dig response from the Ubuntu server to the client shows "no servers could be reached" when I dig against the Ubuntu. I also see the same message in the dns response in the pcap (obviously). Ryans-MacBook-Pro:~ ryanc$ dig @10.10.1.50 www.example.com <-me querying the Ubuntu for www.example.com ; <<>> DiG 9.8.3-P1 <<>> @10.10.1.50 www.example.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Do you have any ideas as to why this is happening? Ryan Chervenka___ 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: Answers from cache or authority section?
On Tue, 2013-06-25 at 17:20 +0100, Phil Mayers wrote: > On 25/06/13 16:53, John Horne wrote: > > > servers. However, there is a whole load of muttering that Microsoft and > > AD won't like that; it's all integrated with each other; running the DNS > > zone on Linux servers will be a problem with the MS servers etc etc. > > I'm sure you know this, but just in case - that is FUD. > Yes, so I gather. Unfortunately because I deal with the Linux side of things, I don't carry much weight here at all when trying to point out that we can integrate the MS stuff with the Linux servers. > As long as you setup appropriate dynamic update ACLs, AD works fine with bind > DNS > servers. > That is my understanding, and I have been saying it for a very long time now. It may well be that our current problem, despite the fact it took someone external to point it out!, is enough to get our DNS correctly sorted out (with respect to visible/accessible name servers). > Happy to discuss this offline if it helps. > Okay, thanks. The guy who knows the most about our AD/Exchange setup is on hols for the week, but I'll let him know when he returns. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: Answers from cache or authority section?
On 25.06.13 15:32, John Horne wrote: If, however, you run a general query for the NS records: dig 163.141.in-addr.arpa ns then you will get an ANSWER section which lists several of our 'ils' servers: == ;; ANSWER SECTION: 163.141.in-addr.arpa. 3600 IN NSils022.uopnet.plymouth.ac.uk. 163.141.in-addr.arpa. 3600 IN NSils001.uopnet.plymouth.ac.uk. 163.141.in-addr.arpa. 3600 IN NSils009.uopnet.plymouth.ac.uk. (etc) == The problem is that all these servers are internal to our site. They cannot be directly queried externally (you get a timeout). then, you must configure proper NS records for the 163.141.in-addr.arpa zone So I think my question is what is the resolver doing? Does it use cached NS records seen in the AUTHORITY section yes, that is the definition of AUTHORITATIVE data. if your servers are authoritative for the zone, the given NS records prevail over delegation from parent zone. -- 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. - Holmes, what kind of school did you study to be a detective? - Elementary, Watson. -- Daffy Duck & Porky Pig ___ 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: Answers from cache or authority section?
On Jun 25, 2013, at 7:32 AM, John Horne wrote: > Hello, > > I am having a bit of trouble understanding what happens when, in this > instance, a DNS reverse lookup occurs. Our site has the class-C > 141.163.0.0 address range. If I perform reverse lookups from inside or > outside our site, then they seem to work fine. However, we are currently > investigating a problem an external site has with reverse lookups of our > IP addresses. > > If I run (externally): > >dig 141.in-addr.arpa ns > > then 6 NS records are returned. If I query any one of those using: > > dig +norecurse 163.141.in-addr.arpa ns @tinnie.arin.net > > (using 'tinnie' in this example) then I get our 4 NS records relating to > our local and remote name servers: > > == > ;; AUTHORITY SECTION: > 163.141.in-addr.arpa. 172800 IN NS dns2.cis.strath.ac.uk. > 163.141.in-addr.arpa. 172800 IN NS dns1.cis.strath.ac.uk. > 163.141.in-addr.arpa. 172800 IN NS dns1.plymouth.ac.uk. > 163.141.in-addr.arpa. 172800 IN NS dns0.plymouth.ac.uk. > == > > There is no ANSWER section, but a referral to the servers listed in the > AUTHORITY section. > > So, I assume that at this point the name server used by a resolver will > now cache those NS records. As such, any subsequent reverse lookup for a > 141.163.x.x address should use one of the above cached name servers and > get an answer. Your assumption is incorrect. The delegation will only be cached until a more reliable rrset is found -- the NS records returned by your servers (more reliable because of the 'aa' flag). You already know the solution. Don't publish internal-only name servers to the public. You can do any of the following to fix this: - Turn on minimal responses on all 4 name servers listed in the referral from ARIN (but this can have undesirable side effects) - Use two views (but this can cause lots of extra work) - Publish your external name servers internally (but this can require firewall changes) - Make your internal name servers reachable from the Internet Regards, Chris Buxton BLUECAT ___ 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: Answers from cache or authority section?
On Tue, 2013-06-25 at 17:07 +0100, Steven Carr wrote: > On 25 June 2013 16:53, John Horne wrote: > > So what I now do not understand is why (at home) I can do several > > reverse lookups for different IP addresses, and they all give me an > > answer. Likewise if I do something like: > > > >dig -x 141.163.99.16 @8.8.8.8 > > > > I get a non-authoritative answer. If I repeat this for addresses > > 141.163.99.17, 18, 20 and so on I get answers. In all these cases > > shouldn't the first lookup work and subsequent ones fail? Using Google's > > name server, shouldn't it at some point have received the authoritative > > answer with the AUTHORITY section NS records and so be using those > > (internal) name servers for subsequent lookups? > > Using Google you will get unexpected results, not sure exactly what > caching engine they use but it doesn't work like most other caching > servers, they definitely do some jiggery pokery with the results > Ah, that is what I was wondering. Thanks. > I would suggest you install a local copy of BIND configured for > recursion and let it do the queries for you then you can also use rndc > to inspect the cache for yourself. > Yes, I did try that. Cleared the cache, then ran 'rndc dumpdb' after the first query, saved the file then ran it again after a second query. Unfortunately I couldn't see our internal servers being cached at all (which they should have been after the first query). At that point I thought I'd ask on the list. I'll repeat the testing to see if I can see what is going on. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: Answers from cache or authority section?
On 25/06/13 16:53, John Horne wrote: servers. However, there is a whole load of muttering that Microsoft and AD won't like that; it's all integrated with each other; running the DNS zone on Linux servers will be a problem with the MS servers etc etc. I'm sure you know this, but just in case - that is FUD. As long as you setup appropriate dynamic update ACLs, AD works fine with bind DNS servers. Happy to discuss this offline if it helps. ___ 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: Answers from cache or authority section?
On 25 June 2013 16:53, John Horne wrote: > So what I now do not understand is why (at home) I can do several > reverse lookups for different IP addresses, and they all give me an > answer. Likewise if I do something like: > >dig -x 141.163.99.16 @8.8.8.8 > > I get a non-authoritative answer. If I repeat this for addresses > 141.163.99.17, 18, 20 and so on I get answers. In all these cases > shouldn't the first lookup work and subsequent ones fail? Using Google's > name server, shouldn't it at some point have received the authoritative > answer with the AUTHORITY section NS records and so be using those > (internal) name servers for subsequent lookups? Using Google you will get unexpected results, not sure exactly what caching engine they use but it doesn't work like most other caching servers, they definitely do some jiggery pokery with the results (I've seen Google continue to return correct results for domains that had completely corrupted NS records both in the parent and authoritative). I would suggest you install a local copy of BIND configured for recursion and let it do the queries for you then you can also use rndc to inspect the cache for yourself. Steve ___ 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: Answers from cache or authority section?
On Tue, 2013-06-25 at 10:46 -0400, Barry Margolin wrote: > > In addition, the authoritative answer may contain an Authority section. > These nameservers take precedence over the NS records from the > delegation -- the assumption is that the authoritative server knows its > domain's nameservers more reliably than the parent domain's servers. > Ah. This is the bit I did not know. Okay, so from a fresh cache the first reverse lookup will work its way down from the root and provide an authoritative answer. The AUTHORITY section NS records are cached. So for any subsequent reverse lookup (for a different IP address) the resolver will use the cached name servers. In our case these are internal and would give a timeout. So what I now do not understand is why (at home) I can do several reverse lookups for different IP addresses, and they all give me an answer. Likewise if I do something like: dig -x 141.163.99.16 @8.8.8.8 I get a non-authoritative answer. If I repeat this for addresses 141.163.99.17, 18, 20 and so on I get answers. In all these cases shouldn't the first lookup work and subsequent ones fail? Using Google's name server, shouldn't it at some point have received the authoritative answer with the AUTHORITY section NS records and so be using those (internal) name servers for subsequent lookups? > That seems to be where your problem is -- the NS records you're handing > out are not appropriate for public consumption. But they replace the NS > records coming from the delegation. You MUST fix this. Configuring views > would be a solution: > Unfortunately the internal servers are MS Windows name servers and they are the masters for our reverse zone. The two secondary servers 'dns0.plymouth.ac.uk' and 'dns1.plymouth.ac.uk' are Linux servers and are to be added to the list of authoritative NS records. This should be a short-term solution to our problem with the external company, but I have already stressed to management that this is not a long term solution and that the internal servers should be just that - internal. Ideal would be moving the reverse zone onto the Internet-facing Linux servers. However, there is a whole load of muttering that Microsoft and AD won't like that; it's all integrated with each other; running the DNS zone on Linux servers will be a problem with the MS servers etc etc. John. -- John Horne, Plymouth University, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 ___ 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: Answers from cache or authority section?
In article ,
John Horne wrote:
> So I think my question is what is the resolver doing? Does it use cached
> NS records seen in the AUTHORITY section, or does it use NS records seen
> in an ANSWER section? Or is it working its way down until it receives an
> authoritative answer ('aa' flag set), and then query one of those name
> servers?
Neither. It never queries for a parent domain, all queries contain the
full name being looked up.
When starting from an empty cache, the query is sent first to the root
servers, a la
dig x.y.163.141.in-addr.arpa @a.root-servers.net
If this returns an authoritative answer, the answer is used and cached.
If not, it should contain a delegation in the Authority section; the NS
records in the delegation are cached, and then it repeats the query to
one of those nameservers. This process repeats until it gets an
authoritative answer or an error.
In addition, the authoritative answer may contain an Authority section.
These nameservers take precedence over the NS records from the
delegation -- the assumption is that the authoritative server knows its
domain's nameservers more reliably than the parent domain's servers.
That seems to be where your problem is -- the NS records you're handing
out are not appropriate for public consumption. But they replace the NS
records coming from the delegation. You MUST fix this. Configuring views
would be a solution: one version of the zone for internal use, another
for external. The external view should contain the public NS records and
other records for publicly-accessible servers; the internal view can
contain internal NS records and all the machines on your LAN.
--
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
Answers from cache or authority section?
Hello,
I am having a bit of trouble understanding what happens when, in this
instance, a DNS reverse lookup occurs. Our site has the class-C
141.163.0.0 address range. If I perform reverse lookups from inside or
outside our site, then they seem to work fine. However, we are currently
investigating a problem an external site has with reverse lookups of our
IP addresses.
If I run (externally):
dig 141.in-addr.arpa ns
then 6 NS records are returned. If I query any one of those using:
dig +norecurse 163.141.in-addr.arpa ns @tinnie.arin.net
(using 'tinnie' in this example) then I get our 4 NS records relating to
our local and remote name servers:
==
;; AUTHORITY SECTION:
163.141.in-addr.arpa. 172800 IN NS dns2.cis.strath.ac.uk.
163.141.in-addr.arpa. 172800 IN NS dns1.cis.strath.ac.uk.
163.141.in-addr.arpa. 172800 IN NS dns1.plymouth.ac.uk.
163.141.in-addr.arpa. 172800 IN NS dns0.plymouth.ac.uk.
==
There is no ANSWER section, but a referral to the servers listed in the
AUTHORITY section.
So, I assume that at this point the name server used by a resolver will
now cache those NS records. As such, any subsequent reverse lookup for a
141.163.x.x address should use one of the above cached name servers and
get an answer.
If, however, you run a general query for the NS records:
dig 163.141.in-addr.arpa ns
then you will get an ANSWER section which lists several of our 'ils'
servers:
==
;; ANSWER SECTION:
163.141.in-addr.arpa. 3600 IN NSils022.uopnet.plymouth.ac.uk.
163.141.in-addr.arpa. 3600 IN NSils001.uopnet.plymouth.ac.uk.
163.141.in-addr.arpa. 3600 IN NSils009.uopnet.plymouth.ac.uk.
(etc)
==
The problem is that all these servers are internal to our site. They
cannot be directly queried externally (you get a timeout).
The external site (after flushing the cache) performs a reverse lookup
and receives an answer. So working from the root down works. However,
any subsequent reverse lookup of our IP address range has their resolver
looking at the 'ils' servers mentioned above and not the local and
remote name servers (dns0, dns1 etc) seen in the reply from 'tinnie'.
So I think my question is what is the resolver doing? Does it use cached
NS records seen in the AUTHORITY section, or does it use NS records seen
in an ANSWER section? Or is it working its way down until it receives an
authoritative answer ('aa' flag set), and then query one of those name
servers? The 'aa' flag is only set if a query for the
163.141.in-addr.arpa NS records is directed to one of our local/remote
name servers listed in the AUTHORITY by 'trinnie'. It will list the
'ils' servers mentioned above. However, the question then is how come
our reverse lookups work at all - they do for me from home. If the
resolver was looking for an authoritative answer, and they are only
provided by our internal servers, then all the lookups should fail.
Comments? Corrections to where I have gone wrong?
I should point out that I have for a long time banged on at management
about the fact that our internal name servers are visible on the
Internet but cannot be accessed. This is bound to lead to problems. Does
anyone listen though...?
John.
--
John Horne, Plymouth University, UK
Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001
___
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: Secondary DNS question...
On 24.06.13 07:41, Frank Bulk wrote: Interesting to note that querying for ANY does return an SOA. I can't explain that behavior. On 24.06.13 14:54, Matus UHLAR - fantomas wrote: I can guess a kind of DNS filter/firewall. Some l3 switches or load balancers tend to produce strange results too... aa! I am getting response packets but they are somehoe not accepted by dig: % dig +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norec +bufsize=4096 -t soa starionline.com @ns1.starionhost.net ;; global options: +cmd ;; connection timed out; no servers could be reached ... in the meantime: 13:21:38.837415 IP (tos 0x0, ttl 64, id 9452, offset 0, flags [none], proto UDP (17), length 72) 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) 13:21:39.009098 IP (tos 0x10, ttl 50, id 15611, offset 0, flags [none], proto UDP (17), length 196) 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) 13:21:43.837389 IP (tos 0x0, ttl 64, id 9453, offset 0, flags [none], proto UDP (17), length 72) 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) 13:21:44.009780 IP (tos 0x10, ttl 50, id 4231, offset 0, flags [none], proto UDP (17), length 196) 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xe731!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns1.starionhost.net., starionline.com. [1d] NS ns2.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) 13:21:48.837515 IP (tos 0x0, ttl 64, id 9454, offset 0, flags [none], proto UDP (17), length 72) 62.168.95.114.39172 > 74.87.108.83.53: [udp sum ok] 51735 [1au] SOA? starionline.com. ar: . OPT UDPsize=4096 (44) 13:21:49.011060 IP (tos 0x10, ttl 50, id 38531, offset 0, flags [none], proto UDP (17), length 196) 74.87.108.83.53 > 62.168.95.114.39172: [bad udp cksum 0x5586 -> 0xf531!] 51735*- q: SOA? starionline.com. 1/2/3 starionline.com. [1d] SOA ns1.starionhost.net. info.starionhost.net. 2008122905 28800 7200 1209600 3600 ns: starionline.com. [1d] NS ns2.starionhost.net., starionline.com. [1d] NS ns1.starionhost.net. ar: ns1.starionhost.net. [1d] A 74.87.108.83, ns2.starionhost.net. [1d] A 64.136.200.138, . OPT UDPsize=4096 (168) stariononline.com has two NSes listed, ns1.starionhost.net [74.87.108.83] and ns2.starionhost.net [64.136.200.138]. But the first one does not seem to want to respond (http://goo.gl/s41wN and http://dnscheck.iis.se/ and http://www.zonecut.net/dns/index.cgi are just a few examples) to a few of the online checkers. I checked with some others and it looks like you have no SOA set for for ns1.starionhost.net: -- 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. I don't have lysdexia. The Dog wouldn't allow that. ___ 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
