- dns-wg - mailman.ripe.net

Deprecation of ip6.int scheduled for 1 June 2006
by Andrei Robachevsky 02 Jun '06

02 Jun '06

Dear Colleagues In August 2005, the IETF published RFC 4159: 'Deprecation of "ip6.int"', as a Best Current Practice document. The RFC noted that maintenance of "ip6.int" is no longer needed and called on the Regional Internet Registries (RIRs) to decide when to stop providing support for the domain. The RIRs have jointly agreed to do this on 1 June 2006. There will be a short presentation on this at the RIPE 52 Meeting in Istanbul. You can find more information about this meeting at: http://www.ripe.net/ripe/meetings/ripe-52/index.html Regards Andrei Robachevsky Chief Technical Officer RIPE NCC

12 16

[RIR] Deprecation of ip6.int Scheduled for June 1, 2006
by bmanning＠vacation.karoshi.com 01 Jun '06

01 Jun '06

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(a)vacation.karoshi.com and > hostmaster(a)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

4 3

Measuring the effects of DNSSEC deployment on query load
by Jelte Jansen 12 May '06

12 May '06

Hi, i have performed a little research on the effects of deploying DNSSEC, which might be interesting to the people of this wg. you can find it at http://www.nlnetlabs.nl/downloads/dnssec-effects.pdf ------------------------------------------------------------------ Abstract Ripe NCC recently started signing the zones on their DNS servers. This document presents a few measurements of the effects (if any) on the behaviour of the resolvers sending queries to the Ripe nameservers. We have looked at the rate of queries with the DO bit (’use DNSSEC’) set to 1, compared to those with the DO bit set to 0. We have also looked at the number of DNS responses that were truncated. ------------------------------------------------------------------- Jelte Jansen NLnet Labs

1 0

ip6.int deprecation
by Pim van Pelt 12 May '06

12 May '06

Dear wg, I have heard from Bill Manning that ARIN has requested removal of their space from the ip6.int tree, and I'm wondering what the current point of view is for the RIPE NCC. I would like to see ip6.int dismanteled 'correctly', ie not in the way described below: I wrote to ipv6-ops(a)lists.cluenet.de: > I have heard DNS operators are planning on removing ip6.int from their > resolvers (ie by plugging ip6.int into an empty zone on their recursors). > What are your thoughts on this? I am considering removing ip6.int also > in the same way, because I think it can take a long time for the parent > of .int to remove ip6 delegation (if they are even considering this is > unknown to me) and for sure it might take a long time for the ip6.int > folks to remove children from their zone. > Bill replied: | ip6.int is ready to remove zone cuts for ARIN. | they are the only RIR who has requested delegation removal. | when/if the other RIRs request delegation removal, it will | occur. Has this been discussed before? If so, I'm sorry I missed it :) What was the outcome in that case? I think it is a very good idea to have RIPE NCC and APNIC request delegation removal. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim(a)ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------

4 3

Announcement DNS for LIRs Training Course
by RIPE NCC Training Services 09 May '06

09 May '06

Dear Colleagues, The RIPE NCC Training Services Department invites you to register for one of our upcoming DNS for LIRs Training Courses: And Date: Tuesday 13 June 2006 Time: 0900-1700 Location: Riyadh, Saudi Arabia Hosted by:ZAJIL International Telecommunications Co. W.L.L. And Date: Thursday 13 July 2006 Time: 0900-1700 Location: Munich, Germany And Date: Friday 8 September 2006 Time: 0900-1700 Location: Manchester, United Kingdom And Date: Friday 29 September 2006 Time: 0900-1700 Location: Amsterdam, Netherlands The main objective of the DNS for LIRs Training Course is to provide LIRs with information about the different DNS related services the RIPE NCC has available for them. It covers reverse DNS procedures and checks, as well as giving information about DNS Monitoring (DNSMON), K-Root and anycasting. The course also covers DNSSEC and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zones. Please note that the DNS for LIRs course focuses on DNS services and procedures related to being an LIR. The course does: - NOT teach the basics of DNS - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe fully how to operate a Local Internet Registry (LIR) The course is intended for technical staff of LIRs. It is assumed that all attendees are familiar with common DNS terminology and have a practical knowledge of operating DNS servers. The course is free of charge. We provide lunch and printed training materials. We do not cover any of your travel expenses or accommodation. We give all of our training courses in English. You can find more information about the course at: http://www.ripe.net/training/dns REGISTRATION: ============ To register for this course, please use the LIR Portal or complete the registration via our website on: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

