March 2007 - dns-wg - mailman.ripe.net

What about the last mile, was: getting DNSSEC deployed
by Roy Arends 06 Apr '07

06 Apr '07

Kudo's to TDC Song, C&W and others. Real nice they're validating data. So what about joe end user. Are there initiatives to offer tsig/sig0/dtls between user and isp ? Are there initiatives to deploy code at the OS level, similar as to what the NLNetLabs and Sparta folk are building for the application level ? Are formentioned providers deploying either of these two sets of solutions to their end users ? Or is it all just security theater ? Bring dns validation to where dns requests are initiated and where it is consumed; at the end user. That part is still vulnerable to spoofing while we're trying to secure the invisible infrastructure. Note that with end user validation, and well established methods to update the end users' certificate store, we might be well on our way. See also: http://dnss.ec/blog/?p=10 Sure, signing the root is crucial, and I'm not convinced dlv is a viable alternative, but thats all meaningless if layer 6/7 don't get some fondling. Roy

14 49

use of "rev-srv" attribute in "inetnum" (and "inet6num") objects
by Peter Koch 04 Apr '07

04 Apr '07

Dear colleagues, rather recently I was involved in clearing up some old inetnum assignments in the RIPE database. During that archaeologic work a couple of objects with the "rev-srv" attribute were discovered and it turned out that the presence of this attribute not necessarily contributed to an easy solution. The rev-srv attribute was intended to specify the name servers for the "reverse mapping" for a given address range. However, it is just informative in nature. For quite some time now the automatic generation of the IN-ADDR.ARPA zones has been based solely on the "domain" objects (see <http://www.ripe.net/reverse/>). So, it turns out "rev-srv" has some disadvantages: (D1) the "rev-srv" attribute is redundant, because only "domain" objects cause delegations to be present in reverse zone maintained by the NCC (D2) "rev-srv" lacks consistency checks with both the reality and any potential "domain" object; several attributes just contain incorrect information (D3) the "rev-srv" attribute does not really help finding the zone for address ranges smaller than /24 (where delegations are following RFC 2317) On the other hand, it might still have advantages: (A1) where there is a delegation from an NCC maintained zone to an LIR for, say, a /16 address range, the "rev-srv" attribute for enclosed /24s may provide useful additional information (A2) even if the leaf zone name cannot be guessed for RFC 2317 delegations, the "rev-srv" attribute might help in locating the zone containing the CNAME RRs (A3) "rev-srv" attributes could provide additional information in legacy class B space (D1), (D2), and (A1) similarly apply to v6 reverse and inet6num objects. Today, approximately 5% of all "inetnum" objects have at least one "rev-srv" attribute. Of these objects, 17% have been changed in 2007 (which does not imply the rev-srv was changed or checked), and 35% were changed in 2006 or 2007. That means "rev-srv" does not only appear in old objects, but may still be carried as a legacy. The objects with "rev-srv" are maintained by 1300 different maintainers, almost 500 of which own only a single object with "rev-srv". Given the confusion mentioned in the introduction and looking at the pros and cons (where the lists above are not meant to be exhaustive), what is the use of "rev-srv" for a "user" of the object or for its publisher/maintainer? The DB WG chairs' advice was that the purpose and/or future of "rev-srv" should be discussed here first. That said, what do you think about deprecating the "rev-srv" attribute? -Peter (speaking as $self)

9 10

Agenda Items for RIPE54
by Jim Reid 24 Mar '07

24 Mar '07

It's time to invite the WG to make suggestions for agenda items and discussion topics for next month's RIPE meeting. Please let the WG co-chairs know if you have suggestions for the agenda in Tallin.

1 0

RIPE NCC KSK Rollover Announcment
by Brett Carr 20 Mar '07

20 Mar '07

-- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam

1 0

Maintenance on ns-tld.ripe.net
by Brett Carr 15 Mar '07

15 Mar '07

[Apologies for duplicate e-mails] Dear Colleagues, On Wednesday, 21 March 2007, the authoritative DNS Services on the ns-tld.ripe.net server will be unavailable between 20:00 and 21:00 UTC. This will affect all ccTLD nameservers contained within the server including all servers named in the format 'ns-ccTLD.ripe.net'. During this time we will carry out essential maintenance work. We apologise in advance for any inconvenience that this may cause. If you have any questions or concerns about this, send an e-mail to dns-help(a)ripe.net. Regards, Brett Carr DNS Services Group Manager RIPE NCC

1 0

ICANN Successfully Conducts Laboratory Tests of Internationalised Domain Names
by Leo Vegoda 08 Mar '07

08 Mar '07

Hi, Anyone interested in the deployment of IDNs might be interested yesterday's announcement of the successful conclusion of laboratory tests of internationalised TLDs in a setting corresponding to the public root. The announcement, details of the test setup and results can be found at: http://www.icann.org/announcements/announcement-4-07mar07.htm Regards, -- Leo Vegoda IANA Numbers Liaison

1 0

Maintenance on ns-pri.ripe.net
by Brett Carr 05 Mar '07

05 Mar '07

[Apologies for duplicates] Dear Colleagues, On 7 March, 2007, authoritative Reverse DNS Services on ns- pri.ripe.net will be unavailable between 20:00 and 21:00 UTC. During this maintenance window, the server will be upgraded to NSD version 3.0.4. We apologise for any inconvenience this causes. If you have any questions or concerns about this, please e-mail: dns- help(a)ripe.net -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam

1 0