- dns-wg - mailman.ripe.net

Re: [dns-wg] Delegation checking policy/procedure at ARIN
by Thor Kottelin 15 May '03

15 May '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dns-wg-request(a)ripe.net wrote: > From: "JFC (Jefsey) Morfin" <jefsey(a)jefsey.com> > when the nameserver is on the same machine as > the site, I never understood why I would need two name servers. > Either the machine is in operation or not. Why could I not > have only one nameserver in that case? As a practical example, someone might need to look up the mail address in your SOA record while "the machine" is down. More generally speaking, domains are administrative entities; using second level domains to name individual boxes is not good namespace administration. Thor - -- http://thorweb.anta.net/ PGP public key available "Women should always wear tight clothes, and men should carry powerful handguns." - Calvin (by Bill Watterson) -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPsNfh+lROe8ye3NFEQLKDQCfdulKFvL1NJ5MdfIARNl9ER1aE4EAoJKV QNm51VjqQB09CyOLkKCHKtiB =8AQi -----END PGP SIGNATURE-----

1 0

Re: [dns-wg] Delegation checking policy/procedure at ARIN
by Jim Reid 15 May '03

15 May '03

>>>>> "JFC" == JFC (Jefsey) Morfin <jefsey(a)jefsey.com> writes: JFC> When I cannot register a ".fr" or a ".tp" name because of the JFC> retsrictions imposed by their NICs I am upset. I would prefer JFC> - and I would be gratefull - if they told me what is wrong I JFC> could correct when I want, but securing the DN in the JFC> meanwhile? This is really something to discuss with the registry concerned. There should be some forum where its customers -- or stakeholders -- can influence policy. However registries don't usually run DNS consultancy businesses, so there will be limits on what they can and cannot do. It's hard to see where chatty help messages for the DNS-clueless would stop and DNS consulting starts: how much help and advice is "enough"? And how much of that consultancy can a registry afford to do when it's only getting a few bucks for the registration? JFC> Example: when the nameserver is on the same machine as the JFC> site, I never understood why I would need two name servers. Read section 3.3 of RFC2182. In fact, read the whole RFC. JFC> I would be really interested if Patrick's work permitted JFC> that: to tell me what may be wrong in my files and to teach JFC> me to correcty right them? Well, someone from AFNIC will be talking about their new delegation checking tools and processes at the WG tomorrow. The presentation should be on the RIPE web site by early next week at the latest. I'm hoping the WG will use tomorrow's session on delegation checking to work on this topic: perhaps produce a BCP or something like that. If this gets under way, it would be useful to get contributions on things like the nature of error messages and so on.

4 4

Delegation checking policy/procedure at ARIN
by Jim Reid 13 May '03

13 May '03

Ed Lewis will be giving a presentation at the WG next week on ARIN's proposals for checking DNS delegations. I've passed a copy of his slides to RIPE NCC for their comments. [This could well turn out to be a subject that RIRs might want to co-ordinate or establish a commpn policy.] The slides probably won't be on the RIPE web site until after WG, so apologies that the detail isn't available yet. Ed's kindly provided the following shopping list of stuff that ARIN are considering. These issues -- and others! -- are likely to crop up if/when a similar policy is adopted by RIPE NCC. I've forwarded Ed's summary to the list so that we can think about this and perhaps have a discussion on the mailing list before the WG meets. Hopefully this could bring some focus to the panel session that's been arranged for the WG next week. ------- Forwarded Message Message-Id: <a05111b0ebad47bb890b7(a)[192.168.1.100]> Date: Tue, 29 Apr 2003 15:07:00 -0400 To: Jim.Reid(a)nominum.com, Patrik Faltstrom <paf(a)cisco.com>, Peter Koch <pk(a)techfak.uni-bielefeld.de> From: Edward Lewis <edlewis(a)arin.net> Subject: ripe 45 notes Cc: Edward Lewis <edlewis(a)arin.net> ARIN's membership has adopted a policy (found at the following URL: http://www.arin.net/policy/2002_1.html). The policy omits many engineering details, as these are being uncovered we are noting them. This presentation is a discussion of issues identified to date. Note that this is an engineering discussion, not a report on progress nor a statement on findings. Most of the presentation consists of a laundry list of issues. Here is a synopsis of the issues: 0) What is the purpose? 1) Data is stored in different formats - registration database is not a mirror of the DNS. People will have different perspectives - other than DNS. 2) When is a good time to report problems? How can this be done (wrt time ordering) in a clear manner? 3) Data in DB changes over time, even in result of testing reports 4) Incremental nature of tool development 5) Staff impacts, how this will impact those who answer the email and phones 6) Kinds of (and importance of) statistics 7) Firmness of testing, how rigorous? 8) Correlating data in the DB, specifically ASN's and prefixes with the context being RIR specific here - -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer It's true, my last college class really was "Introduction to Ada." ------- End of Forwarded Message