1 0

Vulnerability Issues in Implementations of the DNS Protocol
by Roy Arends 03 May '06

03 May '06

With all the lies and statistics going on, this vulnerability advisory from NISCC might have slipped by. Since the url points to a pdf file, I took the liberty to convert this. Roy. -------- http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en NISCC Vulnerability Advisory 144154/NISCC/DNS Vulnerability Issues in Implementations of the DNS Protocol Version Information Advisory Reference 144154/NISCC/DNS Release Date 25 April 2006 Last Revision 02 May 2006 Version Number 1.2 Acknowledgement The DNS Test Tool was created by the Oulu University Secure Programming Group (OUSPG) from the University of Oulu in Finland. What is Affected? The vulnerabilities described in this advisory affect implementations of the Domain Name System (DNS) protocol. Many vendors include support for this protocol in their products and may be impacted to varying degrees, if at all. Impact If exploited, these vulnerabilities could cause a variety of outcomes including, for example, a Denial-of-Service (DoS) condition. In most cases, they can expose memory corruption, stack corruption or other types of fatal error conditions. Some of these conditions may expose the protocol to typical buffer overflow exploits, allowing arbitrary code to execute or the system to be modified. Severity The severity of this vulnerability varies by vendor. Please see the 'Vendor Information' section below for further information. Alternatively, contact your vendor for product specific information. Summary During 2002 the Oulu University Secure Programming Group (OUSPG) discovered a number of implementation specific vulnerabilities in the Simple Network Management Protocol (SNMP). Further work has been done to identify implementation specific vulnerabilities in related protocols that are used in critical infrastructure. The DNS protocol, which is the primary naming system used on the Internet, was studied as part of this program of work. DNS is an Internet service that translates domain names into Internet Protocol (IP) addresses and vice versa. Because domain names are alphabetic, they're easier to remember, however the Internet is really based on IP addresses; therefore every time a domain name is requested, a DNS service must translate the name into the corresponding IP address. OUSPG has developed a PROTOS DNS Test Suite for DNS implementations and employed it to validate their findings against a number of products from different vendors. NISCC has contacted multiple vendors whose products support the DNS protocol and provided them with the test tool to allow them to test their implementations. NISCC believes that most of the relevant vendors who provide support for the DNS protocol have been covered by this advisory. Details DNS is a system that stores information associated with domain names in a distributed database on networks such as the Internet. The domain name system associates many types of information with domain names, but most importantly, it provides the IP address associated with the domain name. It also lists mail exchange servers accepting e-mail for each domain and a wide variety of other records. The OUSPG DNS Test Suite covers a limited set of information security and robustness related implementation errors for the DNS protocol. The factors behind choosing DNS included: DNS is a fundamental infrastructure of the Internet, most Internet applications are dependent on it. DNS implementations are ubiquitous: present in servers, end- user equipment such as personal computers or mobile phones and in routers and firewalls. Therefore DNS may be a potential attack vector in a variety of scenarios against a variety of systems and infrastructure components. There are no free, publicly available robustness test suites to evaluate DNS implementations. The material contained in the test suite covers basic queries, dynamic updates, basic responses and zone transfers. However please be aware that the test material does not cover cache poisoning or address spoofing vulnerabilities. There are three sets of test materials available with the tool; these are specifically designed for the following scenarios: 1. The Query Material -> [queries, dynamic DNS updates] -> DNS server 2. The Response Material -> [query replies] -> DNS server 3. The Response Material -> [query replies] -> DNS stub resolver (client) 4. The Zone Transfer Material -> [zone transfers] -> secondary DNS server The test material simulates hostile input to the DNS implementation by sending invalid and/or abnormal packets. Therefore by applying the OUSPG DNS Test Suite to a variety of products, several vulnerabilities can be revealed that can have varying effects. Mitigation Patch all affected implementations. Solution Please refer to the 'Vendor Information' section of this advisory for platform specific remediation. Vendor Information The following vendors have provided information about how their products are affected by this vulnerability. Please note that JPCERT/CC have released a Japanese language advisory for this vulnerability which contains additional information regarding Japanese vendors. This advisory is available at http://jvn.jp/niscc/NISCC-144154/index.html Cisco Systems, Inc Microsoft Delegate MyDNS Ethereal pdnsd Fujitsu Sun Hitachi Wind River ISC Juniper Networks Cisco Systems, Inc Cisco Systems is currently testing its DNS related products. We will provide updates if warranted at http://www.cisco.com/go/psirt. Delegate Vulnerable: DeleGate/9.0.5 (DEVELOPMENT) and prior versions DeleGate/8.11.5 (STABLE) and prior versions Not Vulnerable: DeleGate/9.0.6 and subsequent versions DeleGate/8.11.6 and subsequent versions DeleGate is an application level gateway (proxy server) which relays multiple application protocols including HTTP, FTP, SMTP, SOCKS, DNS; running on Unix and Windows. There have been bugs in its DNS protocol handling unit where a DNS response message is analyzed. Due to this problem, DeleGate can suffer a denial-of-service attack. For some crafted or broken response messages, it reads the message data area beyond the real size of it, or read it in infinitely recursive function call. Then the DeleGate process will abort causing segmentation fault or so accessing non-existent address or non-available memory. DeleGate as DNS proxy, ICP server and UDP-relay might stop their service receiving such broken DNS response, since the abortion occurs in the main process which is not to be restarted automatically by itself. Other DeleGate proxies for other protocols do not stop servicing but a child process for a session might abort without returning response message of each application protocol. These bugs have been fixed in version 9.0.6 (development version) and 8.11.6 (stable version). The impact for resent versions is not more than DoS, but upgrading to these versions (or subsequent ones) is recommended. The impact can be more serious in ancient versions of DeleGate prior to 8.10.3 which also include many other kind of dangers (http://www.delegate.org/mail- lists/delegate-en/2793), so they must be upgraded anyway. Ethereal The Ethereal development team is investigating the reported vulnerabilities to determine if any versions of Ethereal are affected. We will provide updated status information in the near future. Fujitsu Fujitsu have provided more information on this issue at the following location (in Japanese): http://software.fujitsu.com/jp/security/vulnerabilities/niscc144154.html Hitachi Hitachi believe that the AlaxalA Networks AX series, Hitachi GR2000/GR4000/GS4000/GS3000 and Hitachi HI-UX are NOT vulnerable to this issue. ISC ISC has reviewed a bug that can cause named to terminate abnormally if a broken TSIG is present in the second or later message of a zone transfer. However, this is not considered high-risk as the first message must have a correct TSIG present for the transaction to continue. A fix will be included in a future BIND release. Juniper Networks The OUSPG PROTOS c09-dns-response test tool was run against all Juniper Networks platforms. JUNOS and ScreenOS were unaffected. Tests against JUNOSe, found on the E-series routers, did result in an issue with the DNS client code (ref: KA 23381). The issue was resolved in the following JUNOSe updates: 5-3-5p0-2, 6-0-3p0-6, 6-0-4, 6-1-3p0-1, 7-0-1p0-7, 7-0-2, 7-1-0p0- 1, 7-1-1. Later JUNOSe releases are unaffected. Microsoft Microsoft are still testing their products and will provide an update when more information is available. MyDNS MyDNS 1.1.0 has been released which contains a fix for a query-of-death DoS bug uncovered by the test suite. New versions can be obtained from: http://mydns.bboy.net/ pdnsd The current maintainer of the pdnsd project, Paul A. Rombouts, has run tests on pdnsd with the DNS Test Suite mentioned here and discovered one significant flaw in the pdnsd code, which affects several versions of pdnsd. A DNS query with an unsupported QTYPE or QCLASS can cause pdnsd to leak memory. The amount of memory used by pdnsd may thus grow continually and unbounded and may eventually cause pdnsd to crash or cause the system to become sluggish and unresponsive. All users of pdnsd are advised to upgrade to version 1.2.4 or later of pdnsd, which has a fix for this leak and is available at: http://www.phys.uu.nl/~rombouts/pdnsd.html Sun Sun Microsystems is currently investigating the impact of the OUSPG DNS test suite to Sun's products. If any issues are identified, Sun will publish Sun Alerts which will include details of the impact and suggested resolution for those issues. Wind River Wind River does not believe that any of the products we provide are currently vulnerable to the issues described in this Vulnerability Notice. Acknowledgements The NISCC Vulnerability Management Team would like to thank OUSPG for producing the DNS Test Tool. The NISCC Vulnerability Management Team would also like to thank the vendors for their co-operation in handling this vulnerability and to JPCERT/CC for co-ordinating this issue in Japan. Contact Information The NISCC Vulnerability Management Team can be contacted as follows: Email vulteam(a)niscc.gov.uk (Please quote the advisory reference in the subject line.) Telephone +44 (0)870 487 0748 Extension 4511 (Monday to Friday 08:30 - 17:00) Fax +44 (0)870 487 0749 Post Vulnerability Management Team NISCC PO Box 832 London SW1P 1BG We encourage those who wish to communicate via email to make use of our PGP key. This is available from http://www.niscc.gov.uk/niscc/publicKey2-en.pop. Please note that UK government protectively marked material should not be sent to the email address above. If you wish to be added to our email distribution list, please email your request to uniras(a)niscc.gov.uk. What is NISCC? For further information regarding the UK National Infrastructure Security Co-Ordination Centre, please visit the NISCC web site at: http://www.niscc.gov.uk/ Reference to any specific commercial product, process or service by trade name, trademark manufacturer or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NISCC. The views and opinions of authors expressed within this notice shall not be used for advertising or product endorsement purposes. Neither shall NISCC accept responsibility for any errors or omissions contained within this advisory. In particular, they shall not be liable for any loss or damage whatsoever, arising from or in connection with the usage of information contained within this notice. © 2006 Crown Copyright Revision History 25 April 2006 Initial release (1.0) 26 April 2006 Added Vendor Statement from Cisco (1.1) 02 May 2006 Added Vendor Statement from Fujitsu (1.2) <End of NISCC Vulnerability Advisory> http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en

