- dns-wg - mailman.ripe.net

Re: in-addr.arpa zone data in RIPE database
by jalm＠spirou.puug.pt 03 Mar '93

03 Mar '93

...... Still, there are the issues of the DNS versus the DB, but I feel that others are already dealing with that one ;-) In the previous discussion concerning DNS and RIPE database coherence, I think that we should try to keep separate different issues (DNS and RIPE dbm). 1) We have a system designed to deal with addressing, naming servers, etc. the DNS. We should concentrate on this system for this purpose. It should be considered the real source of information for the data it as been designed to deal with. So, the place were I can find the information about servers, addresses, etc. is in the DNS. Well, DNS has been designed to be managed in a decentralized way. This is a very good point but it has a very bad point: in general it contains lots of errors and inconsistencies. Conclusion: we should invest in tools to detect such errors and notify the administrators concerned. There are some of these tools available in the archive of RIPE. Anyway, I, as an administrator, would prefer to have a single point of focus for stating which are the servers running authoritative for my domain or for the reverse mapping of my network and that is the DNS, nothing more. 2) We have the RIPE database: this is a very good tool to deal with some administrative data. Well, lets use it for this purpose. Anyway, we should avoid to have to deal manually with DUPLICATE data. So, we should avoid to have information about servers and addresses of those servers in the RIPE dbm. My suggestion is: use the RIPE dbm to deal * only * with those informations that cannot be effectively registered in the DNS. If we decide to maintain in the RIPE dbm information about DNS servers, those fields should be automatically updated from the DNS on a (for example) monthly basis. And its semantics should be seen as "the vison about this subject that the tools of the RIPE NCC have been able to extract from the DNS some XXX days ago". I do not believe on centralized repositories and management unless I have no other way to avoid it. I do not believe in consistency maintained mannually by hundreds (thousands ?) of administrators. Jose'

2 1

Re: in-addr.arpa zone data in RIPE database
by keith＠pipex.net 02 Mar '93

02 Mar '93

In <9303021347.AA06706(a)mcsun.EU.net>, <Piet.Beertema(a)mcsun.EU.net> wrote: > Interaction is fine. But RIPE stepping into someone else's > authority is quite something different! > I don't see any problem with that as long as we (european > networking people) agree to send update to the RIPE-NCC > instead of sending them to the NIC. > RIPE-DB and DNS are entirely different objects. I would > like RIPE to notify me *in some cases* about discrepancies > between my entries in the RIPE-DB and my DNS entries, but > I do *NOT* want RIPE to step into my authority by asking > or telling the NIC to change *MY* DNS info because they > found discrepancies: I may well have good reason why those > discrepancies exist. This is a bit of an aside to the debate above, but there is something that has struck me as obvious which would make the management of in-addr.arpa much easier for everyone, and help with the above issue. Why not get all of 193.in-addr.arpa delegated to the RIPE NCC, and have it in turn delegate xx.193.in-addr.arpa to the service providers ? That way we don't have to deal directly with the creaking NIC, but authority is still delineated clearly by existing DNS mechanisms. This has not been possible in the past, due to the restriction of in-addr DNS delegations needing to be on byte boundaries, *but* that is exactly how the RIPE supernet block is being assigned. Or have I missed a good reason why this won't work ? Keith Mitchell Network Manager Public IP Exchange keith(a)pipex.net 216 The Science Park keith(a)unipalm.co.uk Cambridge, UK Phone: +44 223-424616 Fax: +44 223-426868

3 2

DNS support for IPv7
by Francis Dupont 28 Feb '93

28 Feb '93

The RARE-WG4-CLNS is looking for an implementation of the DNS support for TUBA (cf the draft RFC from B. Manning). We can spread this demand to all the IPv7 proposals (TUBA, SIP, PIP, ...). Thanks Francis.Dupont(a)inria.fr PS (rumours): an implementation of Manning's proposal for TUBA and an other one for SIP could be available...

1 0

too small TTLs !
by Francis Dupont 28 Feb '93

28 Feb '93

In France we have a lot of problems with the name service of some Japanese sites: the distance between us and them is a little bit more than 30 hops then with a too small UDP default time to live the packets are dropped in transit with a TIME_EXCEEDED error... A recommendation should be produce about this in the IETF DNS group. I propose to recommend that "on name servers default TTLs must be set to a value greater or equal to 60" immediatly in RIPE. Regards Francis.Dupont(a)inria.fr PS: for network operators: you should note the DNS packets in transit with TTL less than 20 and signal them to senders. This can be spread to other services.

1 0

Re: zone-c not mandatory
by rv＠deins.informatik.uni-dortmund.de 22 Feb '93

22 Feb '93

I agree completely. > I think Blasco has a point there and will implement this > unless someone cries "stop". for MX-only domains both name server and zone contact attributes are actually attributes of the parent (or an ancestor) domain. Cheers, Ruediger > Daniel > > ------- Forwarded Message > > Date: Fri, 19 Feb 93 18:49:25 MET > From: bonito(a)nis.garr.it (Antonio_Blasco Bonito) > To: ripe-dbm(a)ripe.net > cc: staff(a)nis.garr.it > Subject: zone-c tag > > Hello NCC people, > > I think the update procedure is not right giving the following error: > > > domain: fis.uniurb.it > > descr: Universita' degli Studi di Urbino > > descr: Istituto di Fisica > > remarks: It is a public institution devoted to researches in some field s > > remarks: of Physics and Biomedical Engineering and teaching > > admin-c: Filippo Martelli > > tech-c: Flavio Vetrano > > tech-c: Pietro Dominici > > remarks: MX-only > > source: RIPE > > changed: domain(a)nis.garr.it 930217 > > WARNING: mandatory attribute "zone-c" missing in object > > A MX-only domain has no nameserver and therefore cannot have a zone-c > contact information. > I think that zone-c should not be considered a mandatory attribute. > > All my best. > - ---------- ---------- > 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 > - ---------- ---------- > > ------- End of Forwarded Message > Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC Postfach 500 500 D-W-4600 Dortmund 50 Germany E-Mail: rv(a)Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386

