- dns-wg - mailman.ripe.net

K-root mirror instance deployed in Athens
by Dave Knight 27 Apr '04

27 Apr '04

Dear Colleagues, The RIPE NCC is pleased to announce the deployment of a new mirror instance of the K-root Internet root name server in Athens, Greece on April 26 2004. This node has been sponsored by the Greek Research and Technology Network (GRNET) and is located at the Athens Internet Exchange. The announcement can be found at: http://www.ripe.net/ripencc/kroot-athens-20040427.html Kind regards, Dave Knight RIPE NCC

1 0

New Policy and Procedures for Reverse DNS Requests
by Olaf Kolkman 26 Apr '04

26 Apr '04

Dear Colleagues, (Apologies for duplicate messages) The RIPE NCC has implemented a number of changes in the policy and procedures for requesting reverse delegation. This follows the effort to streamline reverse DNS operations [1] and make it easier for network administrators to manipulate related DOMAIN objects. You should be aware of the following changes: When users want to update their reverse DNS information, they send an e-mail to <auto-dbm(a)ripe.net> (formerly this mail was sent to <auto-inaddr(a)ripe.net>). The database update program will verify the DNS information and update the RIPE Database. The information will appear in the DNS after a short delay. The policy constraints have been reduced. Previously only space assigned to End Users could be reverse delegated in DNS. This caused administrative burden to LIRs, as every time space was assigned, reverse DNS had to be set up for that space. Now reverse DNS can be set up for an entire allocation. Documentation that details the new setup and authorisation can be found at: http://www.ripe.net/reverse/ More details on these developments is provided below. * The reverse DNS policy as proposed in [3] is published as ripe-xxx. The main change to the policy is the removal of the requirement for valid assignments. Reverse delegations can also be requested by non LIRs if an appropriate "mnt-domains:" attribute is in place in the corresponding INETNUM/INET6NUM object, when submitting requests to <auto-dbm(a)ripe.net>. * The <auto-inaddr(a)ripe.net> interface will be deprecated as of 1 July 2004. To allow for a graceful transition, the "mnt-domains:" based authorisation mechanism has not been implemented for the <auto-inaddr(a)ripe.net> interface. This will continue to use reg ID based authorisation. The "mnt-by:" attribute will become mandatory. However, the existence of the "mnt-by:" attribute in DOMAIN objects is not enforced when the object is submitted through the <auto-inaddr(a)ripe.net> interface. Please contact <inaddr(a)ripe.net> if you have further questions. Olaf Kolkman New Projects, RIPE NCC Can Bican Software Engineering Dept., RIPE NCC ---------------------------------------------------------------------- References: [1] Original RDNS Project Proposal http://www.ripe.net/reverse/proposal.html [2] "mnt-domains:" Attribute Proposal http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00007.html [3] Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region http://www.ripe.net/ripe/docs/rev-del.html [4] Webupdates http://www.ripe.net/perl/webupdates.pl [5] http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00008.html

1 0

draft for revised DNS wg charter
by Peter Koch 15 Apr '04

15 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Dear DNS wg members, during the last couple of meetings we have exercised the merger of the former DNR Forum and the DNS working group. It seemed that both audiences had significant overlap and obviously have been interested in each other's work and topics. So, at the end of the last meeting slot at RIPE 47 the people in the room were in favour of combining the efforts into a single working group covering all issues around the DNS and domain names. The dns wg's charter as it currently is documented on the wg's homepage http://www.ripe.net/ripe/wg/dns/ is too narrowly focused anyway, so the chairs would like to suggest the following text as a basis for discussion for our new working group charter: The DNS Working Group discusses current DNS related issues in technology and operations. The WG supports deployment of DNS and DNS-related protocol components by collecting experience and documenting current practice and recommendations. It therefore provides a mechanism for exchanging practical and operational experience with organisations like CENTR and the IETF. The WG discusses DNS software implementations, especially security and scalability aspects as well as performance and interoperability considerations. DNS quality and other factors that may affect the stability of the DNS system are also discussed by the WG. The DNS WG provides a forum for the Registry and Registrar community. It discusses the technical and operational issues arising from registration policies with a specific focus on the deployment of new and emerging features. The charter is intended to reflect what the WG has been doing during the last couple of RIPE meetings. Please send in feedback! You are invited to comment and/or suggest changes and if you're just happy with it - please say so, too. Given that a holiday season is approaching for many of us, the comment period will *end* at 2004-04-19. - -Peter -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: ascii iQCVAgUBQGxfABePjvYGi6TZAQG8pwQAlD+Q7rAxgPzmRAcQZg38RsGHB7dZxcm4 khPrBFWgI7zsqwreCJSjBYnAXANBio4j63YjdGad8ZmopT0MtC94FY1mrx47Yqs2 dn7L58/uFFiYufEQJ8c62bIViltOMKvxsqOngWOYbCyr0Dmaqs3f5ccY4lcAMRap bduAwQID4uw= =MART -----END PGP SIGNATURE-----

