- dns-wg - mailman.ripe.net

Ripe 46 Meeting
by alireza saleh 17 Jul '03

17 Jul '03

Dear Friends, I'm new in this mailing list, I'm technical person of IR cctld, We would like to start registration through resellers,I would like to know if there is a software available to perform the automatic registration. I'll be grateful if you would give me any idea about reselling , besides , I would like to register for ripe 46 meeting, and would like to know if any discussion about DNS will be held ? Kind regards Alireza.

6 9

Re: http://www.ripe.net/ripe/mail-archives/dns-wg/2003/msg00115.html
by Anne P. Mitchell, Esq. 14 Jul '03

14 Jul '03

> http://www.ripe.net/ripe/mail-archives/dns-wg/2003/msg00115.html > "Would you like a presentation from Habeas?" > === > > Not really... Heh. Ok, fair enough. I thought that the group might find something on building out an ISP-to-ISP DNSWL interesting. Regards, Anne Anne P. Mitchell, Esq. CEO Habeas, Inc.

2 1

EOF, Amsterdam, September - Call for Presentations
by Daniel Karrenberg 11 Jul '03

11 Jul '03

[apologies for duplicates, hint: they have the same message-id] Hi Network Operations Folk, the holiday period is starting! A good time to consider preparing a presentation at the European Operators Forum (EOF) to be held during the 46th RIPE meeting in Amsterdam on September 1st and 2nd. 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. For the EOF "Coordination Group". Daniel Karrenberg -------------------------------------------------------------------------- The EOF The European Operators Forum (EOF) exists for the exchange of Internet operations experience. It has evolved from the "information exchange" part of the early RIPE meetings to provide an open forum outside of the work programme of the working groups and the RIPE plenary. The EOF aims to attract presentations relevant to network operators, practical "hands-on" reports, outlines of future developments and small tutorials. Product marketing presentations are not appropriate, user experience reports are. The EOF programme is assembled by an informal coordination group that is always looking for new people who are able to help by attracting interesting presentations and supporting presenters. Contact: Daniel Karrenberg <daniel.karrenberg(a)ripe.net> Presenting at the EOF The EOF wants to attract practical hands-on experience reports. We aim to make turning interesting experience into a presentation as easy as possible. Consider the following: - presentations do not have to be long Something interesting can be said in as little as 10 minutes. This limits the time spent to prepare material and often is a good way to start for first-timers. - support is available We will do our best to support you in preparing your presentation. If you want, we can help structuring your material, help to polish language and arrange for a test-run of your presentation. We can also try to arrange for someone from the same country or region to support you if that is helpful. We can also help you find someone else to present your material in case you cannot make it to the meeting. In short: If you have something intersting to say, we will help you do it! Contact Daniel Karrenberg <daniel.karrenberg(a)ripe.net> for more information. - no product marketing presentations The EOF is *not* an appropriate forum for product marketing presentations. User experience reports which are presented by users are definitely relevant. In-depth technical presentations or tutorials are also possible. We expect to finalise the program in early August. 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." More information about the meeting can be found at http://www.ripe.net/ripe/meetings/ripe-46/index.html Should you have questions, please do not hesitate to contact me by e-mail at any time. During July and August my response time may be slightly longer than usual due to the holiday period. Thanks Daniel

2 1

Fw: Error in Document Ripe-192 (dns example)
by Fred 16 Jun '03

16 Jun '03

----- Original Message ----- From: Fred To: webmaster(a)ripe.net Sent: Saturday, June 14, 2003 9:18 AM Subject: Error in Document Ripe-192 (dns example) I set up a BIND-8 server per the example file, and found that the following creates errors: company.xy. SOA dns.company.xy. hostmaster.company.xy. ( 1998092900 ; Serial number 86400 ; Refresh 1 day 7200 ; Retry 2 hours 3600000 ; Expire 41.67 days 172800 ) ; Minimum TTL 2 days The closing bracket ")" should appear after the ; Minimum TTL 2 days. This error appears in several places in the document. Please forward this to the authors.

4 4

Call for items for the agenda, RIPE 46
by Patrik Fältström 06 Jun '03

06 Jun '03

I hereby call for items for the agenda for RIPE 46. Patrik, co-chair of DNS-wg, and responsible for next meeting

1 0

ANNOUNCEMENT DNSSec Training Courses
by RIPE NCC Training 03 Jun '03

