- dns-wg - mailman.ripe.net

How to change hardware dns?Please lead us!
by chizari＠irost.com 02 Sep '02

02 Sep '02

Dear Sir/Madam IN Ripe NCC DNS WG Staff Hello,I hope you have fine time, We are one of your LIR and have two DNS server which work as primary & secondary.because of old hardware version of this server we deside to change primary server to new system without losing zonefiles which registred at dns manager and disconnecting of internet connection of our customer.we know that one way is create primary as a master and other system as slave and forward files to new system then converting new system to primary whith the same ip.but we intrest that is there new and easy way to transferring zone files from old system to new system?and if we have only master & slave configuration to rech the aim do you please lead us with step by step configutation to success prossessing.We deside change only system from nt 4. to new system with same IP address. Please advise us Thanks a lot The Best regards.

1 0

E-mail address masquerading for archived mail messages
by RIPE NCC WebMaster 16 Aug '02

16 Aug '02

Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "<somebody@localhost>". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

REMINDER DNSSEC, introduction to the concept and current state (fwd)
by Henk Uijterwaal (RIPE-NCC) 15 Aug '02

15 Aug '02

FYI. ---------- Forwarded message ---------- Date: Thu, 15 Aug 2002 12:13:19 +0200 From: RIPE NCC Training <training(a)ripe.net> To: local-ir(a)ripe.net Subject: REMINDER DNSSEC, introduction to the concept and current state * * * Reminder * * * DNSSEC, introduction to the concept and current state Date: Saturday 14 September 2002 Time: 0900 - 1700 Location: Rhodes, Greece AND Date: Tuesday 22 October 2002 Time: 0900 - 1700 Location: Sarajevo, Bosnia AND Date: Thursday 28 November 2002 Time: 0900 - 1700 Location: Paris, France AND Date: Thursday 12 December 2002 Time: 0900 - 1700 Location: Amsterdam, The Netherlands The Domain Name System (DNS) is one of the main parts of the Internet Infrastructure. DNS is trusted by many end-users to give correct results. At the moment, however, DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSEC is a set of extensions to provide end-to-end authenticity and integrity. This introduction will cover. - DNS security threats; - DNSSEC security mechanisms; + DNSSEC server protection; + DNSSEC data protection; - Delegation issues; - Key management issues; - Current developments; The DNSSEC introduction is intended for those who are familiar with common DNS terminology and are interested in learning about the concepts and mechanisms that DNSSEC offers. Our goal is to provide participants with sufficient background to be able to deploy DNSSEC in their own organization. Examples are based on the BIND name server. More information about the details of the DNSSEC Introduction can be found at: http://www.ripe.net/disi/ Kind regards, Sandra Gijzen RIPE NCC Training Co-Ordinator REGISTRATION ============ To register for these Courses, please complete the registration form below and reply to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add a value in the `box' area marked between the square brackets (i.e. "[" and "]" ). Alternatively, you can use the Training Course Request Form at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions about the DNSSEC Introduction, your registration form or the web page, please contact us at <training(a)ripe.net>. -------------------------- %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: New draft charter for the RIPE DNS WG
by Jim Reid 17 Jul '02

17 Jul '02

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: Brad> I think that we'll all agree that the DNS really needs Brad> to be seriously cleaned up, and if we don't do what we can Brad> to help spur that process along, then who will? This is fair comment. The trouble is how to improve things. There isn't a DNS police to enforce BCPs or whatever and throw persistent offenders in jail. Having a hall of shame for the people with the most badly broken setups is hardly likely to be productive either. And as Peter pointed out, the process for getting TLD delegations amended can be painful and slow, even when the TLD wants to make a change. Friendly persuasion and quiet words of advice from a Jon Postel would probably be effective. But who is there that has that stature and broad acceptance today?

1 0

draft-whois-srv-02.txt
by Gerhard Winkler 16 Jul '02

16 Jul '02