6 6

Signing the Root Zone to be discussed in TechSec WG @ Barcelona
by Daniel Karrenberg 13 May '03

13 May '03

Point C on the agenda below might be interesting for people on this list. Daniel ----- Forwarded message from Daniel Karrenberg <daniel.karrenberg(a)ripe.net> ----- Date: Tue, 13 May 2003 06:50:16 +0200 From: Daniel Karrenberg <daniel.karrenberg(a)ripe.net> To: techsec-wg(a)ripe.net Cc: meeting(a)ripe.net, webmaster(a)ripe.net, Lars-Johan Liman <liman(a)autonomica.se>, Yuri Demchenko <demch(a)nlnetlabs.nl>, "Olaf M. Kolkman" <olaf(a)ripe.net> Subject: Agenda TechSec-wg Barcelona TechSec-ers, Over the last few weeks there have been additional agenda points suggested. Because of other obligations I am a bit late with updating the agenda. My sincere apologies. Here is my suggestion so far. There should be time for more, so if you have relevant material, just be there and we will bash the agenda. (for Ted) Daniel ----- A. Administrative Matters - scribe - list of participants - agenda - minutes B. Disi report, Olaf Kolkman - 15 minutes Report on the status of the DISI project and the state of DNSSEC in the IETF. C. Signing the Root Zone, Johan Ihren (via Lars-Johan Liman) - 40 minutes Presentation on draft-ietf-dnsop-interim-signed-root-01.txt and draft-ihren-dnsext-threshold-validation-00.txt. Also some discussion whether the RIPE NCC should spend time on this. See also message <3EA54B21.3070307(a)ripe.net> from Andrei Robachevsky on the dns-wg and local-ir mailing lists. D. Fonkey project update: target applications, Yuri Demchenko - 15 minutes. Short information about the status of the project and description of target applications, including extended PGP keyserver, attributes/privilege server, location server. E. Overview of Related Activities Elsewhere, Yuri Demchenko - 20 minutes Information about activities and projects among CSIRT community (IETF INCH WG and IODEF development, CERT/CC and TF-CSIRT projects, usage of IRT object in RIPE NCC Database by CSIRT community). Short overview of PKI/AA activities and exploring interest of WG in providing more information about PKI/AA developments (in context of supporting PKI based RIPE NCC Improved Secure Communication System), including training courses. F. Any Other Business ----- End forwarded message -----

1 0

Re: [dns-wg] Delegation checking policy/procedure at ARIN
by Jim Reid 06 May '03