1 1

Change in Reverse Zone File Generation
by Olaf M. Kolkman 06 Apr '04

06 Apr '04

Dear Colleagues, Apologies for any duplicate messages. This message about our zone file generation process is for your information, there is no action required on your part. We have completed the cleanup of a number of DOMAIN objects in the Whois Database and NS Resource Records in the DNS files [1, 2 and 3]. We have verified that data within zone files generated from the Whois Database matches the data currently in our zone files. We will start generating our zone files from the Whois Database on Tuesday 13 April 2004. >From a DNS point of view this change will be transparent. DNS delegations will not change and there will be no interruptions in DNS service. The change in the method of zone generation allows us to migrate to a new interface for submission of reverse delegation requests. We plan to have the new interface available by the end of April, an announcement to the <dns-wg(a)ripe.net> and <ncc-services-wg(a)ripe.net> mailing lists will be sent. We hope we have informed you sufficiently, do not hesitate to contact us if you have further questions. --Olaf Kolkman New Projects, RIPE NCC References: [1] Original RDNS Project Proposal http://www.ripe.net/reverse/proposal.html [2] Cleanup Proposal http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html [3] RDNS Project Page: http://www.ripe.net/reverse/rdns-project/

1 0

EOF, Amsterdam, May - Call for Presentations
by Daniel Karrenberg 25 Mar '04

25 Mar '04

[apologies for duplicates, hint: they have the same message-id] Hi Network Operations Folk, NOW is the time to consider making a presentation at the European Operators Forum (EOF) to be held during the 48th RIPE meeting in Amsterdam on Monday 3rd and Tuesday 4th of May 2004. We would like to have as many practical, hands-on presentations as possible this time. Remember: They do not have to be long. We prefer an stand-up interesting 10 minute presentation over a well prepared 90 minutes explanation of something not so interesting to operators. Find some information about presenting below and think about all those experiences this year that might be interesting to other operators. Should you have questions, please do not hesitate to contact me by e-mail at any time. Thanks Daniel -------------------------------------------------------------------------- Information about the EOF and presenting there: http://www.ripe.net/ripe/meetings/ripe-48/eof.html Information about the meeting in general: http://www.ripe.net/ripe/meetings/ripe-48/index.html -------------------------------------------------------------------------- Guidelines for submitting abstracts: We expect to finalise the program in shortly. We will get back to you then with scheduling details. In the meantime please provide the information below. We place special emphasis on the abstract which should contain references to related material already available if possible. Please send this to eof-coord at-sign ripe.net. - Author(s) - Speaker - (Working) Title - Abstract - Draft Presentation (if available) - Relation to other known work and/or presentations if known - Time Requested It would be helpful if the abstract was written such that potential attenders will learn what to expect from the presentation, i.e. "The presentation will describe our experiences with the Red Packet Washer (http://www.netdet.net/RPW/). We have been using the device for half a year now. It helps us deliver more hygienic datagrams to our customers and peers. We will discuss problems with packet discolouring as well as increased throughput to our upstreams due to decreased clogging by dirty micrograms. We will compare performance with the hand-scrubbing of packets which we used previously. Currently we are optimising device management and getting bugs resolved. We will strive to include the latest experiences in our report." is much better than "The presentation will describe the Red Packet Washer made by Network Detergents."

1 0

Agenda Items for RIPE48
by Jim Reid 22 Mar '04

22 Mar '04

Contributions and suggestions for the DNS WG Agenda at RIPE48 are now invited. Please let dns-wg-chair(a)ripe.net know if you have a presentation or topic for discussion at the WG. It will help the planning if you do this sooner rather than later. Last time, a couple of interesting items were suggested after the Agenda had been finalised. Sigh. The closing date for input to the Agenda is likely to be around April 16th: two weeks before RIPE48.

1 0

