From ripe-wgs.cs at schiefner.de Thu Jun 1 14:35:24 2006 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 01 Jun 2006 14:35:24 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060601074456.GA16230@ripe.net> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> <4475FA0B.5070605@dougbarton.us> <1148584139.22101.27.camel@firenze.zurich.ibm.com> <447633D8.3040102@dougbarton.us> <20060601074456.GA16230@ripe.net> Message-ID: <447EDF0C.9080304@schiefner.de> Katie, to avoid any ambiguity in: Katie Petrusha wrote: > The IPv6 textual compressed form (Section 2.2.2, RFC 4291) is also > accepted (see examples) and will be converted into lowercase canonical > form. and to also cover: nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0 besides: > nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 I would like to see this paragraph rephrased to: The IPv6 notation can be case insensitive, the textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples). [ipv6_address] will always be converted into lowercase canonical form. Best, -C. From ripe-wgs.cs at schiefner.de Thu Jun 1 15:59:48 2006 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Thu, 01 Jun 2006 15:59:48 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060601131815.GG17136@ripe.net> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> <4475FA0B.5070605@dougbarton.us> <1148584139.22101.27.camel@firenze.zurich.ibm.com> <447633D8.3040102@dougbarton.us> <20060601074456.GA16230@ripe.net> <447EDF0C.9080304@schiefner.de> <20060601131815.GG17136@ripe.net> Message-ID: <447EF2D4.2040601@schiefner.de> Hi Katie. > [...] > > Examples: > > The following values would be allowed: > > domain: example.com > > nserver: ns1.example.com 192.0.2.1 > > nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0 > nserver: ns2.d1.example.com 2001:DB8:: > > nserver: ns2.d1.example.com 2001:db8:: > > All other variants of the values will be rejected. > > [...] Thanks & best, -C. From bmanning at vacation.karoshi.com Thu Jun 1 16:05:41 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 1 Jun 2006 14:05:41 +0000 Subject: [dns-wg] [RIR] Deprecation of ip6.int Scheduled for June 1, 2006 In-Reply-To: <4406FF0C.2070206@arin.net> References: <4406FF0C.2070206@arin.net> Message-ID: <20060601140541.GC28849@vacation.karoshi.com.> On Thu, Mar 02, 2006 at 09:19:56AM -0500, Member Services wrote: > In August 2005, RFC 4159 Deprecation of ip6.int was published as Best > Current Practice. This RFC noted that maintenance of ip6.int is no > longer required and that the Regional Internet Registries adopt a > schedule for cessation of ip6.int. All the RIRs have agreed to deprecate > ip6.int on June 1, 2006. Further note that ARIN no longer modifies any > of the zones it administers under ip6.int effective December 7, 2005. > > Ginny Listman > Director of Engineering > American Registry for Internet Numbers and: On Tue, 16 May 2006 11:09:10 +0200, Andrei Robachevsky wrote: > Below is the proposed plan of ip6.int deprecation. Could you please > check if it is detailed enough to be properly coordinated, or if it > misses something. > > Andrei > > ip6.int deprecation plan > ------------------------- > > Advance Work: > > Contact Bill Manning at bmanning at vacation.karoshi.com and > hostmaster at ep.net before the 25th of May and ask him to schedule the > following: > > o June 1st 12:00 GMT: Remove all delegations within the 2.ip6.int zone. > > RIR Plan (common) > > o May 30th 12:00 GMT: Drop TTL on authoritative NS records within the > ip6.int zones to 3600. > > o June 1st 12:00 GMT: All delegations within the ip6.int zone are > removed. No RIR Action needed, other than checking. > > o June 1st 13:00 GMT - 23:59 GMT: All RIR's remove their respective > ip6.int zones from their servers. ........ while i noted the following: not all the zones or data in ip6.int are being removed.... so no, i am not changing the TTLs. the delegations that the RIR's have asked to be removed are scheduled for automatic removal. I will check on the process when i wake up roughly 3.5 hours later. I will be glad to send you email at that time to confirm removal. --bill ....... that being said, the RIR requested delegations have been removed from the IP6.INT zone. what remains is: # dig 2.ip6.int. axfr @::1 ; <<>> DiG 9.3.2 <<>> 2.ip6.int. axfr @::1 ; (1 server found) ;; global options: printcmd 2.ip6.int. 86400 IN SOA dot.ep.net. hostmaster.ep.net. 1999061700 10800 900 604800 129600 2.ip6.int. 86400 IN NS z.ip6.int. 2.ip6.int. 86400 IN NS dot.ep.net. 2.ip6.int. 86400 IN NS flag.ep.net. 0.0.1.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 0.0.1.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 0.0.1.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 1.0.1.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 1.0.1.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 1.0.1.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 2.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 2.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 2.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 2.ip6.int. 86400 IN SOA dot.ep.net. hostmaster.ep.net. 1999061700 10800 900 604800 129600 ;; Query time: 4 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jun 1 06:44:20 2006 ;; XFR size: 14 records (messages 14) --bill From dr at cluenet.de Thu Jun 1 18:25:17 2006 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 1 Jun 2006 18:25:17 +0200 Subject: [dns-wg] [RIR] Deprecation of ip6.int Scheduled for June 1, 2006 In-Reply-To: <20060601140541.GC28849@vacation.karoshi.com.> References: <4406FF0C.2070206@arin.net> <20060601140541.GC28849@vacation.karoshi.com.> Message-ID: <20060601162517.GA2388@srv01.cluenet.de> On Thu, Jun 01, 2006 at 02:05:41PM +0000, bmanning at vacation.karoshi.com wrote: > not all the zones or data in ip6.int are being removed.... So we still need to get IANA to remove ip6.int completely to finally burry the dead horse. Sigh. Is this in the works already? What does it need? Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From david.conrad at icann.org Thu Jun 1 18:52:08 2006 From: david.conrad at icann.org (David Conrad) Date: Thu, 1 Jun 2006 09:52:08 -0700 Subject: [dns-wg] [RIR] Deprecation of ip6.int Scheduled for June 1, 2006 In-Reply-To: <20060601162517.GA2388@srv01.cluenet.de> References: <4406FF0C.2070206@arin.net> <20060601140541.GC28849@vacation.karoshi.com.> <20060601162517.GA2388@srv01.cluenet.de> Message-ID: <7EE5C072-456D-49D4-98CE-90242815F339@icann.org> Hi, Yes, it is in the works. I've been asking if anyone knows any reason why ip6 shouldn't be removed from .int. To date, only Bill Manning has expressed concerned. Rgds, -drc On Jun 1, 2006, at 9:25 AM, Daniel Roesen wrote: > On Thu, Jun 01, 2006 at 02:05:41PM +0000, > bmanning at vacation.karoshi.com wrote: >> not all the zones or data in ip6.int are being removed.... > > So we still need to get IANA to remove ip6.int completely to finally > burry the dead horse. Sigh. > > Is this in the works already? What does it need? > > > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From andrei at ripe.net Fri Jun 2 07:47:48 2006 From: andrei at ripe.net (Andrei Robachevsky) Date: Fri, 02 Jun 2006 07:47:48 +0200 Subject: [dns-wg] Re: Deprecation of ip6.int scheduled for 1 June 2006 In-Reply-To: <4471D95A.7010300@ripe.net> References: <4416BA2F.8080809@ripe.net> <4471D95A.7010300@ripe.net> Message-ID: <447FD104.1010204@ripe.net> Dear Colleagues, On 1 June 2006, the reverse delegations in the ip6.int DNS tree corresponding to IPv6 address space allocated by the RIPE NCC were deleted as planned. This means that these reverse delegations will no longer be supported. The corresponding DOMAIN objects were also deleted from the RIPE Whois Database. This has been coordinated with other Regional Internet Registries and is based on an IETF Best Current Practice document (RFC 4159). Regards, Andrei Robachevsky Chief Technical Officer RIPE NCC From dr at cluenet.de Fri Jun 2 10:51:17 2006 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 2 Jun 2006 10:51:17 +0200 Subject: [db-wg] Re: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060515095947.GA28870@ripe.net> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> <20060515095947.GA28870@ripe.net> Message-ID: <20060602085117.GA13030@srv01.cluenet.de> Dear Katie, On Mon, May 15, 2006 at 11:59:47AM +0200, Katie Petrusha wrote: > > What's the reason not to use one line per server and list all v4 an/or v6 > > addresses within that one line? > > 'One name per line' syntax seemed to be more clear and short... Hm, I disagree. I'd prefer a syntax like Peter proposes too. It's IMHO more logical to have one line per nameserver, and only list the glue addresses behind it. One nameserver, one line, with n (n >= 0) optional glue addresses. This would be logical and intuitive for me. All else needs more complicated parsing in mind and automated code. Sorry for the late comment, didn't have much time to follow discussions here lately. Feel free to ignore. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From katie at ripe.net Thu Jun 1 09:44:56 2006 From: katie at ripe.net (Katie Petrusha) Date: Thu, 1 Jun 2006 09:44:56 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <447633D8.3040102@dougbarton.us> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> <4475FA0B.5070605@dougbarton.us> <1148584139.22101.27.camel@firenze.zurich.ibm.com> <447633D8.3040102@dougbarton.us> Message-ID: <20060601074456.GA16230@ripe.net> On Thu, May 25, 2006 at 03:46:48PM -0700, Doug Barton wrote: Dear colleagues, I have updated the proposal; hopefully all parties are now satisfied with the changes. Please find the proposal below. > > Thus my 'vote': represent with compressed lowercase. > > But I could live with uncompressed too, as long as it would be done then > > also everywhere in a consistent fashion. > > On that we are in complete agreement. Proposal for the change of "nserver:" syntax in "domain" object in the RIPE Whois Database ---------------------------------------------- Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and the updated delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server with or without a trailing "." [ipv4_address] is an IPv4 address of the name server, in decimal dotted quad form [ipv6_address] is an IPv6 address of the name server, in lowercase canonical form (Sect 2.2.1, RFC 4291) The IPv6 textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples) and will be converted into lowercase canonical form. If [domain_name] is followed by an IP address, it must be inside the domain that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be accepted: domain: example.com nserver: ns1.example.com 192.0.2.1 nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 nserver: ns2.d1.example.com 2001:DB8:: nserver: ns2.d1.example.com 2001:db8:: All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. All IPv6 glue addresses in "nserver:" attribute will be represented in domain objects in the RIPE Whois Database in the lowercase uncompressed form, e.g. 2001:db8:0:0:0:0:0:0. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: The introduction of the new syntax will add the following new DNS checks for glue records: * every glue record has at least one IPv4 or IPv6 address specified in domain object (error otherwise) * glue record name is inside the domain to be delegated (error otherwise) * glue nameserver should be authoritative for his own A/AAAA record (error otherwise) -- Katie Petrusha RIPE NCC From katie at ripe.net Thu Jun 1 15:18:15 2006 From: katie at ripe.net (Katie Petrusha) Date: Thu, 1 Jun 2006 15:18:15 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <447EDF0C.9080304@schiefner.de> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> <4475FA0B.5070605@dougbarton.us> <1148584139.22101.27.camel@firenze.zurich.ibm.com> <447633D8.3040102@dougbarton.us> <20060601074456.GA16230@ripe.net> <447EDF0C.9080304@schiefner.de> Message-ID: <20060601131815.GG17136@ripe.net> On Thu, Jun 01, 2006 at 02:35:24PM +0200, Carsten Schiefner wrote: Thanks Karsten, Posting the corrected proposal below. > Katie, > > to avoid any ambiguity in: > > Katie Petrusha wrote: > >The IPv6 textual compressed form (Section 2.2.2, RFC 4291) is also > >accepted (see examples) and will be converted into lowercase canonical > >form. > > and to also cover: > > nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0 > > besides: > > >nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 > > I would like to see this paragraph rephrased to: > > The IPv6 notation can be case insensitive, the textual compressed form > (Section 2.2.2, RFC 4291) is also accepted (see examples). > [ipv6_address] will always be converted into lowercase canonical form. > > Best, > > -C. Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and the updated delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server with or without a trailing "." [ipv4_address] is an IPv4 address of the name server, in decimal dotted quad form [ipv6_address] is an IPv6 address of the name server, in lowercase canonical form (Section 2.2.1, RFC 4291) The IPv6 notation can be case insensitive, the textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples). [ipv6_address] will always be converted into lowercase canonical form. If [domain_name] is followed by an IP address, it must be inside the domain that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.example.com 192.0.2.1 nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 nserver: ns2.d1.example.com 2001:DB8:: nserver: ns2.d1.example.com 2001:db8:: All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. All IPv6 glue addresses in "nserver:" attribute will be represented in domain objects in the RIPE Whois Database in the lowercase uncompressed form, i.e. 2001:db8:0:0:0:0:0:0. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: The introduction of the new syntax will add the following new DNS checks for glue records: * every glue record has at least one IPv4 or IPv6 address specified in domain object (error otherwise) * glue record name is inside the domain to be delegated (error otherwise) * glue nameserver should be authoritative for his own A/AAAA record (error otherwise) -- Katie Petrusha RIPE NCC From katie at ripe.net Thu Jun 1 16:04:24 2006 From: katie at ripe.net (Katie Petrusha) Date: Thu, 1 Jun 2006 16:04:24 +0200 Subject: [dns-wg] Re: [db-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <447EF2D4.2040601@schiefner.de> References: <4475ECAE.80205@dougbarton.us> <1148579895.22101.6.camel@firenze.zurich.ibm.com> <4475FA0B.5070605@dougbarton.us> <1148584139.22101.27.camel@firenze.zurich.ibm.com> <447633D8.3040102@dougbarton.us> <20060601074456.GA16230@ripe.net> <447EDF0C.9080304@schiefner.de> <20060601131815.GG17136@ripe.net> <447EF2D4.2040601@schiefner.de> Message-ID: <20060601140424.GI17136@ripe.net> On Thu, Jun 01, 2006 at 03:59:48PM +0200, Carsten Schiefner wrote: Carsten, I've corrected it :) Please find it below. > > >[...] > > > >Examples: > > > >The following values would be allowed: > > > >domain: example.com > > > >nserver: ns1.example.com 192.0.2.1 > > > >nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 > > nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0 > > >nserver: ns2.d1.example.com 2001:DB8:: > > > >nserver: ns2.d1.example.com 2001:db8:: > > > >All other variants of the values will be rejected. > > > >[...] > > > Thanks & best, > > -C. Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and the updated delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server with or without a trailing "." [ipv4_address] is an IPv4 address of the name server, in decimal dotted quad form [ipv6_address] is an IPv6 address of the name server, in lowercase canonical form (Section 2.2.1, RFC 4291) The IPv6 notation can be case insensitive, the textual compressed form (Section 2.2.2, RFC 4291) is also accepted (see examples). [ipv6_address] will always be converted into lowercase canonical form. If [domain_name] is followed by an IP address, it must be inside the domain that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.example.com 192.0.2.1 nserver: ns1.d1.example.com 2001:db8:0:0:0:0:0:0 nserver: ns1.d1.example.com 2001:DB8:0:0:0:0:0:0 nserver: ns2.d1.example.com 2001:DB8:: nserver: ns2.d1.example.com 2001:db8:: All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. All IPv6 glue addresses in "nserver:" attribute will be represented in domain objects in the RIPE Whois Database in the lowercase uncompressed form, i.e. 2001:db8:0:0:0:0:0:0. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: The introduction of the new syntax will add the following new DNS checks for glue records: * every glue record has at least one IPv4 or IPv6 address specified in domain object (error otherwise) * glue record name is inside the domain to be delegated (error otherwise) * glue nameserver should be authoritative for his own A/AAAA record (error otherwise) -- Katie Petrusha RIPE NCC From david.kessens at nokia.com Thu Jun 1 19:11:19 2006 From: david.kessens at nokia.com (David Kessens) Date: Thu, 1 Jun 2006 10:11:19 -0700 Subject: [dns-wg] [RIR] Deprecation of ip6.int Scheduled for June 1, 2006 In-Reply-To: <7EE5C072-456D-49D4-98CE-90242815F339@icann.org> References: <4406FF0C.2070206@arin.net> <20060601140541.GC28849@vacation.karoshi.com.> <20060601162517.GA2388@srv01.cluenet.de> <7EE5C072-456D-49D4-98CE-90242815F339@icann.org> Message-ID: <20060601171119.GC24122@nokia.com> David, On Thu, Jun 01, 2006 at 09:52:08AM -0700, David Conrad wrote: > > Yes, it is in the works. > > I've been asking if anyone knows any reason why ip6 shouldn't be > removed from .int. To date, only Bill Manning has expressed concerned. I think the summary from the last RIPE meeting was that most people expressed concern why this has still not been done ;-). David Kessens --- From katie at ripe.net Fri Jun 2 11:59:01 2006 From: katie at ripe.net (Katie Petrusha) Date: Fri, 2 Jun 2006 11:59:01 +0200 Subject: [db-wg] Re: [dns-wg] Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060602085117.GA13030@srv01.cluenet.de> References: <20060515070249.GA26086@ripe.net> <20060515083020.GB11280@unknown.office.denic.de> <20060515095947.GA28870@ripe.net> <20060602085117.GA13030@srv01.cluenet.de> Message-ID: <20060602095901.GA23697@ripe.net> On Fri, Jun 02, 2006 at 10:51:17AM +0200, Daniel Roesen wrote: Dear Daniel, Thanks for your input. From the delegation checker point of view, every pair " " is treated as a separate entity, undergoing its own checks, hence my preference for the syntax that reflects this. However if anybody else has strong preferences for either variant of the syntax, please let us know, so we could wrap this discussion up and send final proposal. > Dear Katie, > > On Mon, May 15, 2006 at 11:59:47AM +0200, Katie Petrusha wrote: > > > What's the reason not to use one line per server and list all v4 an/or v6 > > > addresses within that one line? > > > > 'One name per line' syntax seemed to be more clear and short... > > Hm, I disagree. I'd prefer a syntax like Peter proposes too. It's > IMHO more logical to have one line per nameserver, and only list the > glue addresses behind it. > > One nameserver, one line, with n (n >= 0) optional glue addresses. This > would be logical and intuitive for me. All else needs more complicated > parsing in mind and automated code. > > Sorry for the late comment, didn't have much time to follow discussions > here lately. Feel free to ignore. :-) > > > Best regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 -- Katie Petrusha RIPE NCC From katie at ripe.net Fri Jun 2 14:29:43 2006 From: katie at ripe.net (Katie Petrusha) Date: Fri, 2 Jun 2006 14:29:43 +0200 Subject: [dns-wg] Re: Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060602.132247.35858695.he@uninett.no> References: <20060601074456.GA16230@ripe.net> <447EDF0C.9080304@schiefner.de> <20060601131815.GG17136@ripe.net> <20060602.132247.35858695.he@uninett.no> Message-ID: <20060602122943.GA24500@ripe.net> On Fri, Jun 02, 2006 at 01:22:47PM +0200, Havard Eidnes wrote: Dear Havard, > it's possible that I've overlooked the real background of this > issue, so please forgive me for asking: > > > Motivation: > > > > We plan to automate management of DNS delegation in the > > e164.arpa zone (ENUM). The provisioning system, with the RIPE > > Database as a front end, must support IPv6 glue records. > > While I can agree that out of completeness it is good to have the > support for glue records in the software, I still wonder if > anyone has specifically asked for being able to name the name > servers for these delegation points within the delegated domain? Yes, this feature was explicitly requested. > This would be the only real reason for registering the glue > information, as otherwise the glue information is not needed, and > in fact might be extraneous information more likely to cause > confusion and a maintenance problem than actually being helpful. > Anyone for a "detect unneeded glue" feature? ;-) > > After all, there's a strictly limited number of delegations which > the RIPE database software needs to handle. > > Regards, > > - H?vard -- Katie Petrusha RIPE NCC From randy at psg.com Fri Jun 2 18:58:58 2006 From: randy at psg.com (Randy Bush) Date: Fri, 2 Jun 2006 06:58:58 -1000 Subject: [dns-wg] Re: [db-wg] Re: Proposal to change the syntax of "nserver:" attribute References: <20060601074456.GA16230@ripe.net> <447EDF0C.9080304@schiefner.de> <20060601131815.GG17136@ripe.net> <20060602.132247.35858695.he@uninett.no> <20060602122943.GA24500@ripe.net> Message-ID: <17536.28242.339798.978566@roam.psg.com> >> While I can agree that out of completeness it is good to have the >> support for glue records in the software, I still wonder if >> anyone has specifically asked for being able to name the name >> servers for these delegation points within the delegated domain? > > Yes, this feature was explicitly requested. perhaps a clue record would be more appropriate? randy From he at uninett.no Fri Jun 2 13:22:47 2006 From: he at uninett.no (Havard Eidnes) Date: Fri, 02 Jun 2006 13:22:47 +0200 (CEST) Subject: [dns-wg] Re: Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060601131815.GG17136@ripe.net> References: <20060601074456.GA16230@ripe.net> <447EDF0C.9080304@schiefner.de> <20060601131815.GG17136@ripe.net> Message-ID: <20060602.132247.35858695.he@uninett.no> Hi, it's possible that I've overlooked the real background of this issue, so please forgive me for asking: > Motivation: > > We plan to automate management of DNS delegation in the > e164.arpa zone (ENUM). The provisioning system, with the RIPE > Database as a front end, must support IPv6 glue records. While I can agree that out of completeness it is good to have the support for glue records in the software, I still wonder if anyone has specifically asked for being able to name the name servers for these delegation points within the delegated domain? This would be the only real reason for registering the glue information, as otherwise the glue information is not needed, and in fact might be extraneous information more likely to cause confusion and a maintenance problem than actually being helpful. Anyone for a "detect unneeded glue" feature? ;-) After all, there's a strictly limited number of delegations which the RIPE database software needs to handle. Regards, - H?vard From jim at rfc1035.com Tue Jun 6 10:59:00 2006 From: jim at rfc1035.com (Jim Reid) Date: Tue, 6 Jun 2006 09:59:00 +0100 Subject: [dns-wg] Re: Proposal to change the syntax of "nserver:" attribute In-Reply-To: <20060602.132247.35858695.he@uninett.no> References: <20060601074456.GA16230@ripe.net> <447EDF0C.9080304@schiefner.de> <20060601131815.GG17136@ripe.net> <20060602.132247.35858695.he@uninett.no> Message-ID: On Jun 2, 2006, at 12:22, Havard Eidnes wrote: > While I can agree that out of completeness it is good to have the > support for glue records in the software, I still wonder if > anyone has specifically asked for being able to name the name > servers for these delegation points within the delegated domain? Yes. I'm probably the guilty one who started this. ENUM delegations use the same process and templates as reverse delegation. When 4.4.e164.arpa got delegated years ago, in-bailiwick glue was requested and I was surprised that wasn't then possible. Carsten was the NCC's Mr. ENUM at the time. He might well remember kludging a workaround for that problem. From pk at DENIC.DE Mon Jun 12 20:12:43 2006 From: pk at DENIC.DE (Peter Koch) Date: Mon, 12 Jun 2006 20:12:43 +0200 Subject: [dns-wg] DRAFT meeting minutes DNS WG @RIPE52 In-Reply-To: <20060525194437.GB17032@denics7.denic.de> References: <20060525194437.GB17032@denics7.denic.de> Message-ID: <20060612181243.GB1177@unknown.office.denic.de> Dear DNS WG, > here are the draft meeting minutes for Istanbul. Please have a look at the > text and send comments or requests for changes to the wg chairs until > June, 17th. the draft minutes are also available at . > You'll find the list of five new action items at the end. Please verify > the transcript, especially if you're quoted or have (been) volunteered > for an action. -Peter From pk at DENIC.DE Thu Jun 29 16:53:35 2006 From: pk at DENIC.DE (Peter Koch) Date: Thu, 29 Jun 2006 16:53:35 +0200 Subject: [dns-wg] Final RIPE 52 DNS WG minutes Message-ID: <20060629145335.GT2727@unknown.office.denic.de> Dear DNS WG, here are the final edited meeting minutes for Istanbul. There were no comments received for the draft version posted in , so the changes are a typo and a clarification of action item 52.3 only. Thanks again to Adrian for the minutes and to Susannah and Caz for acting as jabber proxies. -Peter ----------------------------------------------------------------------------- RIPE DNS WG minutes for RIPE 52, Istanbul ----------------------------------------------------------------------------- WG: DNS Meeting: RIPE 52, Istanbul Date-1: Thursday, 27 April 2006 Time-1: 11:00 - 12:30 (UTC +0300) Chair-1: Peter Koch Minutes-1: Adrian Bedford Jabber: xmpp:dns at conference.ripe.net J-Scribe-1: Susannah Gray J-Script-1: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/dns.txt Audio-1: http://www.ripe.net/ripe/meetings/ripe-52/podcasts/dns-01.mp3 WG URL: http://www.ripe.net/ripe/wg/dns/ Material: http://www.ripe.net/ripe/meetings/ripe-52/presentations/index.html Agenda: http://www.ripe.net/ripe/meetings/ripe-52/agendas/dns.html ----------------------------------------------------------------------------- 0) Administrivia To remove the need for changeover between presenters, Andrei asked that items 4 and 5 be switched. The WG agreed to this. There were no other changes to the agenda. ----------------------------------------------------------------------------- 1) Status Reports o IANA Overview (David Conrad, IANA) Daniel Karrenberg commented on the proposed new IANA website, he was interested to see it was a draft and that feedback was encouraged. Jim Reid asked about the IDN testing and wondered if this would happen within the root zone or if there would be a test bed. David replied that this would be discussed in more depth in the next slot. If it were to happen within the root zone, IANA would be involved; otherwise they would not have a role in this. o IETF - DNSEXT, DNSOP and Others (Olaf Kolkman, NLnetLabs) Ed Lewis asked about experiences people had with split view DNS. Around 15 people said that they had. He also wondered if people who had inherited systems found them confusing. His questions lead him to ask how important the IETF documents were on this topic. Although the particular draft (draft-krishnaswamy-dnsop-dnssec-split-view) was more than a year old, there had been little comment. Olaf replied that there is a need for people to commit to work with the DNSEXT and DNSOP working groups and review papers. If there are not five people willing to do this, then the work is stalled. Carsten Schiefner asked if there was any relationship between the nameserver ID flag (draft-ietf-dnsext-nsid) and Host Identity Protocol (HIP). Olaf explained there was no relationship. Daniel Karrenberg commented that if using split DNS, it is vital to review your work regularly. The deployments out there use different nameservers to make for easier debugging. He added that maybe there is no current solution to the problem. o DNSSEC News/Statistics from the NCC (Brian Riddle, RIPE NCC) Daniel Karrenberg suggested the RIPE NCC prepare a presentation on the causes of the extra network traffic (in excess of the predicted growth) for the next RIPE Meeting. This was accepted as an action item. Jim Reid asked what might be causing the additional 4% of CPU cycles. Brian promised to investigate and report back. Ed Lewis asked about registration activity and requested that the RIPE NCC report on how many signed zones and how many signed delegations exist in the NCC maintained reverse tree. Brian agreed to look into this and report back either through the working group mailing list or at the next meeting. Olaf commented that when writing ripe-352, the authors promised to look at the effects of DNSSEC on the amount of due queries. A paper on this is ready for publication on the NLnetLabs website. (post meeting hint: ----------------------------------------------------------------------------- 2) Action Item Review (Peter Koch) 48.1 This is still to be written up - ongoing 48.2 Mans had made some progress, he will continue the work, including a SIG(0) approach and hopes to complete the work by the next RIPE Meeting - ongoing 49.1 This is on hold as a presentation is being made to the NCC Services Working Group. 49.2 Some work has been done. Jim will circulate a draft to Fernando and the DNS WG co-chairs in the coming weeks. - ongoing 51.1 see plenary presentation on K-root 51.2 see (4) 51.3 Liman has still to write this up. It will possibly be handed over to the NCC Services Working Group. For now it will stay with this group until there is further clarification on the proposal. - ongoing 51.4 - ongoing 51.5 see (6) ----------------------------------------------------------------------------- 3) Anycast on K-Root (Lorenzo Colitti, RIPE NCC) Daniel Karrenberg noted that he hoped everyone was happy with how the RIPE NCC was running K. Andrei later amplified this and outlined a few plans to deploy a further global node on the west coat of the US and then gradually more local nodes. They would look at where successful local nodes existed. He wanted to know that the community supported these plans. Comments were made that local nodes tended to have greater impact when deployed in places where there were no global nodes and in more remote locations. Daniel thanked him for these comments, but wished to point out that global nodes are paid for by the RIPE NCC as the operator, local nodes have a contribution made by local hosts. There was a question about whether the RIPE NCC could look into doing some work to compare experiences and impacts gained by other root operators and look at different set-ups in use. Lorenzo said he would personally find this interesting. Daniel Karrenberg backed this by saying he felt it would be useful work. He asked that anyone with suggestions should contact Lorenzo directly. Randy Bush wished to state that he was happy with how the service had been running so far. He had reported a bug and was encouraged by the response from the RIPE NCC to resolve the issue. ----------------------------------------------------------------------------- 5) Reverse DNS Quality (Brian Riddle, RIPE NCC) George Michaelson commented that it was interesting that Brian felt the difference in measure might come down to methodology. He added that it might just be that APNIC have a higher level of lameness than the RIPE NCC. He attributed some of this to stronger admission controls within the domain update process. APNIC have discussed both tightening and weakening their rules. He concluded by saying that the reason that APNIC had 13% lame, compared with 9% in RIPE, came down to better running of the DNS. Olaf asked what definition was used of lames. Brian replied that a record was seen as lame whenever there was no authoritative answer for the SOA. Jim Reid observed that lameness will always be with us. We need to look at ways of dealing with it rather than keep trying to eliminate it completely. He did feel that we needed to do something from a point of view of operational impact and the resultant load that lameness placed on servers. It would be a good step to alleviate problems rather than just keep insisted to everyone that they should keep their DNS in good order. This presentation, he added, was follow-on from an incident that Jim noticed and flagged to the RIPE NCC. There was a lame delegation caused by a master being unathoritative for an extended period of time. There is a need to look at the issues around the progression of a slave secondary service, a part of doing this job responsibly is having some kind of policy and escalation mechanism for flagging lame master servers. This would make sure something is done before a zone expires on the slave servers. Carsten Schiefner said he would like to see some measures in place to check whether the nameserver set of the parent exactly matches the nameserver set announced by the master of the zone. People can change their configuration all the time and there can be nothing on the master server of the child zone. He felt that monitoring this exact match would be an issue, particularly if these changes are also to be applied for ENUM zones. Peter Koch declared this out of scope for this discussion. Ed Lewis asked what would be done when something is lame and gives no response, should it be taken out of DNS and remove the NS record. Brian asked for the community to give guidance on this. Peter Koch suggested that there be an action on the RIPE NCC to post their questions and write up a proposal and question to submit to the working group mailing list. This would be discussed further offline and formulated as action point. ----------------------------------------------------------------------------- 4) IP6.INT Phase Out (Andrei Robachevski, RIPE NCC) There was a short discussion about the best way forward with this. A major concern was that all RIRs should coordinate their work to ensure that all IP6.INT delegations are pulled at the same time. David Conrad commented that as maintainer of the .INT domain he had asked about the impact of simply pulling IP6.INT through various mailing lists. He had seen little in the way of significant negative implications suggested if this happened. He was backed up on this by George Michealson, who commented that he had spent some time trying to find any IP6.INT queries without success. Joao and Daniel noted that if something serves no purpose, then it should go. There was a note of caution sounded by David Conrad. RIRs must work together and agree on a date for this to happen. David Kessens commented that it would be useful to discuss this topic further in the IPv6 Working Group later today. ----------------------------------------------------------------------------- 6) Proposal to Bring ENUM Zone Management in Line with the Reverse DNS (Andrei Robachevski, RIPE NCC) Carsten Schiefner commented that he welcomed this proposal. Jim Reid stated that care was needed when it came to the top delegations under E164.ARPA concern national resources. There are issues of sovereignty and national interests. If we are going to report errors in the delegations, we need to handle it with a degree of sensitivity. It could impact on other things that are not directly connected with the RIPE NCC. Andrei replied that it was equally dangerous to keep errors in the delegation. Appropriate checks will stop the errors from propagating into the system. Daniel Karrenberg stressed that the RIPE NCC was sensitive to the issues, but the priority had to be to keep things working. The IAB would be informed as the party responsible for E164.ARPA. Carsten felt the actions remained unclear and that it was up to the group to define the actions. 51.5 was changed to 52.5 to work together to put forward a semi proposal, or a pre-formal proposal on this and the ENUM WG lists and coordinate between the two groups. Andrei saw two parts of the proposal. One side involved automating and making the existing system less error prone, this is just a call to improve the system. The other side was to look at doing regular lameness checks and looking at how the RIPE NCC should act on these. An action was put on Carsten to come up for a more formal proposal for discussion at working group level, it was felt this should not yet be put forward at the more formal level of the RIPE Policy Development Process. Andrei asked for consensus that this should go through to the Database Working Group to have the RIPE NCC automate checks. There was no objection. ----------------------------------------------------------------------------- Date-2: Thursday, 27 April 2006 Time-2: 16:00 - 17:00 (UTC +0300) Chair-2: Jaap Akkerhuis Minutes-2: Adrian Bedford J-Scribe-2: Caz Merrison J-Script-2: http://www.ripe.net/ripe/meetings/ripe-52/transcripts/dns.txt Audio-2: http://www.ripe.net/ripe/meetings/ripe-52/podcasts/dns-02.mp3 ----------------------------------------------------------------------------- 7) Plenaries Followup Time was given to discussions that followed on from presentations that happened during the plenary. There were several DNS related presentations in the plenary, of which "Security and ENUM" had been discussed in the ENUM Working Group. There was no feedback or questions from the room on any of those presentations. ----------------------------------------------------------------------------- 8) ICANN IDN guidelines & IDN Future (Marcos Sanz, DENIC) During the presentation Patrik F?ltstr?m asked about the issue that arises when, for example, URLs such as deutschebank.de and deutsche-bank.de occurs. He wondered if this was the end of the problem. Marcos replied that he did not feel it was. Rob Blokzijl commented that although the presenter started out by saying it was unwise to look at domain name labels as words, he went on to talk about the confusion that occurs when this happens. Marcos agreed, pointing out that he was talking merely about the ICANN guidelines. There are assumptions made about what is in a domain name and he felt this was not the right direction to follow. Rob noted that language is a very rich thing and trying to constrain it in domain names was unwise. He did not feel that any rules or regulations would help. Olaf encouraged everyone to take a look at the IAB document which touched on the same type of issues raised here. It will be published after 17 May 2006. ----------------------------------------------------------------------------- 9) Dynamic Registry Updates (John Dickinson, Nominet) Jaap Akkerhuis asked if the work mentioned was available for public use. John replied that it was. Jim Reid asked if tools had been used to inspect the contents of journal files. John replied that this area had been left alone. He also wondered what type of sanity checking was in place when managing the updates. John replied that currently, all existing information was removed from zone files and then the updates made within the same transaction to avoid any errors or duplicate entries. Peter Koch asked for clarification on the point made that updates ran in batches of 500. John explained that updates happened every minute. Whatever was there was automatically updated, if there was less than 500, it would run anyway, if there were more than 500, they would be processed in consecutive batches of a maximum of 500 updates. The discussion then moved onto reliance on transfer methods, John stressed that backup methods were in place where there were potentials for communication errors. It was stressed that this was not to be seen as real-time dynamic updating. The TTL and SOA values had not been adjusted and there were no plans to do this. ----------------------------------------------------------------------------- X) I/O with other WGs ENUM related issues were already covered under (6). ----------------------------------------------------------------------------- Y) AOB Peter Koch wished to follow up on a discussion in the Plenary. An Internet Draft will soon be published addressing both reflection and amplification attacks. He encouraged everyone here to read this and comment on it through both the DNS WG Mailing List and also through the IETF DNSOP List. A show of hands suggested a need to cross post the announcement about the draft. ----------------------------------------------------------------------------- Z) Wrap-Up & Close Jaap summarized the action items: 52.1 RIPE NCC: investigate causes for extra DNSSEC network traffic (in excess of the predicted growth) and extra CPU cycles 52.2 RIPE NCC: report number of signed zones and signed delegations in the reverse tree 52.3 RIPE NCC: post questions and proposal to wg mailing list on how to deal with lame delegations when either the NCC is responsible for maintaining the parent or for running a (secondary) server for the child that is or is about to become delegated lame due to an unavailable *xfr source. [this is related to 48.1, but differs in that it should suggest ways forward for ns*.ripe.net] 52.4 RIPE NCC: automate and streamline the process for ENUM delegations, including checks similar to those applied to the reverse tree 52.5 Carsten Schiefner: [continued from 51.5] write a proposal for performing regular lameness checks in E164.ARPA and actions to follow -----------------------------------------------------------------------------