|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
This week's distributed denial-of-service (DDOS) attack on the Domain Name System (DNS) root server system (see story) got the attention of the Internet Corporation for Assigned Names and Numbers (ICANN), the U.S.-created private group that is charged with ensuring the stability and security of the DNS.
ICANN, which has been increasing its focus on security issues since the Sept. 11 terrorist attacks, formed a security committee to examine what can be done to improve DNS system security.
Internet pioneer Stephen Crocker, who helped develop protocols for Arpanet, the original network that became the basis for the Internet, chairs that committee. Crocker will be discussing the DDOS attacks at ICANN's annual meeting in Shanghai next week, and in an interview with Computerworld reporter Patrick Thibodeau, he assessed the impact of the recent attack and outlined some of the options for improving DNS security.
Q: What's your assessment of the DOS attack?
A: There is good news and complications here. There are 13 root servers. Some of them were effectively out of service for a while, but the impact on the whole community was negligible. Further good news is that a number of the servers were very, very well set up, well provisioned, have first-class staffs who rose to the occasion and worked very hard to stave off the affects of the attack and stay up in service.
In a sense, one can say, the defenses were tested and it turns out that the system is pretty good. The impact on the community was pretty modest.
Q: What's the bad news?
A: Does that mean we should all sleep soundly? Not really; suppose the attack was bigger or lasted longer?
I think the result there is somewhat nuanced. It's the nature of the DNS service that because there is a lot of caching [in other DNS servers], most of the world would go on pretty well for a long time, for a day or so, before there would be much degradation -- if all the servers went down.
If an attack went on for a day, vastly more resources would be brought to bear. It would be expensive, but I still think the impact on the community would have been relatively modest.
Q: How was the attack conducted?
A: There are two elements to an attack like this. The amount of traffic sent, and how long it goes on for. At the level of traffic that was generated, which was quite substantial, it effectively stopped some of servers from responding because they were overwhelmed with noise and not real traffic. But enough of them continued to operate and provide service anyway, and they could have done that indefinitely.
To effectively stop service, you would have to have a much larger attack and somewhat more sophisticated. I don't want to get into the details, but there is some evidence that this was not the most sophisticated possible attack.
Q: What are the lessons learned from this attack?
A: There are some old lessons that are just evident again. This doesn't teach us anything we didn't know before. As with any attack, it reminds us that we need to make some progress. We shouldn't say everything is fine and expect the system to survive indefinitely. There will be other attacks, and they'll be more sophisticated and they'll be more massive.
Q: Where is improvement needed?
A: There are three areas for improvements. They range from relatively easy to relatively hard to do, and range from useful to more important.
The first is improving the core protocols and service for DNS, and second, tightening up the Internet against DDOS attacks by having the Internet service providers impose some discipline and authentication on the hosts. In today's Internet, it's relatively easy for a host to lie about its address and send packets with misleading return addresses. It's possible to fix this.
As part of tightening up the basic DNS system, we need to deploy the DNS security protocol [DNSSEC, a security protocol intended to improve data origin authentication] and create a wider set of implementations of BIND [the Internet Software Consortium's Berkeley Internet Name Domain server software used for DNS]. I hasten to add that lack of diversity is not actively causing any harm, and the main reason for wanting diverse implementations is general good practice. On the other hand, we do know that many people are running obsolete versions of BIND, and the older versions are known to have critical bugs.
Q: The third problem?
A: What I think our biggest problem globally is are off-the-shelf computers. The minute you plug them in they are susceptible to being enlisted unwittingly to a DOS attack. And I don't understand why that's OK. To have that same computer be used to attack someone else, it's a public nuisance issue. Computers should not be wide open.
Q: Will this incident accelerate the work of the ICANN security committee?
A: I think we're pretty motivated. The attack acts as a certain amount of stimulus, but there is not enough new information in this. I think it's kind of a reflected effect. We recognize that because something like this happens, it causes other people and the media to take notice, and that increases the pressure and perhaps increases the opportunity.
BIND 8.3.3 BIND version 8 is still in wide usage. The latest version of BIND 8 is BIND Version 8.3.3 (Released June 28, 2002)
The U.S. military's years-long effort to deploy DNS Security is a good example of how difficult it is for enterprises to retrofit their networks with security fixes to the Internet's underlying protocols.
An early and ongoing participant in the development of DNS Security, the Defense Department has worked both directly and through contractors to prepare .mil to be the Internet's first domain to deploy DNS Security. Yet despite efforts going back at least five years, .mil remains vulnerable to hackers who want to spoof one of its Web sites by exploiting well-known holes in DNS.
DNS Security adds digital signatures and public key encryption to the DNS' hierarchical, distributed database system to verify that a domain name matches a corresponding IP address. Developed by the Internet Engineering Task Force, DNS Security was issued as a proposed standard in November, 2000.
Since then, the Defense Information Systems Agency has been working to deploy DNS Security across the thousands of applications servers in use today on .mil that provide Web, e-mail and other services. The upgrade involves migrating all of these servers to the latest version of Berkeley Internet Name Domain (BIND) software, 9.2.1, which supports DNS Security.
DISA officials say they are deploying DNS Security in two phases. First they are rolling out the Secret Key Transaction Authentication for DNS, dubbed TSIG. TSIG provides transaction-level authentication for the dynamic updates coming from DNS clients as well as the responses sent by DNS servers. Next, DISA will deploy Signed Zones, which uses digital signatures to verify information for a particular spot in the DNS hierarchy.
Together, TSIG and Signed Zones will ensure that the .mil ``domain name information and transactions are genuine,'' a DISA spokesman says. ``DISA plans to implement both Transaction Authentication and Signed Zone as soon as technically feasible.''
DISA is rolling out TSIG on DNS servers under its control at the highest levels of the .mil hierarchy, a process that will be completed by the end of the calendar year. DISA then plans to coordinate with the military's Joint Staff to address TSIG deployment on DNS servers under the control of various military services and agencies.
DISA will not start signing zones under the .mil domain until the IETF finalizes a companion specification called Delegation Signer Resource Record. Delegation Signer streamlines how parent domains hand out keys to child domains. The IETF is expected to complete Delegation Signer before the end of the year.
``We strongly support the [Delegation Signer] record, and DISA's implementation will depend on its stability,'' the DISA spokesman says. ``With [Delegation Signer] support available, several issues with DNS Security key management will become much simpler and will be better for DOD in the long run.''
DISA says it will begin signing the .mil zone once Delegation Signer support is stable in BIND 9.3. That's not likely to happen until the middle of 2003, experts say.
So far, DISA has run into some issues with TSIG, which requires DNS administrators to manage cryptographic keys. The agency is looking for management software to ease the burden of DNS Security key management. It's also beefing up training and setting policies for its DNS administrators.
While TSIG deployments have had little impact on DISA's networks, the agency says it's gearing up for a significant increase in system load and network bandwidth requirements with Signed Zones.
``We've conducted extensive load and performance testing of the BIND 9 software releases, and we're confident that it will be usable and stable in the field,'' the DISA spokesman says. ``There will likely be some need for hardware upgrades, but other security requirements will also affect DNS servers. For example, we expect to require that all DNS servers in DOD be dedicated to performing only DNS functions with minimal other software installed for security and administration. If dedicated DNS servers are in use, then we expect most modern computer systems can sustain the expected load even with the addition of DNS Security Signed Zones.''
Once DISA has deployed both aspects of DNS Security, the agency plans to help the U.S. federal government with deployment across the .gov domain.
``We are active participants in the IETF and have held a number of DNS Security workshops,'' the DISA spokesman says. ``We are documenting our experiences for use by other organizations as they implement DNS Security functionality in the future.''
A short paper describing Secure DNS provides a high-level description of the extensions. Several prototype implementations have been released. All future releases will be made by the Internet Software Consortium.
We have made a number of presentations that explain DNSSEC and its use, "DNSSEC How to with BIND-9" "Introduction to DNSSEC" "DNS Security Extensions, Presentation to the 19th NANOG".NLlabs in Holland maintains a good collection of links to DNSSEC resources.
No company can afford to ignore the security of its DNS service, the crucial service that provides host-name and IP address resolution on the Internet. Although Windows 2000 provides a built-in DNS service, BIND is the most widely used DNS software on the Internet, and many Win2K administrators use BIND to maintain their Internet DNS servers. In "Secure Your BIND DNS Service," December 2001, InstantDoc ID 22930, I discuss the vulnerabilities in older BIND versions and describe how to use newer BIND 8 (i.e., BIND 8.2.3 and later) and BIND 9 (i.e., BIND 9.1.0 and later) access-control settings to implement a basic layer of protection. However, those settings don't address two important security concerns: data authentication and data integrity. To be truly secure, a DNS client or server must communicate only with a trusted DNS server and must authenticate received data. Authentication involves confirming that no one has intercepted a query reply and changed its content during its transmission over the Internet.
To help companies guarantee data authentication and integrity, the Internet Engineering Task Force (IETF) launched development of the DNS Security (DNSSEC) Internet standard, which uses public key and digital signature technologies that developers can apply in their DNS software implementations. The IETF also developed the Transaction Signature (TSIG) DNS transaction-authentication protocol, which uses shared secret key technology to help secure DNS transactions. (IETF Request for Comments—RFC—2535 and RFC 3008 discuss DNSSEC; RFC 2845 deals with TSIG. For more information about DNSSEC, you can also visit NLnet Labs' DNSSEC resources Web site at http://www.nlnetlabs.nl/dnssec.)
The Internet Software Consortium (ISC), which develops and maintains BIND source codes, has incorporated DNSSEC and TSIG in BIND 8.2.3 and later and in BIND 9.1.0 and later. The newer BIND 9 versions have better support for DNSSEC and TSIG than do the BIND 8 versions. Both generations can generate public and private keys, but BIND 9.1.0 has extended zone-signing capabilities. Therefore, this article focuses on implementing DNSSEC and TSIG in BIND 9.1.3. (The ISC hasn't imported BIND 9.1.3 into Win2K or Windows NT yet, but you can run BIND 9.1.0 on most UNIX and Linux platforms. Also, BIND Release Candidate—RC—9.2.0 supports Win2K and NT.) This article assumes you have a basic knowledge of BIND, digital signature technology, and shared secret key technology. (For more information about these topics, see "Secure Your BIND DNS Service"; "Digital Signature Technology," February 1999, InstantDoc ID 4772; and Gary C. Kessler, "How DNS Works," June 2000, InstantDoc ID 8666.)
DNSSEC Basics
Implementing DNSSEC on your BIND DNS server involves signing the server's DNS domain zone file. (I explain that process later.) DNSSEC then uses digital signature technology to sign each record in the zone. When a DNS client queries a specific DNS record, the DNS server replies with the signed version of the requested record. The DNS client then uses digital signature technology to confirm the data integrity of the received record and to authenticate the DNS server. To support digital signature technology, DNSSEC introduces two new DNS resource records (RRs): SIG and KEY. The security protocol also introduces the NXT RR to help authenticate nonexistent DNS records.The SIG RR. A SIG RR contains the digital signature for each original RR (e.g., Start of Authority—SOA—NS, A, PTR, MX, CNAME). In a signed zone, DNSSEC associates each original RR with a SIG RR to form a record set. Listing 1 shows the zone file for an unsigned, unsecured zone, us.example.com. Figure 1 shows the zone file for the corresponding secure, signed zone. As Figure 1 shows, a SIG RR follows each original RR in the signed zone. A SIG RR's syntax is
corresponding_RR_type signing_algorithm number_of_owner_labels original_TTL signature_expiration signature_inception key_tag signer signatureFor example, callout D in Figure 1 shows the SIG RR for www.us.example.com's A record. This output shows that the SIG RR corresponds to an A RR and that DNSSEC used Digital Signature Algorithm (DSA) to sign the original RR. (RFC 2535 discusses the possible signing algorithms: 1 is RSA/Message Digest 5—MD5— 2 is Diffie-Hellman, and 3 is DSA.) The A RR's owner (i.e., www.us.example.com) has four labels (i.e., www, us, example, and com). The original Time to Live (TTL) value of the A RR is 86400 seconds (i.e., 1 day), the signature expires at 6:10:13 Greenwich Mean Time (GMT) on April 3, 2001 (i.e., 20010403061013), and the signature became valid at 6:10:13 GMT on March 4, 2001 (i.e., 20010304061013). The key tag (i.e., a number that identifies the zone's public and private key pair) is 51297. The signer is us.example.com, and the final strange string is the signature.
The KEY RR. You use a zone's private key (from its public and private key pair) to sign the zone during DNSSEC implementation. You keep the private key secret, and the KEY RR stores the public key, which a DNS client uses to verify the signatures of received DNS records. DNSSEC provides a corresponding SIG RR for each KEY RR, but the parent zone signs the KEY RR. For example, the parent zone example.com would sign a KEY RR in the signed zone us.example.com. The KEY RR's syntax is
flags protocol algorithm public_keyFlags indicate the type of the included key and how to use it. For example, callout A in Figure 1 shows us.example.com's KEY RR. This output shows that the key is a zone key and is used only for authentication. The protocol is DNSSEC (represented by the number 3), the signing algorithm is DSA (represented by the number 3), and the final string is the zone's public key. (RFC 2535 discusses the meanings of the KEY RR's options.) The KEY RR's corresponding SIG RR, which callout B in Figure 1 shows, defines the signer of the KEY RR (i.e., us.example.com's parent zone, example.com).
The Public DNS Service is a public service provided by Granite Canyon Group, LLC. The Service offers both primary and secondary DNS free of charge to anyone who asks. The Service maintains UPS protected FreeBSD servers that satisfy DNS queries. The servers are geographically separated and all are connected to the Internet via 7x24 dedicated lines with disjoint routes to the Internet's North American backbones.
The Public DNS is useful if you:
- Can't get free service from an ISP and don't want to do it yourself
- Need secondary DNS servers
- Need MX records for a virtual domain
- Want control over your DNS records: change DNS frequently, changing ISPs soon
- Are inside of a firewall and need publicly-accessible name servers outside of your firewall
- Need name servers that are closer to the North American Internet backbones
Please re-read the FAQ, the status update, the restrictions and the indemnification and warranty disclaimer. We are supported by register.com, Senator Enterprises, and PayPal donations.
In January 2001, an attacker fooled VeriSign, the parent company of Network Solutions, into signing a fake ``Microsoft Corporation'' ActiveX key. We're supposed to trust these people?
About: mkrdns is a small Perl script that helps automate changes to your DNS zone files. It does this by reading your named.boot/named.conf file to find all the domains/networks for which you are authoritative. It then reads all of the forward zone files and generates PTR records which it inserts in the reverse zone maps.
Changes: mkrdns incorrectly assumed that commands in named.conf files would be on seperate lines in some cases. This could cause mkrdns to ignore other multiple commands on a single line.
The Berkeley Internet Name Domain software, AKA "named," is one of the most important pieces in the mosaic that represents the structure of the Internet. Due to this importance, it is also a preferred target for hackers, who want to keep DNS from working, or worse, use security holes in the software to gain control over the machine. Such hacking of a DNS server can result in a break of confidentiality of the data returned from this server, and is, in general, a bad thing.
The "named" process usually runs as the root user on a system. There are two things that can be done to make things more safe against break-ins: The first is to not let the daemon run with full system (root) privileges; the other is to limit the possible damage by putting the named into a chroot environment where it can't access anything but a few files it needs to run. Running a program with a different root directory than /, which is done via the chroot command, is also called "sandboxing" or "jailing".
This article describes the steps that are necessary to run the BIND9 package on NetBSD in a chroot cage, using NetBSD's new rc.d-based startup system.
SecurityPortal - DNS Server Infrastructure By Kurt Seifried which discusses the infrastructure of DNS and some basic security matters. They compare the DNS implementations for several high profile sites, including sun.com.
At a bare minimum, you'll need a 1U rack mount server with enough RAM to handle the database in memory (in most cases 512 megs will be plenty). You may additionally want to place a firewall in front of it to prevent attacks directly on the firewall.
By having several sets of DNS servers at different providers, you achieve a much more robust system. An attacker must take out more than one target. However, if all your DNS servers are running at 100% capacity and an attacker takes one server out, that may cause enough added load on the other servers to make them unresponsive.
Ideally, a single server should be able to handle the full load. Realistically, you should be able to lose at least one, and probably two servers without overloading the remaining ones.
Lately, there's been a lot of news about BIND. First of all, a new bug was found in BIND 8. Basically, a problem in the transaction signature handling code could allow a buffer overflow which allowed code to be executed as the user running the nameserver. Then secondly, remote attackers can get information about the running bind process from environment variables and the stack. Security problems in BIND are not new news. In fact, one of my name servers was attacked almost a year ago due to a buffer overflow problem. For information about some more BIND security issues, visit http://www.isc.org/products/BIND/bind-security.html.
So what are the alternatives?
Paul Vixie wrote to the bsdi-users mailing list: "See BIND9. Written by a new team, sharing no code with BIND8. Two years in the preparation. 6+ months of testing. Now in its second cut (9.1.0)". And then later, he said: "Anyone who listens to naysayers without reading (or even just sampling) the source and trying it out is shortchanging themselves." The BIND 9 webpage says: "BIND version 9 is a major rewrite of nearly all aspects of the underlying BIND architecture." So maybe BIND 9 is an alternative. Time will tell. For information, check out http://www.isc.org/products/BIND/bind9.html.
Also, ISC -- the BIND maintainer -- is looking to create a special members-only forum. ISC believes it will help vendors by providing read access to ISC's internal CVS and more lead time to prepare patches. But also, they plan to have a non-disclosure agreement. ISC has no plans to stop working with CERT to share the security information to the public.
Another alternative is to use djbdns from D. J. Bernstein of qmail (and other) notoriety. djbdns uses an entirely different format for configurations; plus it requires Bernstein's daemontools (which you may find useful). For more information, visit http://cr.yp.to/djbdns.html.
In addition, the djbdns DNS utilities are free, but the license is strict: you may not distribute modified (patched) versions. So if you are worried about a delayed patch for BIND, with djbdns you can't even distribute a fixed version until it is official from Bernstein. (It is interesting to note that a small monetary award is available to the "first person to publicly report a verifiable security hole in the latest version of djbdns.")
A third choice is the GPL'd dents. It has had slow development over the past year, but -- according to the dents discussion forum -- a new beta tarball may soon be released integrating the vast changes found in the dents CVS. Two of dents main features are a CORBA-based control facility and modular driver architecture. Download dents via http://sourceforge.net/projects/dents/. (dents uses pthreads -- I haven't successfully built it yet.)
Others? I don't know. But maybe www.openbind.org will have something soon.
So what does it take to write a DNS server? There are a lot of features and capabilities. And DNS doesn't communicate in a readable, easily-understandable protocol like POP3, HTTP or SMTP. Have a look at the RFCs -- such as 1035. (On a related note: if you know of any good explanations or easy-to-follow code for parsing the message compression and the header, question, answer and other section formats, please let me know. Thanks.)
djbdns license
Neil Schemenauer - February 02, 2001 18:04:45
> In addition, the djbdns DNS utilities are free, but the license > is strict: you may not distribute modified (patched) versions. > So if you are worried about a delayed patch for BIND, with > djbdns you can't even distribute a fixed version until it is > official from Bernstein.You have the source code. No one can stop you from distributing patches. The only thing that is disallowed it distributing modified source or precompiled binaries. Yes, its slightly annoying but not a huge problem.
It's funny to see the Internet sneaking up on businesses and becoming a critical component, without many people seeming to realize it. Many businesses now rely heavily on email as a messaging system, and use Web servers to distribute corporate data and allow access to a variety of services.
All these services rely on DNS. DNS is the directory to the Internet; it maps names such as www.securityportal.com to IP addresses such as 209.67.74.22. To see a Fortune 100 company such as Microsoft suffer a multi-day outage because its DNS infrastructure was not up to the task is disturbing indeed.
Checkservice is a Perl script that monitors services on remote hosts. It uses plugins to provide a more thorough check than just a socket check, and can be configured to check multiple services on multiple hosts using two different methods (simple and extended). It is able to write logs and when running in the background enables warnings. It features a beep-, mail-, and SMS-warning system.
You can check the relevant links here. There is also a history of changes (since the last beta and during the full beta period). Some of the important features of BIND 9 are:
- DNS Security: DNSSEC (signed zones), TSIG (signed DNS requests)
- IP version 6: Answers DNS queries on IPv6 sockets, IPv6 resource records (A6, DNAME, etc.), Bitstring Labels, Experimental IPv6 Resolver Library
- DNS Protocol Enhancements: IXFR, DDNS, Notify, EDNS0, Improved standards conformance
- Views: One server process can provide multiple "views" of the DNS namespace, e.g. an "inside" view to certain clients, and an "outside" view to others;
- Multiprocessor Support
- Improved Portability Architecture"
If you are running any version of BIND version 8, we recommend you upgrade to BIND version 8.2.2 patchlevel 7 for security reasons.
Name: "nxt bug"
Versions affected: 8.2, 8.2 patchlevel 1, 8.2.1 Severity: CRITICAL Exploitable: Remotely Type: Access possible Description:
A bug in the processing of NXT records can theoretically allow an attacker to gain access to the system running the DNS server at whatever privilege level the DNS server runs at.
Workarounds:
None.
Active Exploits:
Scripts are available which can implement this attack.
- Introduction: Why bother? What risks does an insecure BIND pose?
- Install and Configure BIND: compile, install, create DNS data, start BIND.
- Chroot'ing BIND: Create chroot jail, copy BIND to jail, start BIND.
- Troubleshooting
- Configuration Notes
- Footnotes
- References
jrh - Subject: Just don't use BIND! ( Oct 2, 2000, 09:04:06 ) BIND is the sendmail of DNS....great software written in a totally different time of the internet. A big piece of monolithic stuff that needs to be completely redone.
Take a look at djbdns (http://cr.yp.to/djbdns.html). Modular. Written with security in the forefront of the author's consideration.
- linux.ie: How DNS works(Jan 23, 2000)
sendmail.net: Why You Should Upgrade to BIND 8.2.2(Jan 09, 2000)
InfoWorld: Working with your Domain Name System will run more smoothly without 'lame' servers(Dec 19, 1999)
UNIX & LINUX Computing Journal: Overview of DNS(Dec 12, 1999)
Security Portal: Securing your name servers(Nov 24, 1999)
Linux.com: A Guide to Named(Nov 14, 1999)
sendmail.net: Vixie Wraps BIND(Nov 13, 1999)
LinuxForum: A Simple Home DNS Configuration(Oct 10, 1999)
32BitsOnline: Book Review: "DNS and BIND" from O'Reilly(Sep 15, 1999)
Network Computing: Developments in DNS: Investigating Bind 8(Nov 28, 1998)
Subject: W2K DNS port usage changes
From: Russ ([email protected])
Date: Tue Mar 21 2000 - 15:03:28 EST
- sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Chris Brenton: "Re: W2K DNS port usage changes"
- Previous message: Tom Yergeau: "Re: Terminal Service for Win2k fails when High Encryption is selected and 128-bit encryption pack has been applied"
- Next in thread: Chris Brenton: "Re: W2K DNS port usage changes"
Problem:
Windows 2000 Server or Advanced Server DNS Service uses dynamic UDP ports (above 1023) for all standard query messages.
For a W2K DNS server which is facing the Internet (acting as primary for zones, or performing root server lookups for client requests) being protected (at least in part) by router Access Control Lists (ACLs), it must now permit unrestricted UDP inbound access to any high UDP port on the W2K DNS box in order for it to work.
Note, this is a change from NT 4.0 DNS server which always performed all such lookups using UDP 53 as a source port (thereby allowing router ACLs to restrict access to port UDP 53 on the DNS server.)
I have not checked to see if this is, or isn't, in line with current DNS RFCs. What it means, however, is that a UDP port scan can be performed on any W2K box with a DNS configured as above (which is being protected, at least in part, by router ACLs) as long as the source port of the scan is UDP 53. Since RPC is still in use on W2K, numerous services may be listening on high UDP ports which you wouldn't want interrogated.
I would be interested to hear about other DNS servers and whether they use dynamic source ports for such queries.
Status:
Microsoft had implemented a registry key that would permit you to restrict the source port on the DNS server to a single port. The "SendPort" key was intended to serve this functionality, however, it doesn't work...;-[ Microsoft are researching a fix (presumably fixing whatever is broken in the "SendPort" functionality).
Meanwhile, might be wise to ensure that your Internet-facing DNS server isn't running Windows 2000.
Cheers,
Russ - NTBugtraq Editor
"The Internet Software Consortium released on Monday another patchlevel to their ever popular BIND software package. The ISC has recommended that everyone using BIND upgrade to this latest version (BIND v8.2.2 patchlevel 3) due to security holes existing in previous versions. If you are using a version previous to BIND 8.2.1 then pay special attention to the ISC configuration hints on a new required TTL setting which should be added to every zone file. More information on the TTL setting is also available in RFC 2038. On a side note, those who enjoy the bleeding edge should read the ISC future plans page which now has information on the thread-safe/multi-processor ready BIND version 9 (major rewrite) going beta in January. "
UNIX & LINUX Computing Journal: Overview of DNS |
(Dec 12, 1999, 15:00 UTC) (Posted by
marty) (0 talkbacks posted) (433
reads)
"DNS came about quite simply because using hostname resolution was getting
to be a severe burden. There was a "Master Host File" maintained at one
time, unfortunately it simply got too big and cumbersome."
CS-98.04.html -- Cert advisory
CS-98.05.html -- Cert advisory
TDS
Knight - May 09th 1999, 07:55 EST
Toplevel Domain Scanner is a tool for scanning through DNS records. It
allows you to plug scanned data into security software that checks your
networks for holes, or look for weaknesses in other networks.
| Download: | http://www.phunc.com/tools/tds/tds-0.02.tar.gz |
| Alternate Download: | ftp://ftp.phunc.com/pub/phunc/tools/tds-0.02.tar.gz |
| Homepage: | http://www.phunc.com/tools/tds/ |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