DNS registrant details...
by reaction＠optionalreaction.net 11 Mar '04

11 Mar '04

Hello, This is my first post to this mailing list. When a person or persons register a domain name, a clear distinction should be made to exclusively identify a difference between input of credit card details and input of domain name registrant details. There are some large companies that 'automatically' use the entered credit card details, as the address of the registrant a domain name. This, as is true in my case, depending on the content of the domain names associated website(s), may lead to someone having to physical location because _they were not aware that domain registrant address details had been taken from their credit card details_. Regards, optionalreaction.net (webmaster)

3 2

FYI: Cleanup of domain objects.
by Olaf M. Kolkman 04 Mar '04

04 Mar '04

Dear Colleagues, Excuxes for the duplicate messages. During the third week of March we will perform the cleanup as described in section B of the "Domain Cleanup Proposal"[1]. Users affected by this cleanup were contacted during the first week of January 2004[2]. Once the domain object cleanup has been finished, the RIPE NCC provisioning system will be migrated to generate reverse zones from the whois database. We will proceed with that around the last week of March 2004. This change should be transparent. A small notification will be sent to the dns-wg mailing list. The next step of the RDNS project [3] will be the introduction of the "mnt-domain:" attribute. More information about this introduction will be sent to the ncc-services-wg and dns-wg mailing lists by the end of March 2004. Please reply to me in private or to the <dns-wg(a)ripe.net> mailing list if you have any questions or comments. --Olaf Kolkman New Projects RIPE NCC [1] http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html [2] The set of people contacted was larger than the set of people actually affected by the cleanup see http://www.ripe.net/ripe/mail-archives/db-wg/2004/msg00086.html for details. [3] http://www.ripe.net/reverse/rdns-project/

1 0

Drafts minutes DN* WG, RIPE 47 etc.
by Jaap Akkerhuis 19 Feb '04

19 Feb '04

