1. Top-level domain: su
2. Complete Domain Name: jinr.dubna.su
3a. Organization name: Joint Institute for Nuclear Research
3b. Organization address: P.O.Box 79 10100 Moscow
4. Date operational: 1-10-1993
Administrative Contact
5a. NIC Handle (if known) : VS86
5b. Name (Last, First) : Vladislav Shirikov
5c. Organization: Joint Institute for Nuclear Research
5d. Mail Address: shirikov(a)jinr.dubna.su
5e. Phone Number: Dubna (221) 62387
5f. Net Mailbox :
Technical and Zone Contact
6a. NIC Handle (if known):
6b. Name (Last, First) : Evgeny Mazepa
6c. Organization: Joint Institute for Nuclear Research
6d. Mail Address: mazepa(a)jinr.dubna.su
6e. Phone Number: Dubna (221) 65020
6f. Net Mailbox :
Primary Server: HOSTNAME, NETADDRESS, HARDWARE, SOFTWARE
7a. Primary Server Hostname: 1: ns.jinr.dubna.su (jimex.jinr.dubna.su)
2: ns.kiae.su
3: ns.ussr.eu.net
7b. Primary Server Netaddress: 1: 159.93.17.7
2: 144.206.130.3
3: 192.16.202.11
7c. Primary Server Hardware: 1: SUN SPARCstation 1+
2:
3:
7d. Primary Server Software: 1: Sun/OS 4.1.1
2:
3:
(8) The Secondary server information.
8a. Secondary Server Hostname: 1: ns.kiae.su
2: ns.ussr.eu.net
8b. Secondary Server Netaddress: 1: 144.206.130.3
2: 192.16.202.11
8c. Secondary Server Hardware: 1:
2:
8d. Secondary Server Software: 1:
2:
(9) If any currently registered hosts will be renamed into the new
domain, please specify old hostname, netaddress, and new hostname.
(10) Please describe your organization briefly.
Nuclear research
Dear colleagues,
I'm surprised to find that the top level domain names CY and GR (for
Greece and Cyprus) have been dropped from the most recent root zone (Serial
930927 as available by FTP from rs.InterNIC.net)
While all of the master servers for those TLDs - with the exception of
NS.EU.NET - seem still to carry those two zones, root server NS.INTERNIC.NET
does not delegate CY and GR anymore (see logs from checking with dig
and host below).
Checking the InterNIC whois shows that the TLD entries have been changed
yesterday; probably that update sunk CY and GR as collateral damage:-)
Please correct the root zone immediately and take action to
have the broken zone replaced on all "infected" root servers.
As of the time of sending this message serial 930927 had found it's way to
NS.INTERNIC.NET, C.NYSER.NET, TERP.UMD.EDU, NS.NASA.GOV, and NS.NIC.DDN.MIL
(AOS.ARL.ARMY.MIL still has 930924, NIC.NORDU.NET is still at 930922,
and KAVA.NISC.SRI.COM is not responding).
Regards,
Ruediger
Ruediger Volk
Universitaet Dortmund, Informatik IRB DE-NIC
D-44221 Dortmund, Germany
E-Mail: rv(a)Informatik.Uni-Dortmund.DE
Phone: +49 231 755 4760 Fax: +49 231 755 2386
================================================================================
Cyprus (Republic of) top-level domain (CY-DOM)
University of Cyprus
75 Kallipoleos str
Nicosia
CYPRUS
Domain Name: CY
Administrative Contact, Technical Contact, Zone Contact:
Stylianou, Agathoclis (AS183) agatho(a)CYEARN.BITNET
+02 366186
Record last updated on 27-Sep-93.
Domain servers in listed order:
JUPITER.CCA.UCY.CY 193.92.92.33
NICOSIA.CCS.UCY.CY 193.92.92.65
PYTHIA.ICS.FORTH.GR 139.91.1.1
NS.EU.NET 192.16.202.11
SUNIC.SUNET.SE 192.36.125.2, 192.36.148.18
NS.UU.NET 137.39.1.3
ADM.BRL.MIL 192.5.25.4, 192.5.21.30
; <<>> DiG 2.0 <<>> @ns.InterNIC.net cy. any
;; ->>HEADER<<- opcode: QUERY , status: NXDOMAIN, id: 10
;; flags: qr aa ; Ques: 1, Ans: 0, Auth: 1, Addit: 0
;; QUESTIONS:
;; cy, type = ANY, class = IN
;; AUTHORITY RECORDS:
. 86400 SOA NS.INTERNIC.NET. HOSTMASTER.INTERNIC.NET. (
930927 ;serial
10800 ;refresh
900 ;retry
604800 ;expire
86400 ) ;minim
;; Sent 1 pkts, answer found in time: 200 msec
;; FROM: seins to SERVER: ns.InterNIC.net 198.41.0.4
;; WHEN: Tue Sep 28 08:54:42 1993
;; MSG SIZE sent: 20 rcvd: 81
servers listed in 930924 were:
PYTHIA.ICS.FORTH.GR
NS.EU.NET
SUNIC.SUNET.SE
NS.UU.NETADM.BRL.MIL
The list of servers in the CY zone is different, and ALMOST matches the
new whois data [aos.brl.mil ./. ADM.BRL.MIL]
When I trick "host" into starting from a server that still has root(930924)
"host -C CY." lists:
CY NS PYTHIA.ICS.FORTH.GR
jupiter.cca.ucy.cy kasenid.jupiter.cca.ucy (20005 86400 14400 2592000 345600)
CY NS NS.EU.NET
Nameserver NS.EU.NET not responding
CY SOA record not found, try again
CY NS SUNIC.SUNET.SE
jupiter.cca.ucy.cy kasenid.jupiter.cca.ucy (20005 86400 14400 2592000 345600)
CY NS NS.UU.NET
jupiter.cca.ucy.cy kasenid.jupiter.cca.ucy (20005 86400 14400 2592000 345600)
CY NS ADM.BRL.MIL
jupiter.cca.ucy.cy kasenid.jupiter.cca.ucy (20005 86400 14400 2592000 345600)
Greece (Hellenic Republic) top-level domain (GR-DOM)
Insitute of Computer Science
P.O. Box 1385
71110 Heraklio, Crete
GREECE
Domain Name: GR
Administrative Contact, Technical Contact, Zone Contact:
Sartzetakis, Stelios (SS241) stelios(a)CSI.FORTH.GR
+30 81 221171
Record last updated on 27-Sep-93.
Domain servers in listed order:
PYTHIA.ICS.FORTH.GR 139.91.1.1
TERPSI.CSI.FORTH.GR 139.91.1.17
LESVOS.CSI.FORTH.GR 147.52.33.9
NS.EU.NET 192.16.202.11
NS.UU.NET 137.39.1.3
SUNIC.SUNET.SE 192.36.125.2, 192.36.148.18
AOS.ARL.ARMY.MIL 128.63.4.82, 192.5.25.82
Top Level domain for the Hellenic Republic
; <<>> DiG 2.0 <<>> @ns.InterNIC.net gr. any
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10
;; flags: qr aa ; Ques: 1, Ans: 0, Auth: 0, Addit: 0
;; QUESTIONS:
;; gr, type = ANY, class = IN
;; Sent 1 pkts, answer found in time: 340 msec
;; FROM: seins to SERVER: ns.InterNIC.net 198.41.0.4
;; WHEN: Tue Sep 28 08:53:34 1993
;; MSG SIZE sent: 20 rcvd: 20
servers listed in 930924 were:
PYTHIA.ICS.FORTH.GR
NS.EU.NETNS.UU.NET
SUNIC.SUNET.SE
AOS.ARL.ARMY.MIL
The list of servers in the GR zone is different, and ALMOST matches the
new whois data [aos.brl.mil ./. AOS.ARL.ARMY.MIL]
When I trick "host" into starting from a server that still has root(930924)
"host -C GR." lists:
GR NS PYTHIA.ICS.FORTH.GR
pythia.csi.forth.gr stelios.nic.csi.forth.gr (20008 86400 7200 2592000 345600)
GR NS NS.EU.NET
Nameserver NS.EU.NET not responding
GR SOA record not found, try again
GR NS NS.UU.NET
pythia.csi.forth.gr stelios.nic.csi.forth.gr (20008 86400 7200 2592000 345600)
GR NS SUNIC.SUNET.SE
pythia.csi.forth.gr stelios.nic.csi.forth.gr (20008 86400 7200 2592000 345600)
GR NS AOS.ARL.ARMY.MIL
pythia.csi.forth.gr stelios.nic.csi.forth.gr (20008 86400 7200 2592000 345600)
Dear Jon (and others),
during last week's RIPE meeting the question of start up toplevel domains
has been discussed in the local registry working group. The concern (spawned
by the situation in Lebanon) is that when first starting it is difficult
to find a registrar acceptable to the community within the country and
this could delay things very much.
The RIPE NCC was asked and accepted to offer a temporary TLD registry service
for start up TLDs in and around Europe as necessary. The procedure would be
to wait for about a dozen registrations and then have the registered
organisations agree on a local registrar.
I hereby offer this service whenever you may think it is appropriate.
Please note that we still feel that having a local registrar accepted
by the local community is much preferrable to an external registrar.
This offer is intended only to speed up the creation and population
of new TLDs where necessary and appropriate.
Regards
Daniel
Hello,
anyone has hints/advices about the following problem:
We (GARR-NIS) have registered a new domain under .it with the following records:
eurolan.it. 604800 NS ns.iunet.it.
604800 NS eurolan.it.
eurolan.it. A 192.106.195.1
As you can see one of the servers (a secondary at the moment, may become
the primary in the future) has the same name of the whole domain.
I think this should not be a problem, but querying our server we
do not get information about autoritative servers:
Query about eurolan.it for record types ANY
Trying eurolan.it ...
Query done, 1 answer, authoritative status: no error
eurolan.it 432000 IN A 192.106.195.1
On the contrary, querying the primary server we get the right answer:
Query about eurolan.it for record types ANY
Server: ns.iunet.it
Address: 192.106.1.1
Trying eurolan.it ...
Query done, 8 answers, authoritative status: no error
eurolan.it 14400 IN SOA ns.iunet.it postmaster.iunet.it (
930224 ;serial (version)
28800 ;refresh period
14400 ;retry refresh time
604800 ;expiration period
14400 ;default ttl
)
eurolan.it 432000 IN NS ns.iunet.it
eurolan.it 432000 IN NS eurolan.it
eurolan.it 172800 IN A 192.106.195.1
eurolan.it 14400 IN MX 0 eurolan.it
eurolan.it 14400 IN MX 10 relay.iunet.it
eurolan.it 14400 IN MX 20 relay1.iunet.it
eurolan.it 14400 IN MX 50 mcsun.eu.net
Additional information:
ns.iunet.it 604800 IN A 192.106.1.1
ns.iunet.it 463543 IN A 130.251.1.17
eurolan.it 172800 IN A 192.106.195.1
relay.iunet.it 14400 IN A 192.106.1.2
relay1.iunet.it 14400 IN A 192.106.1.3
mcsun.eu.net 94962 IN A 192.16.202.1
---------- ----------
Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it
GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito
c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246
Via S. Maria, 36 Telex: 500371 CNUCE I
56126 PISA Italy Fax: +39 (50) 904052
---------- ----------
Here is the final draft agenda for the DNS WG meeting :
* old items, including a second root name server in Europe
* IPng support (input needed from IPng (TUBA/SIP/PIP/TPIX) groups)
* software and tools (BIND version 4.9.2)
* input for Piet Beertema's internet draft on DNS (BIND) config errors
(draft-ietf-dns-config-errors-00.txt)
We need 1.0 hour to 1.5 hours.
Thanks
Francis.Dupont(a)inria.fr
PS: I apologize but I was at a (very fine) summer school without decent
connections...
PS for the NCC: we need some copies of the Piet's document.
>> Dear colleagues,
>>
>> rather nasty bogus info for NS.NIC.DDN.MIL is spreading, and your host already
Please be aware that there is bogus info for KAVA.NISC.SRI.COM. as well.
Please look for address
223.184.64.35
which is given for KAVA.NISC.SRI.COM in addition to 192.33.33.24.
>> got it:
>
>Hello Ruediger,
>
> Try: dig -x 137.129.1.1
>and then check your cache...
>
>Even though you seem to accept commonly happening faults in German DNS
>configurations, this one is in France...
>
>It took circa 30-40 minutes to get that fault to happen the first time
>after I restarted the dns server. Once I found that, French site, it
>is repeatable reliably :-( -- 5 minutes later, it seems I can't repeat
>that at all.. No, again... Now with "named -d 255", which gives somewhat
>more data.. There we are.
>
> Yes, we definitely get the contamination from 137.129.150.2
>( xdata.cnrm.meteo.fr, DNS manager: company(a)ctidev.cnrm.meteo.fr )
>
I'm not quite sure whether this one is the origin of the bogus data. I just
queried this host and it still has bogus data for NS.NIC.DDN.MIL and
KAVA.NISC.SRI.COM.
>
> /Matti Aarnio <mea(a)nic.funet.fi> Postmaster
Arnold Nipper
nipper(a)xlink.net
XLINK Hostmaster
Dear colleagues,
rather nasty bogus info for NS.NIC.DDN.MIL is spreading, and your host already
got it:
; <<>> DiG 2.0 <<>> @nic.funet.fi NS.NIC.DDN.MIL. any
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10
;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 2, Addit: 2
;; QUESTIONS:
;; NS.NIC.DDN.MIL, type = ANY, class = IN
;; ANSWERS:
NS.NIC.DDN.MIL. 517916 A 192.112.36.4
NS.NIC.DDN.MIL. 131377 A 192.112.36.255
;; AUTHORITY RECORDS:
NIC.DDN.MIL. 205986 NS NIC.DDN.MIL.
NIC.DDN.MIL. 205986 NS DIIS-DEV.DDN.MIL.
;; ADDITIONAL RECORDS:
NIC.DDN.MIL. 205986 A 192.112.36.5
DIIS-DEV.DDN.MIL. 205986 A 192.112.38.89
;; Sent 1 pkts, answer found in time: 1120 msec
;; FROM: heinz to SERVER: nic.funet.fi 128.214.6.100
;; WHEN: Tue Aug 24 14:57:50 1993
;; MSG SIZE sent: 32 rcvd: 144
(for servers of the other To; addressees please see trace at the bottom)
We don't have yet an idea about the source for this; I would not be too
surprised if some misconfigured server in Germany is the source - but as
it already spread to Finland, probably warning should be distributed
more widely.
Any hints about possible sources for the bad A record would be appreciated.
(so far I have only seen TTLs of upto 160000, and most in teh range of 130000)
Best regards,
Ruediger
Ruediger Volk
Universitaet Dortmund, Informatik IRB DE-NIC
D-44221 Dortmund, Germany
E-Mail: rv(a)Informatik.Uni-Dortmund.DE
Phone: +49 231 755 4760 Fax: +49 231 755 2386
; <<>> DiG 2.0 <<>> @dfnnoc.GMD.DE NS.NIC.DDN.MIL.
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10
;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 8, Addit: 13
;; QUESTIONS:
;; NS.NIC.DDN.MIL, type = A, class = IN
;; ANSWERS:
NS.NIC.DDN.MIL. 494406 A 192.112.36.4
NS.NIC.DDN.MIL. 129880 A 192.112.36.255
;; AUTHORITY RECORDS:
. 494406 NS NS.INTERNIC.NET.
. 494406 NS AOS.ARL.ARMY.MIL.
. 494406 NS KAVA.NISC.SRI.COM.
. 494406 NS C.NYSER.NET.
. 494406 NS TERP.UMD.EDU.
. 494406 NS NS.NASA.GOV.
. 494406 NS NIC.NORDU.NET.
. 494406 NS NS.NIC.DDN.MIL.
;; ADDITIONAL RECORDS:
NS.INTERNIC.NET. 500936 A 198.41.0.4
AOS.ARL.ARMY.MIL. 517638 A 128.63.4.82
AOS.ARL.ARMY.MIL. 517638 A 192.5.25.82
AOS.ARL.ARMY.MIL. 32753 A 26.3.0.29
KAVA.NISC.SRI.COM. 500936 A 192.33.33.24
KAVA.NISC.SRI.COM. 86839 A 223.184.64.35
C.NYSER.NET. 500936 A 192.33.4.12
TERP.UMD.EDU. 500936 A 128.8.10.90
NS.NASA.GOV. 500936 A 128.102.16.10
NS.NASA.GOV. 500936 A 192.52.195.10
NIC.NORDU.NET. 500936 A 192.36.148.17
NS.NIC.DDN.MIL. 494406 A 192.112.36.4
NS.NIC.DDN.MIL. 129880 A 192.112.36.255
;; Sent 1 pkts, answer found in time: 779 msec
;; FROM: heinz to SERVER: dfnnoc.GMD.DE 192.88.108.8
;; WHEN: Tue Aug 24 15:22:53 1993
;; MSG SIZE sent: 32 rcvd: 475
; <<>> DiG 2.0 <<>> @deneb.dfn.de NS.NIC.DDN.MIL.
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10
;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 2, Addit: 2
;; QUESTIONS:
;; NS.NIC.DDN.MIL, type = A, class = IN
;; ANSWERS:
NS.NIC.DDN.MIL. 445700 A 192.112.36.4
NS.NIC.DDN.MIL. 129700 A 192.112.36.255
;; AUTHORITY RECORDS:
NIC.DDN.MIL. 166305 NS NIC.DDN.MIL.
NIC.DDN.MIL. 166305 NS DIIS-DEV.DDN.MIL.
;; ADDITIONAL RECORDS:
NIC.DDN.MIL. 166305 A 192.112.36.5
DIIS-DEV.DDN.MIL. 166305 A 192.112.38.89
;; Sent 1 pkts, answer found in time: 579 msec
;; FROM: heinz to SERVER: deneb.dfn.de 192.76.176.9
;; WHEN: Tue Aug 24 15:25:43 1993
;; MSG SIZE sent: 32 rcvd: 144
I am collecting the ideas for the DNS WG agenda...
Here are some elements:
- a second root name server in Europe
- IPng support (input needed from IPng (TUBA/SIP/PIP/TPIX) groups)
- last BIND software (version 4.9.2 is still beta)
Francis.Dupont(a)inria.fr
Oops,
Sorry people, the last message about the database software was supposed to
have gone to the db-wg in stead of the dns-wg. Not that you cannot try the
stuff if you do not want to, but still ...
-Marten
Dear all,
We finally have some beta software running at the NCC for the database, and
we would like you to test some things. We have created an empty test RIPE
database on ncc.ripe.net running with the new whois daemon. You can send in
updates to:
testdb(a)ripe.net
It will be processed and incorporated in a test database running on
ncc.ripe.net (also a whois daemon running on that database). You should
receive a ack mail back (to the Reply-To field, or From: is no Reply-To field
present) and you should be able to find it in the whois server immediately.
Acks should be send to you within minutes.
You can also delete objects in that test database, by simply adding a delete:
line to an object. So,
person: Marten Terpstra
address: RIPE Network Coordination Centre (NCC)
address: Kruislaan 409
address: NL-1098 SJ Amsterdam
address: Netherlands
phone: +31 20 592 5065
fax-no: +31 20 592 5090
e-mail: marten(a)ripe.net
nic-hdl: MT2
changed: marten(a)ripe.net 930503
source: RIPE
delete: just try and delete this thing
should delete this object in the database, if all fields are the same as in
the database. The ordering of fields does not matter, just as long as
attributes with the same name are in the same order, ie in the object above
you cannot change the place of two "address:" fields. Also the place of the
delete field does not matter, it can be anywhere in the object. Updating
should be very quick, ack mails should be send to you within minutes.
Please try some stuff and see what happens. Comments on the format of the ack
mail are also appreciated. Currently verbose ack is default ie you get at
least a one line ack per object you send in, and the full object if there
were errors or warnings. If you send in objects with a source other than RIPE
it should complain that this is an unknown source and should refuse the
update.
-Marten
PS All requests are already properly logged so be careful with those
deletes ;-)
PPS The syntax checker for this test database is VERY strict, simply because
there is no manual intervention from the NCC any longer. It may well be that
existing objects in the real database are no longer accepted ;-)