06 May '03

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: >> Ed Lewis will be giving a presentation at the WG next week on >> ARIN's proposals for checking DNS delegations. I've passed a >> copy of his slides to RIPE NCC for their comments. [This could >> well turn out to be a subject that RIRs might want to >> co-ordinate or establish a commpn policy.] The slides probably >> won't be on the RIPE web site until after WG, so apologies that >> the detail isn't available yet. Brad> Specifically, I was thinking about a distributed Brad> collection script and a centralized checking facility, where Brad> results could be posted to the appropriate mailing lists and Brad> newsgroups, in much the same way as the reports made by Rob Brad> Thomas to the NANOG mailing list (especially his "lame Brad> delegation" report at <http://www.cymru.com/DNS/lame.html>). I encourage you (and others) to expand on these thoughts on the list. Or if you'd prefer, bring this to the WG at a future RIPE meeting. Brad> Perhaps this is something that could be done in Brad> conjunction with the RIRs? Could we all pool our resources? Brad> Perhaps we can talk to Rob as well? These are all good ideas. In fact the RIRs are mumbling about having a common policy on this. We should know more after Ed's presentation and the panel session in Barcelona next week. My hope is there will be enough commitment for the subject to become a work item for the WG. This subject is going to become more important and there's a gap here that will need to be filled, possibly soon. IMO the WG is an ideal forum for the discussion to take place because of the combination of operational, policy and standards issues that are involved.

2 1

Announcement RIPE NCC DNSSec Training Courses
by RIPE NCC Training 01 May '03

01 May '03

------- Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the DNSSec Training Course. The main objective of the DNSSec Training Course is to provide LIRs with sufficient background to be able to deploy DNSSec in their own organisation as soon as the protocol is standardised. This course also explains the specific procedures set up by the RIPE NCC to to secure the in-addr.arpa zone. The Domain Name System (DNS) is one of the main parts of the Internet infrastructure. At the moment DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSec is a set of extensions to provide this end-to-end authenticity and integrity. It is currently being developed within the IETF dnsnext Working Group. The protocol is about to be finalised and the code implementing the protocol is available in alpha releases. The DNSSec course consists of two parts: an "Introduction to DNSSec" and a real life demonstration. The "Introduction to DNSSEC" will cover: - DNS security threats - DNSSec security mechanisms - DNSSec server protection - DNSSec data protection - Delegation issues - Key management issues - Current developments Examples are based on the BIND name server. Please note that DNSSec is an advanced course. It will: - NOT teach the basics of DNS. - NOT describe how to receive Internet resources from the RIPE NCC not describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network & system operators, engineers, etc. This course is not intended for administrative or management staff (e.g. Hostmasters). It is assumed that all attendees are familiar with common DNS terminology, have a practical knowledge in operating DNS servers and are interested in learning the concepts and mechanisms that DNSSec offers. The DNSSec course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the DNSSec Training Course can be found at: http://www.ripe.net/training/dnssec/ REGISTRATION: You can register for a course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> In order to register for a DNSSec Training Course you must be an employee of an LIR and either : - be an LIR contact - be confirmed by an LIR contact. LIR contacts are those employees of an LIR who are registered with the RIPE NCC as authoritative contact persons. It is expected that most of those interested in the DNSSec Training Course will not be an authorative contact persons for their LIR, and therefore will be refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, The RIPE NCC Training Team COURSE DATES AND VENUES +++++++++++++++++++++++ Date: Friday 4 July 2003 Time: 0900 - 1700 Location: Glasgow,Scotland AND: Date: Friday 18 July 2003 Time: 0900 - 1700 Location: Vienna, Austria AND: Date: Friday 19 September 2003 Time: 0900 - 1700 Location: Amsterdam, The Netherlands REGISTRATION FORM +++++++++++++++++ %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

[staff] [local-ir@ripe.net]signing the roots
by Andrei Robachevsky 01 May '03

01 May '03

Dear colleagues, At the DNS-WG at the last RIPE meeting (RIPE 44) Johan Ihren presented his proposal for an interim scheme for signing the public DNS root. The current version of this Internet-Draft is: draft-ietf-dnsop-interim-signed-root-01.txt The full text of this Internet-Draft can be found at: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-interim-signed-root-01… In the Internet-Draft, a mechanism has been proposed for a first stage of a transition from a unsigned DNS root to a signed root, such that the data in the root zone is accompanied by DNSSEC signatures to allow validation. The process of doing this involves the use of a set of operator keys which are signed by one key signing key, sometimes referred to a "master key". It has been further proposed that these key signing keys be managed by the Regional Internet Registries (RIRs). The proposal states the requirements of the RIRs would be to: * establish a secure out-of-band communication path in collaboration with the signing operators which will be used for authenticated exchange of the unsigned keyset. * periodically generate strong keys using a good random number generator * manage their keys (i.e. use them for signing the operator keyset and keeping the private key appropriately secret) Question: Since this Internet-Draft suggests future action by the RIRs, the RIPE community should discuss this issue and provide feedback to the author. Therefore, the following question is asked: Is this a task that should be performed by the RIPE NCC? Please direct your feedback to dns-wg(a)ripe.net mailing list. Regards, Andrei Robachevsky CTO, RIPE NCC

1 0

views.........please
by Mansoor Ahmed 29 Apr '03

29 Apr '03

Hi, I have a requirment of 2 views one for internal and one for external, the named.conf is very simple, but i am unable to query other domains when doing nslookup from outside, it is replaying root servers only. ------------------------------------------------------------ options { directory "/var/named"; pid-file "/var/named/named.pid"; }; logging { channel sec_channel { file "/var/tmp/named.security"; severity info; }; category security { sec_channel; default_syslog; default_debug; }; }; acl "corpnet" { 10.0.0.1; }; view "internal" { match-clients { "corpnet"; }; recursion yes; zone "." in { type hint; file "root.ca"; }; zone "domain-local" { type slave; file "domain-local.hosts"; allow-transfer { any; }; masters { 216.137.31.87; }; }; }; view "external" { match-clients { any; }; recursion no; zone "." in { type hint; file "root.ca"; }; zone "domain1.com" { type slave; file "domain1.com"; allow-transfer { none; }; masters { 216.137.31.87; }; }; }; Please advice, thanks in advance. Mansoor

1 0

I-D on SRV and whois servers
by Marcos Sanz/Denic 29 Apr '03

29 Apr '03

Hi all, In this version of the draft, Gerhard and I have incorporated comments made in the last WG session: http://www.ietf.org/internet-drafts/draft-sanz-whois-srv-00.txt Feedback and comments are very welcome. On the other hand I'd like to raise the question whether some registry zone administrators would be willing to include SRV records pointing to their whois servers, as .de and .at have done. This would increase the gene pool of the initiative. Regards, Marcos Sanz DENIC eG

1 0

add me
by Mansoor Ahmed 29 Apr '03

29 Apr '03

2 1