03 Jun '03

Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the DNSSec Training Course. The main objective of the DNSSec Training Course is to provide LIRs with sufficient background to be able to deploy DNSSec in their own organisation as soon as the protocol is standardised. This course also explains the specific procedures set up by the RIPE NCC to to secure the in-addr.arpa zone. The Domain Name System (DNS) is one of the main parts of the Internet infrastructure. At the moment DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSec is a set of extensions to provide this end-to-end authenticity and integrity. It is currently being developed within the IETF dnsnext Working Group. The protocol is about to be finalised and the code implementing the protocol is available in alpha releases. The DNSSec course consists of two parts: an "Introduction to DNSSec" and a real life demonstration. The "Introduction to DNSSEC" will cover: - DNS security threats - DNSSec security mechanisms - DNSSec server protection - DNSSec data protection - Delegation issues - Key management issues - Current developments Examples are based on the BIND name server. Please note that DNSSec is an advanced course. It will: - NOT teach the basics of DNS. - NOT describe how to receive Internet resources from the RIPE NCC not describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network & system operators, engineers, etc. This course is not intended for administrative or management staff (e.g. Hostmasters). It is assumed that all attendees are familiar with common DNS terminology, have a practical knowledge in operating DNS servers and are interested in learning the concepts and mechanisms that DNSSec offers. The DNSSec course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the DNSSec Training Course can be found at: http://www.ripe.net/training/dnssec/ REGISTRATION: You can register for a course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> In order to register for a DNSSec Training Course you must be an employee of an LIR and either : - be an LIR contact - be confirmed by an LIR contact. LIR contacts are those employees of an LIR who are registered with the RIPE NCC as authoritative contact persons. It is expected that most of those interested in the DNSSec Training Course will not be an authorative contact persons for their LIR, and therefore will be refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team COURSE DATES AND VENUES ======================= Date: Friday 4 July 2003 Time: 0900 - 1700 Location: Glasgow,United Kingdom AND: Date: Friday 18 July 2003 Time: 0900 - 1700 Location: Vienna, Austria AND: Date: Monday 18 August 2003 Time: 0900 - 1700 Location: Dubai, United Arab Emirates AND: Date: Friday 19 September 2003 Time: 0930-17:00 Location: Amsterdam, The Netherlands REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

Re: [dns-wg] Progress with DNS Quality, Also: Lameness
by Jim Reid 27 May '03

27 May '03

>>>>> "john" == john brown <dns-wg(a)chagres.net> writes: john> We have been developing such a tool. Currently it has about john> 40 million zones loaded in a SQL database. john> Today the tool lets you type in ripe.net john> it returns the list of NS's that end with ripe.net and a john> count of the zones in the DB for each NS. john> You can then get a list of zones, or do a LAME check. john> You can also create a list thats the DIFF between two john> different NS"s. This sounds like ideal material for a presentation at RIPE46. :-)

1 0

Re: [dns-wg] lameness and unreachability
by Jim Reid 25 May '03

25 May '03

>>>>> "Ed" == Edward Lewis <edlewis(a)arin.net> writes: >> W ICMP answer Ed> I don't know that this is a concern of DNS - what the other Ed> protocols can or can't do. Indeed. In fact checking for ICMP responses may give false positives. It's likely some good name servers will be behind firewalls or routers that don't allow ICMP through. >> W nameserver addresses are all on the same subnet (RFC2182) Ed> The problem with this test is the rise of anycast. It's Ed> harder to determine remotely if servers are all on the same Ed> subnet. True, but it's easy to accommodate the relatively small number of anycast servers and operators. >> W delegated domain is not an openrelay >> W domain of the hostmaster email is not an openrelay Ed> That's beyond DNS. A real concern, but if I just want to test Ed> DNS, then I don't want to do those tests. I agree. Checking and suppressing open relays is a Noble Thing. But it's orthogonal to whether some domain has been set up correctly on decent DNS infrastructure.

3 3

Re: [dns-wg] Progress with DNS Quality, Also: Lameness
by Jim Reid 25 May '03

25 May '03

>>>>> "Daniel" == Daniel Karrenberg <daniel.karrenberg(a)ripe.net> writes: Daniel> How about your friendly RIR providing an extra service of Daniel> checking your reverse DNS tree for a small additional fee Daniel> that covers the people resources needed to get the reports Daniel> to you and follow up on them. I agree that someone could/should offer a service selling police reports. And related stuff such as audits and logs: "Yes, your name servers were working just fine between 14:40 and 16:00 on June 1st 2002". However I am very uncomfortable with an RIR providing this kind of service, even though they're more likely to be respected as protocol police. There are a number of reasons for this. First of all I'm not sure if services like this fall within the remit of what an RIR is supposed to do. Secondly an RIR is a monopoly and should be *very* careful about extending into new service areas. The likes of the EU anti-competition folks could get very excited about that. Thirdly, this the kind of service that could be offered by others: ISPs, registrars, DNS consulting companies and so on. Many of them will already be paying fees to the RIR. An RIR shouldn't be competing with its customers -- why bite the hand that feeds it? -- or distorting the market. Fourthly, if an RIR diversifies into offering these peripheral services, there is a danger that it will lose sight of its core registry function. I do like the idea of RIRs having top-up charging for additional services. This is a good way to make those services self-financing and be seen to not be a drain on the RIR's core funding. And if that keeps the annual fees down, even better. However this is a discussion that should be going on somewhere else: the new NCC services WG perhaps? Finding out who'd be willing to pay for lameness checks would be worthwhile. However I suspect it won't tell us anything we don't already know. Clueful people might pay. But in general they don't have lame servers. The clueless won't pay because they don't know or care about lameness. They'll be the ones that have the lame delegations. The challenge will always be how to reach out to these people. There's an education problem here. I think the WG could come up with a definition of lameness and a business justification why it's a bad thing. It would be great if registrars & registries could pick this up, point their customers at checking tools and persuade them to regularly use those tools. This is do-able IMO.

2 1

Re: [dns-wg] lameness and unreachability
by Jim Reid 24 May '03

24 May '03

>>>>> "Ed" == Edward Lewis <edlewis(a)arin.net> writes: Ed> Peter mentioned that there is a RIPE document behind this. I Ed> wasn't aware of that. (As an aside, there was a short post Ed> meeting discussion about where would we publish operations Ed> documents - as in within what venue?) The same place as all other RIPE documents? Or am I missing something? To my mind, the DNS WG should produce this document and publish it in the usual way. Though if somewhere like NANOG or IETF would be more appropriate, that's fine by me.

1 0