1 0

"DNS Vulnerabilities" paper hits the mainstream
by Jim Reid 02 May '06

02 May '06

Emin Gun Sirer's paper/presentation at RIPE52 has been picked up by the BBC: http://news.bbc.co.uk/1/hi/technology/4954208.stm Any thoughts on how to respond to that?

10 11

DRAFT DNS WG Meeting Agenda for RIPE 52
by Peter Koch 20 Apr '06

20 Apr '06

Dear DNS WG, here's an updated draft agenda for the upcoming meetings on Thursday next week. Changes include an extra slot for discussion of K-Root anycast. DNSSEC status updates were merged into the general reports item. -Peter # $Id: RIPE52agenda,v 1.6 2006/04/20 11:14:44 pk Exp $ ############################################################################# D R A F T ############################################################################# DNS-related presentations in the EOF/plenary: TUE, 2006-04-25: Reflector Attacks Using DNS Infrastructure (Joao Damas) DNS amplification attacks (Matsuzaki Yoshinobu) Security Issues in ENUM (Gerhard Schröder) WED, 2006-04-26: Perils of Transitive Trust in the Domain Name System (Emin Gun Sirer) The Impact of anycast on Root DNS Servers. The Case of K-root (Lorenzo Colitti) DNS in Turkey (Attila Ozgit) ############################################################################# 2006-04-27 1100 - 1230, DNS WG slot I [90 min] ############################################################################# 0) Administrivia [chairs][ 5 min] - scribe, jabber, minutes - agenda bashing 1) Status Reports [][30 min] - IETF dnsext, dnsop and others [Olaf Kolkman][18 min] - IANA Overview [David Conrad][ 7 min] - DNSSEC News/Statistics from the NCC [][ 5min] 2) Action Item Review [chairs][15 min] <http://www.ripe.net/ripe/wg/dns/dns-actions.html> 48.1 48.2 49.1 49.2 51.1: see (3) and plenary presentation on K-root 51.2: see (4) 51.3: see also <http://www.ripe.net/news/review-secondary-dns.html> 51.4 51.5: see (6) 3) Anycast on K-Root [Lorenzo Colitti, RIPE NCC][10 min] 4) IP6.INT phase out [Andrei Robachevski, RIPE NCC][10 min] 5) Reverse DNS Quality [Brian Riddle, RIPE NCC][10 min] 6) Proposal to bring ENUM Zone Management in line with the Reverse DNS [N.N., RIPE NCC][10 min] ############################################################################# 2006-04-27 1600 - 1700, DNS WG slot II [60 min] ############################################################################# 7) Plenaries Followup [chairs][15 min] Discussion of details postponed from plenary presentations (see above), including identification of potential work for the WG 8) ICANN IDN guidelines & IDN Future [Marcos Sanz][20 min] <http://www.icann.org/topics/idn/implementation-guidelines.htm> [may also touch draft-iab-idn-nextsteps-05.txt] 9) Nominet's Dynamic Updates [Jay Daley][15 min] X) I/O with other WGs [chairs][ 4 min] Y) A.O.B. [chairs][ 4 min] Z) Wrap-Up & Close [chairs][ 2 min] #############################################################################

