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

Agenda for RIPE54
by Jim Reid 24 Apr '07

24 Apr '07

Here is the agenda for the DNS WG sessions in Tallinn. This will be on the RIPE web site shortly. As always, items may be subject to last minute changes due to external circumstances. # # $Id: dnswgagenda,v 2.2 2007/04/24 14:00:20 jim Exp $ # [1] Administrivia (5 mins) [2] Review of Action Items (15 mins) [3] IETF WG news update (10 mins) Anton Verschuren, SIDN (TBC) [4] NCC Update (10 mins) Brett Carr, RIPE NCC [5] Proposal on rev-srv (10 mins) Peter Koch, DENIC [6] Finding a DNSSEC Trust Anchor (30 mins) Mats Dufberg, TeliaSonera In the absence of a signed root zone, DNS resolving risks of either being isolated (only for the local TLD) or cumbersome and error-prone (through the chasing for the latest key of all signed TLD's). It is in the interest of both ISP's and DNSsec if there would be one safe place with good reputation to get the keys from. We see RIPE NCC to be a good candidate to host such a trust anchor in co-operation with all registries of signed TLD's. Such a trust-anchor should be limited to TLD's and reverse tree. [7] Discussion time for EOF items (10 mins) Lunch Break [8] IDN progress at ICANN (5 mins) Leo Vegoda, ICANN [9] OARC News & DNS DDoS Followup (10 mins) Keith Mitchell, OARC [10] Traffic analysis the .SE way using DNS2DB. (25 mins) Niclas Rosell, NIC-SE DNS2DB is a newly developed tool for analyzing dns-data. It converts raw pcap-files with dns-traffic to Sqlite-databases which then can be used to dig into and analyze the traffic. This presentation will demonstrate this tool and show how it's used in the daily work at the cctld .se. [11] Anycast experiences in Japan (15 mins) Shinta Sato, JPRS In the presentation, the experience of the test run of the new anycast site is shown. Through the presentation, what the actual TLD operators are doing for its measurement is briefly described. [12] AOB/General Discussion (5 mins)

1 0

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

RIPE NCC Network Maintenance 1700 UTC (1900 CEST) Thurday 5 April 2007 Postponed
by Mark Guz 05 Apr '07

05 Apr '07

Dear Colleagues, Due to the fact that the RIPE NCC will be closed tomorrow and Monday we have decided to postpone this maintenance until next Wednesday (11/04/07 ). Apologies for the inconvenience this may cause. If you have any questions please send them to ops(a)ripe.net Kind Regards Mark Guz Senior Engineer OPS/IT RIPE NCC Amsterdam

1 0

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

RIPE NCC Network Maintenance 1700 UTC (1900 CEST) Thurday 5 April 2007
by Mark Guz 03 Apr '07

03 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [apologies for duplicates] Dear Colleagues, On Thursday 05/04/2007, between 17:00 and 19:00 (UTC), the RIPE NCC will carry out planned maintenance work on our core network infrastructure. RIPE NCC services will be temporarily unavailable during this period. We apologise for any inconvenience that this may cause. This work is due to the deployment of a new section of dark fibre between two of our PoPs If you have any questions about this, please send an e-mail to: ops(a)ripe.net Regards Mark Guz Senior Engineer Operations Department RIPE NCC http://www.ripe.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEhqgl42z2L2N9gERAofHAKClFauaor8xhKENLD4dp5PSfN9MFQCfZhCh D1RBdhQbWlox3dtzLzLPvLE= =g9jU -----END PGP SIGNATURE-----

1 0

Maintenance on ns-sec.ripe.net
by Brett Carr 02 Apr '07

02 Apr '07

[Apologies for duplicates] Dear Colleagues, On 4 April, 2007, authoritative Reverse DNS Services on ns- sec.ripe.net will be unavailable between 19:00 and 20:00 UTC. During this time we need to carry out maintenance work. 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