- dns-wg - mailman.ripe.net

minutes for RIPE36 meeting
by Ruediger Volk, Deutsche Telekom - NI 1632 14 Sep '00

14 Sep '00

Dear working group members, I apologize for sitting a bit too long on Vesna's draft minutes for the Budapest session. Vesna did a really good job; please find the draft below. I'll wait for comments until Sept. 30th. So the draft is expected to become final on October 1st. I'm sorry that some problems in my day job escalated yesterday evening in ways so that today in the early morning it turned out that there would be no way to make the planned trip to Amsterdam safely and in time. (There is a down side to having the conference locally - or "within short driving distance":-( I hope those attending the current meeting do have a good time; looking forward to see you again at future meetings. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv(a)NIC.DTAG.DE Phone: +49 251 7985 200 fax: +49 251 7985 109 DNS Working Group RIPE #36, Budapest 18 May 2000 Chair: Rudiger Volk Scribe: Vesna Manojlovic Agenda: 0. Agenda bashing 1. David Conrad, ISC: BIND 9 2. Bill Manning: Preparing for DNS evolution -=- coffee break -=- 3. Report from CENTR DNSSEC workshop 4. IETF - Randy Bush 5. AOB 5.1. Fernando - Document about re-delegation 5.2. RIPE documents published since the previous meeting 1. David Conrad gave quick update of current status of BIND BIND9 * complete rewrite of code * includes support for everything - full IPv6 support - DNSSEC support - not supporting EDNS1 - multi-lingual support - MS interoperablity * RFC compliant (first time, cheers from the audience :) - first time it has lots of documentation :) * 1.2 mil $ to develop * release - 30.6. * availability now - beta David was asking the audience for help : - to support INN (BIND and DHCP are supported by Nominum) - from people with NT experience to debug NT port of BIND 8.2.3 - to test BIND9 - performance - IPv6 support in BIND 9 - DNSSEC 2. Bill Manning -- Wither DNS? PPT presentation available on http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ Current assumptions: - constant MTU - ASCII - BIND (UNIX based) - single authority (server) - hierarchy - zone management - static behaviour (client) - merged server and resolver - reachability: reliable network (up, end-to-end) On the horizon: DNSsec IPv6 dynamic DNS integration with other applications - database back-end (LDAP,Oracle,mail) I18N (internationalisation) DNS version diffusion survey Q&A session: Q: how is this taken? A: exhaustive search of inaddr tree. Q: is it biased? A (audience): it is security biased! they are not responding if they are security conscious => shows higher % of vulnerable Q: how big is the percentage of the servers that are blocked by firewall and therefore not included? A: few years ago - 20%. recently - 25% Conclusion: people are moving into new code but not (as) fast (as ... ) Discussion about IPv6 inverse tree Randy Bush: Is IPv6 inaddr tree going to be set-up separately? (rfc 2826) Bill: That is the suggestion (to use separate set of root nameservers) Randy: That would cause technical and other problems. Other possibility is to take one of existing root servers. -= coffee break =- 3. Report from DNSSEC workshop Workshop was initiated by CENTR, held in NLnet labs in Amsterdam. One report was already done by Jaap Akkerhuis in CENTR DNR-wg; technical report - here. The goal was to check resources needed for introducing DNSSEC on the level of TLD zones. Result of the previous previous attempts was: it is still hard work, not feasible at this time. This new workshop gave different results. In Europe, .de tld zone is chosen as the worst case. Experiment was done with off-the-shelf PC, with extra large memory. "Signer" software was provided by Nominum. Two test runs were done: 1. on original data signing -- ~ 14 hours CPU time expansion factor of 4.4 (of adding all the dnssec data) 2. modified zone (taken out mx & A records; left just ns) runtime -- 3.2 hours of CPU time 117 mb -> 380 mb, so expansion factor a bit lower (3.2) for smaller base data Conclusion: you need some resources, but it's within the reach of current hw and sw. the few people with much larger zones will have more work - but it can be assumed they'll have more revenues. Q: Does it mean a recommendation to DEnic to get rid of mx only domains? A: yes Q: Compared with Swedish workshops? Liman: different, smaller results. Bigger times & data. Used signer from bind8. Q: What do you consider normal zones? A: Less then a million records. (.de = 3,000,000 RR) Liman: Does it make a difference if you have to include ns or mx/a records? David: Not significant. David: Wildcards in the sign zone makes signing 2 orders of magnitude more difficult. We don't support them! Liman: Only in DNSSEC? David: Yes, only if you try to sign them; we either ignore them or generate an error. 4. Randy Bush: DNS from IETF perspective What features are important? For a log time, specifications were stable, code was fairly unstable. Now we are in period when specifications are fairly stable, and the code is little unstable. The increased features that are being specified will cause code instability that will last forever (you can't have all this sugar and not be unhealthy). Main new features: security / DNSSEC & multi-lingual support / IPv6 Security problem: For example: the size of the root zone sign becomes larger then bits in the MTU of the standard UDP packet and therefore all the sessions will fall back to TCP and cause 6 times bigger amount of traffic. Multi-lingual problem: It's not really the DNS problem, but application problem - what is my web browser going to be able to read. i like to call it not internationalisation but localisation, which can cause that our customers not able to do e-commerce with Japanese customers David: stability of the code: bind9 _designed_ and not _evolved_ ; therefore more stable. architectured much better. Bill: operational community has to find the way to provide the feedback to engineering community. this forum might be a right place for it. Randy: yes - we need operators back in ietf. protocols became designed without taking a consideration operational issues. David(?): ietf is quite large cumbersome. having smaller groups of operational people come to some consensus, and then having spokesperson is probably a better solution. Chair: in communities like this there is opportunity to keep information flow in both directions. The survey was conducted by Bill to check who is using which version of BIND. Results: [ ] 5.1. Document about re-delegation Draft paper on how to help re-delegation was presented in RIPE #33 in Vienna by Fernando [ ]. Paper was describing the case of DNS transfer of customers from one ISP to another - how that can be done without losing the service, how to minimise problems, including variations of cases of (non)cooperating ISPs. Help is needed about transfer procedures in ccTLD zones other then .es . Question from the audience: Wouldn't CENTR think they should take part in it? Since large amount of these re-delegations problems are from ccTLD registrars. Chair: Indication of involvement should come from CENTR. However, administrative procedures in many registrars are much worse then they should be; we should push CENTR in the right direction. Liman: There should be one document describing technical issues (in which order what.. ), which are the same all over the world; then, what are the implications of administrative models; and in the different part of the same document, point to possible pitfalls. ACTION on Fernando to sent index/draft to the DNS-WG mailing list; make appendix about procedures in the registries/registrars that we know about. 5.2. RIPE documents published since the previous meeting - Recommendations for DNS SOA Values (RIPE-203) - Simple DNS Configuration Example (RIPE-192) There is work in progress on more detailed documentation. Peter Koch was encouraged to work more on it. Chair invited everyone to express their need for new documents. Q: There is confusion about old and new minimum value in bind4 and bind8. Liman: Dummy guide is meant for "the newest version of BIND". Comments about other versions are welcome, but should be published as separate document. --==_Exmh_9077542070--

1 0

Domain change document draft
by Fernando Garcia 11 Sep '00

11 Sep '00

Hello all In the last RIPE meeting I made a proposal for a document that would help hostmasters to change domains between ISPs, carriers, etc. Included in this message is a draft version of that document. Is not perfect, but I think is a good starting point that can be completed by all the members of the WG. Regards, Fernando Garcia. -------------------------------------------------------------------- Fernando Garcia | Email: fgarcia(a)eurocomercial.es EuroIDT - Eurocomercial | Tel: +34 91 435 96 87 Internet Development Team | http://www.eurocomercial.es/ --------------------------------------------------------------------

3 2

The Domain change document draft
by Fernando Garcia 10 Sep '00

10 Sep '00

Hello It was supposed that the original document was text. In any case, here it is inserted as text... Recomendations to migrate a domain between networks Fernando Garc°a FernÝndez <fgarcia(a)eurocomercial.es> September, 2000 1 Abstract This document gives a set of recommended steps to migrate a domain name and their related services (mail server, web server, etc.) from one IP address range to another to avoid loss of visibility on the net. 2 Table of Contents 1 ABSTRACT 1 2 TABLE OF CONTENTS 1 3 INTRODUCTION 1 3.1 SITUATIONS 2 3.2 MIGRATING A DOMAIN FROM ONE ISP TO ANOTHER 2 3.3 CHANGING THE IP NUMBERING OF THE ISP 2 3.4 CHANGING PROVIDER 2 4 REQUIREMENTS 2 4.1 COMMON SENSE 2 4.2 MINIMUM DNS COMPREHENSION 2 5 TARGETS 2 5.1 PROVIDE NO BLACKOUT IN THE DOMAIN ANSWERS 2 5.2 AVOID LONG TERM POLLUTION OF THE DNS SPACE WITH INCORRECT OLD DNS RECORDS 3 5.3 AVOID SHORT TERM BLACKOUT ON HOSTS ANSWERS (A AND PTR RECORDS) DUE TO CACHING 3 6 REQUIREMENTS 3 3 Introduction Due to the dynamic nature of Internet and to the several economical and political elements involved, it is common that a domain name and related services (mail server, web server, etc.) needs to change from one IP range to another. The most frequent case is when the ISP or company that maintains the domain nameservers moves from one carrier to another, but there are more circumstances that can lead to this situation. If an incorrect procedure is followed during this migration, an "outage" can happen on the domain and its services would be unrecheable during a long period of time (even days). To avoid this, it is recommended to follow the set of steps suggested along this document, that would eliminate, or at least would reduce to the minimum, this "outage". 3.1 Situations There is a variety of situations which could lead to the necessity for this change of network, among others, the following ones: 3.2 Migrating a domain from one ISP to another When the company that owns a domain, changes its Internet services from one provider to another motivated by economical and/or other sort of factors. The new ISP will have a different IP address range and the nameserver for the domain name will be one belonging to the new ISP. 3.3 Changing the IP numbering of the ISP Even if a company does not change of ISP, this provider can change itself its IP address range, just because it changes of carrier, or becomes LIR with its own IP address range; or rare but can happen, because the carrier reorganizes its IP space. 3.4 Changing of provider This case provokes a similar situation for the ISP itself, that needs to keep running their own services without disruptions. Usually an ISP handles hundreds of domains and a 'change without disruption' should be compulsory. 4 Requirements To be able to perform the change without dramatic consequences, the requirements below are recommended to be followed: 4.1 Common sense As usually occurs in Internet as well as in any other technically related area, even with a good cookbook, unexpected things may happen and in these situations, 'common sense' is a must to solve the problem. 4.2 Minimum DNS knowledge Read 4.1 and replace "common sense" with "DNS understanding" 5 Targets The final intention of the procedure described below is to keep active (and visible) all services in a domain during the most part -if not always- of the time. This goal can be achieved through the following independent targets: 5.1 Avoid the 'outage' of the domain The intention is to have always a DNS server answering queries for the domain, and hopefully it will answer correctly most of the time. Probably the worst thing that can happen is losing the DNS servers. In this case recovering the servers and all the information can be a time consuming process involving a lot of contacts to solve it. 5.2 Avoid pollution of the DNS caches with incorrect information Another problem that must be avoided is that the IP address of the DNS servers should be changed as soon as possible in the root servers so the domain authoritative information is updated with enough time to be distributed worldwide before the change of address of the servers happens. In case the IPs of these DNS servers are not changed with the sufficient advance, many servers worldwide will cache the previous information and the incorrect data will be kept until its expiration. In case that DNS servers that exist in the previous IP address don't answer anymore, we would be in the situation stated previously in 5.1. But if they answer with incorrect data (i.e. the former ISP is non collaborative and denies any change), the clients would get the former IP address for the services and this IP wouldn't change or would return outdated information. 5.3 Avoid short term blackout on hosts answers due to caching This is similar to the previous one. If the DNS servers information is not updated and propagated in a timely manner, when the servers are moved from one IP address space to another, many DNS servers worldwide will keep the previous IPs cached and they will return this information to their clients. 6 Requirements 6.1 Planning in advance, two weeks minimum To avoid problems with timeouts and caching stated in the previous section, the changes detailed below must be done with the sufficient advance. Two weeks are usually enough time to accomplish this with standard DNS SOA times following the RIPE and/or the local NICs. In some specific cases this two weeks won't be enough and the recommended time must be calculated according to the settings in the SOA record. 6.2 Co-ordination between ISPs is strongly recommended Though it is possible to make this migration without the cooperation of the former DNS administrator (usually the ISP that is losing the customer that owns the domain) and in some cases this is the only way to go, it is recommended that both DNS administrators work together (collaborate??). There are no written rules or laws to force the former DNS administrator to help in the migration, but denying his collaboration would neither help him and could create a bad reputation for him. 6.3 NIC contacts A preliminary task to do is to check the authoritative NIC of the domain to see the contact(s), who is authorised to make changes to the domain record. At least one of these persons (usually the administrative contact) must belong to the company_s staff that owns the domain and wants to make the changes. In some NIC registries this relation between the administrative contact and the company is compulsory. But in others (specifically in Network Solutions, formerly InterNIC) the contacts can be any person without any relation with the company. Specifically these contacts can be members of the former ISP, and if this is not collaborative this can lead to the impossibility of changing the domain unless some legal measures were taken, but this goes beyond the scope of this document. 7 Scenary The scenary designed to draw the situation is probably one of the more complex, and in some cases few steps can be ommited. All the examples shown along the document make use of private IP addresses (RFC 1918) to avoid using the legitimate rights of some IP owner space. Of course this address must be changed for the legal ones assigned to this companies. As well as the domains and subdomains used in this example are purelly fictional and any coincidence with real domain or subdomain names is purely accidental. 7.1 Starting situation Company X owns the domain "foo.bar.", with the registry of the "newer" country, that can be contacted in http://www.nic.bar/. This company has Internet connectivity through carrier A, which has delegated to them the IP range 192.168.10.0/24. >From this range, the Network administrator of Company X have set on nic.bar. the following information: Primary domain server for foo.bar.: 192.168.10.2 Secondary domain server for foo.bar.: 192.168.10.240 Later, this administrator have set up the information of this domain to resolve that: www.foo.bar. is a "IN PTR" to 192.168.10.10 mail.foo.bar. is a "IN PTR" fo 192.168.10.15 The MX for foo.bar. is mail.foo.bar. with a preference of 10, there isn_t any other MX. Of course, our administrator (is responsible)<-(yo lo quitar°a) and also has setup de inverse-resolution (in our) nameservers after being delegated from RIPE-NCC. 7.2 Ending situation After the migration, company X would be connected through carrier B. This carrier would have agreed to delegate to company X a range of IP addresses, specifically the group 10.40.5.0/24. The new servers would be: Primary domain server for foo.bar.: 10.40.5.2 Secondary domain server for foo.bar.: 10.40.5.240 www.foo.bar. as a "IN PTR" to 10.40.5.10 mail.foo.bar. as a "IN PTR" to 10.40.5.15 The "IN MX" for foo.bar. would continue being mail.foo.bar. with a preference of 10, without any other "IN PTR" . The inverse-resolution for the new IP address range would be delegated and correctly configured. 7.3 Restrictions There are some of the mechanics involving the transfering that are NIC specific. Mainly the administrative tasks explained step by step and forms to be filled. Especific forms for particular NICs may be found in the appendix below. The following ones, are generic instructions. 8 Mechanics (how to proceed) The underlying idea of this procedure is to carry out the transition in two steps: The first one will change the DNS servers to the new IP address range but keeping the hosts in the previous range. This includes updating the database of the authoritative NIC for that domain. Once the information for the DNS servers have been changed (updated) all over Internet, the IP addresses of the hosts will be changed in this new DNS servers, but previously the refresh and expiration times should be lowered to allow for the change to be updated across Internet in a quick way. This is the main point in the process, to have expiration times low enough that when you change some value, the new information is distributed enough fast that the machines that try accesing the old information are reduced to a minimum. When this changes are finished, the this DNS values should return to their normal values to avoid unnecesary traffic in the network. 9 Shopping list If you have lot of experience with your DNS server and your NIC, this is probably the only list you need. In a brief list, this is what needs to be done: * Create (Install/Setup) a new DNS server in the new IP address range * Configure this DNS server with the host information for the existing IP addresses. i.e. Do not modify 'IN A' records, 'IN MX' records, etc. * Modify the primary name server (NS record) to itself. * Change secondaries name servers if they are in the old network (192.168.10.0/24), do not change them in case they're in a different network * Reduce SOA times for the domain. * Start the server * With a client application (nslookup, dig) check all the information * Send a form to the NIC asking for the change of primary name server (and secondary if needed) * Wait for the changes to propagate * Install duplicate servers (web, mail) in new IP address range * Change "IN A" records in new DNS server to point to duplicate servers * Wait for the changes to propagate * Deactivate old servers 10 Commented steps Next, all the above described steps are explained in depth: 10.1 Setup a DNS server in the new IP address space This is a technical task. Besides installing a new server and the DNS Server software (Bind, dnscache or similar), or using one that already exists, the information on this machine must be updated correctly. This information must be setup with the following data 10.1.1 Duplicate the current domain information in the new server The information to setup is mainly the existing in the former DNS. So the easiest way to work is making a full transfer of the domain and modifying the relevant items (RECORDS). The domain transfer can be achieved with #dig @192.168.10.2 foo.bar. axfr in > /etc/notarealdomain.conf after this you must add this domain to the list of domains handled by this server editing /etc/named.conf and inserting the following lines: zone "foo.bar." { type master; file foo.db; }; The main point here is to preserve the actual addresing of the hosts, so www.foo.bar. is still a "IN PTR" to 192.168.10.10 and mail.foo.bar. is a PTR to 10.40.5.15 10.1.2 Modify primary "IN NS" to itself With any text editor open the file "foo.db" and change the NS resource record to itself. The secondaries must be changed only if the former ones are in the old network (192.168.10.0/24) and you're setting up new servers in the new network. If this secondaries are hosted in another network (carrier, NIC, friendly ISP, etc.) do not change them and do not tell the hostmaster of the remote network to change them. Specifically DO NOT change the primary name server. This will be done later. 10.1.3 Reduce SOA times At the top of the "foo.db" file are the following lines (numbers may be diferent): Write the real values in paper and change the numbers -no matter what the previous values are- to: Refresh: .............................. Retry: .................... Expire: ....................... Minimum: ........................ 10.2 Test the new server Start the DNS server as indicated by the manual or if the server is actually running, tell him to reload the configuration file. This command depends of the server application and the operating system. With Unix and the BIND server, you get the process ID of the server application with $ ps -ax | grep named or $ ps -ef | grep named And then: $ kill -1 PID Or easily: $ ndc reload Replacing PID with the id number for the named process returned in the previous command. After that, check the messages log of the system for the presence of error messages. Usually a "tail -f /var/log/messages" will show you if the server was correctly reloaded of if an error happened. Use a client configured with this server as primary DNS server and check that it resolves the hosts (the existing ones) correctly: nslookup - 10.40.5.2 > www.foo.bar. 192.168.10.10 10.3 Modify primary "IN NS" in the NIC Send form to the NIC asking for the change of primary (and secondaries, if needed) name server for that domain to the new one. This is mainly an administrative task and the time it takes to process the change is greatly dependent of the NIC itself and the workload in each moment. Usually the NIC informs the customer as soon the change is made, but is a good rule of thumb to check it by yourself. Two aspects should be checked. In first place the NIC_s database should be verified -usually through a web page- and also, you must check with the name server itself of the NIC. This can be made with DNS client configured to use the name server of the NIC in the same way that was used to check the new DNS server in section 10.2. 10.4 Change secondaries Once the NIC has updated the information is time to update the secondaries that reside in outer networks. Usually these machines are placed and maintained in third party networks, therefore the change is done asking the hostmaster of each site to change the information about the primary name server and reloading his name server in order the change take effect inmediatly. 10.5 Verify secondaries When the hostmasters inform you that the changes are made, you must check this again with dig or nslookup. $ nslookup - dns.otherserver.com > set type=ns > foo.bar. foo.bar nameserver = primary.foo.bar foo.bar nameserver = dns.otherserver.com primary.foo.bar internet address = 10.50.5.2 dns.otherserver.com internet address = 192.168.13.13 In the information returned, the element to be checked is the information about primary name server, there should appear the new one that you installed in the new IP address range. If this does not happen, It can be because the name server has not been reloaded or the information is incorrectly configured in this secondary. 10.6 Wait until changes get propagated When all the changes are made, it is necesary to wait until the new information gets propagated. The maximum time for this to happen -at least in theory- is the content of the 'expire value' in the former SOA record, but you should check some name servers all over the world in the same way that you test the secondaries. Only when all of them (or, at least all you checked) redistribute the new information is the moment to proceed with the next step. The method to check this, is the one described in previous sections: $ nslookup - the-other-dns-server-name > set type=NS > mydomain.tld answer should be the new "IN NS" 10.7 Hosts changes Now you have a new DNS server with reduced expire and refresh times, but the new DNS server contains the same host information that the old one. i.e. the "IN A" records point to the servers with the old IP addresses. Now it is required to modify these "IN A" records to point to IP addresses existing in the new IP range, but previously you must install the servers in this new addresses because if you don't, you will find that your DNS servers have entries pointing to non existing machines. 10.7.1 Install new hosts The best solution is to install a new set of servers with the new IP addresses and duplicate the information of the original servers. Usually this approach can be applied with the web server and the FTP server, but is not a real solution for the mail server (POP3 server) since the contents of this are dinamic and the mailbox of a user can be modified in the interval from the start to the end of the replication. The best solution for the mail server involves some outages, but the point is to reduce them to a minimum. This solution include this steps: * Create a new email server * Duplicate the configuration, incluing the user accounts (user id and passwords) * Stop the POP3 and SMTP servers of the original mail server * Transfer all the mailbox contents from the old mail server to the new one * Configure the old mail server as a forwarder to the new one * Start the POP3 and SMTP servers in the new machine * Start the POP3 and SMTP servers in the old machine If you cant duplicate the servers, you must transfer them as fast as posible. But an important thing to remember is that the outage is not limited only to the time that you transfer the machines. The DNS servers all over the world will have the information for the old machines cached and though you modify it inmediatly, the old one will remain valid until it expires. This is the reason to reduce the SOA times as described in 10.1.3, to limit this outage to a minimum. 10.7.2 Modify "IN A" and "IN PTR" After installing the alternate set of servers in the new address or moving them, you must change the A and PTR records in the DNS servers to point to the new machines. Also you can restore the original SOA times. This are the new and, hopefully, definitive servers so their IP address can be cached. 10.8 Wait until the changes get propagated Use the usual method described previously with nslookup or dig. Of course you can't check all DNS servers all over the world, but a representative subset is more feasible. 10.9 Deactivate old servers in former ISP Everything is going to the servers in the new address space, so you can deactivate all servers in the old address space, including DNS server, web server, etc. 11 Special situations The previously section describes the more typical situation, but the're some variants that should be explained. 11.1.1 traumatic change of provider The best thing is to maintain both providers or, if your company has it own Internet access and want to change carrier, both carriers. But if you can't, these are some tips: 11.1.1.1 headache assured You will have an outage in any case, and this will create problems with your customers os the boss. 11.1.1.2 You need help from a third party At least you need to maintain always the DNS server reachable. The only way to do it in this situation is through a third party that will keep this server up and running in another network. There are two diferents methods in this situations, the fast and the slow, or the one with long outages and the one with minimum outages 11.1.1.3 Fast method (with blackouts) In this method the outages can be long and the main purpose is to avoid a lost of control in the domain. A fast description is: * Reduce SOA times in the existing DNS server and wait for the information to propagate * Install a DNS server for the domain in the third party server * Change information in the NIC to point to this DNS server * Deinstall servers from older lines, ISP, etc. * Install servers in new lines, ISP, etc. * Install DNS server in new ISP * Change information in the NIC to point to the new DNS server * Restore SOA times to the standard ones During the migration period (days, weeks) you'll have blackout of services because the only server that can be reached in all times is the DNS server. 11.1.1.4 Slow method (minimum blackout) This method reduces the outages to a minimum but require to maintain both conections (former and new ISP or carrier) during some time. * Reduce SOA times in the existing DNS server and wait for the information to propagate * Install a DNS server for the domain in the third party server * Change information in the NIC to point to this DNS server * When the new line arrives, install hosts in the new IPS * Change hosts address in the DNS server to point to the new ones * Change information in the NIC to point to the DNS server in the new network 12 Related information Other documents that can be hepfull are: * ripe-192 - Simple DNS Configuration Example * ripe-203 - Recommendations for DNS SOA Values * ripe-114 - Taking Care of Your Domain * "DNS & BIND 3rd Edition" by Paul Albitz & Cricket Liu, O'Reilly & Associates Inc. -------------------------------------------------------------------- Fernando Garcia | Email: fgarcia(a)eurocomercial.es EuroIDT - Eurocomercial | Tel: +34 91 435 96 87 Internet Development Team | http://www.eurocomercial.es/ --------------------------------------------------------------------

2 1

unregister
by Sulyok Gyula 21 Aug '00

21 Aug '00

1 0

Registration of .be domains and .com,.net or .org
by Cain Ransbottyn 15 Aug '00

15 Aug '00

Hello guys, I have a question and maybe you guys know an answer for it... we are a belgian company and we are very interested in running our own domain registration for .be domains... or even for .com,.net or .org domains... There are already a lot of .com,net.org domain registration companies but for .be there is only ONE... is it possible to have 2 official domain registers in one company ? We would like to be one... I suppose we have to pay quite a lot for it but we have financial investors to realise this project... we are also interested to become a .com,net,org domain register... Could you tell me where i have to with these questions ? Thanks in advance for helping us out ! Cain Ransbottyn CEO RealROOT / Securax

2 1

[RETRANSMISSION] DNS problems with nameservers for .be and 193.in-addr.arpa
by Brad Knowles 14 Jul '00

14 Jul '00

[ The previous version of this message (with attachments included) was too large to be accepted by certain recipient addresses, so I am retransmitting the message with the attachments instead available at the URL <ftp://ftp.shub-internet.org/pub/shub/brad/dns/>. I also mistakenly left off a few recipients on the original version, which are included here. -Brad ] Folks, A couple of problems with some pretty important nameservers has been brought to my attention in the last couple of weeks. I would not normally bring this issue directly to such a wide group of people, but I believe that this matter is sufficiently serious to warrant such an approach. In particular, we have discovered that holem.belnet.be [193.190.198.10] (acting as one of the two nameservers for ns.belnet.be) is acting as both an authoritative nameserver for .be (among many others, I'm sure), as well as acting as a general caching nameserver. This has hit us a few times when we've changed machines on our own networks, made the changes in our authoritative nameservers and then reloaded the zones, and then finally restarted our caching nameservers -- only to have the data in the caching nameservers poisoned by incorrect information from holem.belnet.be [193.190.198.2]. Earlier we had the same problem with vivaldi.belnet.be [193.190.198.2] (the other machine acting as ns.belnet.be). However, the problem with vivaldi.belnet.be appears to have since been corrected. However, I note that DNS.CS.KULEUVEN.AC.be, NS.EU.NET, SPARKY.ARL.MIL, and SUNIC.SUNET.SE appear to have the same problem as holem.belnet.be [193.190.198.10]. This is an extremely dangerous situation, one that has long since been recognized by experienced nameserver administrators. This is why section 2.5 of RFC 2870 "Root Nameserver Operational Requirements" says: 2.5 Servers MUST provide authoritative responses only from the zones they serve. The servers MUST disable recursive lookup, forwarding, or any other function that may allow them to provide cached answers. They also MUST NOT provide secondary service for any zones other than the root and root-servers.net zones. These restrictions help prevent undue load on the root servers and reduce the chance of their caching incorrect data. While these machines are not root nameservers (to the best of my knowledge), the same rules and regulations should be applied to their maintenance and operation, for the same reasons. Therefore, I recommend that these machines be fixed ASAP, and if they cannot be fixed within a reasonable period of time, they should be removed from the list of authoritative nameservers for .be. Furthermore, I recommend that if these machines cannot be fixed within a reasonable period of time, they be removed from all nameserver duties for all upper-level domains, including root nameservice, gTLD and ccTLD duties, service for any of the in-addr.arpa zones, etc.... I have also noticed that while vivaldi.belnet.be [193.190.198.2] and AUTH02.NS.UU.NET do not appear to be caching data directly, they do appear to somehow be secondaries for the .com zone, as the referrals they give for www.aol.com go directly to the AOL nameservers, and not through the root or .com gTLD nameservers. Try as I might, I cannot find the IP addresses 193.190.198.2 and 198.6.1.82 on the list of published nameservers for the .com gTLD. This concerns me, but without additional information, I can't call this an "error" per se. You can confirm my test results by executing the following Bourne shell script: #!/bin/sh BENS="DNS.CS.KULEUVEN.AC.be. SECDNS.EUNET.be. SPARKY.ARL.MIL. SUNIC.SUNET.SE. AUTH02.NS.UU.NET. NS.EU.NET. 193.190.198.10 193.190.198.2 NS.DNS.be." for NS in $BENS do dig @$NS www.aol.com. a +aa done Note that because of the lossy nature of sending UDP packets via the Internet, you may need to run this script multiple times in order to get complete output. I know I did. The results I get can be found at <ftp://ftp.shub-internet.org/pub/shub/brad/dns/be.txt>. I would also refer you to the output of running "doc -d be" at <ftp://ftp.shub-internet.org/pub/shub/brad/dns/log-be.txt>. I have also discovered that NS.EU.NET is not properly handling DNS queries for 193.in-addr.arpa. In particular, I was trying to do a reverse lookup on 193.74.108.3, and was getting SERVFAIL responses, something that I should not be getting -- especially not from nameservers that are supposed to be serving 193.in-addr.arpa. I wrote the following script to check out the nameservers for this top-level reverse zone: #!/bin/sh REVNS="NS.RIPE.NET. NS.EU.NET. AUTH03.NS.UU.NET. NS2.NIC.FR. SUNIC.SUNET.SE. MUNNARI.OZ.AU. NS.APNIC.NET." for NS in $REVNS do dig @$NS -x 193.74.108.3 done The results I get are at <ftp://ftp.shub-internet.org/pub/shub/brad/dns/reverse.txt>. I would recommend that you also look at the output of running "doc -d 3.108.74.193.in-addr.arpa" and "doc -d 74.193.in-addr.arpa" at <ftp://ftp.shub-internet.org/pub/shub/brad/dns/log-reverse.txt>). You will note that NS.EU.NET is not the only nameserver here that is giving me SERVFAIL. I also get it from SUNIC.SUNET.SE and MUNNARI.OZ.AU. Again, if these machines cannot be fixed in a reasonable period of time, I suggest that they should be removed from the list of authoritative nameservers for 193.in-addr.arpa. Also note some of the interesting and different answers given back by the various machines for the IP address of ns.ripe.net in particular -- some list the IPv6 address and some don't. Is this an error? I honestly don't know.... With this information, I hope that you will understand the issues, and share my very deep concern that this is a systemic problem that affects everyone on the Internet, and goes far beyond the operational problems that any one ISP may be currently experiencing. I don't want to come across as a self-styled DNS expert, although I do believe that I know more on this topic than the average system administrator. I hope that you won't hold against me the fact that I am the current maintainer of the DNS debugging tool "doc", and that I have used the output of this tool to help document my position. If I wanted to be really nasty, I'd ask that you take away the high-level authoritative nameserver privileges for the above named machines, and that you instead give them to us, thus increasing the prestige of my employer. However, all I really want to do is get these problems fixed, and stop having so many complaints being delivered to me which ultimately result from the issues I have raised here -- and therefore, problems that I cannot do anything about, at least not by myself. That said, if it would help for Skynet to provide a nameserver to fill in for these various different roles, I'm sure that I and my employers would be more than happy to move Heaven and Earth to make sure that we got a suitable machine up and running as quickly as humanly possible. ADDENDUM: Please note that we have previously brought up these issues regarding ns.belnet.be with Marc Roger at Belnet. So far as I can tell, he didn't seem to care. We also brought these issues up with DNS.BE, and again we haven't seen any results. Also note that the information at <http://www.iana.org/root-whois/be.htm> appears to be out-of-date, as I keep getting bounces back from the supposedly official address "marc.vanwezemael(a)dns.be" as the Administrative POC for .be. I know that the management of EUnet is aware of their reverse DNS problems, because we have been having running problems with them for at least the last couple of weeks, and our servers don't accept mail from any of theirs, because they don't have reverse DNS. Of course, the reason they don't have reverse DNS is that the same servers are used for serving various important zones within Europe as well as serving those local to EUnet, and these machines are the ones that are screwed-up. Unfortunately, while they have been aware of the problems for a while and we've been trying to get them to fix their local problems in that time, it wasn't until more recently that I realized just how severe the issue with their nameservers really is. Again, I have yet to see anything useful at all come from them on this issue. Frankly, I just don't know what else to do. If I have not used the proper escalation procedure, then I would appreciate it if someone would tell me what the proper escalation procedure is. I would also like to see where this is documented on the appropriate web sites, because I looked everywhere I could think of, and still haven't found it. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, <blk(a)skynet.be> || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium

3 4

Re: DNS problems with nameservers for .be and [ 194.in-addr.arpa ]
by Brad Knowles 12 Jul '00

12 Jul '00

On Wed, 12 Jul 2000 20:11:26 +0200 Brad Knowles <blk(a)skynet.be> said: > A couple of problems with some pretty important nameservers > has been brought to my attention in the last couple of weeks. I > would not normally bring this issue directly to such a wide group > of people, but I believe that this matter is sufficiently serious > to warrant such an approach. Sorry, I meant to mention that we had previously brought up these issues with Marc Roger at Belnet, and so far as I am able to determine, he simply didn't seem to care. I believe that these issues have also been brought up with the management of DNS.BE, and again we haven't seen any results. Likewise, I believe that the administrators of EUnet are well aware of their DNS problems -- they are certainly aware of the problems of getting e-mail from any of their servers to many of ours, since our more recently configured and install machines refuse to accept mail from hosts that do not have proper reverse DNS, in accordance with Internet standard practice going back at least two years. Again, we have yet to see any results. If I have not followed the proper escalation procedure, I would appreciate it if you would please let me know what the proper escalation procedure is. I would also ask that you tell me where this escalation procedure is documented, because I'm certainly not aware of anything of this sort. -- These are my opinions -- not to be taken as official Skynet policy ====================================================================== Brad Knowles, <blk(a)skynet.be> || Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium

1 0

Re: PGP 5 CERT Advisory
by Wilfried Woeber, UniVie/ACOnet 27 Jun '00

27 Jun '00

Adrian, actually an alert was already circulated by the RIPE NCC on Fri, 16 Jun 2000 15:32:58 +0200. But you do have a point in that the warning was only sent to the DB-WG list. Touching on Alessandro's point, I'd be *really* interested to find out about the "hit-rate" in our community. I.e. how many of us (if anyone at all) were satisfying the criteria to end up with a potentially vulnerable key! Wilfried. PS: on the GnuPG pages, there is interesting information wrt the randomness issue ( http://www.gnupg.org/download.html --> see EGD ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

R: PGP 5 CERT Advisory
by Alessandro.Pelosi＠swisscom-italy.com 27 Jun '00

27 Jun '00

Thank You. You've benn very kind to remark it because there are too many people who completely trust this technology. -----Messaggio originale----- Da: adrian.pauling(a)bt.com [mailto:adrian.pauling@bt.com] Inviato: lunedì 26 giugno 2000 18.27 A: lir-wg(a)ripe.net; dbm-ripe(a)ripe.net Cc: kevin.bates(a)bt.com Oggetto: PGP 5 CERT Advisory Are RIPE Community aware of the CERT Advisory regarding PGP version 5 for UNIX? http://www.cert.org/advisories/CA-2000-09.html Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering Technical Architecture AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling(a)bt.com * +44 19 2685 1992 / +44 78 0290 4877 British Telecommunications plc Registered Office 81 Newgate Street London EC1A 7AJ Registered in England no 1800000

1 0

New draft for ``long'' server setup document posted
by Peter Koch 29 Feb '00

29 Feb '00

Dear all, an action item from last week's DNS WG meeting was to post the latest version of "RIPE DNS WG Guide To Setting Up a DNS Server", the only remaining document in our trilogy. The draft has just been sent to the Internet Drafts directory: draft-koch-ripe-dns-setup-guide-00.txt Until all mirror sites have grabbed it you can also access my local copy at http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-koch-ripe-dns-setup-guide… This is a draft, so there are several sections ``TBD''. However, we all know much more to say about DNS, but we have to constrain ourselves to a digestable piece of paper. Any comments and suggestions are very welcome, but I would like to suggest that we only very carefully add more bullet points. Maybe we could even get rid of some. Any first hand experiences with the desired target audience are especially appreciated. I plan to have an updated draft with all the gaps filled ready by RIPE 36. Please post contributions to this list. -Peter

1 0