- dns-wg - mailman.ripe.net

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

6to4 reverse delegation
by Andrei Robachevsky 29 Jan '04

29 Jan '04

Colleagues, This is just a heads-up that an Internet draft has been published by Geoff Huston (draft-huston-6to4-reverse-dns-00.txt). It describes a pragmatic solution for managing reverse delegation for 6to4 networks (2002::/16). The intent of circulating the proposed methodology for implementation of the service is to ensure that there is some level of peer review in order to provide some additional assurance that there is nothing critical that is missing from the proposed specification. Regards, Andrei Robachevsky RIPE NCC

1 0

Agenda Tuesday
by Jaap Akkerhuis 28 Jan '04

28 Jan '04

For all around at the current Ripe meeting. This is the current time plan for the two last slots for the dns-wg meetimng. jaap Second Slot: 29 January 09:00-10:30 News from CZ, Ing Tomas Marsalek [15 min] covers: new registry model enum idn. News from PL, Andrzej Bartosiewicz [20 min] covers: idn monitoring internal systems ISO 9001 certification archiving blessed by Polish Certification Office (www.DNS.pl/ENUM/ripe47_dns_pl.pdf) E. Oher news News from ISC, Joao Damas [ 20 min] covers: Bind roadmap OARC DNS SEC LC Workshop [Joao 10 min] F. Tools Fingerprint DNS-servers, Jakob Schlyter, Roy Arends [20 min] Third Slot: 29 January 11:00-12:30 NSD & DNSSEC, NLnetlabs, Erik Rozendaal [5 min] PowerDNS, Bert Hubert, [30 min] G. Experiences DNSSEC in .NL; preliminary results (Miek Gieben, NLnetlabs) [20 min] IDN Implementations in Europe, Kim Davies [40 minutes] H. To merge or not to merge (continued) Discussion about where we go from here with DN* I. AOB $Id: pagenda,v 1.3 2004/01/19 14:01:43 jaap Exp jaap $

1 0

DNS Related Policy and Procedure Proposals
by Olaf Kolkman 22 Jan '04

22 Jan '04

Dear Colleagues, Apologies for duplicate mails. Shortly after this mail we will be sending two separate mails to the DNS Working Group mailing list. We will also be posting a draft policy document (see below). These mails also have relevance to the RIPE NCC Services and Database Working Groups. The two messages and revised policy document are part of a project started in October 2003 to streamline and simplify the process of requesting and managing reverse DNS delegation for the holders of the address space allocated or assigned by the RIPE NCC. The original proposal can be found at: http://www.ripe.net/reverse/proposal.html The content of the mails are: - A proposal for the introduction of a new "mnt-domains:" attribute in INETNUM objects to authorise the creation of DOMAIN objects. This proposal also suggests making "mnt-by:" a mandatory DOMAIN object attribute. This authorisation mechanism will enable address space users to delegate the responsibility for maintaining reverse address space to third parties in a flexible manner. - An assessment of the consequences of the introduction of the "mnt-domains:" attribute and of the "mnt-by:" attribute being made mandatory. The reverse delegation policy has been revised, relaxing the terms under which reverse delegation will be serviced and providing the framework to implement the authorisation mechanism described above. The draft "Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region" can be found at: http://www.ripe.net/ripe/draft-documents/reverse-draft-200401.html We would like to invite your comments on this. Please discuss these proposals on the DNS Working Group mailing list. More information can be found at: http://www.ripe.net/reverse/rdns-project/ -- Olaf Kolkman New Projects Group RIPE NCC

3 2