Gentlefolks, Below you'll find the Draft minutes of our meetings at RIPE-47. They have been reviewed by the chairs already. Please send your comments to the list or directly to the list. Thanks to our scribes, Timur Bakeyev and Arno Meulenkamp (in alphpabetical order of last name) and the webmaster(a)ripe.net whois is Bcc'd on this so he/she can place the minutes on the ripe web site. Note that there is also an action item to work on: Formulate a charter/workingplan for the new combined group. I will try to make a rough proposal, although I wouldn't mind if somebody else would do that instead. I don't know who put the charter up at http://www.ripe.net/ripe/wg/dns/index.html and assume it is only a placeholder for the real one to come. Does anybody has an old version of the charter of as well as the DNR forum and the DNS-wg oldstyle lying around? These might be a good start for a new charter. Anyway, enjoy, jaap ---- DRAFT minutes, cut here ------ RIPE 47 Meeting DNS Working Group and DNR Forum Agenda Date: Tuesday 27 January 2004 Time: 16.00 - 17.30 Location: Grand Ballroom A. Administrative matters: - Scribe: Arno Meulenkamp - Blue sheets - Agenda bashing Jaap: (1) The talk about WSIS will be drop, because it is also on the agenda of the Plenray; will be replaced by a report over the "Last Call Workshop at Ripe NCC" about DNSSEC (2) The talk about the SSAC DNSS document will not be seperate agenda item, but will be covered during the "News from ICANN" item (3) Jakob Schlyter couldn't come. - Minutes Ripe 46 (http://www.ripe.net/ripe/wg/dns/r46-minutes.html) B. To merge or not to merge Heads up for discussion at end of Agenda (Chairs). Not a lot of discussion on the mailing list, so no decision can be made currently, discussion needs to be continued. C. Status reports Centr Report (Kim Davies) [5-10 minutes] Kim Davies presented the report. Daniel Karrenberg: Freedom of information? Kim: Perhaps I should have said data protection laws provreg (Jaap [1 min]) Jaap Akkerhuis: We were waiting on the IANA XML registry. This is just recentky established, the XML RFC is published. So now the rfc-editor can continue dnsext Suzanne Woolf dnsop Suzanne Woolf Suzanne Woolf presented an overview of what happened recently in the WGs enum Patrick Faltstrom Patrick Faltstrom: the RFC has been approved, the RFC editor will look at it, it is in the queue right now Jaap: 3 documents? Patrick Faltstrom: Yes, 3 documents Jim Reid: what's the estimate before the RFC editor will look at it? Patrick Faltstrom: hard to say, we are #5 on the list. Could be up to 3 months from now. sshfp Jakob Schlyter Jakob couldn't make it crisp Lesley/Anthony [By proxy, 5 min, Jaap] They also couldn't make it, but they did send slides, which Jaap presented. ICANN/IANA news [10 min] presented by Doug Barton No slides. DNS Infrastructure Recommendation Of the Security and Stability Advisory Committee. ICANN report, which can be found here: http://icann.org/committees/security/dns-recommendation-01nov03.htm AAAA records in the root, Daniel Karrenberg There was some research to see what happens with more glue in the root, this to accomodate IPv6 addresses in the zone file. There might be a technical problem. Doug: There are concerns over changing the root zone. We're trying to work with all parties involved. Jim Reid: is there look into what might happen when AAAA records are added, because IPv6 traffic might cause other operational things Doug: this is looked at. Iljitsch van Beinum: This is looked at for tld's and root zone? Daniel: yes Daniel: what is the timeline? Doug: the RSAC recommendation (see link) needs to be formally presented to the ICANN board. And it also needs to be published publicly and we need to see what the feedback is. Suzanne Woolf: is the IANA looking at how the technical recommendation would be operationally implemented? Doug: yes, when we present the plan officially, we also want to add a recommendation. D. Registrar/Registry News News from RIPE NCC Update on dnsmon: Going beta [5 min], Daniel Karrenberg It is now Beta, still on development machines, documentation is much improved, soon completely ready. Changes in RDNS [25 min], Olaf Kolkman (or replacement) Olaf presented the project. Andre: does the mnt-domains in inetnum override the mnt-by in the domain object? Olaf: no, it only controls the creation of the object, the mnt-by in the domain object then takes care of protecting the object. Peter Koch: you said this will not save the lameness problem,why not, what are you going to do? Olaf: it is quite different thing, we're not trying to solve too many problems at the same time. We check when delegations are created, that will not change. Lameness might come later. Peter: Old domain objects could be fed through the system, do you have any number of lame delegations or other DNS problems? Olaf: not currently Jim Reid: with regard to lameness, the working group should look at this and maybe make a definition of lameness after which we can map the situation (with the help of the RIPE NCC, perhaps) Jim Reid: as chair: does this working group approve of this project, do we think we need to say something about this (as it is internal housekeeping to some extent)? Jaap Akkerhuis: time flies. Let's postpone the other registry points to the other slots. Date: Thursday 29 January 2004 Time: 09.00 - 12.30 Location: St. Johns II Chair: Jaap Akkerhuis, Jim Reid Scribe: Timur Bakeyev, RIPE NCC Thanks to our scribe. Introduction. Short description of the Tuesday session. Scribe is presented to the public. News from CZ, Ing Tomas Marsalek [15 min] covers: new registry model enum idn file:DNS/cznic.ppt A nice story about cybersquatter who claimed 10.000$ for the domain from one of the bank groups but was sued and charged for half of this sum :> No questions were asked. News from PL, Andrzej Bartosiewicz [20 min] covers: idn monitoring internal systems ISO 9001 certification archiving blessed by Polish Certification Office file:DNS/RIPE47_DNS_PL.ppt Due to the shortage of time the introduction slides were skipped. Andrzej described the process of deployment of IDN for .pl domain. The policy is: First come - first served. In first few days a peak of the interest to the IDN was noticed(1600 registrations), now the average number of new domains registrations is around 20 per week. EPP for ENUM part of the presentation was skipped; it was already presented during the enum BOF. The overview of the process of monitoring DNS servers and services was done by Slawomir Gruca. In the past they had several conflicts, then the customer claimed, that the given domain wasn't accessible at certain date/time. Since then they start to use zone signing service via SigNet.pl as a proof that domain zone did exist in the particular time in this state. Q: In the slides it's mentioned, that the 'crucial domain list' is used to monitor the possible harmful changes to the DNS. Who did compile this list? A: This is the list of the most popular domains, which was provided by the 3-d parity. It's assumed that domains from that list are the best target for frauge. The changes in nameservers layout of these domains are also verified by a human. Q: Do you provide monitoring from the end user point? A: That's in the plans of the company. Q(Bruce): What is actually tracked for the domains from the 'crucial list'? A: List is monitored by script, which checks changes in the name servers structure and delegation information. E. Other news News from ISC, Joao Damas [20 min] covers: Bind road map OARG file:DNS/dns-wg-ripe47.ppt ISC is dead! Long life ISC! ISC had changed their name from Internet Software Consortium to the Internet System Consortium. New incidental respond group is created - Operations, Analysis and Research Center(OARC). http://oarc.isc.org. F-root server in Paris, Moscow, Dubai, Beijing, Taipei, Singapore. New Bind forum(and DHCP in future). Bind will remain free! Two parallel versions were released - Bind 8.4.4 and Bind 9.2.3. Bind8 is in a maintainace phase - only security fixes. Focus is on Bind9 and improving it's performance and support of DNSSEC. Q: It is said, that F-root server in Paris is IPv6 enabled. Is this information publically available and how to get it? A: You need to ask sysadmins of their provider. Q: Is this some kind of a secret then? A: No, it just means that this setup is still considered under trial and still in development. Q: Whom should I contact then? A: Tiscali.fr. Q(humorous): Can you, please, stop releasing Bind8? Version 9 is so cool and existence of the persistently updating Bind8 keeps people from switching to version 9. A: For Bind8 only bug fixes are done. All new features are added to the Bind9. Comment(Daniel): Bind8 is buggy, that's the reason for so often releases. Also, it still outperforms Bind9. Comment(Joao): One nice feature Bind9 has - an automated update of the hints file(with the list of root servers). With the upcoming change of the IP of the B-root server tomorrow(30 Jan 2003) it makes it very neat feature(Bind8 users need eventually to download a new version of hint file by themselves). Q: Regarding IPv6 support. http://www.root-servers.org/ lists the IPv6 addresses of some of the root servers. Would it be possible to ship hints file which will include IPv6 addresses of these servers as well? A: Speaking about web page - it's a good idea. Hints file... Well, we'll see :) Comment: B-root would be available on the old address for quite reasonable amount of time(2 years). Q: For Bind8 users - the change of the B-root IP address isn't an emergency? A: Completely not, but eventually this file should be replaced. DNSSEC workshop, Joao Damas [20 min] file:DNS/lcws.ppt The workshop was done in cooperation with NLnet Labs and RIPE NCC. The goal was to check interoperability of two implementations of the DNSSEC - one is in the beta version of Bind9.4 and another in NSD2.0. The results of workshop did prove, that this two versions can interoperate, but also a lot of updates and remarks were done to the DNSSEC draft and send back to IETF. Q: How long will it take before thre is a standard? A: Workshop helped a lot to spot the issues in the current draft of the standard. It will take a while, before all of them will be fixed in the document. At minimum, 2 more months... F. Tools Fingerprint DNS-servers, Roy Arends [20 min] file:DNS/Fingerprinting DNS.ppt The goal of survey was troubleshooting, statistic information on distribution of different version of DNS software. Different versions of different name servers were run in the test environment to collect an authentic fingerprint of them. Still looking for pre BSD4.3-tahoe bind implementation. Comment(Daniel): We have contacts with people who are still own necessary hardware and software. Still, no available CISCO DNS implementation(?) Olaf's DNS calculator was mentioned as on of the amazing examples of Perl based DNS servers. Survey also helped in spotting bug in the QR bit handling of one of the DNS server implementations, which could lead to the DoS attack. Fixed! Software is available at: http://www.rfc.se/fpdns/ Note from the audience: PowerDNS is mentioned twice on the slide! Q(Jim Reid): What is the distribution of the DNS software according to the survey? A: Out of 50.000 queried servers nearly half do run Bind9, a quarter - Bind8 and most of the rest are Windows DNS. But if to count by number of zones, supported by server, then Bind8 is the winer :() NSD & DNSSEC, NLnetlabs, Erik Rozendaal [5 min] file:DNS/erik-rozendaal.tar.gz Short introduction to NDS - simple, high performing name server for authoritative zones. Q(Joao): What kind of traffic is shown on the graphs? Does it reflect real life scenario, when unreplied(dropped) queries actually create additional queries, coming from the client side, artificially increasing load? A: Have no idea... PowerDNS, Bert Hubert [30 min] file:DNS/powerdns.pdf Written in C++, multithreaded DNS server. Multiple backends. No DJB-isms :)) Had a 0x1FFFFFFF bug in the code :) Q: Is TSIG supported? A: I have it in my plans. G. Experiences DNSSEC in .NL; preliminary results (Miek Gieben, NLnetlabs) [20 min] file:DNS/miek.tgz Q: What does phrase in the slides 'automated key compromise' actually mean :)? A: The zone dropped immediately. IDN Implementations in Europe, Kim Davies [40 minutes] file:DNS/ripe47-dn-idneurope.pdf Q: End user problem: How can I type in Chinese, let's say domain name? A: Have no idea, the main application for IDN is local usage within this language speaking country/community. Q: Any plans for having IDN for TLDs? A: Not yet. Q: What browsers are already support IDN out of the box? A: Two are known at the moment - Mozilla and Opera. H. To merge or not to merge (continued) 5 minutes past the lunch break. Jim shouts: Shall we merge or not? Audience screams: YES! Everyone runs for the lunch :) Action Item: Charter for the new group. $Id: minutes,v 1.2 2004/02/19 20:31:07 jaap Exp jaap $