Hi, we have now changed our first version and have incorporated a lot of comments which were made during/after the last RIPE meeting. Please feel free to discuss and send any comments. We will try to move this paper forward. regards, Gerhard draft-whois-srv-02.txt Linus Corin Marcos Sanz Gerhard Winkler 1 July 2002 Using DNS SRV records to locate whois servers Status of this Memo This document is a draft on the usage of the DNS SRV RR for the location of whois servers. Abstract Whois servers are used to locate administrative, technical and security contacts for given IP addresses, domain names or other network objects associated with an organisation, e.g. AS numbers. While usually Top Level Domain (TLD) registries run a whois server, there is no generic name for it and it may not even be obvious that the TLD registry's whois server is the right one to ask, since there are TLDs where registration takes place under specialised second level domains (e.g. UK, AT). The Regional Internet Registries (RIR) also provide whois service as part of their coordination task. All this can be solved by central "master" or "meta" whois servers, which keep track of all new and changing servers and refer to the DNS registries' or RIRs' whois servers. This document proposes an approach which eliminates the need for a central master repository and works down to lower levels in the hierarchy. It is the intent to locate a whois server as close to the target (in terms of hierarchy) as possible, while preserving the opportunity to locate higher level servers for escalation purposes. This situation can be improved by using DNS SRV records and SRV-cognizant whois clients. This document deals with domain information only and it describes how DNS SRV records should be used but it does not define any search strategies (this will be discussed in a additional document). 0. Definitions The key words "MUST", "SHOULD", and "RECOMMENDED" in this document are to be interpreted as described in [RFC 2119]. Other terms used in this document are defined in the DNS specification, [RFC 1034]. 1. Format The general format of DNS SRV records is documented in RFC 2782: _Service._Proto.Name TTL Class SRV Priority Weight Port Target Therefore the simplest format of an SRV record to locate a whois server is: _nicname._tcp IN SRV 0 0 43 whois.nic.example. [IANA-NUM] foresees the possibility of a whois service over UDP. Common use is TCP but nothing would prevent from analogously setting the _Proto field to the value _udp. Nevertheless this document deals with the TCP case only. The symbolic name of the service is defined as "nicname" (case insensitive), because it is defined in [RFC 954] in this way; though the most familiar name is "whois". Priority and Weight have a value of 0 in the example above just for readability purposes. It is RECOMMENDED to use the port number 43, as specified in [IANA-NUM]. SRV-cognizant whois clients SHOULD interoperate with traditional whois servers which are in place right now. 2. Usage If there is a whois server running for a specific domain, such an SRV record can be defined. When used for looking up information about a domain, whois clients can do DNS lookups for SRV records, and can use the retrieved target information to point their whois queries accordingly. This kind of client is called "SRV-cognizant" or "SRV-aware" whois client. It is imaginable that this functionality could be extended for other purposes (like IP address space allocation or handle lookup), but this remains open for a future discussion. 3. Restrictions The service record functionality is meant as an extension to the existing whois service and not as a new service. In the absence of a whois protocol whose specification calls for the use of other weighting information, the field Weight in the SRV record keeps the standard meaning specified in [RFC 2782]. As defined in [RFC 2782] the client SHOULD abort if it finds a record defined like: _nicname._tcp IN SRV 0 0 0 . This means the SRV processing should be aborted at that level. But nothing avoids the client to search for other SRV records above or under that level. This behavior should be scope of search strategies. The given SRV record does not provide any information about the existance/absence of a service with the same name on subdomains or zones below or above. The search behavior of the client must be defined as it should be independant from conventional DNS search algorithms defined by searchlists. To avoid unnecessary load on the DNS root servers, a client MUST NOT ask for a whois server for the root domain, i.e. it MUST NOT issue queries for _nicname._tcp. 4. Authority There is no authority which defines who should run a whois server, though it is usual that the TLD registry runs a whois service for the zone where it is authoritative. There is no definition of which target should be used as a default for an SRV-cognizant whois client if no whois server could be discovered by means of SRV records. The use of a default whois server is local dependent. 5. Security Considerations The same security considerations as defined in [RFC 2782] should apply. There is no discussion on security, data protection and privacy relating to the contents of the whois server in this paper. This is the responsibility of the whois server operator and has nothing to do with a mechanism that describes how whois servers can be reached. A client developer must be aware that DNS search algorithms can lead to this problem: By using DNS query logging an organisation could find out who is issuing whois queries about them even without operating a whois server themselves. 6. References [RFC 954] NICNAME/WHOIS [RFC 1034] Domain names - concepts and facilities [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels [RFC 2782] A DNS RR for specifying the location of services (DNS SRV) [IANA-NUM] www.iana.org: Directory of General Assigned Numbers 7. Authors' Addresses Linus Corin Telia International Carrier 4th Floor, 330 High Holborn WC1V 7QY London, United Kingdom linus(a)telia.net Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt/Main, Germany sanz(a)denic.de Gerhard Winkler Vienna University Computer Center / NIC.AT Universitaetsstrasse 7 A-1100 Vienna, Austria gerhard.winkler(a)univie.ac.at -- Gerhard Winkler | E-Mail: gerhard.winkler(a)univie.ac.at Vienna University Computer Center | Universitaetsstrasse 7 | Tel: +43 1 4277 14035 A-1010 Vienna, Austria | Fax: +43 1 4277 9140

1 0

Re: Re: New draft charter for the RIPE DNS WG
by Marcos Sanz/Denic 15 Jul '02

15 Jul '02

On 12.07.2002 15:36 Brad Knowles <brad.knowles(a)skynet.be> wrote: > > > The aspect of topological diversity > > is approached by the ``shared secondary servers(?)'' project, which I think > > is led by DE-NIC under the umbrella of CENTR. So, should we try to learn > > more about these efforts? > > That would be something we should learn more about, and perhaps > provide any additional support or assistance that we can. The charter of the project can be found under http://www.centr.org/groups/sss-wg/ There is also a mailing list, which has been very quiet since its establishment (euphemism for no messages at all). Questions, suggestions and support to the project are really welcome. Regards, Marcos Sanz DENIC eG

1 0

New draft charter for the RIPE DNS WG
by Peter Koch 15 Jul '02

15 Jul '02