3 3

european parliament
by Pierre.Verbaeten＠cs.kuleuven.ac.be 05 Feb '93

05 Feb '93

Hello, After our discussion in Praag, I contacted the european parliament again: - they agree to register under be - they choose eppe as domain name. This abreviation is often used. As suggested in the meeting in Praag the name eppe should be reserved in other countries. Regards, Pierre

2 1

Re: RIPE 14 - WG meetings
by k13＠nikhef.nl 21 Jan '93

21 Jan '93

1 0

Re: RIPE 14 - WG meetings
by Erik-Jan.Bos＠SURFnet.nl 21 Jan '93

21 Jan '93

Francis, > Draft agenda for the meeting of the DNS WG at RIPE-14 in Prague : > > Old open items : > - root servers in Europe > - global DNS server coordination in Europe > - cookbook, advices, horror stories, ... > - DNS software (with known bugs) and tools > > Special items for RIPE-14 : > - BIND 4.9 (a beta version is available) > - (again) names for European organizations (European Parliament) > - DNS for IPv7 (TUBA/SIP/PIP) > > Actions (from RIPE-13) : > - cookbook on DNS : the "DNS and BIND" O'Reilly book is not yet available > in Europe (but I am trying to get one for the meeting) then I propose to > extend this action. I can take mine, if you want. > Needed for this meeting : > - a report about BIND 4.9 > - input for DNS support for IPv7 __ Erik-Jan.

1 0

Re: RIPE 14 - WG meetings
by Francis Dupont 21 Jan '93

21 Jan '93

Draft agenda for the meeting of the DNS WG at RIPE-14 in Prague : Old open items : - root servers in Europe - global DNS server coordination in Europe - cookbook, advices, horror stories, ... - DNS software (with known bugs) and tools Special items for RIPE-14 : - BIND 4.9 (a beta version is available) - (again) names for European organizations (European Parliament) - DNS for IPv7 (TUBA/SIP/PIP) Actions (from RIPE-13) : - cookbook on DNS : the "DNS and BIND" O'Reilly book is not yet available in Europe (but I am trying to get one for the meeting) then I propose to extend this action. Needed for this meeting : - a report about BIND 4.9 - input for DNS support for IPv7 Regards Francis.Dupont(a)inria.fr

1 0

Re: domain name for european parliament
by Dave Morton 18 Jan '93

18 Jan '93

>I have been passed on the following message and would like to comment >on it: > >> Yes - we told them it might not be a good idea in the >> long term but what can you do.... >> >> Not much. It's a bit surprising though that the NIC did >> accept this registration from people outside DG. > >We have been funded by the CEC/BRA to set up an support infrastructure >to help researchers in Europe exchange information and to supply >support for issues like storage, naming, etc. The infrastructure is based >on a large number of fileservers throughout Europe using AFS as main >technology. Although in the startup phase aiming to support the nodes >covered by the three first Networks Of Excellence: ELSNET, CaberNet and >Compulog, the infrastructure is supposed to be the blueprint for an >infrastructure also covering the new NOE's formed last year. > >In the framework of naming we wanted to enable resolution through >the DNS. As there was no top domain available that would cover a >general CEC organization, under which the infrastructure could be placed, >we requested (with full knowledge and appreciation of DG) a domain name >for a top domain ec.org. This domain was to be managed by the Infrastructure >Task Force of the proposed infrastructure for a startup-period, after >which the management of the top domain would be handed over to an >institution selected by DG. The subdomains dedicated to the research >infrastructure would still be managed by our own people. > >(Instead of calling it "funny", Dave, you could have explained all this >as you are aware of most of the details of the infrastructure provision, >including the naming part) Werner, yes - this is true I could have mentioned all the above at the risk of flooding the whole list. However you may have missed the original e-mail requesting guidance on the provision of a domain name for the Europen Parliment. What I mean by "funny" is (and I mentioned it to the NOEs when this suggestion of ec.org was made) that we would have multiple organisations connected in one way or another to the commission or the EC all seeking to register domain names in an uncoordinated way. At the time I suggested consulting the RIPE people for guidance but I think this didn't happen. As other more experienced DNSs have already mentioned there are many good reasons to think twice before registering any old name just because it might sound reasonable. And yes - I'm still not convinced registration under .org was a good choice. Perhaps I should have been more careful in my choice of words - it's not funny - it's a pity that it was not thought about a little more beforehand. >> And as >> far as the nameservers are concerned: > >..... > >> So not to be taken serious. > >I do not think that is a remark to be made without any further >consultation of the people involved. > >At the time of registration of the ec.org name, the machines to run the >servers were not yet delivered. The two names were supplied to the NIC >as being "temporary", to be replaced as soon as the initial part of the >research infrastructure was in place. The first two servers (INESC and >Univ. of Twente) are running now, while this week the servers at the >Univ. of Newcastle and at LAAS will be added. Our first concern is to >have the AFS servers properly running, after that the NIC will be informed >about which machines will provide the DNS service. It might also be a good idea to inform the RIPE NCC so that people in Europe also know what's going on. Dave

1 0