From owner-dns-security Wed May 6 11:12:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA26317 for dns-security-outgoing; Wed, 6 May 1998 11:08:07 -0400 (EDT) Message-Id: <199805061506.LAA10851@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-05.txt Date: Wed, 06 May 1998 11:06:35 -0400 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake Filename : draft-ietf-dnssec-secext2-05.txt Pages : 51 Date : 05-May-98 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback on RFC 2065 from early implementers and potential users. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext2-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-secext2-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980506102154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980506102154.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Mon May 18 15:07:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA13580 for dns-security-outgoing; Mon, 18 May 1998 15:02:15 -0400 (EDT) Reply-To: James M Galvin From: James M Galvin To: Jeff Schiller , Marcus Leech cc: iesg-secretary@ietf.org, dns-security@ex.tis.com Subject: DNS Security to the IESG MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1943.895518628.1@elistx.com> Date: Mon, 18 May 1998 15:10:28 -0400 Message-ID: <9805181510.aa01947@one.eListX.com> Sender: owner-dns-security@ex.tis.com Precedence: bulk As Chair of the DNS Security Working Group with this message the working group is submitting the following documents to be considered for publication as Proposed Standards: draft-ietf-dnssec-secext2-05.txt draft-ietf-dnssec-dss-02.txt draft-ietf-dnssec-rsa-00.txt draft-ietf-dnssec-certs-02.txt draft-ietf-dnssec-indirect-key-01.txt draft-ietf-dnssec-dhk-02.txt These documents represent consensus although not unanimity. Concerns fall in to the categories of specification clarity and lack of operational experience to be absolutely certain of a few technical choices. There are also some subjective concerns regarding the utility of a few functions and features. Nonetheless, it is my opinion these documents represent "as far as we are going to get" with respect to resolution. Further, it is my opinion that operational experience will present the necessary "clarity of opinion" to permit resolution of the concerns when the documents are eligible to be advanced to Draft Standard. Operational experience is problematic unless these documents are advanced to at least the Proposed Standard level. Experimental is not an option. During your review please note that the first three documents are a logical set replacing RFC 2065. RFC 2065 is the current Proposed Standard for DNS Security. The technical changes between this version and that version require recycling at the Proposed Standard level. Note further that the first two documents are required to advance together according to IETF rules regarding encumbered technologies; the third is text split from RFC 2065 so as to permit the DNS Security extensions themselves to be algorithm independent. Enjoy, Jim -- James M. Galvin Director, Electronic Commerce Technologies CommerceNet Consortium +1 410.549.5545 http://www.commerce.net +1 410.549.5546 FAX From owner-dns-security Thu May 21 08:59:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA25621 for dns-security-outgoing; Thu, 21 May 1998 08:57:07 -0400 (EDT) Date: Thu, 21 May 1998 08:13:54 +0200 Message-Id: <199805210613.IAA01745@mir3.ida.liu.se> To: dns-security@tis.com From: Yahya Al-Salqan Subject: Enterprise Security Workshop: Call for participation Sender: owner-dns-security@ex.tis.com Precedence: bulk ============================================================= Call for Participation: IEEE WET ICE '98 Third International Workshop on Enterprise Security Stanford University, Palo Alto, USA June 17-19 1998 ============================================================= On behalf of the Workshop Program and Organizing Committees, I would like to invite you to participate in The 3rd IEEE International Enterprise Security Workshop to be held on June 17-19, Stanford University, Palo Alto, California. The Workshop includes paper presentations, panel discussions, keynote speeches and invited talks covering all aspects of enterprise security. Topics to be covered include: Public key infrastructure, intrusion detection, Web security, application security (e.g. digital library and health care), and access control. Highlights of the program: o Keynote speech by Dr. Li Gong, Java Security Architect, Sun Microsystems; o Industrial security expertise from: Microsoft NT security group, Sun Microsystems, Entrust, Certicom, Verisign, SSH Communication security and many others. It is an unprecedented opportunity to put all these companies in one room. Don't miss it. o Participation of IETF security group leaders; o Participation of NSA (National Security Agency); o Two panel discussions: - "State-of-the-art Enterprise Security: Practice and Future" - "Intrusion Detection: Present and Future" o Workshop is held in conjunction with other WETICE workshops: - "Web-based infrastructure for collaborative Enterprises," - "Collaboration in Presence of Mobility," o Two social events. The Workshop Preliminary program can be found at: http://www.ida.liu.se/labs/iislab/SECWK/agenda.html The Registration form can be found at: http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html (Please mark the Enterprise Security Workshop on the registration form) The Workshop main page can be found at: http://www.ida.liu.se/labs/iislab/SECWK/ I look forward to meeting you at the Workshop. Sincerely, Yahya Al-Salqan, Ph.D. Workshop General Chair Sun Microsystems From owner-dns-security Wed May 27 08:41:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA20502 for dns-security-outgoing; Wed, 27 May 1998 08:38:13 -0400 (EDT) Message-Id: <199805271244.IAA11159@clipper.hq.tis.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 27 May 1998 08:52:07 -0400 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ns.ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com From: "David M. Balenson" Subject: CFP: 1999 Network & Distributed System Security Symposium (NDSS '99) Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_896287927==_" Sender: owner-dns-security@ex.tis.com Precedence: bulk --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" C A L L F O R P A P E R S The Internet Society 1999 Network and Distributed System Security Symposium (NDSS'99) Where: Catamaran Resort, San Diego, California When: February 3-5, 1999 GOAL: The symposium will foster information exchange among hardware and software developers of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Topics for the symposium include, but are not limited to, the following: * Security in malleable systems: mobile code, mobile agents, active networks, dynamic policy updates, etc. * Special problems: e.g. interplay between security goals and other goals such as efficiency, usability, reliability, interoperability, resource sharing, and cost. * Integrating security services with system and application security facilities and with application protocols, including message handling, file transport, remote file access, directories, time synchronization, data base management, routing, voice and video multicast, network management, boot services, and mobile computing. * Fundamental services: authentication, integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification infrastructures, audit, and intrusion detection. * Telecommunications security, especially for emerging technologies -- very large systems, e.g., the Internet, high-speed systems, e.g., the gigabit testbeds, wireless systems, personal communication systems, and large-scale, heterogeneous distributed systems. * Controls: firewalls, packet filters, application gateways * Object security and security objects * Network information resources and tools such as World Wide Web (WWW), Gopher, archie, and WAIS. * Electronic commerce: payment services, fee-for-access, EDI, notary services; endorsement, licensing, bonding, and other forms of assurance; rights management and other forms of intellectual property protection * Implementation and management of network security policy * Security for voice over IP * Security for routing GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CHAIRS: Stephen Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute TUTORIAL CHAIR: Doug Maughan, National Security Agency PROGRAM COMMITTEE: David Balenson, TIS Labs at Network Associates Steve Bellovin, AT&T Labs -- Research Matt Bishop, University of California at Davis Bob Blakley, IBM Doug Engert, Argonne National Laboratories Warwick Ford, VeriSign Li Gong, Sun Microsystems Rich Graveman, Bellcore Ari Juels, RSA Laboratories Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Michael Roe, Cambridge University Jeffrey Schiller, MIT Wolfgang Schneider, GMD Darmstadt Christoph Schuba, Purdue University Win Treese, Open Market Jonathan Trostle, Cisco LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: John Kochmar, SEI PUBLICITY CHAIR: David Balenson, TIS Labs at Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society REGISTRATIONS CHAIR Beth Strait, Internet Society SUBMISSIONS: The committee invites technical papers and panel proposals, for topics of technical and general interest. Technical papers should be 10-20 pages in length. Panel proposals should be two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may at the discretion of the panel chair, include written position statements from each panelist. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, Internet electronic mail addresses, and must list a single point of contact if more than one author. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by 31 July 1998, and must be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, it will be returned and hardcopy requested. Therefore, PostScript submissions must arrive well before 31 July. All submissions and program related correspondence (only) should be directed to the program chair: Stephen Kent c/o BBN Technologies 70 Fawcett Street Cambridge, Mass. 02138 Email:sndss99-submissions@bbn.com Phone: +1 (617) 873-1996 FAX: +1 (617) 873-4086 Dates, final call for papers, advance program, and registration information will be available at the URL: http://www.isoc.org/ndss99. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by 18 September 1998. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by 16 October 1998. --=====================_896287927==_ Content-Type: text/plain; charset="us-ascii" ---------------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 --=====================_896287927==_-- From owner-dns-security Wed May 27 15:00:27 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA22759 for dns-security-outgoing; Wed, 27 May 1998 14:59:09 -0400 (EDT) Message-ID: <356C63A5.61CC@ccnet.com> Date: Wed, 27 May 1998 12:04:05 -0700 From: Kurt Stammberger X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: ids@uow.edu.au, firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com Subject: RSA'99 Deadline Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk Dave's NDSS note reminded me to remind y'all: D E A D L I N E ! D E A D L I N E ! The Deadline for talk proposals for RSA'99 is SIX DAYS AWAY (June 1st). For more information, or to propose a talk or submit a paper for presentation, visit www.rsa.com/conf99 Questions? E-mailez-moi. Kurt Stammberger Conference Director RSADSI From owner-dns-security Wed May 27 15:27:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA22994 for dns-security-outgoing; Wed, 27 May 1998 15:27:11 -0400 (EDT) Message-Id: <199805271925.MAA21067@basilisk.Eng.Sun.COM> Date: Wed, 27 May 1998 12:25:35 -0700 (PDT) From: Yahya Al-Salqan Reply-To: Yahya Al-Salqan Subject: Call for participation (FYI) To: firewalls@greatcircle.com, cat-ietf@mit.edu, ietf@ietf.org, ipsec@tis.com, dns-security@tis.com, www-security@ns2.rutgers.edu, www-buyinfo@allegra.att.com, ietf-otp@bellcore.com, pem-dev@tis.com, virus-l@lehigh.edu, ietf-pkix@tandem.com, spki@c2.net, ietf-tls@consensus.com, ietf-open-pgp@imc.org, ietf-smime@imc.org, aft@socks.nec.com, ietf-radius@livingston.com, ietf-ssh@clinet.fi, OGsecurity@opengroup.org, cryptography@c2.net, risks@csl.sri.com Cc: ssl-talk@netscape.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SCk4v9pjCPXd6BFIFnKHgg== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-dns-security@ex.tis.com Precedence: bulk Today is the deadline for the early registration ... take advantage of it. My appology if you receive this e-mail more than once! ================================================= Call for Participation: IEEE WET ICE '98 Third International Workshop on Enterprise Security Stanford University, Palo Alto, USA June 17-19 1998 ================================================= On behalf of the Workshop Program and Organizing Committees, I would like to invite you to participate in The 3rd IEEE International Enterprise Security Workshop will be held June 17-19, Stanford University, Palo Alto, California. The Workshop includes paper presentations, panel discussions, keynote speeches and invited talks covering all aspects of enterprise security. Topics to be covered include: Public key infrastructure, intrusion detection, Web security, application security (e.g. digital library and healthcare), and access control. Highlights of the program: o Keynote speech by Dr. Li Gong, Java Security Architect, Sun Microsystems; o Industrial security expertise from: Microsoft NT security group, Sun Microsystems, Entrust, Certicom, Verisign, SSH Communication security and many others. It is an unprecedented opportunity to put all these companies in one room. Don't miss it. o Participation of IETF security group leaders; o Participation of NSA (National Security Agency); o Two panel discussions: - "State-of-the-art Enterprise Security: Practice and Future" - "Intrusion Detection: Present and Future" o Workshop held in conjunction with other WETICE workshops: "Web-based infrastructure for collaborative Enterprises," "Collaboration in Presence of Mobility," o Two social events. The Workshop Preliminary program can be found at: http://www.ida.liu.se/labs/iislab/SECWK/agenda.html The Registration form can be found at: http://www.cerc.wvu.edu/WETICE/WETICE98/registration.html (Please mark the Enterprise Security on the registration form) The Workshop main page can be found at: http://www.ida.liu.se/labs/iislab/SECWK/ I look forward to meeting you at the Workshop. Sincerely, Yahya Al-Salqan, Ph.D. Workshop General Chair Sun Microsystems ------------- End Forwarded Message ------------- ------------- End Forwarded Message ------------- From owner-dns-security Fri May 29 10:58:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA03440 for dns-security-outgoing; Fri, 29 May 1998 10:52:51 -0400 (EDT) Message-Id: <199805291445.KAA03800@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; From: Internet-Drafts@ietf.org cc: dns-security@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-lewis-dnskey-referral-00.txt Date: Fri, 29 May 1998 10:45:31 -0400 Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Zone Referral Key Author(s) : E. Lewis, J. Scharff, J. Gilmore Filename : draft-lewis-dnskey-referral-00.txt Pages : 7 Date : 28-May-98 A new type of key is defined to address the problems of performance in large delegeted zones and issues of liability of registrars with regards to the storing of public keys belonging to zone cuts. This new key type also brings DNSSEC more in line with the DNS treatment of zone cuts and speeds recovery in handling key exposure. The new type of key is a referral record that is stored, signed, at the parent zone's place for the delegation point. A resolver receiving this record is being informed that there are genuine public keys at the child's authoritative name servers. The parent no longer needs to store the child's public keys locally. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lewis-dnskey-referral-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-lewis-dnskey-referral-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lewis-dnskey-referral-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980528164613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lewis-dnskey-referral-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-lewis-dnskey-referral-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980528164613.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Fri May 29 15:35:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA04621 for dns-security-outgoing; Fri, 29 May 1998 15:33:54 -0400 (EDT) X-Authentication-Warning: defenestration.hq.tis.com: bwelling owned process doing -bs Date: Fri, 29 May 1998 15:49:04 -0400 (EDT) From: Brian Wellington X-Sender: bwelling@defenestration.hq.tis.com To: namedroppers@internic.net, dns-security@tis.com Subject: AXFR & NS records at delegation points Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk In prototyping DNSSEC functions in BIND, we've come across a problem concerning zone transfers. This problem is not specific to DNSSEC, however. The problem is determining what is returned (specifically regarding the NS record) at delegation points in a zone when the source of the transfer is authoritative for both the zone being transfered and the zone below the delegation point. Example 1: zone.bar.com: ... foo NS a.foo.bar.com ... zone.foo.bar.com: ... @ NS b.foo.bar.com As an example, say our nameserver is serving bar.com and foo.bar.com. When the name server receives an AXFR request for bar.com, which NS record does it include for foo.bar.com? The one from the bar.com zone or the (more credible) one from the foo.bar.com zone? In BIND, only the more credible record is stored (the other is expunged from memory). The data from the lower zone is more credible, but including it leads to a problem where two servers can both be serving bar.com and contain the same serial number in the SOA, but if only one is serving foo.bar.com, the AXFR will contain different data. In other words, for a secondary claiming serial number = 1998052913, the NS record would be a.foo.bar from a server authoritative only for the bar.com zone, and it would be b.foo.bar.com from a server authoritative for both zones. Example 2: zone.bar.com: ... foo NS a.foo.bar.com ... zone.foo.bar.com.signed: ... @ NS a.foo.bar.com SIG NS ... ... This also related to DNSSEC. If the upper zone is unsigned and the lower zone is signed, the upper zone will overwrite (in BIND, at least) its unsigned NS record for foo.bar.com with the signed one from the lower zone. Should the AXFR contain the SIG NS record or not? Additionally, there may be a similar problem with KEY records, as the parent and child zones both contain KEY records at delegation points. In this case, though, the parent should not contain the key record in the first place. Any suggestions? Brian From owner-dns-security Fri May 29 16:16:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA04770 for dns-security-outgoing; Fri, 29 May 1998 16:15:53 -0400 (EDT) To: Brian Wellington Cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: AXFR & NS records at delegation points In-Reply-To: Brian Wellington's message of "Fri, 29 May 1998 15:49:04 -0400." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 May 1998 06:31:16 +1000 Message-Id: <3673.896473876@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Fri, 29 May 1998 15:49:04 -0400 (EDT) From: Brian Wellington Message-ID: | The problem is determining what is returned (specifically regarding the NS | record) at delegation points in a zone when the source of the transfer is | authoritative for both the zone being transfered and the zone below the | delegation point. This has always been a point of irritation, and there are arguments for both possible answers. In general however, I believe that the authoritative data is the data that matters, that should be believed, and that any copies of inconsistent unauthoritative data are errors, and should be expunged by any means possible. That is, the delegation information in the parent zone should be identical to the NS record set in the child zone, always (allowing for the permitted inconsistencies around times of updates as always in the DNS). If it is different, the parent is wrong, and should be connected. Whether or not it is good for it to be corrected (or partly corrected) "by accident" by virtue of the server also being authoritative for the child is a complex issue, and not really worth debating. But it ought be corrected one way or another. | As an example, say our nameserver is serving bar.com and foo.bar.com. When | the name server receives an AXFR request for bar.com, which NS record does | it include for foo.bar.com? I would suggest that including the RRset from the child zone is perfectly reasonable - but I would hesitate to make that mandatory. | The data from the lower zone is more credible, but including it leads to a | problem where two servers can both be serving bar.com and contain the same | serial number in the SOA, but if only one is serving foo.bar.com, the AXFR | will contain different data. There are plenty of other ways for DNS configuration errors (which is what the above scenario represents) to cause that effect. It is not worth worrying specially about this one particular case. | Example 2: | If the upper zone is unsigned and the lower zone | is signed, [...] Should the | AXFR contain the SIG NS record or not? No, the SIG records belong to the child zone, and should remain there. Glue should only ever be included when necessary for correct functioning of the DNS - anything below the zone cut is glue. That includes the NS records themselves, however they are (obviously) required in the parent zone. kre From owner-dns-security Fri May 29 19:10:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05323 for dns-security-outgoing; Fri, 29 May 1998 19:10:21 -0400 (EDT) Message-Id: <199805292325.QAA17875@bb.rc.vix.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Brian Wellington cc: namedroppers@internic.net, dns-security@tis.com Subject: Re: AXFR & NS records at delegation points In-reply-to: Your message of "Fri, 29 May 1998 15:49:04 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 May 1998 16:25:31 -0700 From: Jerry Scharf Sender: owner-dns-security@ex.tis.com Precedence: bulk Brian, (I am probably about to put my foot in my mount, so it's much better to do it in public.) My understanding is exactly the opposite of what kre said. When I read about the "mount-like semantics" discussed in 2181 zone cuts, I assume that it is just like the unix file mount: When you mount a new filesystem on some point, all the files below the old mount point are unavailable but do not disappear. If you unmount the other filesystem, they reappear instantly. Also, if you dump the disk by walking the inode tree, you will get all the files including the hidden ones. So when I do dump -> restore, the hidden files are there, which is the analog of axfr. In the case of DNS, since the NS records are still there on the copy, the data is still hidden. I thought that this was one of the exact things that 2181 was supposed to clarify! I can imagine a case where you could use this, but I do agree that this can be done better in other ways. I am also not exactly sure why being authoritative for the child or not should change the contents of the zone transfer (though it would certainly make the interal data storage for BIND different.) jerry From owner-dns-security Fri May 29 19:27:39 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA05356 for dns-security-outgoing; Fri, 29 May 1998 19:27:21 -0400 (EDT) To: Jerry Scharf Cc: Brian Wellington , namedroppers@internic.net, dns-security@tis.com Subject: Re: AXFR & NS records at delegation points In-Reply-To: Jerry Scharf's message of "Fri, 29 May 1998 16:25:31 -0700." References: <199805292325.QAA17875@bb.rc.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 May 1998 09:41:48 +1000 Message-Id: <7650.896485308@munnari.OZ.AU> From: Robert Elz Sender: owner-dns-security@ex.tis.com Precedence: bulk Date: Fri, 29 May 1998 16:25:31 -0700 From: Jerry Scharf Message-ID: <199805292325.QAA17875@bb.rc.vix.com> | My understanding is exactly the opposite of what kre said. I don't think so. I don't disagree at all with any of what you have said, except possibly whether axfr is quite the analog of dump/restore. In any case, having different NS records in the parent and child is a config error, and I'm not sure that anything that could be specified here can really cope with all such errors. kre From owner-dns-security Fri May 29 23:30:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA05700 for dns-security-outgoing; Fri, 29 May 1998 23:29:42 -0400 (EDT) Date: Fri, 29 May 1998 23:45:15 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: dns-security@tis.com cc: namedroppers@internic.net Subject: Re: AXFR & NS records at delegation points In-Reply-To: <199805292325.QAA17875@bb.rc.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk I agree entirely with Robert Elz. On Fri, 29 May 1998, Jerry Scharf wrote: > Date: Fri, 29 May 1998 16:25:31 -0700 > From: Jerry Scharf > To: Brian Wellington > Cc: namedroppers@internic.net, dns-security@TIS.COM > Subject: Re: AXFR & NS records at delegation points > > Brian, > > (I am probably about to put my foot in my mouth, so it's much better to do > it in public.) > > My understanding is exactly the opposite of what kre said. > > When I read about the "mount-like semantics" discussed in 2181 zone cuts, I > assume that it is just like the unix file mount: When you mount a new > filesystem on some point, all the files below the old mount point are > unavailable but do not disappear. If you unmount the other filesystem, they > reappear instantly. Also, if you dump the disk by walking the inode tree, you No, the non-authoritative NS and A (or maybe AAAA) RRs can get completely overwritten by the better data from the subzone. If you are doing an AXFR, you could send either. It won't effect validation of the zone based on SIGs and NXTs. If you happen to have a child SIG on an NS or glue A RRs, I guess there is some ambiguity on whether you could send those in an AXFR. But since such SIGs are explicitly prohibited in the parent zone, I think they should NOT be send in an AXFR. (Of course you should not send the child NXTs but I guess a security un-aware server migh send those along with child glue SIGs so I guess a secure server has to be able to handle receiving these in an AXFR.) > will get all the files including the hidden ones. So when I do dump -> > restore, the hidden files are there, which is the analog of axfr. In the case > of DNS, since the NS records are still there on the copy, the data is still > hidden. I thought that this was one of the exact things that 2181 was supposed > to clarify! > > I can imagine a case where you could use this, but I do agree that this can be > done better in other ways. I am also not exactly sure why being authoritative > for the child or not should change the contents of the zone transfer (though > it would certainly make the interal data storage for BIND different.) To quote from the current secext2 draft: DNS security would like to view each zone as a unit of data completely under the control of the zone owner with each entry (RRset) signed by a special private key held by the zone manager. But the DNS protocol views the leaf nodes in a zone, which are also the apex nodes of a subzone (i.e., delegation points), as "really" belonging to the subzone. For backward compatility (think of a zone transfer from a secondary that hasonly "Basic" server conformance, i.e., understands KEY, SIG, and NXT but does not crypto), DNSSEC needs to yield to the DNS way. Besides, I really don't see any harm in some versions of a zone being "better" as long as it doesn't break any SIGs, etc. > jerry Thanks, Donald ===================================================================== Donald E. Eastlake 3rd +1 978-287-4877(tel) dee@cybercash.com 318 Acton Street +1 978-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.privacy.org/ipc