Dear DNS WG members, the working group charter posted at http://www.ripe.net/ripe/wg/dns/ is a bit out of date and no longer really accurate: The Domain Name System working group discusses current BIND versions. It is also concerned with potential pollution of the DNS and with domain name related issues. Jim and I have discussed this and we thought the charter should be adjusted to better reflect what the WG has been dealing with during the past couple of meetings and is going to do in the near future. Together with the meeting agendas this may help (new) participants to decide whether to attend and contribute ideas and questions. So, this is our suggestion for an updated charter: The Domain Name System (DNS) working group discusses current DNS related issues in technology and operations. It supports deployment of newly developed DNS and DNS related protocol components by collecting experience and documenting current practice and recommendations. It is therefore also a feedback channel to the IETF. The WG also discusses DNS software implementations, especially security and scalability aspects as well as performance and interoperability. It does not try to ``support'' all these software products. Bugs in specific products are only discussed if they affect critical infrastructure or interoperability at a large scale (differential analysis). The DNS WG works as a contact for the Registry and Registrar community, watching DNS quality. It discusses registration policies only to the extent technical questions are concerned (e.g. pre delegation checks & quality control). Please send comments to this list. -Peter

7 16

Re: New draft charter for the RIPE DNS WG
by Jim Reid 15 Jul '02

15 Jul '02

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: >> Jim and I have discussed this and we thought the charter should >> be adjusted to better reflect what the WG has been dealing with >> during the past couple of meetings and is going to do in the >> near future. Brad> I think that you've come up with a much better charter Brad> for this group. Thank you, though Peter deserves all the credit for coming up with the revised charter. Brad> Out of curiosity, do you think that the group should Brad> also help sponsor the development of open source tools to Brad> help monitor DNS-related issues, or evaluate DNS-related Brad> tools (either open source or commercial)? Yes, absolutely. These are clearly things that will be of interest to the WG membership and the DNS community as a whole. Do you feel there's nothing in the revised charter which addresses your points? If not, please suggest some text we could add or at least discuss. Your question of sponsorship is a good one. But there's a problem about how the term is defined. If you mean sponsor in the the sense of encourage or nurture, then I would say yes, that's definitely something the WG can and should do. If you mean hand over money, I'd have to uhm and ahh. The WG has no money or budget and I'd be pleasantly surprised if the members would be willing to put their hands in their pockets. Deciding how any money raised got spent would also present an administrative headache. These are not intractable problems. My view is that if the WG decided it did want to fund tool development or support, Peter and I would have to try and find a way of making that happen. Some guidance from the WG would be welcome: maybe this should be an agenda item for RIPE43? One thing I would ask people on this list to do is give more feedback and suggestions on what the WG should and should not do. Peter and I have outlined our ideas for the future of the WG and had little response so far. This is disappointing. I'm not sure if we should interpret the silence as approval for our ideas or if there's little interest in them from the WG membership.

3 6

Re: New draft charter for the RIPE DNS WG
by Jim Reid 11 Jul '02

11 Jul '02

>>>>> "Stephen" == Stephen Burley <stephenb(a)uk.uu.net> writes: Stephen> I would just like to remind all that the more RIPE/NCC Stephen> get diversified in their focus, the less gets done in the Stephen> areas that realy matter to us. I am not disagreeing with Stephen> the outline i just feel we need to evaluate how much of Stephen> what is discussed at the meetings is IP relavent. What you say is reasonable, but I think you are working from a false assumption. It's the job of the RIPE Working Groups to, well, work on the stuff that interests them. NCC staff might contribute to those efforts, presumably if this is OK with the NCC management and the stuff done for the WG doesn't affect their day-to-day workload in their real jobs. It certainly should not be assumed that RIPE NCC would stop doing the excellent job they do on the stuff that matters to all RIPE members, just to satisfy the whims of a WG. [I exaggerate for effect.] The WGs do not have any input to the policy and business decisions made by the RIPE NCC board and management. Unless WG members happen to be board members too, obviously... In my limited experience, RIPE NCC staff just provide the things that help to make the DNS WG happen: arranging venues, organising the meeting space, providing net connectivity, giving the odd presentation and so on. Speaking as one of the DNS WG chairs, I don't expect the RIPE NCC staff to do much more than that for the WG. Though if the likes of Olaf or Daniel volunteer tools and resources, I'd be delighted to accept their help just as I'd take contributions to the WG from whoever provided them. It's really up to the people who come to the WG and are active in the mailing list to make the Working Group work, not the NCC staff. Stephen> We can not complain at the NCC about high wait times on Stephen> requests if we the community are distracting the NCC with Stephen> none core function projects and fact finding. If you have any specific examples of this, you should take it up with the RIPE NCC Management and the WG Chairs who have created that extra load on the people at RIPE NCC. I would hope that if this has happened, the NCC staff would already have made that known to the NCC management.

1 0

Dear Sir
by nader 07 Jul '02

07 Jul '02

Hi , I have DNS Version 4 installed on NT4 machine , I have a problem that many sites did not open although when i changed to use another DNS IP's it worked very well , How can I make my dns work properly? Waiting for your reply Nader

1 0