- dns-wg - mailman.ripe.net

Re: Fundamental problem with mandatory field zone-c
by Marten Terpstra 26 Nov '93

26 Nov '93

Ruediger Volk <rv(a)deins.informatik.uni-dortmund.de> writes * Andreas writes: * > There is no zone for aic.de, thus there is no zone contact. * and the data base entry for AIC.DE is gone also... * * > Opinions ? * possible ways out: * * (a) drop domain entries completely * (b) don't register MX-only domains (in RIPE db) * (c) make zone-c optional (with the convention that this is only allowed * for MX-only domains) * (d) insert the zone contact for MX-only - defaulting to zone-c of * the zone containing the MX * * I vote for (c) In the past (Blasco has mentioned this before) we said to include the zone-c of the parent zone, since he/she maintains the MX records. This is Ruediger's option (d). Looking at the number of syntax errors in the database currently for domains, and the population, I would even vote for (a) or (b), but this has been rejected by the dns-wg on several occassions (on very good grounds). The question was and is whether the domain objects give added information compared to what is in the DNS. With 4.9 and the TXT and RP RRs I am not quite sure if these grounds still hold ... Other opinions ? -Marten PS I have CCed the dns-wg as well ...

4 3

Query: What to do if you use an A record but can't handle mail
by arthur＠midir.ucd.ie 11 Nov '93

11 Nov '93

Gentlemen - Apologies for intruding in this manner, but I have a query for which the usual sources don't seem to have an answer. What is the collective wisdom on providing A records (for Internet access) but stopping mail access? There are a large number of machines here in University College Dublin which require Internet access but can't run a SMTP server (they're PC and the like). I want to ensure that anyone trying to send mail to them gets a prompt refusal -- what I plan to do to is provide a DNS entry like this: toaster.ucd.ie. IN A 137.43.2.29 toaster.ucd.ie. IN MX undeliverable.ucd.ie. The host undeliverable.ucd.ie doesn't exist, which should as far as I know return a prompt "can't deliver mail" message. So, is this how other people do it? Is this the right way? Is there a better way? Any and all suggestions will be gratefully received. - Arthur Green University College Dublin Computing Services Tel: +353 1 706 2456 Fax: +353 1 283 7077 E-mail: arthur(a)midir.ucd.ie

2 1

Re: MX in IN-ADDR.ARPA domains?
by hh＠tip.net 13 Oct '93

13 Oct '93

At 04:55 PM 10/13/93 +0100, Daniel Karrenberg wrote: > > > hh(a)tip.net (Hakan Hansson) writes: > > > > Well, I have only experience from sendmail, and there it is possible to > > configure multiple mail-domains for incoming mail. Do you mean that this > > does no apply for all mail softwares? If so, then I agree that this was a > > bad idea.... > >Even with sendmail this depends on what your sendmail.cf >looks like and how well you can debug sendmail. > >Daniel > > I don't think it is hard to do that, just do like this: Cmubn.net Cmse.ubn.net Cmtip.net Cmtipnet.se Cmsti.se Cm44.193.in-addr.arpa /Hakan

2 1

Re: MX in IN-ADDR.ARPA domains?
by hh＠tip.net 13 Oct '93

13 Oct '93

At 04:41 PM 10/13/93 +0100, Daniel Karrenberg wrote: > > > hh(a)tip.net (Hakan Hansson) writes: > > Hi there, > > > > Then I come to think of: > > Why couldn't he send a request to hostmaster(a)44.193.in-addr.arpa? > >The main problem would be that not even all sevice providers >will get their mail systems to recognise hostmaster(a)44.193.in-addr.arpa >as local mail! > >Daniel > Well, I have only experience from sendmail, and there it is possible to configure multiple mail-domains for incoming mail. Do you mean that this does no apply for all mail softwares? If so, then I agree that this was a bad idea.... /Hakan

2 1

MX in IN-ADDR.ARPA domains?
by hh＠tip.net 13 Oct '93

13 Oct '93

Hi there, Now we have delegation of the IN-ADDR.ARPA domains from the root servers, similar to the delegation of the 'ordinary' domains. Before this happened there were only one single registry that handled all the reverse NS delegations, former <hostmaster(a)nic.ddn.mil>. This was easy to understand. Yesterday I spent some time trying to explain for one of our customers how the registration currently works. Well, you know the story.... Then I come to think of: Why couldn't he send a request to hostmaster(a)44.193.in-addr.arpa? The information about the hostmaster of each domain is of course already viewable in the zone files, but wouldn't it be more user-fiendly to be able to address the hostmaster of the IN-ADDR domain directly? Maybe this way of using IN-ADDR.ARPA isn't approved in applicable RFC's (I haven't checked)? Regards, Hakan Hansson == Unisource Business Networks Sweden == Unidata IP Services * TIPnet NMC * Gothenburg == phone +46-31-7708072 * fax +46-31-114664 *** Aktiv medlem i '8:e bit:ens vdnner' ***

2 1

DNS form for JINR
by root＠jimex.jinr.dubna.su 05 Oct '93

05 Oct '93

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

2 1

two Mediterrean TLDs dropped!???
by Ruediger Volk 28 Sep '93

28 Sep '93

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.NET ADM.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.NET NS.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)

2 2

RIPE NCC Temporary Registrar
by Daniel Karrenberg 23 Sep '93

23 Sep '93

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

1 0

host and domain with same name
by bonito＠nis.garr.it 21 Sep '93

21 Sep '93

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 ---------- ----------

1 0

DNS WG at the 16th RIPE meeting (final draft)
by Francis Dupont 09 Sep '93

09 Sep '93

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.

1 0