- dns-wg - mailman.ripe.net

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

BIND
by Support ＠ Nätverk Engelholm 29 Feb '00

29 Feb '00

Hi, Does anyone no where to get the latest BIND for WinNT? Regards Mats N.

2 1

RE: Please publish.
by Hallgren, Michael 28 Feb '00

28 Feb '00

>Go ahead. Publish the bl**dy thing. You'll feel much better for it. :) mh > >>On 24-Feb-2000 Lars-Johan Liman wrote: >> randy(a)psg.com: >>> seems ill-advised as they are not standard and are a kink of one >>> implementation. >> >> Mja, it's really not _that_ bad. >> >> It's not full standard yet, agreed, but it _is_ on standards track >> (RFC 2308, proposed standard), so it not just "a kink of one >> implementation". >> >> I agree we should probably wait until it's a bit further along the >> track before recommending it, though. >> >> /Liman > >-- >Tel: +44 171 864 4450 Fax: +44 171 864 4488 >Well I'm disenchanted too. We're all disenchanted (James Thurber) >(http://www.seanet.com/~thurber/disenchanted.gif) >

1 0

RE: Please publish.
by Hallgren, Michael 28 Feb '00

28 Feb '00

Hi, >Hi! > >Would you please publish the following document as RIPE-192. The >number has already been assigned long ago by Ambrose. The DNS WG has >approved this document long ago. As said while eating, perhaps adding the (late) Bind $TTL statement to the zone files ? (Was somewhat reluctant to propose, since Bind is merely one of a few implementations... ... but who uses other ? :) Michael > >*** PLEASE OBSERVE *** that the RIPE document number 192 has already >been reserved. > > Cheers, > /Liman >#---------------------------------------------------------------------- ># Lars-Johan Liman, Systems Specialist ! E-mail: liman(a)sunet.se ># KTH Network Operations Centre ! HTTP : //www.sunet.se/~liman ># Royal Institute of Technology, Sweden ! Voice : Int +46 8 - 790 65 60 >#---------------------------------------------------------------------- <<new-recommend.txt>>

4 3