- dns-wg - mailman.ripe.net

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

Re: views in bind9
by Jim Reid 29 Apr '03

29 Apr '03

Mansoor, your question would probably be better posted to bind9-users(a)isc.org, rather than this mailing list. dns-wg(a)ripe.net is for stuff related to the RIPE DNS Working Group and doesn't usually deal with errors or misunderstandings about named.conf files. If you do post to bind-users, I strongly suggest you provide your named.conf file *exactly* as your name server would see it. [Don't hide domain names or whatever.] That would permit someone on that list to accurately diagnose the problem. My guess is you have syntax errors in named.conf or perhaps you're running a BIND8 name server with a BIND9 configuration file. If it's the former, you can use named-checkconf from BIND9 to find the error. A sample named.conf file which uses views can be found under the tests directory in the BIND9 distribution. This directory contains a test suite for most of the features in BIND9. Here's an outline of how to set up views in BIND9, with an inside view for network 10/8 and an outside view for everything else. options { ...... }; controls { ...... }; view "inside" { match-clients { 10/8; }; zone "." { ....... }; zone "example" { ..... }; }; view "outside" { match-clients { !10/8; }; zone "." { ....... }; zone "example" { ..... }; }; If you have further questions about BIND9 config file syntax, please take them to bind9-users(a)isc.org, not here. And please don't ask me directly. :-)

1 0

32.48.194.in-addr.arpa to 63.48.194.in-addr.arpa
by UTA HostMaster 31 Mar '03

31 Mar '03

hello there seems to be problem with the dns-entries for 32.48.194.in-addr.arpa to 63.48.194.in-addr.arpa. the entries in the RIPE-db have the correct dns (dns1.uta.at / ns1.ooe.gv.at). but the entries in ns.ripe.net show ns1.ooe.gv.at and ns.ooe.gv.at. is there a possibility to correct this without sending the reverse delegations again to auto-inaddr(a)ripe.net? > 63.48.194.in-addr.arpa Server: ns1.ooe.gv.at Address: 194.48.60.9 63.48.194.in-addr.arpa origin = ns1.ooe.gv.at mail addr = domain-admin.ooe.gv.at serial = 2001011600 refresh = 86400 (1D) retry = 7200 (2H) expire = 604800 (1W) minimum ttl = 3600 (1H) 63.48.194.in-addr.arpa nameserver = dns1.uta.at 63.48.194.in-addr.arpa nameserver = ns1.ooe.gv.at ns1.ooe.gv.at internet address = 194.48.60.9 > server ns.ripe.net Default Server: ns.ripe.net Address: 193.0.0.193 > set type=any > 63.48.194.in-addr.arpa Server: ns.ripe.net Address: 193.0.0.193 Authoritative answers can be found from: 63.48.194.in-addr.arpa nameserver = ns1.ooe.gv.at 63.48.194.in-addr.arpa nameserver = ns.ooe.gv.at with best regards ------------------------------------------------------- Peter Steinkellner Engineering & Operations Services UTA Hostmaster UTA Telekom AG Donau-City-Strasse 11 A-1220 Wien T: +43/1/9009-4130 F: +43/1/9009-3967 M: +43/699/1388-4130 mailto:peter.steinkellner@uta.at http://www.uta.at -------------------------------------------------------

2 1

Upgrade of 'NCC.RIPE.NET' - 2003-03-21 13:30-14:00 UTC
by Bruce Campbell 20 Mar '03

20 Mar '03

The RIPE NCC is upgrading a portion of the Hostcount project, 'NCC.RIPE.NET', between 13:30 and 14:00 (UTC) on the 21st of March, 2003 by replacing the hardware with a new machine. Sessions to this machine (updates of hostcount data) will be interrupted during this time. Kind regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security

1 0

Slot request for next RIPE Meting: ZoneCheck Tool from French NIC
by Mohsen Souissi 19 Mar '03

19 Mar '03

Hi Jim & Peter, As I told Jim this afternoon, AFNIC would like to present to the DNS community the new version of our ZoneCheck tool (ZoneCheckv2) which allows DNS zone checking with respect to DNS standards. Stephane D'Alu (address Cc'ed) wrote the new version from scratch. It fully supports IPv6 and open to support new technologies such as DNSsec and IDN. Here is the URL of a non-definitive version of our ZoneCheck tool : http://zonecheck.nic.fr/v2/ Should you need any further information, please send an e-mail to Stephane and/or zonecheck(a)nic.fr Thanks beforehand, Mohsen.

1 0