1 0

Oluf Nielsen is out of the office.
by Oluf Nielsen 14 Apr '06

14 Apr '06

I will be out of the office starting 10-04-2006 and will not return until 18-04-2006. I will respond to your message when I return.

1 0

DRAFT Meeting Agenda for RIPE 52
by Peter Koch 13 Apr '06

13 Apr '06

Dear WG, find below the draft agenda for our two sessions during the upcoming meeting in Istanbul. Please send comments to the chairs. -Peter # $Id: RIPE52agenda,v 1.5 2006/04/13 15:06:05 pk Exp $ ############################################################################# D R A F T ############################################################################# DNS-related presentations in the EOF/plenary: TUE, 2006-04-25: Reflector Attacks Using DNS Infrastructure (Joao Damas) DNS amplification attacks (Matsuzaki Yoshinobu) Security Issues in ENUM (Gerhard Schröder) WED, 2006-04-26: Perils of Transitive Trust in the Domain Name System (Emin Gun Sirer) The Impact of anycast on Root DNS Servers. The Case of K-root (Lorenzo Colitti) DNS in Turkey (Attila Ozgit) ############################################################################# 2006-04-27 1100 - 1230, DNS WG slot I [90 min] ############################################################################# 0) Administrivia [chairs][ 5 min] - scribe, jabber, minutes - agenda bashing 1) Status Reports [][25 min] - IETF dnsext, dnsop and others [Olaf Kolkman][18 min] - IANA Overview [David Conrad][ 7 min] 2) DNSSEC Status and Deployment Reports [][20 min] - SE Experiences [][] - DNSSEC Deployment WG [][] - News/Statistics from the NCC [][] - Other 3) Action Item Review [chairs][10 min] <http://www.ripe.net/ripe/wg/dns/dns-actions.html> 48.1 48.2 49.1 49.2 51.1: see plenary presentation on K-root 51.2: see (4) 51.3: see also <http://www.ripe.net/news/review-secondary-dns.html> 51.4 51.5: see (6) 4) IP6.INT phase out [Andrei Robachevski, RIPE NCC][10 min] 5) Reverse DNS Quality [Brian Riddle, RIPE NCC][10 min] 6) Proposal to bring ENUM Zone Management in line with the Reverse DNS [N.N., RIPE NCC][10 min] ############################################################################# 2006-04-27 1600 - 1700, DNS WG slot II [60 min] ############################################################################# 7) Plenaries Followup [chairs][15 min] Discussion of details postponed from plenary presentations (see above), including identification of potential work for the WG 8) ICANN IDN guidelines & IDN Future [Marcos Sanz][20 min] <http://www.icann.org/topics/idn/implementation-guidelines.htm> [may also touch draft-iab-idn-nextsteps-XX.txt] 9) Nominet's Dynamic Updates [Jay Daley][15 min] X) I/O with other WGs [chairs][ 4 min] Y) A.O.B. [chairs][ 4 min] Z) Wrap-Up & Close [chairs][ 2 min] #############################################################################

1 0