I just installed the patched BIND 9.2.x for NodeWorks so it could keep finding dead links for customer sites. Without this kind of technical solution, I would have had to check for redirects to the sitefinder site, and added specific logic to mark the response as invalid since it would otherwise return a valid 200 HTTP response code.
The new feature just needed this bit added to named.conf to get it working:
zone "com" { type delegation-only; }; zone "net" { type delegation-only; };
When its running, it will put message like this to/var/log/messages so you can see it working!
Sep 17 12:58:15 proxy named[1130]: enforced delegation-only for 'com' (www.asdfsdafs.com)
Its really amazing that the open source community can turn around a patch like this within hours of the initial problem being reported! Not only that, but the implementation is clean and technically elegant.
The new *.com & *.net wildcard resolutions are breaking the way the internet is linked together. I run a link checker service at NodeWorks... as a result of Verisign's / Network Solution's just implemented changes resolving *.com and *.net for non-existant domains to their web server, web links with host names that would fail before will now succeed, resulting finally in a 200 HTTP success code from sitefinder.verisign.com which is incorrect! How can an invalid address result in a success HTTP error code?
Any attempts to fix this problem externally are just hacks including null routing the IP address for *.com, and resolving sitefinder.verisign.com to 0.0.0.0, as Verisign can easily change both the IP address of sitefinder.verisign.com as well as the IP address for *.com, so this is just an arms race that can't be won.
Therefore the quality of the web will begin to degrade as Verisign is not supporting the internet protocols correctly, and there is no "correct" way to work around this defect they have caused. If they sent back a web error code, that would be "more correct", but still a flawed implementation as a non-existant domain name should not resolve at all.
It is my wish that some governing body like ICANN or IETF can make a ruling banning this disruptive behavior from Verisign.
I have benchmarked Cocoon before back in 1.x, but could not get 2.x installed this time around on my new development server. I'll try again later, and do feel like it would be an important contribution to the XSLT benchmarks.
I had installed Zend Cache recently while benchmarking but it seemed to offer no speedup, but I am not sure I actually had it installed correctly because of the lack of apparent difference. Because the amount of code is so small on these tests, I would not be surprised if the caching didn't help, as it seems that it is more geared to larger code bases that would really benefit from this. It may be that a better benchmark in the future for this would create some 10K lines of code and then run that for its output.
I will however give the zend cache another chance in the future, or might wait for the zend engine to become part of the standard PHP release, as they are in alpha for that now.
mod_perl can be not too bad on memory, but it depends what you are doing with it. If you look at the environments that run on mod_perl like Embperl, Apache::ASP, Template Toolkit, HTML::Mason, AxKit, etc, you will see more memory usage than using raw mod_perl itself, because the amount of actual code running is much greater, but then people use these environments because of the greater application services they provide than raw mod_perl handlers, so its a trade off. I have known web sites with 20K to 50K lines of perl/mod_perl code and it scales fine as long as one is proficient with tuning mod_perl applications.
As far as benchmarking other java application environments, I will do so as long as they are easy to set up, and benchmarking is allowed in their evaluation license. For example, I did not benchmark Chilisoft ASP because they have a clause in their license that excludes benchmarking, whereas Resin/Caucho did not. I'll check out JBoss and see if I can get it working.
I just shelled out $100 for the Netgear RT311 as my DSL router, it was easy to set up via a simple web interface and "just works". It does not have all the features you are going for though, as it is NAT only, but does this well.
I had a Netgear ISDN router for 3 years before it finally died & it worked like a charm for basic NAT + full PPTP server to server routing. The last is important for my DSL line because I could never get PPTP routing to work with my Linux 2.2.14 kernel & IP MASQ... I'm sure its possible just never did.
I have never needed much the port forwarding,
except when gaming, you can have all ports default to an internal IP, which is quite handy.
Also my old ISDN router would need to be power cycled from time to time, weekly maybe, so I wouldn't serve up anything mission critical
behind one of these, but for SOHO access,
it should be fine.
Slashdot Mirror
The new feature just needed this bit added to named.conf to get it working:
When its running, it will put message like this toAny attempts to fix this problem externally are just hacks including null routing the IP address for *.com, and resolving sitefinder.verisign.com to 0.0.0.0, as Verisign can easily change both the IP address of sitefinder.verisign.com as well as the IP address for *.com, so this is just an arms race that can't be won.
Therefore the quality of the web will begin to degrade as Verisign is not supporting the internet protocols correctly, and there is no "correct" way to work around this defect they have caused. If they sent back a web error code, that would be "more correct", but still a flawed implementation as a non-existant domain name should not resolve at all.
It is my wish that some governing body like ICANN or IETF can make a ruling banning this disruptive behavior from Verisign.
I have benchmarked Cocoon before back in 1.x, but could not get 2.x installed this time around on my new development server. I'll try again later, and do feel like it would be an important contribution to the XSLT benchmarks.
I had installed Zend Cache recently while benchmarking but it seemed to offer no speedup, but I am not sure I actually had it installed correctly because of the lack of apparent difference. Because the amount of code is so small on these tests, I would not be surprised if the caching didn't help, as it seems that it is more geared to larger code bases that would really benefit from this. It may be that a better benchmark in the future for this would create some 10K lines of code and then run that for its output.
I will however give the zend cache another chance in the future, or might wait for the zend engine to become part of the standard PHP release, as they are in alpha for that now.
mod_perl can be not too bad on memory, but it depends what you are doing with it. If you look at the environments that run on mod_perl like Embperl, Apache::ASP, Template Toolkit, HTML::Mason, AxKit, etc, you will see more memory usage than using raw mod_perl itself, because the amount of actual code running is much greater, but then people use these environments because of the greater application services they provide than raw mod_perl handlers, so its a trade off. I have known web sites with 20K to 50K lines of perl/mod_perl code and it scales fine as long as one is proficient with tuning mod_perl applications.
As far as benchmarking other java application environments, I will do so as long as they are easy to set up, and benchmarking is allowed in their evaluation license. For example, I did not benchmark Chilisoft ASP because they have a clause in their license that excludes benchmarking, whereas Resin/Caucho did not. I'll check out JBoss and see if I can get it working.
I had a Netgear ISDN router for 3 years before it finally died & it worked like a charm for basic NAT + full PPTP server to server routing. The last is important for my DSL line because I could never get PPTP routing to work with my Linux 2.2.14 kernel & IP MASQ ... I'm sure its possible just never did.
I have never needed much the port forwarding, except when gaming, you can have all ports default to an internal IP, which is quite handy.
Also my old ISDN router would need to be power cycled from time to time, weekly maybe, so I wouldn't serve up anything mission critical behind one of these, but for SOHO access, it should be fine.