1 0

Fingerprinting DNS implementations.
by Roy Arends 10 Feb '04

10 Feb '04

Hi, Jakob and I spent the past few weeks hacking up a DNS implementation fingerprint tool (where implementation == anything responding to a query). This mail introduces the methodology of fingerprinting DNS implementations. A nameserver basically responds to a query. Inter-operability is an obvious requirement here, the standard protocol behaviour of different DNS implementations is expected to be the same. Protocol behaviour of a DNS implementation is widely documented in the case of a 'common' query. The DNS protocol is over 20 years old and since its inception, there have been over 40 independant DNS implementations, while some implementations have over 20 versions. The methodology used to identify individual nameserver implementations is based on "borderline" protocol behaviour. The DNS protocol offers a multitude of message bits, response types, opcodes, classes, query types and label types in a fashion that makes some mutually exclusive while some are not used in a query messages at all. Not every implementation offers the full set of features the DNS protocol set currently has. Some implementations offer features outside the protocol set, and there are implementations that do not comform to standards. Also, new features added to - or bugs removed allow for differentiations between versions of an implementation. Methodology We use a serie of "borderline" query-response messages to identify implementations. A serie of query-response messages form a sequence. We call the interpretation of these series to form a conclusion "DNS sequencing". As mentioned, responses to a "borderline" query is used in this method. To be somewhat efficient, a tree can be constructed which consists of queries (nodes) and responses (branches), where the leave nodes identify the implementation. Every path, from the root node (initial query) to a leave node (final query) is essentially a "strain". The strains are used to distinguish between, and as said, ultimatly identify implementations. Parallel to this technique it is possible to identify some brands and their versions by doing a specific query asking for the servers' version. This technique does not satisfy our requirement since this has not been implemented in all brands of nameservers (it is not part of any standard), operators may have obscured the information and there are implementations that try to resolve the query, essentially asking root-servers from a different class for their version. Implementation. Our current software is written as a proof-of-concept. In field tests, false positives were encountered when trying to identify a set of servers residing behind a load-balancing apparatus where the servers itself are of different implementations, or when a specific implementation behaves like a forwarder. We are actively looking for implementations not yet identified by this tool to complement the set of strains. The current set of strains identify the following implementations and their versions: ATLAS BIND 4 BIND 4.8 -- 4.8.3 BIND 4.9.3 -- 4.9.11 BIND 8 BIND 8.1 -- 8.2.1T4B BIND 8.2.1 BIND 8.2.2P3 -- 8.4.1 BIND 8.4.1P1 BIND 9 BIND 9.0.0b5 -- 9.0.1 BIND 9.1.0 -- 9.1.3 BIND 9.2.0a1 -- 9.2.0rc3 BIND 9.2.0rc4 -- 9.2.2P3 BIND 9.2.3rc1 -- 9.4.0a0 eNom DNS Incognito DNS Commander MARADNS Microsoft Windows Server 2003 Server 2000 Server NT4 MyDNS Nominum ANS Nominum CNS NonSequitur DNS NSD Oak DNS Pliant DNS Server Posadis PowerDNS 2.8 -- 2.9.3 2.9.4 -- 2.9.11 QuickDNS Simple DNS plus TinyDNS UltraDNS We are actively looking for volunteers who allow us to identify their running code in some form or configuration of some version of: chives custom-dns dents dnrd dnsmasq gnudip-www ibmdns jeeves lbdns lbnamed ldapdns MacDNS Microsoft Windows Server NT3.51 pdnsd Stanford::DNSserver yaku-ns and/or All other unidentified, unmentioned original code. Thanks, Roy Arends Jakob Schlyter

1 1