Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
On 2011-03-01 21:00, Torinthiel wrote: > On 03/01/11 20:17, fakessh @ wrote: > And about OVH - I don't know if it's related, but I've asked Polish OVH > how about providing DNSSEC, as .pl is planned to be signed mid-year, and > they've answered me they will probably be ready. This might, or might > not be related to providing DNSSEC by other OVH branches and for other > registries. I asked this to OVH.fr somewhere around October 2010. They answered that they were working on it and it would be available "soon". I re-asked it mid Februari 2010 to OVH.nl. They answered that it's on their roadmap but they don't have a timing yet... They only could provide me with this forum link: http://forum.ovh.nl/showthread.php?t=963 Greets ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Optimising rndc reload times on a slave server with 50,000 zones
One other thing: on the filesystem in which reside directories that house the zone files, set the mount option "noatime". This will improve the performance of re-reading the zone files because it will take out the necessity of updating a time-stamp for each read. -DTK On Mon, Feb 28, 2011 at 7:34 AM, david klein wrote: > 5 files in a single directory will make difficult for any > filesystem. I would recommend breaking that out into groups of less > than 1 per directory. For better performance, separate them onto > directories that are on different spindles; the parallelization of > seek (and with thousands of small files that can each be read in one > or two reads, your disks will spend a lot of this time seeking) should > show noticeable performance improvement. > > Do only some of the zones update at any given 15 minute cycle? If so, > you may show an even bigger improvement by only reloading those that > will have changed. > > > > On Sat, Feb 26, 2011 at 8:56 PM, Dennis Perisa > wrote: >> Hi folks, >> I'm looking for suggestions to substantially improve reload times on a slave >> that is serving 50,000 zones (mostly customer zones). >> 'rndc reload' is being executed on the slave every 15 minutes. Due to the >> large number of zones to trawl through, the reload process is causing >> intermittent outages and/or significant delays to zone transfers. >> Here are some ideas I have: >> - use rndc reconfig instead >> - separate zone files into separate dirs to improve O/S performance >> (currently, all zone files are in a single dir) >> Are these viable options? Any other thoughts/suggestions? >> This is expected to be a short-term fix while we consider brute force >> approach of throwing more cpu/mem/IO at this. >> DP >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> > > > > -- > > david t. klein > > Cisco Certified Network Associate (CSCO11281885) > Linux Professional Institute Certification (LPI000165615) > Redhat Certified Engineer (805009745938860) > > Quis custodiet ipsos custodes? > -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Optimising rndc reload times on a slave server with 50,000 zones
Running off SSDs has also proved to help startup/reload times in our usage. Dan Durrer No-IP On Mar 2, 2011, at 5:32 AM, david klein wrote: > One other thing: on the filesystem in which reside directories that > house the zone files, set the mount option "noatime". This will > improve the performance of re-reading the zone files because it will > take out the necessity of updating a time-stamp for each read. > > > -DTK > > > On Mon, Feb 28, 2011 at 7:34 AM, david klein wrote: >> 5 files in a single directory will make difficult for any >> filesystem. I would recommend breaking that out into groups of less >> than 1 per directory. For better performance, separate them onto >> directories that are on different spindles; the parallelization of >> seek (and with thousands of small files that can each be read in one >> or two reads, your disks will spend a lot of this time seeking) should >> show noticeable performance improvement. >> >> Do only some of the zones update at any given 15 minute cycle? If so, >> you may show an even bigger improvement by only reloading those that >> will have changed. >> >> >> >> On Sat, Feb 26, 2011 at 8:56 PM, Dennis Perisa >> wrote: >>> Hi folks, >>> I'm looking for suggestions to substantially improve reload times on a slave >>> that is serving 50,000 zones (mostly customer zones). >>> 'rndc reload' is being executed on the slave every 15 minutes. Due to the >>> large number of zones to trawl through, the reload process is causing >>> intermittent outages and/or significant delays to zone transfers. >>> Here are some ideas I have: >>> - use rndc reconfig instead >>> - separate zone files into separate dirs to improve O/S performance >>> (currently, all zone files are in a single dir) >>> Are these viable options? Any other thoughts/suggestions? >>> This is expected to be a short-term fix while we consider brute force >>> approach of throwing more cpu/mem/IO at this. >>> DP >>> >>> ___ >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >>> >> >> >> >> -- >> >> david t. klein >> >> Cisco Certified Network Associate (CSCO11281885) >> Linux Professional Institute Certification (LPI000165615) >> Redhat Certified Engineer (805009745938860) >> >> Quis custodiet ipsos custodes? >> > > > > -- > > david t. klein > > Cisco Certified Network Associate (CSCO11281885) > Linux Professional Institute Certification (LPI000165615) > Redhat Certified Engineer (805009745938860) > > Quis custodiet ipsos custodes? > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On 3/1/2011 5:27 PM, Kevin Darcy wrote: See my other post. This is designed-in behavior for Cisco GSSes, since there is no "service unavailable, try again later" RCODE. - Kevin When the question is "what is the ip address of 'foo'" an answer of "the web server is down" in nonsensical. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On Mar 1, 2011, at 5:27 PM, Kevin Darcy wrote: See my other post. This is designed-in behavior for Cisco GSSes, since there is no "service unavailable, try again later" RCODE. Yes[0]. W [0]: there is no "service unavailable, try again later" RCODE. - Kevin On 3/1/2011 4:25 PM, Mark Andrews wrote: Ring Cisco and complain that their nameservers are broken for the zone. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13389 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 204 msec ;; SERVER: 72.163.4.28#53(rcdn9-14p-dcz05n-gss1.cisco.com) ;; WHEN: Wed Mar 2 08:23:59 2011 ;; MSG SIZE rcvd: 33 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- There are only 10 types of people in this world -- those who understand binary arithmetic and those who don't. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On 3/2/2011 10:34 AM, David Sparro wrote: On 3/1/2011 5:27 PM, Kevin Darcy wrote: See my other post. This is designed-in behavior for Cisco GSSes, since there is no "service unavailable, try again later" RCODE. When the question is "what is the ip address of 'foo'" an answer of "the web server is down" in nonsensical. Hmmm... matter of perspective I suppose. Load-balancer architecture sees DNS as just the externally-visible portion of a whole subsystem. The SERVFAIL, in their view, does not communicate a DNS problem _per_se_, but a problem with the whole subsystem. It's more of a "what you're trying to get to is unavailable right now" message, communicated, in their view, _through_ DNS (as a sort of conduit), not necessarily _about_ DNS. They don't see it as specifically meaning "I've got a DNS problem". I'm not saying I agree with this perspective, only that I've dealt with load-balancer vendors enough (Cisco in particular) to understand that this is where they're coming from. Besides, what alternative is there? If the load-balancer returns an address that it knows to not be working, then it's purposely causing the client to go into a relatively-slow connection-timeout failure mode. Is that responsible behavior? If it gives a "normal" response that is lacking answer information (NODATA, NXDOMAIN), then this response gets negatively cached, and the negative cache entry may delay clients from re-trying the resource even after it recovers. So, what's left? NOTIMP? FORMERR? REFUSED? NOTAUTH? Those aren't any better than SERVFAIL from a strictly functional perspective, and are even more misleading and confusing with respect to the real source of the problem. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Help with unresolvable domain (subdomain, actually)
What's really strange is that when we attempt a query, be it DIG or an attempt to browse tools.cisco.com, they send some sort of query back to us from/to UDP 53. We drop it at the firewall due to some sort of "sanity check" so I can't see the contents. This is in addition to the SERVFAIL message. Although I get SERVFAIL, Kloth.net does not, even if we DIG the same server: cax01-bb14-dcz01n-gss1.cisco.com >From Kloth ; <<>> DiG 9.3.2 <<>> @cax01-bb14-dcz01n-gss1.cisco.com tools.cisco.com A ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41388 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; ANSWER SECTION: tools.cisco.com. 20 IN A 72.163.4.38 ;; Query time: 131 msec ;; SERVER: 173.37.144.100#53(173.37.144.100) ;; WHEN: Wed Mar 2 19:15:04 2011 ;; MSG SIZE rcvd: 49 >From Us [root@ns1 ~]# dig -b 148.165.3.10 @cax01-bb14-dcz01n-gss1.cisco.com tools.cisco.com ; <<>> DiG 9.4.3-P3 <<>> -b 148.165.3.10 @cax01-bb14-dcz01n-gss1.cisco.com tools.cisco.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26463 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 45 msec ;; SERVER: 173.37.144.100#53(173.37.144.100) ;; WHEN: Wed Mar 2 10:15:31 2011 ;; MSG SIZE rcvd: 33 So I wonder if the query they make is some kind of authentication attempt? -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, March 01, 2011 3:31 PM To: Kevin Darcy Cc: bind-us...@isc.org Subject: Re: Help with unresolvable domain (subdomain, actually) In message <4d6d7268.1080...@chrysler.com>, Kevin Darcy writes: > I got a trouble ticket on this too. > > From the looks of things, Cisco is using GSSes to load-balance this > site. GSSes return SERVFAIL if all of the resources behind the > load-balancer are down (which it determines via a heartbeat mechanism). > So I think this is a "simple" case of a website (or cluster) going down. > It was down earlier today, then up again, as of this writing, it is down > again. > > DNS doesn't really have a response code of "requested resource not > available", so SERVFAIL is Cisco's closest approximation. It has the > drawback, however, of often making other sorts of problems appear to be > DNS problems. That's just a cross that we DNS admins have to bear... > > - Kevin Then the load balancer should return default records or 0.0.0.0/:: to indicate the name is good but doesn't currently have a address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On 3/2/2011 1:20 PM, Kevin Darcy wrote: I'm not saying I agree with this perspective, only that I've dealt with load-balancer vendors enough (Cisco in particular) to understand that this is where they're coming from. Besides, what alternative is there? If the load-balancer returns an address that it knows to not be working, then it's purposely causing the client to go into a relatively-slow connection-timeout failure mode. Is that responsible behavior? Short answer: yes. The DNS side of the load-balancer has does't know why it got the query. Maybe I was trying to ping the endpoint, I could have been trying to make an FTP connection, or HTTPS, etc. In order for it to be consistent, it would have to be able to figure out that a SERVFAIL should be returned for the query from my gopher:// connection, but an IP should be returned for http://. If it gives a "normal" response that is lacking answer information (NODATA, NXDOMAIN), then this response gets negatively cached, and the negative cache entry may delay clients from re-trying the resource even after it recovers. So, what's left? NOTIMP? FORMERR? REFUSED? NOTAUTH? Those aren't any better than SERVFAIL from a strictly functional perspective, and are even more misleading and confusing with respect to the real source of the problem. SERVFAIL caching is coming to a BIND server release this year. (I listened to the BIND 9.8 features webinar this morning. I don't remember which version (9.9 or 9.10) had this attached to it on the What's Next slide.) -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On Mar 2, 2011, at 1:20 PM, Kevin Darcy wrote: On 3/2/2011 10:34 AM, David Sparro wrote: On 3/1/2011 5:27 PM, Kevin Darcy wrote: See my other post. This is designed-in behavior for Cisco GSSes, since there is no "service unavailable, try again later" RCODE. When the question is "what is the ip address of 'foo'" an answer of "the web server is down" in nonsensical. Hmmm... matter of perspective I suppose. Load-balancer architecture sees DNS as just the externally-visible portion of a whole subsystem. The SERVFAIL, in their view, does not communicate a DNS problem _per_se_, but a problem with the whole subsystem. It's more of a "what you're trying to get to is unavailable right now" message, communicated, in their view, _through_ DNS (as a sort of conduit), not necessarily _about_ DNS. They don't see it as specifically meaning "I've got a DNS problem". But, everyone else *will*. I'm not saying I agree with this perspective, only that I've dealt with load-balancer vendors enough (Cisco in particular) to understand that this is where they're coming from. Besides, what alternative is there? If the load-balancer returns an address that it knows to not be working, then it's purposely causing the client to go into a relatively-slow connection-timeout failure mode. Is that responsible behavior? If it gives a "normal" response that is lacking answer information (NODATA, NXDOMAIN), then this response gets negatively cached, and the negative cache entry may delay clients from re-trying the resource even after it recovers. So, what's left? NOTIMP? FORMERR? REFUSED? NOTAUTH? Those aren't any better than SERVFAIL from a strictly functional perspective, and are even more misleading and confusing with respect to the real source of the problem. A few options: 1: once the LB knows that all back-ends are down, it can continue to answer with the correct A, but drop the TTL to be much shorter -- this allows things to recover faster. 2: have the LB itself serve a 'sorry' page -- the ability to serve static content locally should be simple, but if it not able to do so it can always return a set of 'sorry' servers optimized for this purpose. You shouldn't be breaking both your serving *and* 'sorry' backends often enough for there to be special handling needed (and, if you are, you shouldn't make things worse by making other folk waste their time debugging your problem). W - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- I had no shoes and wept. Then I met a man who had no feet. So I said, "Hey man, got any shoes you're not using?" ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On 3/1/2011 6:30 PM, Mark Andrews wrote: In message<4d6d7268.1080...@chrysler.com>, Kevin Darcy writes: I got a trouble ticket on this too. From the looks of things, Cisco is using GSSes to load-balance this site. GSSes return SERVFAIL if all of the resources behind the load-balancer are down (which it determines via a heartbeat mechanism). So I think this is a "simple" case of a website (or cluster) going down. It was down earlier today, then up again, as of this writing, it is down again. DNS doesn't really have a response code of "requested resource not available", so SERVFAIL is Cisco's closest approximation. It has the drawback, however, of often making other sorts of problems appear to be DNS problems. That's just a cross that we DNS admins have to bear... - Kevin Then the load balancer should return default records or 0.0.0.0/:: to indicate the name is good but doesn't currently have a address. I like that solution, actually. Even if the client doesn't recognize it as a "special" address, hopefully if it tries to connect to it, the packet won't make it past the first router or switch hop... Has anyone proposed this to the load-balancer vendors? - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Help with unresolvable domain (subdomain, actually)
> A few options: >1: once the LB knows that all back-ends are down, it can continue to answer >with the correct A, but drop the TTL to be much shorter -- this allows >things to recover faster. This would work well because the actually web site wasn't down, at least not yesterday. If I substituted the IP address for the domain name, it was reachable and links maintained the domain portion of the URL in dotted decimal format. It seems only DNS is hosed. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
On Mar 2, 2011, at 1:21 PM, Mike Bernhardt wrote: What's really strange is that when we attempt a query, be it DIG or an attempt to browse tools.cisco.com, they send some sort of query back to us from/to UDP 53 Many GSLB solutions attempt to figure out what the best location to serve from is by sending a query to the server that just queried *them* -- this allows them to figure out latency and decide which cluster might be closest I'm suspecting (although I avoid Cisco LB like the plague and so am not sure) that this is the cause. The other possibility -- I ran tcpdump to see if I could see what the query might be I found that I was getting a FormErr response to my initial query, causing me to requery without DNSSEC / EDNS0 -- maybe you are actually not seeing a query from them, mebe its a FormErr response that your FW is noting? W wkumari@vimes:~/src/perl/IODEF$ dig +edns=0 tools.cisco.com @128.107.227.197 ; <<>> DiG 9.7.2-P3 <<>> +edns=0 tools.cisco.com @128.107.227.197 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 41568 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 75 msec ;; SERVER: 128.107.227.197#53(128.107.227.197) ;; WHEN: Wed Mar 2 14:17:38 2011 ;; MSG SIZE rcvd: 33 wkumari@vimes:~/src/perl/IODEF$ dig tools.cisco.com @128.107.227.197 ; <<>> DiG 9.7.2-P3 <<>> tools.cisco.com @128.107.227.197 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54960 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; ANSWER SECTION: tools.cisco.com.20 IN A 173.37.145.8 ;; Query time: 75 msec ;; SERVER: 128.107.227.197#53(128.107.227.197) ;; WHEN: Wed Mar 2 14:17:45 2011 ;; MSG SIZE rcvd: 49 . We drop it at the firewall due to some sort of "sanity check" so I can't see the contents. This is in addition to the SERVFAIL message. Although I get SERVFAIL, Kloth.net does not, even if we DIG the same server: cax01-bb14-dcz01n-gss1.cisco.com From Kloth ; <<>> DiG 9.3.2 <<>> @cax01-bb14-dcz01n-gss1.cisco.com tools.cisco.com A ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41388 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; ANSWER SECTION: tools.cisco.com.20 IN A 72.163.4.38 ;; Query time: 131 msec ;; SERVER: 173.37.144.100#53(173.37.144.100) ;; WHEN: Wed Mar 2 19:15:04 2011 ;; MSG SIZE rcvd: 49 From Us [root@ns1 ~]# dig -b 148.165.3.10 @cax01-bb14-dcz01n-gss1.cisco.com tools.cisco.com ; <<>> DiG 9.4.3-P3 <<>> -b 148.165.3.10 @cax01-bb14-dcz01n- gss1.cisco.com tools.cisco.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26463 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;tools.cisco.com. IN A ;; Query time: 45 msec ;; SERVER: 173.37.144.100#53(173.37.144.100) ;; WHEN: Wed Mar 2 10:15:31 2011 ;; MSG SIZE rcvd: 33 So I wonder if the query they make is some kind of authentication attempt? -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, March 01, 2011 3:31 PM To: Kevin Darcy Cc: bind-us...@isc.org Subject: Re: Help with unresolvable domain (subdomain, actually) In message <4d6d7268.1080...@chrysler.com>, Kevin Darcy writes: I got a trouble ticket on this too. From the looks of things, Cisco is using GSSes to load-balance this site. GSSes return SERVFAIL if all of the resources behind the load-balancer are down (which it determines via a heartbeat mechanism). So I think this is a "simple" case of a website (or cluster) going down. It was down earlier today, then up again, as of this writing, it is down again. DNS doesn't really have a response code of "requested resource not available", so SERVFAIL is Cisco's closest approximation. It has the drawback, however, of often making other sorts of problems appear to be DNS problems. That's just a cross that we DNS admins have to bear... - Kevin Then the load balancer should return default records or 0.0.0.0/:: to indicate the name is good but doesn't currently have a address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -
Re: Help with unresolvable domain (subdomain, actually)
On 3/2/2011 1:57 PM, David Sparro wrote: On 3/2/2011 1:20 PM, Kevin Darcy wrote: I'm not saying I agree with this perspective, only that I've dealt with load-balancer vendors enough (Cisco in particular) to understand that this is where they're coming from. Besides, what alternative is there? If the load-balancer returns an address that it knows to not be working, then it's purposely causing the client to go into a relatively-slow connection-timeout failure mode. Is that responsible behavior? Short answer: yes. The DNS side of the load-balancer has does't know why it got the query. Maybe I was trying to ping the endpoint, I could have been trying to make an FTP connection, or HTTPS, etc. In order for it to be consistent, it would have to be able to figure out that a SERVFAIL should be returned for the query from my gopher:// connection, but an IP should be returned for http://. That's an implementation decision. If an implementor decides to run a bunch of disparate services under a single FQDN (as opposed to, say, www.example.com/ftp.example.com/gopher.example.com and so forth), then they'd need to come up with a reasonable way with their load-balancer keepalives to decide when the whole thing is "down" or not. If the vast majority of their traffic is web-based (typical), they may choose to call the whole thing "down" if the web part is down, and the other parts (FTP, gopher, whatever) will just have to suffer. That's the price to be paid for the convenience of having a single name for a bunch of different services -- lack of granularity. Things would be better, of course, if clients used SRV records for accessing resources -- then a single "service" name could be differentiated by protocol. But for whatever reason client software authors have not, by and large, embraced this idea. If it gives a "normal" response that is lacking answer information (NODATA, NXDOMAIN), then this response gets negatively cached, and the negative cache entry may delay clients from re-trying the resource even after it recovers. So, what's left? NOTIMP? FORMERR? REFUSED? NOTAUTH? Those aren't any better than SERVFAIL from a strictly functional perspective, and are even more misleading and confusing with respect to the real source of the problem. SERVFAIL caching is coming to a BIND server release this year. (I listened to the BIND 9.8 features webinar this morning. I don't remember which version (9.9 or 9.10) had this attached to it on the What's Next slide.) I think Mark has the right approach: return a "special" address (e.g. 0.0.0.0 or the IPv6 equivalent) in this situation, instead of messing with the RCODE. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig result whiout "ADDITIONAL SECTION",why?
bind-dlz (BDB as backend) [root@flyinweb ~]# dig @ns1.dnssafe.cn www.djytest.com ; <<>> DiG 9.7.0-P2 <<>> @ns1.dnssafe.cn www.djytest.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23086 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.djytest.com. IN A ;; ANSWER SECTION: www.djytest.com.600 IN A 218.5.74.144 ;; AUTHORITY SECTION: djytest.com.7200IN NS ns2.dnssafe.cn. djytest.com.7200IN NS ns1.dnssafe.cn. ;; Query time: 2 msec ;; SERVER: 218.5.74.138#53(218.5.74.138) ;; WHEN: Thu Mar 3 09:47:08 2011 ;; MSG SIZE rcvd: 99 Is it correct without "ADDITIONAL SECTION"? The additional section of a reply. The default is to display it. 2011-03-03 ShanyiWan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig result whiout "ADDITIONAL SECTION",why?
On Mar 2, 2011, at 8:49 PM, ShanyiWan wrote: > bind-dlz (BDB as backend) > > > [root@flyinweb ~]# dig @ns1.dnssafe.cn www.djytest.com > > ; <<>> DiG 9.7.0-P2 <<>> @ns1.dnssafe.cnwww.djytest.com > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23086 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.djytest.com. IN A > > ;; ANSWER SECTION: > www.djytest.com.600 IN A 218.5.74.144 > > ;; AUTHORITY SECTION: > djytest.com.7200IN NS ns2.dnssafe.cn. > djytest.com.7200IN NS ns1.dnssafe.cn. > > ;; Query time: 2 msec > ;; SERVER: 218.5.74.138#53(218.5.74.138) > ;; WHEN: Thu Mar 3 09:47:08 2011 > ;; MSG SIZE rcvd: 99 > > > Is it correct without "ADDITIONAL SECTION"? Erm, I'm low on coffee and so might be unsane at the moment There is no additional section because the name-server that you queried (ns1.dnssafe.cn) doesn't know the addresses for: ns1.dnssafe.cn ns2.dnssafe.cn airnet:.subversion wkumari$ dig +norecurse ns1.dnssafe.cn @ns1.dnssafe.cn ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norecurse ns1.dnssafe.cn @ns1.dnssafe.cn ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26342 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns1.dnssafe.cn.IN A ;; AUTHORITY SECTION: . 360 IN NS H.ROOT-SERVERS.NET. . 360 IN NS B.ROOT-SERVERS.NET. . 360 IN NS M.ROOT-SERVERS.NET. . 360 IN NS K.ROOT-SERVERS.NET. . 360 IN NS I.ROOT-SERVERS.NET. . 360 IN NS L.ROOT-SERVERS.NET. . 360 IN NS E.ROOT-SERVERS.NET. . 360 IN NS J.ROOT-SERVERS.NET. . 360 IN NS C.ROOT-SERVERS.NET. . 360 IN NS D.ROOT-SERVERS.NET. . 360 IN NS G.ROOT-SERVERS.NET. . 360 IN NS A.ROOT-SERVERS.NET. . 360 IN NS F.ROOT-SERVERS.NET. ;; Query time: 638 msec ;; SERVER: 211.99.203.62#53(211.99.203.62) ;; WHEN: Wed Mar 2 22:43:04 2011 ;; MSG SIZE rcvd: 243 but, then again, it does the same thing for, well, anything airnet:.subversion wkumari$ dig +norecurse +tcp LaLaLaHappyDays @ns1.dnssafe.cn ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norecurse +tcp LaLaLaHappyDays @ns1.dnssafe.cn ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35320 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;LaLaLaHappyDays. IN A ;; AUTHORITY SECTION: . 360 IN NS H.ROOT-SERVERS.NET. . 360 IN NS L.ROOT-SERVERS.NET. . 360 IN NS J.ROOT-SERVERS.NET. . 360 IN NS A.ROOT-SERVERS.NET. . 360 IN NS C.ROOT-SERVERS.NET. . 360 IN NS K.ROOT-SERVERS.NET. . 360 IN NS E.ROOT-SERVERS.NET. . 360 IN NS F.ROOT-SERVERS.NET. . 360 IN NS D.ROOT-SERVERS.NET. . 360 IN NS B.ROOT-SERVERS.NET. . 360 IN NS I.ROOT-SERVERS.NET. . 360 IN NS G.ROOT-SERVERS.NET. . 360 IN NS M.ROOT-SERVERS.NET. ;; Query time: 487 msec ;; SERVER: 211.99.203.62#53(211.99.203.62) ;; WHEN: Wed Mar 2 22:46:02 2011 ;; MSG SIZE rcvd: 244 Methinks someone forgot to configure it W > The additional section of a reply. The default is to display it. > > > 2011-03-03 > > > > ShanyiWan > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.8.0 is now available
In addition to my pvt email Evan The dev link page still shows 9.7.3 as current production, no 9.8.0, but going to all downloads shows 9.8.0 as current production, and as things happen in three's ... bind-9.8.0.tar.gz clicking on this yields a file called bind-980targzno periods, looks like some script has collapsed asc sha1 sha256 sha512 On Tue, 2011-03-01 at 17:29 +, Evan Hunt wrote: > __ > > Introduction > >BIND 9.8.0 is the first production release of BIND 9.8. > >This document summarizes changes from BIND 9.7 to BIND 9.8. Please see >the CHANGES file in the source code release for a complete list of all >changes. > > Download > >The latest development versions of BIND 9 software can always be found >on our web site at http://www.isc.org/downloads/development. There you >will find additional information about each release, source code, and >some pre-compiled versions for certain operating systems. > signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
