The parent is correct in that the MTA should not provide its own name resolution, but should rather rely on the provided resolver library.
The GP hits on a capability of the standard resolv(3) library by mentioning ignoring cached entries. Passing the RES_AAONLY flag to resolver calls causes the resolver library to only accept authoritative (i.e. non-cached) entries, or return an error if it is unable to find one. This would hopefully handle the TTL issue, unless the DNS server was set to return authoritative answers for all queries.
FWIW, the FC3 man page I looked this up in indicates RES_AAONLY is not currently implemented. But the man page is also dated 1993-05-21...
One would hope that if Lycos is centrally managing the sites targeted by the screensavers and monitoring the sites to ensure they aren't DDOS'ed completely off the map, they wouldn't make it that easy to circumvent.
Although I couldn't find any details on how the screensavers do it, I would think that Lycos driving the list of targets via its DNS servers would work quite well. The screensaver simply looks up a hostname and makes the request to the IP address returned. This would behave a little differently if the site is running as a virtual server (i.e. not on a dedicated machine) but then that would be a problem for the ISP that is hosting the spam site to deal with.
Weeell, Atanasoff was American, as it happens & he was officially first (it went to a legal challenge).
Funny how the second edition of the book didn't catch that. The Honeywell lawsuit was decided in 1973 and recognized the Atanasoff-Berry Computer as the
first electronic digital computer.
Some types of applications, it's easy to visualize how to get a dozen or a hundred computers to help with the problem (serving static web pages). Others, it's not (databases)
Databases may not be easy, but they have been done (http://www.teradata.com/). Not sure if I'd call it a "typical cluster", but I can't say that any cluster is typical. Current Teradata stuff doesn't do Linux, but they're going there as I type.
Part of the problem with the Windows Task Manager is that it only shows RAM and CPU.
Task Manager has numerous other items it tracks,
such as I/O operations, I/O bytes, threads,
page faults, etc. The default setting just
doesn't display them all.
Look for a "Choose Columns..." or similar menu
option. (Can't get to exactly what the name is
or which menu it is in, as I am privileged enough to not need Windows at home.)
It's actually better to have one system and have multiple clients to the system with downgraded permissions, so that a team can go through and audit the whole system easier.
I agree with the idea of a single system, however all the data is coming from multiple (i.e. owned by the individual states), assuredly heterogeneous systems. Each state stores their data in their own way, and they undoubtedly have clients that depend on their particular system, schema, etc.
While access auditing may be easier in a single-system, multiple-client approach, the task of data auditing does not become any easier. Any corruption/problems/issues with the data in the states' warehouses would be propogated to the central server. Validation ("sanity checking") of the data coming from a particular state would be rather difficult, given the volume of data at the central server. Also, validation of the data does not seem very high on the government agenda, given the apparent "No-fly first, ask questions later" philosophy.
If everyone is concerned about privacy (especially when involving a non-governmental entity) a hybrid approach to a single-server system might be in order. The MATRIX could be housed in a "secured" (whatever that needs to mean) Federal facility, but each organization would store its data on a separate physical database system. No need to worry about giving "the man" access to proprietary/private data -- the NSA/CIA/FBI already have it anyway, they just can't tell us. Each organization would have secure (authenticated & encrypted) access to their own server to replicate their data to the central repository. No entity (other than those contributing data) would have access to any individual database (and then, only their own). Instead, all external queries would be through one or more gateways that would have connectivity to all of the individual servers. The gateway would authenticate all requests for data, use its access privileges to get the data, and join/aggregate records as necessary. This would allow each contributing entity to control its data individually, yet still allow a single point of access for security validation and auditing.
7. Social Engineers can break into state-run systems much easier, because they don't have to travel half way across the country to get in.
I couldn't agree more on that one. A while back (post 9/11) I was working a job commissioned by my state's government. By the time the work got to me, the job had been sub-contracted out 3 levels. Part of my duties involved actual deployment, on-site at the state office. After initial "orientation" as to where the data center and servers were, I was set loose to get the job done. For the next 10 days, I was in & out of the data center without any official state ID or proximity card. I would sign in to the "visitor" sheet, grab a visitor ID, and then would be buzzed in to the data center. Not once after I knew the drill was I questioned as to who I was or what I was doing. On my last day, one employee even asked me which department I worked for, as they thought I was recently hired. I was also left completely alone in the data center one Friday night for a number of hours as I finished up my work, without as much as "We're leaving for the night" or "Be sure to turn your badge in when you leave".
All the firewalls/passwords/security measures in the world become quite worthless when you have physical access (without encryption, of course)!
From the summary: "lab officials said they don't believe it contains any weapons information or any other information that could harm national security"
Aren't these the same lab officials who thought they had adequate security to protect classified data?
Slashdot Mirror
The GP hits on a capability of the standard resolv(3) library by mentioning ignoring cached entries. Passing the RES_AAONLY flag to resolver calls causes the resolver library to only accept authoritative (i.e. non-cached) entries, or return an error if it is unable to find one. This would hopefully handle the TTL issue, unless the DNS server was set to return authoritative answers for all queries.
FWIW, the FC3 man page I looked this up in indicates RES_AAONLY is not currently implemented. But the man page is also dated 1993-05-21...
We need some sort of digital signature...
D'OH!
The results can be seen by the /. logo I have reduced here:
Although I couldn't find any details on how the screensavers do it, I would think that Lycos driving the list of targets via its DNS servers would work quite well. The screensaver simply looks up a hostname and makes the request to the IP address returned. This would behave a little differently if the site is running as a virtual server (i.e. not on a dedicated machine) but then that would be a problem for the ISP that is hosting the spam site to deal with.
It is when it is all online and available on a single database system.
Funny how the second edition of the book didn't catch that. The Honeywell lawsuit was decided in 1973 and recognized the Atanasoff-Berry Computer as the first electronic digital computer.
Still won't help them with they're nuts...
Yep. Even the measly Google cluster suggests a spelling of "Elizabeth Ferrarini" instead of "Elizabeth Ferranini".
Databases may not be easy, but they have been done (http://www.teradata.com/). Not sure if I'd call it a "typical cluster", but I can't say that any cluster is typical. Current Teradata stuff doesn't do Linux, but they're going there as I type.
Task Manager has numerous other items it tracks, such as I/O operations, I/O bytes, threads, page faults, etc. The default setting just doesn't display them all.
Look for a "Choose Columns..." or similar menu option. (Can't get to exactly what the name is or which menu it is in, as I am privileged enough to not need Windows at home.)
I agree with the idea of a single system, however all the data is coming from multiple (i.e. owned by the individual states), assuredly heterogeneous systems. Each state stores their data in their own way, and they undoubtedly have clients that depend on their particular system, schema, etc.
While access auditing may be easier in a single-system, multiple-client approach, the task of data auditing does not become any easier. Any corruption/problems/issues with the data in the states' warehouses would be propogated to the central server. Validation ("sanity checking") of the data coming from a particular state would be rather difficult, given the volume of data at the central server. Also, validation of the data does not seem very high on the government agenda, given the apparent "No-fly first, ask questions later" philosophy.
If everyone is concerned about privacy (especially when involving a non-governmental entity) a hybrid approach to a single-server system might be in order. The MATRIX could be housed in a "secured" (whatever that needs to mean) Federal facility, but each organization would store its data on a separate physical database system. No need to worry about giving "the man" access to proprietary/private data -- the NSA/CIA/FBI already have it anyway, they just can't tell us. Each organization would have secure (authenticated & encrypted) access to their own server to replicate their data to the central repository. No entity (other than those contributing data) would have access to any individual database (and then, only their own). Instead, all external queries would be through one or more gateways that would have connectivity to all of the individual servers. The gateway would authenticate all requests for data, use its access privileges to get the data, and join/aggregate records as necessary. This would allow each contributing entity to control its data individually, yet still allow a single point of access for security validation and auditing.
7. Social Engineers can break into state-run systems much easier, because they don't have to travel half way across the country to get in.
I couldn't agree more on that one. A while back (post 9/11) I was working a job commissioned by my state's government. By the time the work got to me, the job had been sub-contracted out 3 levels. Part of my duties involved actual deployment, on-site at the state office. After initial "orientation" as to where the data center and servers were, I was set loose to get the job done. For the next 10 days, I was in & out of the data center without any official state ID or proximity card. I would sign in to the "visitor" sheet, grab a visitor ID, and then would be buzzed in to the data center. Not once after I knew the drill was I questioned as to who I was or what I was doing. On my last day, one employee even asked me which department I worked for, as they thought I was recently hired. I was also left completely alone in the data center one Friday night for a number of hours as I finished up my work, without as much as "We're leaving for the night" or "Be sure to turn your badge in when you leave".
All the firewalls/passwords/security measures in the world become quite worthless when you have physical access (without encryption, of course)!
Aren't these the same lab officials who thought they had adequate security to protect classified data?