From owner-namedroppers@ops.ietf.org Sat Apr 01 01:39:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPZlt-0000tK-Hg for dnsext-archive@lists.ietf.org; Sat, 01 Apr 2006 01:39:41 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPZlg-0006jS-Ta for dnsext-archive@lists.ietf.org; Sat, 01 Apr 2006 01:39:36 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPZhS-00037Z-Hv for namedroppers-data@psg.com; Sat, 01 Apr 2006 06:35:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPZhR-00037D-BS for namedroppers@ops.ietf.org; Sat, 01 Apr 2006 06:35:05 +0000 Received: from open.nlnetlabs.nl (localhost [127.0.0.1]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k316Z0Uv017694 for ; Sat, 1 Apr 2006 08:35:00 +0200 (CEST) (envelope-from olaf@open.nlnetlabs.nl) Received: (from olaf@localhost) by open.nlnetlabs.nl (8.13.4/8.13.4/Submit) id k316Z0gS017693 for namedroppers@ops.ietf.org; Sat, 1 Apr 2006 08:35:00 +0200 (CEST) (envelope-from olaf) Date: Sat, 1 Apr 2006 08:35:00 +0200 (CEST) From: Olaf Kolkman Message-Id: <200604010635.k316Z0gS017693@open.nlnetlabs.nl> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". To counter a certain class of spam mails messages over 20000 characters, originating from list subscribers, will be held for moderations. Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e. follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.8 2005/01/12 15:54:51 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From attyguy@mentionentertainment.com Sun Apr 02 08:27:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ1gQ-0007Lj-9v for dnsext-archive@ietf.org; Sun, 02 Apr 2006 08:27:54 -0400 Received: from [85.136.238.158] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FQ1gN-0003Mu-1Z for dnsext-archive@ietf.org; Sun, 02 Apr 2006 08:27:54 -0400 Message-ID: <000001c6567b$5a255500$0100007f@localhost> From: "Jaden King" To: Subject: Software At Low Pr1ce Date: Sun, 02 Apr 2006 14:28:03 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C6567B.5A255500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6567B.5A255500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C6567B.5A255500" ------=_NextPart_001_000E_01C6567B.5A255500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By the time Scarlett had undressed and blown out the candle, her plan for tomorrow had worked itself out in every detail. It was a ------=_NextPart_001_000E_01C6567B.5A255500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software






------=_NextPart_001_000E_01C6567B.5A255500-- ------=_NextPart_000_0001_01C6567B.5A255500 Content-Type: image/gif; name="Lf.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c63b06$0762dd00$0403a8c0@mlto> R0lGODlhmwBtAaIAAO3uygAzmQAAZv///8xmAAAAAAAAAAAAACH5BAAAAAAALAAAAACbAG0B AAP/OKrS/jDKSau9OOtNlx9cKI5kaXbeqa5sSy5uLM8yQ994noF67/+jD+/jIEpsDRiEl0ym BLYoE0pMCakPI3UKLDKRUmdEiUWKm9jscD2emsFubrS7/NrPZq8+r2TXy1xngmmEhYZ0gnB4 gYQMfGVOZI4geYNvd16SlV2Ki2R/Yo9bg5GlbWqoloyHQJ1pm6mAS3qsYUdxsZezrD+XmhVP o7toWq+rcK5VwZ+Izc7P0NHS09TV1tfY2dozAN3e3+Dh4uPk5ebn6Onq6+zeQu/w8fLz9PX2 9/j59936/f7/AAMKFMJvoMGDCBPmK6iwocOHAxlCnEixIjyJCglo1LiA/4AHjx82huTYEaSC jSQ7fiwp8iRIkjBNQsSIMGVMlR9f5pSZckDPnDhtvhzqsihFmgeFutQJdKRPkz1/sjxp9GlJ q0qPAniY1SNHmUuBZl3606vXqkq/QgXrEKnBrmHfCW1p9arcuGNb0pXa0O1AuFWp1u3Kk63g wWub8tUKESXUlSMTG3X8lO5hnyzLErU70a/Fz6APeg5NuvTCraZTqz7drrXr17Bjy55Nu7bt 27hz697Nu7fv38CDCx9OvLjx48iTK1/OvLnz5gECdIv+vPo6AeyiS/e2HUD37uq0gw9PnXv5 6ee9p2fuYN137vBfv3cff779+M+xpxsvXbx47//mbaedOPcJuF44AtaH34LN6YcOf9Phl6CE CNY3IYDjzIehhupZB4CD50CI4YgXqjcgOP9FqOKIKH5z34oMskffihqWOF6LOJJIYI4X9pjf A+SBV2OA6B14o5AHmnjeiUW6mKSHUEapnH9UVmnllVhmqeWW/knp5ZdghinmmGSWaeaZaKap 5ppstunmm3DGKeecdNZp5514knljjO3sGZufzrUXXobkAJohk4byWehsTKL45DkOglhOfzsS OuOGD14qX4zSDcBia5IuiuSSpKbXKIVKOmlgeY2emGKTRe7JIY2whWoppiq+iOunOvaqq660 +srnq6iCGiSrCuZq4an/qQb7q4RDCgtjhS16mig5ti6q7La7lkiti8l2y6CP0vJa7KzpQBAi jq8i2iqzR0KLJKwmnluqn6aqmidx1zLH5b8AByzwwAT3u+/BCCes8MIMN+zwwxBHLPHEFFds 8cUYZ6xxjhsLuq6zmTK6rKzMQhlpyL3uR9uzPJKZbYWU2vduqfbKmnK8yq5aXQODxhwuuQXu emvKqCI7rYyZ+swt0ApSih6h35XcbrHKnawyjEwvDR/O4HJbaddEV83zoFgH22y9WxP5rbcc Y/3oxhgXLPfccsNt991456333nz37fffgAcu+OCEF74voAav/ObLX7cNtqaQDx2gkSXvNnbS /407vm7ij2vrOdW8Ycd4i6NGbfqoUOvrtLumslq5zTnTK5t+oxf9M8hHA2u0uOxO+rWBZsem bogpsiwzvMWDzXKziB+6JOizX8278b57HS31knMKvfAo58r65KqKuCyLrJdu3rfou8254R7S 7f778GfJ/vz012///fjnr//+/Pfv//8ADE7i1vew4ZmjSwOcVNSCpzbZwUtKtWtbAgu1wLCV i1xPixKQukei1q3KZkoDUKKypiMCHieCyeud8mAmws6t7XZCgyAHT3c+BuLqPc2znfcqh7QP zZCBGExWEMcFQ0UF6nIH5JGrnpc7FfKqSw40UgAPF78qzm2KWMyiFv+3yMUuevGLYAyjGMdI xs9pDInEM2HueNga/rxtZ9kxYhJbJptWyTFQcSTQ83TWxKbRC11HC6R1NvgxOu6ObULKYNdC qDk1FsdqczTk5BC5yPBFyGnpM5fJvBHBC9qQa9EqoRkdeUI0HtCDC0qhJVOJKHNBEYplZJMV ZwmwWNrylrjMpS53ycte+vKXwAwmngxYPU1qLnJ0zGSfUNlAWL4GhWzLXBwNRUrpkTCarulk CFv5ynulLlbgnJA4W0ijt10TnNzDHNAwOERPSkucJPTc8u5ojk5u6Jy4e6IqszZOsz0qkVo7 ZrrINr1zfRKGNVqe+DqHPWNC6lKmY+UfiQj/roR2MFzMSxIsZ6YvYbqGliANKcE8StKSmvSk KE2pSlfK0pb6rZoH81gkgWVG2HC0gWhD0BuBA8liArKmH0VoEbc3nJ76bpvoTGory0nNfHJt WHvsVlRBZUpRkbOgAVXata4nUT1er58yyyYnVYZUdwatgo2bpyB3eEi2YhMdRvVpJbNKoadS FKtPxKjbtPfMqspzrh2kWdpkN0mc3lSn5iNfYmH6S5E69rHyc6lkJ0vZylr2spjNrGY9ytg1 7bQdMi1kDPeDVkbBzoLIrGZcv+lQ4tVQZLf6qfRcyI7V7uhXzKzoVZcaUWXqFpM57ZHrqNMf YoE2tLH1mnJ/m9fR/x7pdS2EXT+lulbQPiiFNFTkXLMrXCkG0meLdas/aaNNIQKRWtNFK7p+ yiGL9hG1tS2vbgPLRwmCj5Ua/ee43LXK9nbWS/+NE2QHTODNGvjACE6wghfM4AY7WE45DGpr 5SQp5CoqwqSdrmiLmUfaCg+JqwWuEQlIUw6b+Lqoyw2IQqxYwZ4tp5K8GXEHtLrh1lfE773N iscaY7y28516LW1A75m9AH9jx90I1SuFKt4X8q5DwdunXl1oZB4n2co69HF1gTwtdhbxrXad jQGRK6J2efO+He1ufTuUWCgv1VFLZONlCUxnKz74znjOs573zGeX+hVS9vyShUt5HdpVOP/Q R7wyewI9tj+77NCXI2SSgeSxDfLs0qEdXqNXTIFJT9rRPzK0pzd9ZFF/SHSiloCnOZlqU7N6 1Zg+tZkwTWliklrWpI60rU0taVi3+tSDhiOuDz2OW8d62K8Wh7GRu2xZJ1vQuhbUrn39aVcD G8SS9qumUX1t9oH6f9/u856DDcBwP9t+5l61xNRVaWlbutXtIWStt43sdzubTc0utbOPfWt9 o7HZqh42uR9N7WtzG9n7jlStwQFwhS8cTg0f9a8TTu1/8/rg91a3m/LN7ou7m9XujrbBM95x cZv85ChPucpXznLAfRZipNqyhCf8sJjvRrYSAy9TyXnYODuzYjqtF1pbP6VWi4G1bP7kqsxr vi0bgQ6fGSszkVIM4zdDueUCrDOVsM71rnv962APu9jHTvY/vXzmeMP5n/aGsw9W/czFy23O mehlJ9a9ygJues2uqUqKufdmTj3oxU4VSu5CS6lnbxje86b1yJb98ZCPvOQnT/nKWz6SvjUc voCqeVdyvnDANXN2Cdu3hkL9pVI2q3H5Zvp8Bq7M30vqiy+vG5HS/va4z73ud2+bBAAAOw== ------=_NextPart_000_0001_01C6567B.5A255500 Content-Type: image/gif; name="MW.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c63b06$076ec3e0$0403a8c0@mlto> R0lGODlhNgFWAKIAAP//////zP/MmcxmM5lmM5kAAAAAAAAAACH5BAAAAAAALAAAAAA2AVYA AAP/CLrc/jDKSau9OOvNu/9gqBiGKJKkyaQbq74whpavGwO2vbL6bfUSnZAGrBR9I9ouOTs2 UaBjVHnLAaFIzjCyXX6kvh6PiiMvuh1wdrozz9YtslNOZ8Md1rPbXMbzL2p3WlQlQn2HTGNM eliMQ41lWE8PLm9JepeWbYWEmoiflZ5+l5gNV3ukjU2bnZCRVqqteaKvnSugnKSIKbySSqGl u7ZeEJUjwWO/w5HIysSHwMVEy8HPqZyKup/CzbrZ3Iva0aDe19qMpnXb5+Pn6ebgXfLq4PUU omJ8+eHV9vOU+qa92zZHHLxsp0Z5wUcPjTRouUr9W9hw2jdaAB2uY+ds/2A3R6tepZsokV6i bzgwdUTZj6CyWB41jiKEi6NNlxKP4XI1EFbIjD/XocnDxdNPlkg7wtMp8mBAhf0sDTUJdBPF nuocSuXZFKC4P16LQvVGTdojgTjTkkxZDeFTj+4gxqSasQ3Wu1efbS0YliwgsEIrWhOrMOnN tdQuOkvot3HNwWMPC+bX7uvcviX/Bnn7uC1auUvHIUYJmPRWs2fpuMrH15phRzsZuws6mOXm 20DpTgLJyjOkqVBsCxpOvLjx48iTK1/OvLnz59CjS59Ovbr169iza98+QEF3AN/Dex8Pnrz4 8ujPqzfPPn3789vjy78xYECA+vft49+vf4AA/v/5BQjggP3l91+BBB4oYH/zNeigCPYJEICE EwZQoYQUZljhhRxiaKGHIH64YYgkiujhhd89qOKKFvg3oogbdmjhiybWGGOIMtKIY4n3segg YGkMxxUD9k1IQAH/EfBfAQQoWYB/TwqA5JEE+DcAk/YVoGWEATS55H1MKnkkkxOGKSGSXVJZ ppgEfJiij/IBSVhLa9AEAZdUSmmkABKyKeZ9SloYKIaDTnhlmnyiiSiSen5oQJlnCorkAIH2 COd8cj4EWRZ2OuBin01SumSTaTZpqgCm+nckl1GKiCSalFaJapVtCmCAkmcm2SeUqaJ4aZzM MMWWKcMWwpQmERkVSyj/vfRwX4WxHgmpfloGgCWiFA5gAKEnomrrhFK6SOm2hBZQ5rmidhmt m7/G+Yuw+hTLFhG37FKvG/UOq28DeDrJpodkFvAoqi5WKKu1tRrMJKiEVmkuhmhua22iueZp aLvxdUovJcdsvDGxZ9yLR76d8otim2TaKq2UYqJJJZtoeqthuODeai6lE1Oa8sPrEkxzthhr p7GwIntMNLwkGxMy0nfqCKOGTkcN9dRPV/0i1f8FEHR2Q++7tLzzcvy11x+DffQCn8pY4tpq t832225DuzXX+W507NJl5123Tl2f7R2CgC8oOIGDB0744Ya/OTd1tDkh9kvvWpWI5ET30F2P /5hfrjkAltpXXuacbw565lqLN7roqIdO3uKYsu7669FlCvvstMcge+2456777rz37vvvsd8u g/DAF//cPnPWAlYgXzALOWx+OG/87MzrpVRxxhobMk0l66u939O3i3wt5MeTi/OQl1WM1x3f 0j33e4cfNPLjmx/cZ718NMH3xMI/tvcAlN/i6KeVlQxjfNVDB8f8Vzn3xU+Av0IgTEByPds8 gXgXzKAGN8hB4kFwO/ULFlHgYkEPLpBkDvwfA9n3QR+FEDRxIQowRJOp7I1thXJIIfhaqKIL QuQ3whnhUZRlhJSUDYDv0yELechEISXDF9I71rJM2MQqmoCKVsyiFv+3yMUuevGLYAyjGMdI xjKa8YxohE4CPVCANBaPNj+AI51i0EY3+q4yRrhecbTExwdoiQF8/CMEAllHBRCykHZkDkkU kT9zNLJ8kLRbA/5YR0QCoI+GLKQgJ6nJTiZSOou0yCOfmKzFKCUQlPTjJT2ZST+ycpWfDB5e YGi+vBBjjavc5AIq+Upd7rKXgYxlc0L5FWQdcA9ypAAhd/nLZrbSAZv05TOFmRxidsZ6s8Ei JwV5SG4u05XBhKYlqWkcGoZjhNjkhjkv0EZpSnOaEfCmM8lZTYaUEjJCNCYQK1BJWHLSlYAc ZzRfSU8wfvOfv/TlQBUazoKOcZwOjSgHICr/0Ypa9KIYzahGN8rRjnr0ow6iaHNEagKSghGd GUjmcChqyYM2VJy6PCg0B+nShmLSkJNMI0o1ExdB1LSlM2VmUHFKVAmYVKiXHGo/h2pG00wQ hujTX1BQmVRVApKpEEWkJpXJz6vmFKcsdSMRQ2OR/eHvrHPMaVi9ytaqfrWoJj1qUd2K1HbG U6yToSEQT0PWDbyTrrncKlLb2sm/yrWlN81lUhM716bmVY8iPGVElEdFxgLWq1q1amM3e1nN MhWsg+3sGKfSmGiYE49+baxIl8rZzH6Ws2/1LGhVi9fL/LC0FcxnWoMK1MGy1q2CJaprYzvI 2PY2uLAVI2tgIYy9L+51JDsFZ0xtmtiXarW6lg3ta19KV8bKFaTG+e4eVwpe6Yh3vHA4b3l/ p97UojEBADs= ------=_NextPart_000_0001_01C6567B.5A255500 Content-Type: image/gif; name="A.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c63b06$077134e0$0403a8c0@mlto> R0lGODlh9QBXAKIAAP//////zP/MmcxmM5lmM5kAAAAAAAAAACH5BAAAAAAALAAAAAD1AFcA AAP/CLrcbsZJKKu9i+LNr+5gKI5kyXxetKEm5Lqnas4KS2Mvm8vAbtm2zGs1rAQfvF+ypJMd OU9Q9CbkfVAa7LK2PF63wjBy2gM3yNCuCm00S91U7nmdzNa3QPy9PR/rKVowYUUxghNqcoRV gYY5c40RilyGZWVPUWxyhzF8nJueYk1VYpWTpKWofaqQoFqqqF+mmrNfTmCYmV5Wt3ufp6Wu nqKpwL2vob3DqcNBzMnGoG2Uvp+X0NHLu792q887eq/O4drC0+Llx7/Sujh0KaPU2a3P3fVp Ptvu89i1sej/6oi1Q9Ru1jqBBrPhI8YNoCY2uOyRCpavITKJCTMWxKYk/5NGhraQJLT4kF6a dw5hkQtIshhGhCBHriTikaKyPBP9qQx5qpmbmzxl5ry4j5bOMQ4pdsilTCVHRgpdSbI0LWC+ Qnn63WEVzdGgqn4YiZ2a7pDPRx7jqF3LlkbatnDjyp1LF+7bunjz6t1L9y7fv4ADCx5MuLBh AAMUJEasuDHjx4sjO5YMebLlypgpaz7MuTOGAQMCgBY9QMDo06FRmy6NmvRq0q5Vt56duvZr 0Ks96969ILSAAAF+Axf+m/jw4MeRF0eunLnx586bQ28efDHv64Z9H18uvbv35dyNRwe/PTl1 8r+tY68Lx62HEtoJFDBNwHQBAgQCFCi9X8B8+f8EpHZfaAXcl99v+NlnH34ByHdfcAZCWJ18 vt0nAIPpradXezi89wN8yFHoX3D1kTgAfvXld2Jx9S0X4HIDFNDggSXS5599xxnw23w3Nvif duppOBeHHhpRZAilhZhgfTEyiOKTF+IXGoUAQBjefwIsmN+TwRlQ43wnkpjlk9qZJiR7lmRw wodb9aMmJWQhJtyTMvpX2pgyFjhliwj212CZM8qIGJOBJnnhfPqJqR+BJ2Io2pnsOVHDmkZa QamlsEyqpgOGrmiho/oZEKqJ4GHY4nEAFoeojXVKKICoN74qJoDIBQlpW5j2oOkEm+q6KabA UspAaEr62KV8JKZYIn7/DzKr6oHKGeAbgDIGGICOJ1qoX3oDjslfjY/eGleua3y4a7C/XupV A4YmF5678EYnr3j0xlvvvOGKa5ew5a4jaboAawqHaN2hV/DBBieM8MIJ26pvHLnC5GvAWVxq ca/D1gYbbRtrzPHHHofc8ci0PWyXJJecMYotWmElQWKPhhsaYzHDbHOVN9eM8846V6bzzznb HMBjJuNFZNFIJ82E0kw3fcPRTkct9dRUV2311VhnrfXWXHfdmV8beS12CwR1MglYH60FiSCE kNU22mNT8ZZNULMVia91rBnxxLruHTfEZTvilT+ARMJyy1apvLeli+st7N9q4SQQ3WcbbpRT /2k7vivGd2PMd+ebQy43QeasRFJLmIewdsWJbKN56KK7FThXlQflElpw+/vN7rz3/k3sgItU iEFnEcURCaB7znfojD8O/AySJwWO8YUPtULfD2Sv8uPJ1/287pZTtYs+xyAu/vHZ3928wMqv D/v3wK8Ojyznyg///e/jr//+/Pfv//8ADKAAB0jAAhrwgHIBmwgKgMDCrEt1DyxLXBjYQMEc ZSm2+0uBNtiADVJQAR78oANCyIAQitCA53BJ9UpSCfM9EA0FAgAFPxjDDtLwhCC84QJqWEGh YE5wPAHi5XQCQwaekIcl1OEIlShDHCIwhacLIjmi9xYP2tCKOdyhE/95yEUsNhCK5BOf7VD3 uxGQMIto7KIE1LjECoKReNNjoQRJgEU2NtGLV+RgG90YFDuEsXhybGEfoWbEGTIxiRuooR2/ iLIVKqUnh4sk+joIwiai0ZI2RGQmL4nEHjbtjDnUYyiPeMNOgtKTUnMiKg2oylW68pWwjKUs Z0nLWtrylp1ppWF0GQde7uaREMxdXnAISjziMY9JFOUILWBMZTqTkrcCJgYTh5diLnOHlcTm NbMpw0Qys4Tc7KY4xblFcUWRdhZx4SDhxCEjblOb2RRhOeHpy1bKM5wzxKYqfakbRRBOinBI J/kuWAF3QvOb40woPMfJS13eM6H5rKQ99QWmlMtVDisCtegCialMeoLznaXcJwaaiUQOFpKY FDVGRh+h0RWK0XuhLKgmtdhRfK7xpgiN50fBScODQqqiP5TiUAhKx3B69ALzNKpSFerTiCrV oArlp2eA6keLHoWd1uNARB/a0J1ydadgBalNP9rTsAopK4HYyViGh9FJJrOkojQhTZvqzJou dIlwNWUyfYpLme5Gqr3s60ivA1gaFFawujlsUcWVAAA7 ------=_NextPart_000_0001_01C6567B.5A255500 Content-Type: image/gif; name="MO.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c63b06$076ec3e0$0403a8c0@mlto> R0lGODlhbQFWAKIAAP//////mcyZZsxmM5kAAAAAAP//zAAAACH5BAAAAAAALAAAAABtAVYA AAP/CLrcWsXJSasFEN7NcnwZ9nFkuXnmOaacxjauK8lvbU90F693n7cengi2+tWCoZuxB2JW jMjk7LMcOhdIR1CL0nWx0OqVlRNLRUWeWKkWmtbjeJNbCsuJuvx8L6P5f193R21PQn94goBu JHCCTnaMbo02ZVSEVmB7fJgPVn9JOyNbXpVno1mIdGihO6RpZ6mZnn2BoyCwtquir4eBt4eq FCituhGfvbAWxLKVwqKcGsu0Q13TfLuympyxetvAmNKLik3V2NnX2eHo1+br29qpoO3g7VKT s4jNUx2b+O9o3JZ1cwfvXDd9cyAZhBcq4Dx9CvVAvLTvX5R5/qBZykex/5BBgd5wJdyYcaA2 Vg4/LvpHLxbIX7lULkR47BSumydJqixXsefIcyCDrgR6CaHLTOZevqP5hSk3k+k6Kp10EarT ha6y/pRIEVjElC2ZFe3oM2ROZ1jAWJtqiCzPg2ShEtRYkOrQcXDlEilFciLHv8ECZ/Q69qnV wnrBDST21ayqq1hnpnGpM7FhyfEmq6go9KzjxjLDbhV72SJi0gcX65ym0JrobwXVejH5ba3m 0qaJUl5nO2roT3Xv7lp927XRxK5f38bgUaM8HL5iSm9bBRXt5bms414ynUut7/Z4LacXgm0U UiWHib8+5bxaRTd9OZpPv779+/jz69/Pv7////8ABijggAQWaOCBCCao4IIMNujggxBGSMEA ClAIgIUYVqjhhRtmyOGHHobY4YggkuihhCimqGIJAwxgQIsvugjjjDIOEACNMeaI4441xnhj jzz+qGONKxZp5JELuBiAAUsyaYCTSzYppZNQVhnlk1dmiSWVWna55ZVQWojkmGQ2aCOXW1Jp 5ZNofummmlqu2WacXr5Y5p39DXVEfsk04CKTAxAQgAA2CkAAATYSIIChiwoaqKKDHiqAAYcq 6mSLkRpgKKI3Hqqkp0sKqmmgnxKQI6B4pqqfnmhZlgg/Eyj5IqKGamrqkgMQSmuNTVoaZa5Q 1opprU9iKiixTN4qaAD/plKqKKbFqiqtfaxCh9uraUlwJq6BGhopjS2G22munU4aqgBTCmqp oeSGq6yNoUZ6LrPhynrjtPi+ag+sMDDXCRXvpYVSwL8ELN+Fl7pr66K2mippjAzPai6wUuZ6 K6OTPoruqMraCuikihYAI6r5ljxGH51k2+8zAPubMsrZGsJvERMmHIDI8jp5qLOAnmkzpeZe yqmtv1oMpahIB8Dsuez+avLTTND8Mg7/Tu0yv1e3jPUzKvsZZqKmbvpup7iCqnGyGzvJKJNi 56jopp+y/fCN6CJKpZhQ5/3GzClrUbW/Wm89M8x9S63tnGlOifjiijee+ONoOn6v3pTXwffV /5cD3rfgXVtdONZ+ein6mqOXTvrppl+Jd+WsC7P1SlxrnvXmhsecOeYM8Djk7rr3DuTvvAPv e+vEO4MT1X673NRew/EC+g8ilih99NSbaP30159Y/PbKcO/99ylWC/745Jdv/vnop6/++uy3 7/778MfP4D11iC///UjiZe171dk/SPOWkEcYaEE//KmvgHSJDbWYE7jNzU5wtTMg/vS3BZuQ JhoA5J+r/uZAzEWQZhGUoPzwor+wVJA4yjmB8pLHua4ZA3QijB8JjdIb1OTlDQRkReDUwI8Q xvB9FAyPKx5SGZgU8CJITKISq/LDEbZlL5qIyEsQOAPcyeyDPYRhE//bV8LR5MaGGPTNBV4o s5U9L4ud2yIXs6DD2XyRHTkcD9XIiEYOerCOuFOjHh0UnhwSTHl99N8eBykgQRLykIhMpCIX ychGOvKRkIykJCdJyUpaUpFUZAEBLsnImADhYAqMwyY5mcjkACEy96nUoRqgSgaocpQSeKUr ZUlKqPnlJ2HEpTEyCJMNAmCVo4TlKlkpTFjOcgHD/KUxa2nL07TRNuVBoXGqBUxixrKY10Qm Npmpt1umJymaCWIKWjlLcipTm9lUQDJpyc2SeVMg1iGMd0BpAXauM5jbtKY6l7nPdrrTmZWR YhFZMs5K9fOgyjQnMRWKTn/ma5q3iKIkwon/DYiSYJPDvGc6K5DRfDp0WtPZpUR9EkcNotKV 6jynSlfaUIS2VKMfjek+DapNms50mfdM5k35KVOH8rSnQK3PT4NK1KIa9ahITapSl8rUpjp1 qUMVUFSdMNWnJpAM9MTPUI2pUIaWk6teRSYFzPnKYnKVlVZtTijVmkmqMnSdKP1lXNEq1pTW c6xzjasw7UrXtHJmPbypR1MEawpqytUBGK2rXc+K2LlWdat55etef1rVp34HjAFUBgpTeIHE 0nWvdWVsXw9L2glEVbSKnSxe/bo/MU6zsG8ZjCFZSlqwwlWxeTUrZetpU9wmVK695StrwSJb 77gjl8WY7W93Ws3QgUZWuDyNLkcju1vQ+na4nimuCQUrGhsEs7HQDS94hXvd0o63tJC1Lnmx 6xh/PGc0wBEjQcHLT/V+N7W4ve96zTta1OrVt5V1KnyAU1L+vYJ5crxmcKHb265+9cGm5Whw pVvT0bJXWgHeT4aZsOELq6jD+QHxC0Ts4R+SuAQnLmoCAAA7 ------=_NextPart_000_0001_01C6567B.5A255500-- From owner-namedroppers@ops.ietf.org Mon Apr 03 00:34:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQGle-0000Pa-MX for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 00:34:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQGle-0003zm-1Y for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 00:34:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQGec-0004Aq-Ts for namedroppers-data@psg.com; Mon, 03 Apr 2006 04:27:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [144.189.100.102] (helo=motgate4.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQGeb-0004Af-Lv for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 04:27:01 +0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k334dfXD002719 for ; Sun, 2 Apr 2006 21:39:41 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k334dbSv010247 for ; Sun, 2 Apr 2006 23:39:37 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Date: Sun, 2 Apr 2006 22:37:35 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790C319D6@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review Thread-Index: AcZRvrqACtxzM9FySdCHbcbNLkHKFAAqFAaQ From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Hi Mike, See below at @@@ -----Original Message----- From: Mike StJohns [mailto:Mike.StJohns@nominum.com]=20 Sent: Monday, March 27, 2006 11:53 AM To: Eastlake III Donald-LDE008; namedroppers@ops.ietf.org Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review At 12:42 AM 3/27/2006, Eastlake III Donald-LDE008 wrote: >Hi Mike, > >See below at @@@ Trimmed all of the text - readers can see previous emails in this thread if they want more detail. Don - If I asked you a question of "how do I form a valid DNSKEY record=20 containing a DSA key" I believe you would claim that this ID taken=20 with 4034 provides sufficient detail to do so. I disagree. What I=20 get from 4034 is the general format of a DNSKEY RR. What I get from=20 this ID is the ordering of bits within a key blob of some form. What=20 I am missing is what format identifier (e.g. Algorithm identifier)=20 applies to this ID and where this key blob explicitly fits within the=20 DNSKEY RR. If you're saying this isn't the job of this ID, then my=20 question is "where is the ID that maps this ID into the DNSKEY RR"? @@@ Of course RFC 4034 and this draft provide all of the information you need to form a valid DNSKEY. RFC 4034 says clearly "where this key blob explicitly fits within the DNSKEY RR". This information is in section 2.1.4 on page 5 of RFC 4034. It is the same place all key blobs for all algorithms usable with DNSKEY fit into DNSKEY. This information is a characteristic of the RR, not of the algorithm. And RFC 4034 says exactly what algorithm ID to use. This information is in section A.1 on page 24. The exact linkage is not particularly due to the string "DSA/SHA-1 [DSA]" but rather due to the exact pointer to RFC 2536 which this draft obsoletes. If you don't like the fact that, assuming this draft was published as RFC RRRR, the text is RFC 4034 wouldn't be magically updated so that DNSKEY Algorithm ID 3 referenced RFC RRRR, it's just the way RFCs are, being immutable ASCII documents rather than having some sort of dynamically updated links in them. Whenever you see in one RFC a reference to a second RFC, it is always the case that the second RFC may have been updated or obsoleted and to be sure you always have to check the RFC index or some similar up-to-date source of this information. So no other "ID that maps this ID into the DNSKEY RR" is necessary. @@@ I can understand if, in your judgment, it is better to be redundant and in every crypto algorithm key/signature DNS encoding RFC, as it comes out, to include within it a snapshot of pointers to all of the latest DNS RR defining RFCs that can use that algorithm encoding along with how, for that RR RFC, to identify the algorithm. This redundancy might be convenient some of the time. But with the gradually growing set of algorithm and RR RFCs, they are not going to be all updated at the same time. So in the long run, more redundancy results in more out of date RFC numbers. @@@ If I were adding such redundancy to this draft, I would probably do it via an Appendix which would say something like the text below. (I still can't really see any reason to list the RR field the crypt goop goes in. Anyone seriously trying to use algorithm X with RR Y just has to read the latest algorithm X RFC and the latest RR Y RFC and every RR RFC of this sort that I'm aware of makes it perfectly clear what field the crypt goop goes in for all algorithms.) Appendix The encodings for DSA keys and signatures specified in this document are usable in a number of different resource records. The table below provides information on such usage at the time of publication of this RFC. Note that, since that time, any of the RFCs referenced below may have been updated or obsoleted and the RFC Index should be checked for this. Also, additional resource records may have been defined that make use of the DSA encodings specified above: Use of DSA Keys --------------- RR RFC Algorithm ID Note -- --- ------------ ---- KEY 3755 3 Used to support TKEY [RFC 2930]. IPSECKEY 4025 1 DNSKEY 4034 3 Use of DSA Signatures --------------------- RR RFC Algorithm ID Note -- --- ------------ ---- SIG 3755 3 Used in SIG(0) [RFC 2931]. RRSIG 4034 3 @@@ Would such an appendix with redundant information make you happy? @@@ Actually, there is an argument for having a third regular document type in this area besides algorithm RFCs and RR RFCs, which is somewhat like the 'linkage' document you are talking about. The idea would be that the basic characteristics and format of an RR, like DNSKEY, changes rarely in comparison with changes in the list of algorithms usable with that RR and their implementation requirement (MANDATORY, OPTIONAL, etc.). So, for each type of key/signature encoding usable in the DNS you should have an algorithm RFC. For each RR (or set of related RRs like DNSKEY and RRSIG) that can include such encoding, you would have an largish RFC that described how that RR or those RRs worked and gives information for them that was algorithm invariant, such as where the encoding was inserted in the RR and how algorithms are identified for that RR (i.e., the location and size of an "algorithm id" field). Then this new third type of short document, which might be called an "RR algorithms" document, would, for that RR (or set of related RRs) list the algorithms that can be used with a snapshot of pointers to their most recent algorithm RFCs and give the algorithm IDs and any particular limitations, such as on RSA prime size. (We already have the case where that limit is different for DNSKEY and IPSECKEY so it was probably not such a good idea to associate the limit with the algorithm. The limit should be associated with the RR). I refer to the Algorithm Identifier field as a format id because=20 that's really what it is. It describes the format of the PublicKey=20 field and needs to reference a specific document to do so rather than=20 the more generic algorithm name. To understand what I mean, let's=20 consider the RSA algorithm. The RSA public key has two common=20 representations - the Public/Exponent representation and the Chinese=20 Remainder Theorem representation. Neither of the two RSA related=20 Algorithm IDs in appendix a.1 of 4034 provide such representation. I=20 would need to define a third (or more) RFC with this format and the=20 assigned algorithm ID would refer specifically to that RFC. @@@ You are correct when you say that the "format id" need to reference a specific document. However you seem to imply that the format ids for RSA related keys/signatures don't reference specific document when they obviously do. Thus far, the idea has been that it is desirable to have one standard encoding in the DNS for a particular kind of public key. If you wanted to provide a second encoding for RSA based on the Chinese Remainder Theorem or whatever, you would need another algorithm ID and mnemonic to specify that encoding and they would need to refer to an RFC specifying the format. You're proposing obsoleting 2546 and 4034 points at 2546 as being the=20 specific document which defines the format for Algorithm ID 3. You=20 need a replacement document which links that algorithm ID (3) to a=20 specific format. Its just a simple as that. This ID does not do that. @@@ Of course this document does that. (By the way, you have a typo, its 2536, not 2546.) This document obsoletes 2536 and so should be used in conjunction with 4034. The linkage is provided by the "obsoletes" information in the RFC Index. Also, the more I think about it, the less I like the current system=20 of assigning a single number for both the public key representation=20 and an associated signature representation. We're about to re-do RSA=20 with SHA1 into RSA with SHA256 and possibly other SHAs. I would=20 expect similar actions for DSA. I suggest we split the algorithm=20 assignments for key and signature as follows: @@@ Here I agree with you completely. For most public key systems, there are many more signature algorithms, differing in hash function, padding, or whatever, than there are key formats. @@@ But while we should remove the linkage between key and signature algorithm numbers, I think we should also, in most cases, add a signature format sub-type. (The usual anti-sub-typing arguments don't really apply since you are already sub-typing your RR with the algorithm ID or whatever.) Otherwise, you have the situation where a relatively small set of values might, in the long run, be getting used up an order of magnitude faster for signature formats than an equal sized population is being used up for key formats. @@@ Thanks, @@@ Donald Algorithm IDs for Key representations: 0 - Reserved 1 - RSA (modulus/exponent form) 2 - DH 3 - DSA (Fips 182-6) 4 - ECC - not yet defined 5 - RSA (modulus/exponent form - same as 1) Algorithm IDs for Signature representations 1 - RSA/MD5 - not recommended 2 - none (was DH) 3 - DSA with SHA1 4 - Reserved 5 - RSA/SHA1 6-127 reserved 127-255 - new signature algorithms. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 06:27:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQMHj-0007U3-Ld for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 06:27:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQMHj-0003ej-5D for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 06:27:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQMDt-000NOd-3q for namedroppers-data@psg.com; Mon, 03 Apr 2006 10:23:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQMDr-000NOI-Vl for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 10:23:48 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id B72D756825; Mon, 3 Apr 2006 03:23:45 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060403061607.03905270@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 03 Apr 2006 06:25:06 -0400 To: "Eastlake III Donald-LDE008" , From: Mike StJohns Subject: RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt review In-Reply-To: <3870C46029D1F945B1472F170D2D9790C319D6@de01exm64.ds.mot.co m> References: <3870C46029D1F945B1472F170D2D9790C319D6@de01exm64.ds.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 At 10:37 PM 4/2/2006, Eastlake III Donald-LDE008 wrote: >Hi Mike, > >See below at @@@ Rather than continue this, here's what I think the document needs to be. I've trimmed the boilerplate at both ends - but I have a xml2rfc file which generates the full document. I don't believe there's a need to obsolete the old document - and doing so would actually void the KEY and SIG mappings. Network Working Group M. StJohns Internet-Draft Nominum, Inc. Updates: 2536 (if approved) April 3, 2006 Expires: October 5, 2006 Use of the Digital Signature Algorithm with DNSKEY and RRSIG draft-ietf-dnsext-dsa-update-00 Abstract This document updates [RFC2536] by providing a mapping of Digital Signature Algorithm (DSA) [FIPS1862] keys and signatures for the DNSKEY and RRSIG DNS resources records respectively. StJohns Expires October 5, 2006 [Page 1] Internet-Draft dsa-update April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. RFC2536 Updates . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DSA Mapping for DNSKEY . . . . . . . . . . . . . . . . . . . . 3 4. DSA/SHA1 Mapping for RRSIG . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 6 StJohns Expires October 5, 2006 [Page 2] Internet-Draft dsa-update April 2006 1. Introduction The DNSKEY and RRSIG records were defined in [RFC4034] as part of the most recent revisions to the DNS Security protocols. DNSKEY replaced the KEY record in functionality and RRSIG replaced the SIG record. This document provides mappings for the DSA for use with the new records. 2. RFC2536 Updates [FIPS1862] has replaced "FIPS 186". None of the changes to FIPS 186 affect processing described by [RFC2536] or, by derivation, this document. 3. DSA Mapping for DNSKEY A DSA public key may be placed in the Public Key field of the DNSKEY record. The format of such a DSA key is identical to the format defined in [RFC2536] section 2. All constraints on DSA keys as defined in that document apply to DSA keys in DNSKEY records. The algorithm ID (e.g. the DNSKEY Algorithm field) for a DSA public key in a DNSKEY record is 3. 4. DSA/SHA1 Mapping for RRSIG A DSA/SHA1 signature may be placed in the Signature field of an RRSIG record. The format of such a signature is identical to the format of a DSA/SHA1 signature as defined in [RFC2536] section 3. The determination of the data to be signed and the formation of the signature is accomplished using the process defined in that section and according to [FIPS1862]. The algorithm ID (i.e. the RRSIG Algorithm field) for a DSA/SHA1 signature in an RRSIG record is 3. Use of DSA with other hashing algorithms for RRSIG is currently not defined. The algorithm ID 3 may only be used with DSA/SHA1 signatures. 5. Security Considerations The security considerations described in [RFC2536] continue to apply. Note that [RFC4086] has updated the randomness requirements. This document has no other or additional security concerns. StJohns Expires October 5, 2006 [Page 3] Internet-Draft dsa-update April 2006 6. IANA Considerations The IANA considerations described in [RFC2536] continue to apply. This document creates no additional IANA actions. 7. References 7.1. Normative References [FIPS1862] National Institute of Standards and Technology, "U.S. Federal Information Processing Standard: Digital Signature Standard", January 2000. [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. 7.2. Informative References [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 13:23:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQSmC-0004EP-7I for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 13:23:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQSmA-00044c-UT for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 13:23:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQShC-000OQ8-1F for namedroppers-data@psg.com; Mon, 03 Apr 2006 17:18:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQShB-000OPu-Bz for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 17:18:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A2E111142C for ; Mon, 3 Apr 2006 17:18:28 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: another question about interpretation of the scriptures: cname chains X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Apr 2006 17:18:28 +0000 Message-ID: <49390.1144084708@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 i know that an authority server can emit an incomplete cname chain if it leads outside the servers's authority zone(s). but what should a recursive server return if a cname chain from the qname leads to an NXDOMAIN? my intuition says "return NXDOMAIN" since the nonterminal cname chain has no value and no meaning to an RD=1 initiator. but i note with dismay that BIND actually emits the nonterminal chain as if it were an answer to the question. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 13:49:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTAl-00064E-Np for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 13:49:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTAk-00050D-81 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 13:49:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQT8s-0000LM-OI for namedroppers-data@psg.com; Mon, 03 Apr 2006 17:47:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQT8p-0000L1-Qb for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 17:47:03 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 742151142D for ; Mon, 3 Apr 2006 17:47:03 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: another out-of-zone cname question-- anti-aliasing of zone servers? X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Apr 2006 17:47:03 +0000 Message-ID: <52230.1144086423@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 "dig en.wikipedia.org a" retrieves from the wikipedia.org authority server the following out-of-zone cname chain: ;; ANSWER SECTION: en.wikipedia.org. 3600 IN CNAME rr.wikimedia.org. rr.wikimedia.org. 600 IN CNAME rr.pmtpa.wikimedia.org. rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.202 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.245 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.246 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.206 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.203 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.236 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.210 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.214 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.235 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.247 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.213 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.205 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.204 rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.248 because the second and subsequent ownernames are outside the wikipedia.org zone, they are thrown away by at least one modern paranoid resolver, since this is the same mechanism that would be used to poison a cache with phish data (like a www.bankofamerica.com name). i don't blame wikipedia for trying this, since it's also what virtually all akamaized services do. check "www.yahoo.com" or "www.microsoft.com" for examples. what this causes is an extra query from the resolver to the zone authority of each out-of-zone cname target. ;; ANSWER SECTION: www.yahoo.com. 300 IN CNAME www.yahoo.akadns.net. www.yahoo.akadns.net. 60 IN A 66.94.230.41 www.yahoo.akadns.net. 60 IN A 66.94.230.39 www.yahoo.akadns.net. 60 IN A 66.94.230.49 www.yahoo.akadns.net. 60 IN A 66.94.230.42 www.yahoo.akadns.net. 60 IN A 66.94.230.36 www.yahoo.akadns.net. 60 IN A 66.94.230.47 www.yahoo.akadns.net. 60 IN A 66.94.230.46 www.yahoo.akadns.net. 60 IN A 66.94.230.44 ;; ANSWER SECTION: www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net. toggle.www.ms.akadns.net. 300 IN CNAME g.www.ms.akadns.net. g.www.ms.akadns.net. 300 IN CNAME lb1.www.ms.akadns.net. lb1.www.ms.akadns.net. 300 IN A 207.46.20.60 lb1.www.ms.akadns.net. 300 IN A 207.46.19.60 lb1.www.ms.akadns.net. 300 IN A 207.46.225.60 lb1.www.ms.akadns.net. 300 IN A 207.46.199.30 lb1.www.ms.akadns.net. 300 IN A 207.46.19.30 lb1.www.ms.akadns.net. 300 IN A 207.46.20.30 lb1.www.ms.akadns.net. 300 IN A 207.46.198.30 lb1.www.ms.akadns.net. 300 IN A 207.46.198.60 so here's my question. should a modern paranoid resolver anti-alias these out-of-zone cname targets, with logic along the lines of "even though the zone of the target isn't within the zone of my question, i know that the zone of the target is served by the same nameservers as the zone of my question, so it is allowed to give me this out-of-zone data"? if we should do this, it will save on backbone and overall DNS traffic, but it will mean we have to think very hard about the ways in which other NS RRs get into our cache. (since they will override some current paranoia logic.) if we should not do this, then wikipedia should put all of its infrastructure under the main (wikipedia.org) name and not switch to wikimedia.org (note the "m" rather than the "p") and akamai's customers should allocate .akamai subdomains of their .com names, still served by akamai but semantically "part of" the zone that the most common queries in the universe are all asking for. either way it's probably time for a BCP document on this kind of processing. i'm especially interested in DJB's perspective on this issue. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 14:37:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTvo-00071I-6r for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 14:37:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTvm-0006tV-T3 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 14:37:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQTt4-0003kG-Tm for namedroppers-data@psg.com; Mon, 03 Apr 2006 18:34:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_SOFTFAIL autolearn=no version=3.1.1 Received: from [66.6.203.2] (helo=hermes.walkereng.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQTt3-0003k0-O2 for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 18:34:49 +0000 Received: (qmail 10090 invoked by uid 1000); 3 Apr 2006 18:34:47 -0000 Date: Mon, 3 Apr 2006 13:34:47 -0500 From: Emilio Perea To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060403183447.GA29373@hermes.walkereng.com> Mail-Followup-To: namedroppers@ops.ietf.org References: <52230.1144086423@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52230.1144086423@sa.vix.com> User-Agent: Mutt/1.5.11 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Mon, Apr 03, 2006 at 05:47:03PM +0000, Paul Vixie wrote: > > i don't blame wikipedia for trying this, since it's also what virtually all > akamaized services do. check "www.yahoo.com" or "www.microsoft.com" for > examples. what this causes is an extra query from the resolver to the zone > authority of each out-of-zone cname target. With all due respect (which in this case is a great deal) why should wikipedia, yahoo and microsoft not be blamed for this abomination? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 14:50:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQU7t-0001NR-Dt for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 14:50:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQU7q-0007FG-MI for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 14:50:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQU4a-0004h3-8W for namedroppers-data@psg.com; Mon, 03 Apr 2006 18:46:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,INFO_TLD autolearn=no version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQU4X-0004fV-0I for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 18:46:41 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 9B2704040; Mon, 3 Apr 2006 20:46:33 +0200 (CEST) Date: Mon, 3 Apr 2006 20:46:33 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060403184633.GA2107@outpost.ds9a.nl> References: <52230.1144086423@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52230.1144086423@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 On Mon, Apr 03, 2006 at 05:47:03PM +0000, Paul Vixie wrote: > "dig en.wikipedia.org a" retrieves from the wikipedia.org authority server > the following out-of-zone cname chain: They run PowerDNS with the GEO IP backend, btw (which was written by a Wikipedian, Mark Bergsma). > ;; ANSWER SECTION: > en.wikipedia.org. 3600 IN CNAME rr.wikimedia.org. > rr.wikimedia.org. 600 IN CNAME rr.pmtpa.wikimedia.org. > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.202 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.245 Here is what it answers here: ;; ANSWER SECTION: en.wikipedia.org. 3600 IN CNAME rr.wikimedia.org. rr.wikimedia.org. 600 IN CNAME rr.knams.wikimedia.org. rr.knams.wikimedia.org. 300 IN A 145.97.39.155 The 'ams' stands for Amsterdam. > because the second and subsequent ownernames are outside the wikipedia.org > zone, they are thrown away by at least one modern paranoid resolver, since > this is the same mechanism that would be used to poison a cache with phish > data (like a www.bankofamerica.com name). The data is also discarded by the powerdns recursor (which I'd like to call modern & paranoid). Output of --trace query for en.wikipedia.org from a cold cache, taking 5 packets in total. I've > quoted the lines that reject the wikimedia.org data: question for 'en.wikipedia.org|A' from 127.0.0.1 en.wikipedia.org: Looking for CNAME cache hit of 'en.wikipedia.org|CNAME' en.wikipedia.org: No CNAME cache hit of 'en.wikipedia.org|CNAME' found en.wikipedia.org: Looking for direct cache hit of 'en.wikipedia.org|A', negative cached: 0 en.wikipedia.org: No cache hit for 'en.wikipedia.org|A', trying to find an appropriate NS record en.wikipedia.org: Checking if we have NS in cache for 'en.wikipedia.org' en.wikipedia.org: Checking if we have NS in cache for 'wikipedia.org' en.wikipedia.org: Checking if we have NS in cache for 'org' en.wikipedia.org: Checking if we have NS in cache for '' en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'a.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'b.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'c.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'd.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'e.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'f.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'g.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'h.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'i.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'j.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'k.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'l.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'm.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'a.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'b.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'c.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'd.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'e.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'f.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'g.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'h.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'i.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'j.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'k.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'l.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: NS (with ip, or non-glue) in cache for '' -> 'm.root-servers.net' en.wikipedia.org: within bailiwick: 1, in cache, ttl=3599999 en.wikipedia.org: We have NS in cache for '' en.wikipedia.org: Cache consultations done, have 13 NS to contact en.wikipedia.org: Nameservers: j.root-servers.net(0ms), g.root-servers.net(0ms), e.root-servers.net(0ms), h.root-servers.net(0ms), en.wikipedia.org: m.root-servers.net(0ms), i.root-servers.net(0ms), f.root-servers.net(0ms), b.root-servers.net(0ms), en.wikipedia.org: l.root-servers.net(0ms), d.root-servers.net(0ms), c.root-servers.net(0ms), a.root-servers.net(0ms), en.wikipedia.org: k.root-servers.net(6ms) en.wikipedia.org: Trying to resolve NS j.root-servers.net (1/13) j.root-servers.net: Looking for CNAME cache hit of 'j.root-servers.net|CNAME' j.root-servers.net: No CNAME cache hit of 'j.root-servers.net|CNAME' found j.root-servers.net: Looking for direct cache hit of 'j.root-servers.net|A', negative cached: 0 j.root-servers.net: Found cache hit for A: 192.58.128.30[ttl=3599999] en.wikipedia.org: Resolved '' NS j.root-servers.net to 192.58.128.30, asking 'en.wikipedia.org|A' en.wikipedia.org: Got 12 answers from j.root-servers.net (192.58.128.30), rcode=0, in 192ms en.wikipedia.org: accept answer 'org|NS|TLD1.ULTRADNS.NET.' from '' nameservers? YES! en.wikipedia.org: accept answer 'org|NS|TLD2.ULTRADNS.NET.' from '' nameservers? YES! en.wikipedia.org: accept answer 'org|NS|TLD3.ULTRADNS.org.' from '' nameservers? YES! en.wikipedia.org: accept answer 'org|NS|TLD4.ULTRADNS.org.' from '' nameservers? YES! en.wikipedia.org: accept answer 'org|NS|TLD5.ULTRADNS.INFO.' from '' nameservers? YES! en.wikipedia.org: accept answer 'org|NS|TLD6.ULTRADNS.CO.UK.' from '' nameservers? YES! en.wikipedia.org: accept answer 'TLD1.ULTRADNS.NET|A|204.74.112.1' from '' nameservers? YES! en.wikipedia.org: accept answer 'TLD2.ULTRADNS.NET|A|204.74.113.1' from '' nameservers? YES! en.wikipedia.org: accept answer 'TLD3.ULTRADNS.org|A|199.7.66.1' from '' nameservers? YES! en.wikipedia.org: accept answer 'TLD4.ULTRADNS.org|A|199.7.67.1' from '' nameservers? YES! en.wikipedia.org: accept answer 'TLD5.ULTRADNS.INFO|A|192.100.59.11' from '' nameservers? YES! en.wikipedia.org: accept answer 'TLD6.ULTRADNS.CO.UK|A|198.133.199.11' from '' nameservers? YES! en.wikipedia.org: determining status after receiving this packet en.wikipedia.org: got NS record 'org' -> 'TLD1.ULTRADNS.NET.' en.wikipedia.org: got NS record 'org' -> 'TLD2.ULTRADNS.NET.' en.wikipedia.org: got NS record 'org' -> 'TLD3.ULTRADNS.org.' en.wikipedia.org: got NS record 'org' -> 'TLD4.ULTRADNS.org.' en.wikipedia.org: got NS record 'org' -> 'TLD5.ULTRADNS.INFO.' en.wikipedia.org: got NS record 'org' -> 'TLD6.ULTRADNS.CO.UK.' en.wikipedia.org: status=did not resolve, got 6 NS, looping to them en.wikipedia.org: Nameservers: tld4.ultradns.org(0ms), tld3.ultradns.org(0ms), tld6.ultradns.co.uk(0ms), tld2.ultradns.net(0ms), en.wikipedia.org: tld5.ultradns.info(0ms), tld1.ultradns.net(0ms) en.wikipedia.org: Trying to resolve NS tld4.ultradns.org (1/6) tld4.ultradns.org: Looking for CNAME cache hit of 'tld4.ultradns.org|CNAME' tld4.ultradns.org: No CNAME cache hit of 'tld4.ultradns.org|CNAME' found tld4.ultradns.org: Looking for direct cache hit of 'tld4.ultradns.org|A', negative cached: 0 tld4.ultradns.org: Found cache hit for A: 199.7.67.1[ttl=172800] en.wikipedia.org: Resolved 'org' NS tld4.ultradns.org to 199.7.67.1, asking 'en.wikipedia.org|A' en.wikipedia.org: Got 6 answers from tld4.ultradns.org (199.7.67.1), rcode=0, in 23ms en.wikipedia.org: accept answer 'wikipedia.org|NS|ns2.wikimedia.org.' from 'org' nameservers? YES! en.wikipedia.org: accept answer 'wikipedia.org|NS|ns1.wikimedia.org.' from 'org' nameservers? YES! en.wikipedia.org: accept answer 'wikipedia.org|NS|ns0.wikimedia.org.' from 'org' nameservers? YES! en.wikipedia.org: accept answer 'ns2.wikimedia.org|A|145.97.39.158' from 'org' nameservers? YES! en.wikipedia.org: accept answer 'ns1.wikimedia.org|A|207.142.131.208' from 'org' nameservers? YES! en.wikipedia.org: accept answer 'ns0.wikimedia.org|A|207.142.131.207' from 'org' nameservers? YES! en.wikipedia.org: determining status after receiving this packet en.wikipedia.org: got NS record 'wikipedia.org' -> 'ns2.wikimedia.org.' en.wikipedia.org: got NS record 'wikipedia.org' -> 'ns1.wikimedia.org.' en.wikipedia.org: got NS record 'wikipedia.org' -> 'ns0.wikimedia.org.' en.wikipedia.org: status=did not resolve, got 3 NS, looping to them en.wikipedia.org: Nameservers: ns2.wikimedia.org(0ms), ns0.wikimedia.org(0ms), ns1.wikimedia.org(0ms) en.wikipedia.org: Trying to resolve NS ns2.wikimedia.org (1/3) ns2.wikimedia.org: Looking for CNAME cache hit of 'ns2.wikimedia.org|CNAME' ns2.wikimedia.org: No CNAME cache hit of 'ns2.wikimedia.org|CNAME' found ns2.wikimedia.org: Looking for direct cache hit of 'ns2.wikimedia.org|A', negative cached: 0 ns2.wikimedia.org: Found cache hit for A: 145.97.39.158[ttl=86400] en.wikipedia.org: Resolved 'wikipedia.org' NS ns2.wikimedia.org to 145.97.39.158, asking 'en.wikipedia.org|A' en.wikipedia.org: Got 3 answers from ns2.wikimedia.org (145.97.39.158), rcode=0, in 10ms en.wikipedia.org: accept answer 'en.wikipedia.org|CNAME|rr.wikimedia.org.' from 'wikipedia.org' nameservers? YES! > en.wikipedia.org: accept answer 'rr.wikimedia.org|CNAME|rr.knams.wikimedia.org.' from 'wikipedia.org' nameservers? NO! > en.wikipedia.org: accept answer 'rr.knams.wikimedia.org|A|145.97.39.155' from 'wikipedia.org' nameservers? NO! en.wikipedia.org: determining status after receiving this packet en.wikipedia.org: status=got a CNAME referral, starting over with rr.wikimedia.org rr.wikimedia.org: Looking for CNAME cache hit of 'rr.wikimedia.org|CNAME' rr.wikimedia.org: No CNAME cache hit of 'rr.wikimedia.org|CNAME' found rr.wikimedia.org: Looking for direct cache hit of 'rr.wikimedia.org|A', negative cached: 0 rr.wikimedia.org: No cache hit for 'rr.wikimedia.org|A', trying to find an appropriate NS record rr.wikimedia.org: Checking if we have NS in cache for 'rr.wikimedia.org' rr.wikimedia.org: Checking if we have NS in cache for 'wikimedia.org' rr.wikimedia.org: Checking if we have NS in cache for 'org' rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld1.ultradns.net' rr.wikimedia.org: within bailiwick: 0, not in cache rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld2.ultradns.net' rr.wikimedia.org: within bailiwick: 0, not in cache rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld3.ultradns.org' rr.wikimedia.org: within bailiwick: 1, in cache, ttl=172800 rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld4.ultradns.org' rr.wikimedia.org: within bailiwick: 1, in cache, ttl=172800 rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld5.ultradns.info' rr.wikimedia.org: within bailiwick: 0, not in cache rr.wikimedia.org: NS (with ip, or non-glue) in cache for 'org' -> 'tld6.ultradns.co.uk' rr.wikimedia.org: within bailiwick: 0, not in cache rr.wikimedia.org: We have NS in cache for 'org' rr.wikimedia.org: Cache consultations done, have 6 NS to contact rr.wikimedia.org: Nameservers: tld3.ultradns.org(0ms), tld5.ultradns.info(0ms), tld6.ultradns.co.uk(0ms), tld2.ultradns.net(0ms), rr.wikimedia.org: tld1.ultradns.net(0ms), tld4.ultradns.org(11ms) rr.wikimedia.org: Trying to resolve NS tld3.ultradns.org (1/6) tld3.ultradns.org: Looking for CNAME cache hit of 'tld3.ultradns.org|CNAME' tld3.ultradns.org: No CNAME cache hit of 'tld3.ultradns.org|CNAME' found tld3.ultradns.org: Looking for direct cache hit of 'tld3.ultradns.org|A', negative cached: 0 tld3.ultradns.org: Found cache hit for A: 199.7.66.1[ttl=172800] rr.wikimedia.org: Resolved 'org' NS tld3.ultradns.org to 199.7.66.1, asking 'rr.wikimedia.org|A' rr.wikimedia.org: Got 6 answers from tld3.ultradns.org (199.7.66.1), rcode=0, in 92ms rr.wikimedia.org: accept answer 'wikimedia.org|NS|ns2.wikimedia.org.' from 'org' nameservers? YES! rr.wikimedia.org: accept answer 'wikimedia.org|NS|ns1.wikimedia.org.' from 'org' nameservers? YES! rr.wikimedia.org: accept answer 'wikimedia.org|NS|ns0.wikimedia.org.' from 'org' nameservers? YES! rr.wikimedia.org: accept answer 'ns2.wikimedia.org|A|145.97.39.158' from 'org' nameservers? YES! rr.wikimedia.org: accept answer 'ns1.wikimedia.org|A|207.142.131.208' from 'org' nameservers? YES! rr.wikimedia.org: accept answer 'ns0.wikimedia.org|A|207.142.131.207' from 'org' nameservers? YES! rr.wikimedia.org: determining status after receiving this packet rr.wikimedia.org: got NS record 'wikimedia.org' -> 'ns2.wikimedia.org.' rr.wikimedia.org: got NS record 'wikimedia.org' -> 'ns1.wikimedia.org.' rr.wikimedia.org: got NS record 'wikimedia.org' -> 'ns0.wikimedia.org.' rr.wikimedia.org: status=did not resolve, got 3 NS, looping to them rr.wikimedia.org: Nameservers: ns0.wikimedia.org(0ms), ns1.wikimedia.org(0ms), ns2.wikimedia.org(5ms) rr.wikimedia.org: Trying to resolve NS ns0.wikimedia.org (1/3) ns0.wikimedia.org: Looking for CNAME cache hit of 'ns0.wikimedia.org|CNAME' ns0.wikimedia.org: No CNAME cache hit of 'ns0.wikimedia.org|CNAME' found ns0.wikimedia.org: Looking for direct cache hit of 'ns0.wikimedia.org|A', negative cached: 0 ns0.wikimedia.org: Found cache hit for A: 207.142.131.207[ttl=86400] rr.wikimedia.org: Resolved 'wikimedia.org' NS ns0.wikimedia.org to 207.142.131.207, asking 'rr.wikimedia.org|A' rr.wikimedia.org: Got 2 answers from ns0.wikimedia.org (207.142.131.207), rcode=0, in 126ms rr.wikimedia.org: accept answer 'rr.wikimedia.org|CNAME|rr.knams.wikimedia.org.' from 'wikimedia.org' nameservers? YES! rr.wikimedia.org: accept answer 'rr.knams.wikimedia.org|A|145.97.39.155' from 'wikimedia.org' nameservers? YES! rr.wikimedia.org: determining status after receiving this packet rr.wikimedia.org: status=got a CNAME referral, starting over with rr.knams.wikimedia.org rr.knams.wikimedia.org: Looking for CNAME cache hit of 'rr.knams.wikimedia.org|CNAME' rr.knams.wikimedia.org: No CNAME cache hit of 'rr.knams.wikimedia.org|CNAME' found rr.knams.wikimedia.org: Looking for direct cache hit of 'rr.knams.wikimedia.org|A', negative cached: 0 rr.knams.wikimedia.org: Found cache hit for A: 145.97.39.155[ttl=300] en.wikipedia.org: Starting additional processing en.wikipedia.org: Done with additional processing answer to question 'en.wikipedia.org|A': 3 answers, 0 additional, took 5 packets, 0 throttled, 0 timeouts, 0 tcp connections, rcode=0 > so here's my question. should a modern paranoid resolver anti-alias these > out-of-zone cname targets, with logic along the lines of "even though the > zone of the target isn't within the zone of my question, i know that the > zone of the target is served by the same nameservers as the zone of my > question, so it is allowed to give me this out-of-zone data"? I've pondered this and decided to waste a few packets on not complicating my nameserver. Yes, the recursor *might* now that the IP address it sent the question to has previously also been known to be authoritative for the wikimedia.org domain, but try figuring that out in a timely manner. It requires lots and lots of memory. Also note that the people who 'suffer' from this negligence are in part the same people that cause it. By the way, I hope you aren't telling me Bind *does* accept the answers the 'modern & paranoid' recursor rejects? How can that be secure? > if we should not do this, then wikipedia should put all of its infrastructure > under the main (wikipedia.org) name and not switch to wikimedia.org (note the > "m" rather than the "p") and akamai's customers should allocate .akamai > subdomains of their .com names, still served by akamai but semantically "part > of" the zone that the most common queries in the universe are all asking for. Sure. However, most DNS traffic I emit is caused by lame or broken servers. > i'm especially interested in DJB's perspective on this issue. I think I modelled the pdns_recursor pretty closely on his (brilliant) paranoia. DJBDNS is pretty hard to beat as a recursor, and I should know, I've been working on it for a month now. Bert. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 15:02:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUJs-0000Zw-DC for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:02:32 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUJr-0007i3-Vs for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:02:32 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUGh-0005is-KJ for namedroppers-data@psg.com; Mon, 03 Apr 2006 18:59:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUGe-0005iV-KZ for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 18:59:12 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 03 Apr 2006 11:58:57 -0700 X-IronPort-AV: i="4.03,159,1141632000"; d="scan'208"; a="1791283101:sNHT2447650036" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k33Iwu1j005665; Mon, 3 Apr 2006 11:58:56 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 14:58:55 -0400 Received: from [161.44.65.139] ([161.44.65.139]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 14:58:55 -0400 Message-ID: <4431706F.7060700@cisco.com> Date: Mon, 03 Apr 2006 14:58:55 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: another question about interpretation of the scriptures: cname chains References: <49390.1144084708@sa.vix.com> In-Reply-To: <49390.1144084708@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2006 18:58:55.0427 (UTC) FILETIME=[A800E930:01C65750] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Paul Vixie wrote: > i know that an authority server can emit an incomplete cname chain if it > leads outside the servers's authority zone(s). but what should a recursive > server return if a cname chain from the qname leads to an NXDOMAIN? my > intuition says "return NXDOMAIN" since the nonterminal cname chain has no > value and no meaning to an RD=1 initiator. but i note with dismay that BIND > actually emits the nonterminal chain as if it were an answer to the question. > Not sure if you are saying BIND returns NOERROR with a CNAME chain, or NXDOMAIN with a CNAME chain. I assume the latter would not be a surprise to you (I think its correct), so I assume you mean the former. Returning NOERROR with a non-terminal CNAME chain to an RD=1 query might be a no-data negative response (depending on the content of the auth section), which not exactly true, though without DNSSEC I don't know if its all that bad. Its certainly better that a referral (which is useless to a stub-resolver. RFC 2308 clarified that an NXDOMAIN response may include a CNAME chain leading to the non-existent name terminating that chain. 2308 doesn't specifically talk about caching such a response (with CNAMEs), but I think its reasonable to conclude that since such a response indicates that the terminal name does not exist, this non-existence may be cached (assuming the answer includes an SOA relevant to the non-existent name). So I think it seems appropriate for a non-authoritative server to provide this same response from cache, as it would any other negative response. From there, I don't think it's a leap to say that there should be no difference in behavior between a server answering from cache and a server that has to recurse before answering to discover the same information. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 15:03:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUKd-0001BE-Le for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:03:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUKc-0007iN-Cn for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:03:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUIa-0005v6-5y for namedroppers-data@psg.com; Mon, 03 Apr 2006 19:01:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUIZ-0005ur-K9 for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 19:01:11 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 40F541142E for ; Mon, 3 Apr 2006 19:01:11 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? In-Reply-To: Your message of "Mon, 03 Apr 2006 20:46:33 +0200." <20060403184633.GA2107@outpost.ds9a.nl> References: <52230.1144086423@sa.vix.com> <20060403184633.GA2107@outpost.ds9a.nl> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Apr 2006 19:01:11 +0000 Message-ID: <59245.1144090871@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 bert hubert wrote: > By the way, I hope you aren't telling me Bind *does* accept the answers the > 'modern & paranoid' recursor rejects? How can that be secure? not at all. bind is perfectly modern and paranoid in this respect. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 15:03:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUKf-0001BX-Er for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:03:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUKf-0007iR-73 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:03:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUJJ-000618-9N for namedroppers-data@psg.com; Mon, 03 Apr 2006 19:01:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUJI-00060v-On for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 19:01:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 822941142B for ; Mon, 3 Apr 2006 19:01:56 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? In-Reply-To: Your message of "Mon, 03 Apr 2006 13:34:47 EST." <20060403183447.GA29373@hermes.walkereng.com> References: <52230.1144086423@sa.vix.com> <20060403183447.GA29373@hermes.walkereng.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Apr 2006 19:01:56 +0000 Message-ID: <59256.1144090916@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Emilio Perea wrote: > With all due respect (which in this case is a great deal) why should > wikipedia, yahoo and microsoft not be blamed for this abomination? perhaps because i recommended stub zones as a solution to what yahoo and microsoft were emitting up 'til last week, i feel that they deserve the benefit of the doubt on the matter. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 15:06:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUNe-0002xp-To for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:06:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUNd-0007q5-7g for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:06:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUM1-0006LY-Pl for namedroppers-data@psg.com; Mon, 03 Apr 2006 19:04:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.96.22.18] (helo=citadel.cequrux.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQULy-0006Jv-UT for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 19:04:44 +0000 Received: (from nobody@localhost) by citadel.cequrux.com (8.12.11/8.12.11) id k33J4aFL013855 for ; Mon, 3 Apr 2006 21:04:36 +0200 (SAST) (envelope-from apb@cequrux.com) Received: by citadel.cequrux.com via recvmail id 13837; Mon, 03 Apr 2006 21:04:32 +0200 (SAST) X-Authentication-Warning: apb-laptoy.apb.alt.za: apb set sender to apb@cequrux.com using -f Date: Mon, 3 Apr 2006 21:03:38 +0200 From: Alan Barrett To: namedroppers@ops.ietf.org Subject: Re: another question about interpretation of the scriptures: cname chains Message-ID: <20060403190338.GC3710@apb-laptoy.apb.alt.za> References: <49390.1144084708@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49390.1144084708@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Mon, 03 Apr 2006, Paul Vixie wrote: > i know that an authority server can emit an incomplete cname chain if > it leads outside the servers's authority zone(s). but what should a > recursive server return if a cname chain from the qname leads to an > NXDOMAIN? my intuition says "return NXDOMAIN" since the nonterminal > cname chain has no value and no meaning to an RD=1 initiator. but i > note with dismay that BIND actually emits the nonterminal chain as if > it were an answer to the question. My intuition says: NXDOMAIN means that the node does not exist in the graph, and that's clearly not the case when a node exists and has a CNAME record. The dangling CNAME *is* an answer to the question. My intuition also says: RD=1 queries should be processed exacly like RD=0 queries until the point where you know whether or not you have an answer. At that point, if you don't have an answer, then RD=0 queries return an error or referral, whle RD=1 queries recurse; but if you have an answer (even if it's a dangling CNAME), then you return that answer, regardless of RD=0 or RD=1. --apb (Alan Barrett) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 15:11:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUSD-0005im-QD for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:11:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUSC-00080h-H7 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:11:09 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUQ4-0006qM-P0 for namedroppers-data@psg.com; Mon, 03 Apr 2006 19:08:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUQ3-0006q2-Uv for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 19:08:56 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k33J8mHL026119 for ; Mon, 3 Apr 2006 15:08:48 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060403150010.033084e8@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 03 Apr 2006 15:08:39 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? In-Reply-To: <20060403183447.GA29373@hermes.walkereng.com> References: <52230.1144086423@sa.vix.com> <20060403183447.GA29373@hermes.walkereng.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f At 14:34 03/04/2006, Emilio Perea wrote: >On Mon, Apr 03, 2006 at 05:47:03PM +0000, Paul Vixie wrote: > > > > i don't blame wikipedia for trying this, since it's also what virtually all > > akamaized services do. check "www.yahoo.com" or "www.microsoft.com" for > > examples. what this causes is an extra query from the resolver to the zone > > authority of each out-of-zone cname target. > >With all due respect (which in this case is a great deal) why should >wikipedia, yahoo and microsoft not be blamed for this abomination? Because the server in question is trying to be helpful and save round trips. IMHO fundamental problem here is #1. that the RFC1034/5 does not exploit say that a server MUST NOT execute the CNAME algorithm when the CNAME chain crosses zone boundary. #2 The CNAME processing is split between the authorative server and the recursive resolver. If all the work was supposed to be done by the recursive resolver we would not have the possibility of a cache poisoning in this case. In this case my reading of the scriptures is different from what I think is a safe behavior and recursors should fetch all data from authorative sources, including the second and subsequent CNAME's if there is a possibility the CNAME is from a different zone than the preceding CNAME. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 15:17:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQUYa-000117-27 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:17:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQUYY-0008Ht-D6 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 15:17:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUVx-0007Ql-H3 for namedroppers-data@psg.com; Mon, 03 Apr 2006 19:15:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQUVv-0007QM-LL for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 19:15:00 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id B715E3FEC; Mon, 3 Apr 2006 21:14:52 +0200 (CEST) Date: Mon, 3 Apr 2006 21:14:52 +0200 From: bert hubert To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: another question about interpretation of the scriptures: cname chains Message-ID: <20060403191452.GA5814@outpost.ds9a.nl> References: <49390.1144084708@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49390.1144084708@sa.vix.com> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f On Mon, Apr 03, 2006 at 05:18:28PM +0000, Paul Vixie wrote: > server return if a cname chain from the qname leads to an NXDOMAIN? my > intuition says "return NXDOMAIN" since the nonterminal cname chain has no > value and no meaning to an RD=1 initiator. but i note with dismay that BIND Which is what the PowerDNS recursor does, although I thought I'd implemented it to return SERVFAIL. So far for my memory. This happens because PowerDNS basically restarts the query as if the target of the CNAME had been the query, which causes a NXDOMAIN. Output: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32827 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;dangle.ds9a.nl. IN A ;; ANSWER SECTION: dangle.ds9a.nl. 3600 IN CNAME bestanie.nowhere. ;; AUTHORITY SECTION: . 86400 IN SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2006040200 1800 900 604800 86400 Trace: question for 'dangle.ds9a.nl|A' from 127.0.0.1 dangle.ds9a.nl: Looking for CNAME cache hit of 'dangle.ds9a.nl|CNAME' dangle.ds9a.nl: No CNAME cache hit of 'dangle.ds9a.nl|CNAME' found dangle.ds9a.nl: Looking for direct cache hit of 'dangle.ds9a.nl|A', negative cached: 0 dangle.ds9a.nl: No cache hit for 'dangle.ds9a.nl|A', trying to find an appropriate NS record dangle.ds9a.nl: Checking if we have NS in cache for 'dangle.ds9a.nl' dangle.ds9a.nl: Checking if we have NS in cache for 'ds9a.nl' dangle.ds9a.nl: NS (with ip, or non-glue) in cache for 'ds9a.nl' -> 'ns1.pine.nl' dangle.ds9a.nl: within bailiwick: 0, not in cache dangle.ds9a.nl: NS (with ip, or non-glue) in cache for 'ds9a.nl' -> 'ns2.pine.nl' dangle.ds9a.nl: within bailiwick: 0, not in cache dangle.ds9a.nl: We have NS in cache for 'ds9a.nl' dangle.ds9a.nl: Cache consultations done, have 2 NS to contact dangle.ds9a.nl: Nameservers: ns2.pine.nl(0ms), ns1.pine.nl(6ms) dangle.ds9a.nl: Trying to resolve NS ns2.pine.nl (1/2) ns2.pine.nl: Looking for CNAME cache hit of 'ns2.pine.nl|CNAME' ns2.pine.nl: No CNAME cache hit of 'ns2.pine.nl|CNAME' found ns2.pine.nl: Looking for direct cache hit of 'ns2.pine.nl|A', negative cached: 0 ns2.pine.nl: Found cache hit for A: 217.114.101.235[ttl=86399] dangle.ds9a.nl: Resolved 'ds9a.nl' NS ns2.pine.nl to 217.114.101.235, asking 'dangle.ds9a.nl|A' dangle.ds9a.nl: Got 27 answers from ns2.pine.nl (217.114.101.235), rcode=0, in 14ms dangle.ds9a.nl: accept answer 'dangle.ds9a.nl|CNAME|bestanie.nowhere.' from 'ds9a.nl' nameservers? YES! dangle.ds9a.nl: accept answer '|NS|a.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|h.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|c.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|g.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|f.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|b.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|j.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|k.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|l.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|m.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|i.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|e.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer '|NS|d.root-servers.net.' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'a.root-servers.net|A|198.41.0.4' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'h.root-servers.net|A|128.63.2.53' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'c.root-servers.net|A|192.33.4.12' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'g.root-servers.net|A|192.112.36.4' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'f.root-servers.net|A|192.5.5.241' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'b.root-servers.net|A|192.228.79.201' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'j.root-servers.net|A|192.58.128.30' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'k.root-servers.net|A|193.0.14.129' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'l.root-servers.net|A|198.32.64.12' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'm.root-servers.net|A|202.12.27.33' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'i.root-servers.net|A|192.36.148.17' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'e.root-servers.net|A|192.203.230.10' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: accept answer 'd.root-servers.net|A|128.8.10.90' from 'ds9a.nl' nameservers? NO! dangle.ds9a.nl: determining status after receiving this packet dangle.ds9a.nl: got upwards/level NS record '' -> 'a.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'h.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'c.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'g.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'f.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'b.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'j.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'k.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'l.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'm.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'i.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'e.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: got upwards/level NS record '' -> 'd.root-servers.net.', had 'ds9a.nl' dangle.ds9a.nl: status=got a CNAME referral, starting over with bestanie.nowhere bestanie.nowhere: Looking for CNAME cache hit of 'bestanie.nowhere|CNAME' bestanie.nowhere: No CNAME cache hit of 'bestanie.nowhere|CNAME' found bestanie.nowhere: Looking for direct cache hit of 'bestanie.nowhere|A', negative cached: 0 bestanie.nowhere: No cache hit for 'bestanie.nowhere|A', trying to find an appropriate NS record bestanie.nowhere: Checking if we have NS in cache for 'bestanie.nowhere' bestanie.nowhere: Checking if we have NS in cache for 'nowhere' bestanie.nowhere: Checking if we have NS in cache for '' bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'a.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'b.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'c.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'd.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'e.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'f.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'g.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'h.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'i.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'j.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'k.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'l.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: NS (with ip, or non-glue) in cache for '' -> 'm.root-servers.net' bestanie.nowhere: within bailiwick: 1, in cache, ttl=3599994 bestanie.nowhere: We have NS in cache for '' bestanie.nowhere: Cache consultations done, have 13 NS to contact bestanie.nowhere: Nameservers: l.root-servers.net(0ms), k.root-servers.net(0ms), g.root-servers.net(0ms), d.root-servers.net(0ms), bestanie.nowhere: b.root-servers.net(0ms), e.root-servers.net(0ms), m.root-servers.net(0ms), a.root-servers.net(0ms), bestanie.nowhere: f.root-servers.net(0ms), h.root-servers.net(0ms), c.root-servers.net(0ms), i.root-servers.net(8ms), bestanie.nowhere: j.root-servers.net(93ms) bestanie.nowhere: Trying to resolve NS l.root-servers.net (1/13) l.root-servers.net: Looking for CNAME cache hit of 'l.root-servers.net|CNAME' l.root-servers.net: No CNAME cache hit of 'l.root-servers.net|CNAME' found l.root-servers.net: Looking for direct cache hit of 'l.root-servers.net|A', negative cached: 0 l.root-servers.net: Found cache hit for A: 198.32.64.12[ttl=3599994] bestanie.nowhere: Resolved '' NS l.root-servers.net to 198.32.64.12, asking 'bestanie.nowhere|A' bestanie.nowhere: Got 1 answers from l.root-servers.net (198.32.64.12), rcode=3, in 181ms bestanie.nowhere: accept answer '|SOA|A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2006040200 1800 900 604800 86400' from '' nameservers? YES! bestanie.nowhere: determining status after receiving this packet bestanie.nowhere: got negative caching indication for RECORD 'bestanie.nowhere' bestanie.nowhere: status=NXDOMAIN, we are done (have negative SOA) bestanie.nowhere: failed dangle.ds9a.nl: failed answer to question 'dangle.ds9a.nl|A': 1 answers, 0 additional, took 2 packets, 0 throttled, 0 timeouts, 0 tcp connections, rcode=3 -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 17:10:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWJz-0004Xk-3n for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 17:10:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWJx-0005oH-Lz for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 17:10:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWHQ-000FuO-LH for namedroppers-data@psg.com; Mon, 03 Apr 2006 21:08:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWHP-000FuB-Oc for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 21:08:07 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2006 14:08:07 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,159,1141632000"; d="scan'208"; a="25085844:sNHT23655908" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k33L86Wc005921; Mon, 3 Apr 2006 17:08:06 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 17:08:06 -0400 Received: from [161.44.65.139] ([161.44.65.139]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 17:08:05 -0400 Message-ID: <44318EB5.6080906@cisco.com> Date: Mon, 03 Apr 2006 17:08:05 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? References: <52230.1144086423@sa.vix.com> In-Reply-To: <52230.1144086423@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2006 21:08:06.0023 (UTC) FILETIME=[B3B80170:01C65762] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Paul Vixie wrote: > > so here's my question. should a modern paranoid resolver anti-alias these > out-of-zone cname targets, with logic along the lines of "even though the > zone of the target isn't within the zone of my question, i know that the > zone of the target is served by the same nameservers as the zone of my > question, so it is allowed to give me this out-of-zone data"? I think it's interesting to consider a resolver asking itself if it would employ the same source for the information it is otherwise likely to ignore from the response. Assuming the resolver wants the complete answer, it will be asking that question (who can I query for this name) soon enough, so why not ask it before tossing away data instead of after. A properly paranoid server would certainly have to be conservative in this regard, but it could save a bit of time and network I/O. So it is an optimization which might not always pan out. If you try to further optimize this check by maintaining information about the relationships between these domains through a common server IP address, you definitely need to be careful not to create information that behaves differently than the NS/A RRs and TTLs that contribute to it. -josh > if we should do this, it will save on backbone and overall DNS traffic, but > it will mean we have to think very hard about the ways in which other NS RRs > get into our cache. (since they will override some current paranoia logic.) > > if we should not do this, then wikipedia should put all of its infrastructure > under the main (wikipedia.org) name and not switch to wikimedia.org (note the > "m" rather than the "p") and akamai's customers should allocate .akamai > subdomains of their .com names, still served by akamai but semantically "part > of" the zone that the most common queries in the universe are all asking for. > > either way it's probably time for a BCP document on this kind of processing. > > i'm especially interested in DJB's perspective on this issue. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 17:31:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWeI-00005g-B5 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 17:31:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWeH-0006e1-UJ for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 17:31:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWbz-000HTr-5I for namedroppers-data@psg.com; Mon, 03 Apr 2006 21:29:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWby-000HTf-7g for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 21:29:22 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 670C81142C for ; Mon, 3 Apr 2006 21:29:21 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? In-Reply-To: Your message of "Mon, 03 Apr 2006 17:08:05 -0400." <44318EB5.6080906@cisco.com> References: <52230.1144086423@sa.vix.com> <44318EB5.6080906@cisco.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 03 Apr 2006 21:29:21 +0000 Message-ID: <70733.1144099761@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 > > so here's my question. should a modern paranoid resolver anti-alias these > > out-of-zone cname targets, with logic along the lines of "even though the > > zone of the target isn't within the zone of my question, i know that the > > zone of the target is served by the same nameservers as the zone of my > > question, so it is allowed to give me this out-of-zone data"? > > I think it's interesting to consider a resolver asking itself if it would > employ the same source for the information it is otherwise likely to ignore > from the response. Assuming the resolver wants the complete answer, it > will be asking that question (who can I query for this name) soon enough, > so why not ask it before tossing away data instead of after. here's why i think it doesn't matter. in my wikipedia example, there's no reason for me to already have a cached copy of the wikimedia.org NS RRset, and so i'd have to go and fetch something. if i run off and fetch that NS RRset it would help me trust out-of-zone CNAME chains from wikipedia to wikimedia in the future, sure. on the other hand if i run off and fetch the name beyond the break (the first name in wikimedia after leaving wikipedia) then it would help me generate the full CNAME chain from cache. either way i have to go fetch something, and either way i can answer from cache thereafter. there's a possible improvement if many other queries will lead me across the same zone boundary, but that doesn't feel like a "big deal". so ultimately the BCP on this would just say, don't bother emitting CNAME chains that cross zone boundaries. if an authority zone has a nonterminal CNAME in it, then the authority servers for that zone should just emit it and let the recursive agents of the world follow it. sadly, this is the opposite of the advice i gave yahoo a week ago, and so i apologize for suggesting stub zones. akamai, if you're listening, you ought to ask each of your clients for a subzone of their main domain, so that you can work your DNS tricks in-ballywick and cut down on the wide area DNS load. and wikipedia, if you're listening, you should stop jumping from wikipedia.org to wikimedia.org, nobody's following those pointers before making an additional query. to suppress that additional query, stay within a single zone. jump from wikipedia.org into network.wikipedia.org or something. i am not volunteering to write this up as a BCP, but that's what it would say. > A properly paranoid server would certainly have to be conservative in this > regard, but it could save a bit of time and network I/O. So it is an > optimization which might not always pan out. If you try to further optimize > this check by maintaining information about the relationships between these > domains through a common server IP address, you definitely need to be > careful not to create information that behaves differently than the NS/A RRs > and TTLs that contribute to it. i'm just as happy that there's no practical reason to pursue this approach, since it feels intuitively like a deep swamp waiting to swallow us all. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 19:40:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQYeO-0006gm-CZ for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 19:40:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQYeM-0004F7-R7 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 19:40:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQYbI-0000Sl-9r for namedroppers-data@psg.com; Mon, 03 Apr 2006 23:36:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQYbF-0000SO-8s for namedroppers@ops.ietf.org; Mon, 03 Apr 2006 23:36:45 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 5C0ECE6107 for ; Mon, 3 Apr 2006 23:36:43 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.4) with ESMTP id k33Nafo8007070; Tue, 4 Apr 2006 09:36:41 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200604032336.k33Nafo8007070@drugs.dv.isc.org> To: Paul Vixie Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? In-reply-to: Your message of "Mon, 03 Apr 2006 17:47:03 GMT." <52230.1144086423@sa.vix.com> Date: Tue, 04 Apr 2006 09:36:41 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 The fix is to fully deploy DNSSEC then each RRset in the answer can be independently be validated. You do then get the savings. > "dig en.wikipedia.org a" retrieves from the wikipedia.org authority server > the following out-of-zone cname chain: > > ;; ANSWER SECTION: > en.wikipedia.org. 3600 IN CNAME rr.wikimedia.org. > rr.wikimedia.org. 600 IN CNAME rr.pmtpa.wikimedia.org. > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.202 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.245 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.246 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.206 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.203 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.236 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.210 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.214 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.235 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.247 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.213 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.205 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.204 > rr.pmtpa.wikimedia.org. 3600 IN A 207.142.131.248 > > because the second and subsequent ownernames are outside the wikipedia.org > zone, they are thrown away by at least one modern paranoid resolver, since > this is the same mechanism that would be used to poison a cache with phish > data (like a www.bankofamerica.com name). > > i don't blame wikipedia for trying this, since it's also what virtually all > akamaized services do. check "www.yahoo.com" or "www.microsoft.com" for > examples. what this causes is an extra query from the resolver to the zone > authority of each out-of-zone cname target. > > ;; ANSWER SECTION: > www.yahoo.com. 300 IN CNAME www.yahoo.akadns.net. > www.yahoo.akadns.net. 60 IN A 66.94.230.41 > www.yahoo.akadns.net. 60 IN A 66.94.230.39 > www.yahoo.akadns.net. 60 IN A 66.94.230.49 > www.yahoo.akadns.net. 60 IN A 66.94.230.42 > www.yahoo.akadns.net. 60 IN A 66.94.230.36 > www.yahoo.akadns.net. 60 IN A 66.94.230.47 > www.yahoo.akadns.net. 60 IN A 66.94.230.46 > www.yahoo.akadns.net. 60 IN A 66.94.230.44 > > ;; ANSWER SECTION: > www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net. > toggle.www.ms.akadns.net. 300 IN CNAME g.www.ms.akadns.net. > g.www.ms.akadns.net. 300 IN CNAME lb1.www.ms.akadns.net. > lb1.www.ms.akadns.net. 300 IN A 207.46.20.60 > lb1.www.ms.akadns.net. 300 IN A 207.46.19.60 > lb1.www.ms.akadns.net. 300 IN A 207.46.225.60 > lb1.www.ms.akadns.net. 300 IN A 207.46.199.30 > lb1.www.ms.akadns.net. 300 IN A 207.46.19.30 > lb1.www.ms.akadns.net. 300 IN A 207.46.20.30 > lb1.www.ms.akadns.net. 300 IN A 207.46.198.30 > lb1.www.ms.akadns.net. 300 IN A 207.46.198.60 > > so here's my question. should a modern paranoid resolver anti-alias these > out-of-zone cname targets, with logic along the lines of "even though the > zone of the target isn't within the zone of my question, i know that the > zone of the target is served by the same nameservers as the zone of my > question, so it is allowed to give me this out-of-zone data"? > > if we should do this, it will save on backbone and overall DNS traffic, but > it will mean we have to think very hard about the ways in which other NS RRs > get into our cache. (since they will override some current paranoia logic.) > > if we should not do this, then wikipedia should put all of its infrastructure > under the main (wikipedia.org) name and not switch to wikimedia.org (note the > "m" rather than the "p") and akamai's customers should allocate .akamai > subdomains of their .com names, still served by akamai but semantically "part > of" the zone that the most common queries in the universe are all asking for. > > either way it's probably time for a BCP document on this kind of processing. > > i'm especially interested in DJB's perspective on this issue. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 03 21:09:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQa2Z-0005qx-95 for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 21:09:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQa2X-0008Ec-Th for dnsext-archive@lists.ietf.org; Mon, 03 Apr 2006 21:09:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQZyR-0007O0-UE for namedroppers-data@psg.com; Tue, 04 Apr 2006 01:04:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQZyR-0007No-AT for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 01:04:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D762E11425 for ; Tue, 4 Apr 2006 01:04:46 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? In-Reply-To: Your message of "Tue, 04 Apr 2006 09:36:41 +1000." <200604032336.k33Nafo8007070@drugs.dv.isc.org> References: <200604032336.k33Nafo8007070@drugs.dv.isc.org> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 04 Apr 2006 01:04:46 +0000 Message-ID: <86303.1144112686@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > The fix is to fully deploy DNSSEC then each RRset in the answer > can be independently be validated. You do then get the savings. well, if boiling the ocean is an option, then let's fully deploy BCP38 which would be a lot less complicated than fully deploying DNSSEC-bis. but since boiling the ocean is out of scope for this moment in time, we probably do need a BCP telling what to do with out-of-zone CNAMEs, both on transmission and on reception. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 02:16:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQenD-0007IW-9z for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 02:13:31 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQeZF-0003TZ-U5 for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 01:59:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQeTX-0000xT-Bg for namedroppers-data@psg.com; Tue, 04 Apr 2006 05:53:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQeTW-0000xH-Cj for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 05:53:10 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id C3E094037; Tue, 4 Apr 2006 07:53:02 +0200 (CEST) Date: Tue, 4 Apr 2006 07:53:02 +0200 From: bert hubert To: Mark Andrews Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404055301.GA23885@outpost.ds9a.nl> References: <52230.1144086423@sa.vix.com> <200604032336.k33Nafo8007070@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604032336.k33Nafo8007070@drugs.dv.isc.org> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Tue, Apr 04, 2006 at 09:36:41AM +1000, Mark Andrews wrote: > The fix is to fully deploy DNSSEC then each RRset in the answer > can be independently be validated. You do then get the savings. You honestly believe that? You'd have far larger packets to carry the RRSIGs and additional packets to walk the authentication chain. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 04:08:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQgav-0003oA-IY for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 04:08:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQgGa-0000Gb-Jo for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 03:47:56 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FQfqk-0007dP-Re for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 03:21:16 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQfnt-0007Iq-KN for namedroppers-data@psg.com; Tue, 04 Apr 2006 07:18:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQfnq-0007Ia-TJ for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 07:18:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 07F7F26C182 for ; Tue, 4 Apr 2006 09:18:14 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id EE58326C14E for ; Tue, 4 Apr 2006 09:18:12 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id E902682DF41 for ; Tue, 4 Apr 2006 09:18:12 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id D902016AA06; Tue, 4 Apr 2006 09:18:12 +0200 (CEST) Date: Tue, 4 Apr 2006 09:18:12 +0200 From: Stephane Bortzmeyer To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404071812.GB20769@nic.fr> References: <52230.1144086423@sa.vix.com> <20060403183447.GA29373@hermes.walkereng.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060403183447.GA29373@hermes.walkereng.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.0 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Mon, Apr 03, 2006 at 01:34:47PM -0500, Emilio Perea wrote a message of 14 lines which said: > With all due respect (which in this case is a great deal) why should > wikipedia, yahoo and microsoft not be blamed for this abomination? Because it is BIND's default behavior when it is authoritative for the two zones? (And rightly so, IMHO, even if it is quite useless since the resolver may not know that we are authoritative.) Check the A record of www.afnic.fr on ns{1,2,3}.nic.fr (ns1 and ns3 are BIND, ns2 is nsd) and appreciate the difference (all three nameservers are authoritative both for nic.fr and afnic.fr). If you blame Microsoft, you have to blame us as well :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 05:31:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQhsg-0000Vv-Ax for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 05:31:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQhsd-0004a7-Jo for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 05:31:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQhpn-000JXV-UT for namedroppers-data@psg.com; Tue, 04 Apr 2006 09:28:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [217.144.230.29] (helo=serenity.infeline.org) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQhpk-000JX6-2T for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 09:28:20 +0000 Received: (qmail 8366 invoked by uid 1036); 4 Apr 2006 09:28:34 -0000 Received: from 213.239.78.130 by serenity (envelope-from , uid 1006) with qmail-scanner-1.25 ( Clear:RC:0(213.239.78.130):. Processed in 50.898957 secs); 04 Apr 2006 09:28:34 -0000 Received: from unknown (HELO ?10.14.0.57?) (213.239.78.130) by serenity.infeline.org with SMTP; 4 Apr 2006 09:27:43 -0000 Message-ID: <44323BFD.6060509@ketil.froyn.name> Date: Tue, 04 Apr 2006 11:27:25 +0200 From: Ketil Froyn User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? References: <52230.1144086423@sa.vix.com> <44318EB5.6080906@cisco.com> <70733.1144099761@sa.vix.com> In-Reply-To: <70733.1144099761@sa.vix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Paul Vixie wrote: > so ultimately the BCP on this would just say, don't bother emitting CNAME > chains that cross zone boundaries. if an authority zone has a nonterminal > CNAME in it, then the authority servers for that zone should just emit it > and let the recursive agents of the world follow it. Interestingly, tinydns doesn't "recurse" CNAME chains at all. Here's an example: dig @a.ns.froyn.name cname.ketil.froyn.name dig @a.ns.froyn.name tst.ketil.froyn.name This simplifies the authoritative server, it doesn't transmit more than necessary (for instance, the CNAME target might be cached already), and as a result it acts like you recommend for CNAMEs across zone boundaries. Ketil Froyn ketil@froyn.name http://ketil.froyn.name/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 08:06:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkIQ-0007lb-Ew for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:06:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkIP-0001va-TL for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:06:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkEC-0005of-H8 for namedroppers-data@psg.com; Tue, 04 Apr 2006 12:01:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkEB-0005oP-4F for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 12:01:43 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1FQkE7-0007Of-RE; Tue, 04 Apr 2006 14:01:39 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.60) (envelope-from ) id 1FQkE6-0000Bo-9t; Tue, 04 Apr 2006 14:01:38 +0200 From: Florian Weimer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: another question about interpretation of the scriptures: cname chains References: <49390.1144084708@sa.vix.com> Date: Tue, 04 Apr 2006 14:01:38 +0200 In-Reply-To: <49390.1144084708@sa.vix.com> (Paul Vixie's message of "Mon, 03 Apr 2006 17:18:28 +0000") Message-ID: <877j65a6sd.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 * Paul Vixie: > i know that an authority server can emit an incomplete cname chain if it > leads outside the servers's authority zone(s). but what should a recursive > server return if a cname chain from the qname leads to an NXDOMAIN? my > intuition says "return NXDOMAIN" since the nonterminal cname chain has no > value and no meaning to an RD=1 initiator. but i note with dismay that BIND > actually emits the nonterminal chain as if it were an answer to the question. The BIND behavior probably looks like NODATA. I don't know what most clients do when confronted with CNAME records (as there is no standard DNS processing library *sigh*). They probably just look at the answer section and snarf the records of the type they requested, leading to a NODATA behavior in this case. This behavior makes sense to me, more than the NXDOMAIN behavior (after all, there is some RR at the requested domain name, but none of the requested type). Just my .02 EUR. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 08:16:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkSI-0005W4-5r for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:16:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkSG-0002WB-Sv for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:16:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkLh-0006Q8-NA for namedroppers-data@psg.com; Tue, 04 Apr 2006 12:09:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkLh-0006OM-0x for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 12:09:29 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1FQkLF-0007Uk-Df; Tue, 04 Apr 2006 14:09:01 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.60) (envelope-from ) id 1FQkLE-0000DR-1M; Tue, 04 Apr 2006 14:09:00 +0200 From: Florian Weimer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? References: <52230.1144086423@sa.vix.com> Date: Tue, 04 Apr 2006 14:09:00 +0200 In-Reply-To: <52230.1144086423@sa.vix.com> (Paul Vixie's message of "Mon, 03 Apr 2006 17:47:03 +0000") Message-ID: <87zmj18rvn.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab * Paul Vixie: > so here's my question. should a modern paranoid resolver anti-alias these > out-of-zone cname targets, with logic along the lines of "even though the > zone of the target isn't within the zone of my question, i know that the > zone of the target is served by the same nameservers as the zone of my > question, so it is allowed to give me this out-of-zone data"? There could be a zone cut somewhere, so you can't really know that the name servers are the same even if you've cached a matching NS RR for a parent zone. If you require exact knowledge of the delegation, I don't think the additional caching logic will buy you much in terms of performance. I don't know if agressive caching (potentially stomping over zone boundaries) is a problem in this case, but it feels wrong (but still being ill, a lot feels wrong 8-/). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 08:21:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkXh-0007W3-PI for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:21:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkXf-0002qU-S9 for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:21:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkVW-0007HV-2p for namedroppers-data@psg.com; Tue, 04 Apr 2006 12:19:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.189.154] (helo=gusto.araneus.fi) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkVU-0007HE-RK for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 12:19:36 +0000 Received: from guava.araneus.fi ([195.238.197.162]) by gusto.araneus.fi (8.13.5.20060308/8.12.10) with ESMTP id k34CJOHg003425; Tue, 4 Apr 2006 05:19:24 -0700 (PDT) Received: from guava.araneus.fi (localhost [127.0.0.1]) by guava.araneus.fi (8.12.10/8.11.6) with ESMTP id k34CJScD015947; Tue, 4 Apr 2006 15:19:28 +0300 (EEST) Received: (from gson@localhost) by guava.araneus.fi (8.13.5.20060308/8.12.6/Submit) id k34CJRT1024446; Tue, 4 Apr 2006 15:19:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17458.25679.190878.522194@guava.araneus.fi> Date: Tue, 4 Apr 2006 15:19:27 +0300 To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: another question about interpretation of the scriptures: cname chains In-Reply-To: <49390.1144084708@sa.vix.com> References: <49390.1144084708@sa.vix.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: gson@araneus.fi (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Paul Vixie wrote: > i know that an authority server can emit an incomplete cname chain if it > leads outside the servers's authority zone(s). but what should a recursive > server return if a cname chain from the qname leads to an NXDOMAIN? my > intuition says "return NXDOMAIN" since the nonterminal cname chain has no > value and no meaning to an RD=1 initiator. but i note with dismay that BIND > actually emits the nonterminal chain as if it were an answer to the question. I'm confused as to what you think is a problem here. I checked what BIND 9.3.1 does, and it does return NXDOMAIN as expected. The response also has a CNAME chain, but that's not "the answer" - the NXDOMAIN is. As for the CNAME chain having "no value and no meaning to an RD=1 initiator", you could equally well make that statement about positive answers containing a CNAME chain and an answer RRset. Why should NXDOMAINs be treated any differently? See also RFC1034 section 4.3.1: If recursive service is requested and available, the recursive response to a query will be one of the following: - The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer. - A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist. -- Andreas Gustafsson, gson@araneus.fi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 08:21:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkXi-0007WF-5r for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:21:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkXh-0002qV-Sl for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:21:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkVo-0007Jw-Ok for namedroppers-data@psg.com; Tue, 04 Apr 2006 12:19:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [212.9.189.167] (helo=mail.enyo.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkVo-0007Jb-2s for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 12:19:56 +0000 Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1FQkVl-0007cJ-Mz; Tue, 04 Apr 2006 14:19:53 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.60) (envelope-from ) id 1FQkVk-0000GS-Bg; Tue, 04 Apr 2006 14:19:52 +0200 From: Florian Weimer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: the RD bit is troubling me today References: <20060204013717.6BD8111427@sa.vix.com> Date: Tue, 04 Apr 2006 14:19:52 +0200 In-Reply-To: <20060204013717.6BD8111427@sa.vix.com> (Paul Vixie's message of "Sat, 04 Feb 2006 01:37:17 +0000") Message-ID: <87mzf18rdj.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 * Paul Vixie: > But if we were going to write another clarification document on this > point, I'd rather we just said "nameservers that offer both > authority and recursive service are undefined, please just don't do > it" than to try to describe how many RD bits should be dancing on > the head of this pin. Judging by the current examples, I think we can save the common case where all delegations and CNAME/DNAME records refer to resources for which the original name server is authoriative as well. Is this correct? If yes, the restriction against dual-use servers wouldn't be very drastic, I think. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 08:26:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQkbi-0007vj-MA for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:26:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQkbh-0002xz-4s for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 08:26:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkaC-0007qs-NX for namedroppers-data@psg.com; Tue, 04 Apr 2006 12:24:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQkaA-0007qN-DZ for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 12:24:27 +0000 Received: from [IPv6:2001:620:20:1000:202:55ff:fee6:21e8] (unknown [IPv6:2001:620:20:1000:202:55ff:fee6:21e8]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 070838070; Tue, 4 Apr 2006 14:24:21 +0200 (CEST) Subject: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) From: Jeroen Massar To: Werner Koch Cc: gnupg-devel@gnupg.org, spf-discuss@v2.listbox.com, namedroppers@ops.ietf.org In-Reply-To: <87lkum26xw.fsf@wheatstone.g10code.de> References: <87lkum26xw.fsf@wheatstone.g10code.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lwUCbinrZMZaJRJjYJ/f" Organization: Unfix Date: Tue, 04 Apr 2006 14:24:18 +0200 Message-Id: <1144153458.10586.54.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --=-lwUCbinrZMZaJRJjYJ/f Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [Cross-post-reply to most-likely interrested parties... strip where needed] On Mon, 2006-04-03 at 14:13 +0200, Werner Koch wrote: =20 > We are pleased to announce the availability of a new stable GnuPG > release: Version 1.4.3 Neat ;) Muchos thanks to all the developers for their work! > * Implemented Public Key Association (PKA) signature verification. [..] > * New auto-key-locate option that takes an ordered list of methods > to locate a key if it is not available at encryption time (-r or > --recipient). Possible methods include "cert" (use DNS CERT as > per RFC2538bis, "pka" (use DNS PKA), "ldap" (consult the LDAP > server for the domain in question), "keyserver" (use the > currently defined keyserver), as well as arbitrary keyserver > URIs that will be contacted for the key. >=20 > * Able to retrieve keys using DNS CERT records as per RFC-2538bis > (currently in draft): http://www.josefsson.org/rfc2538bis These three lead to one big question though: Can we start doing automatic key verification for mail !? It would be really good if there would now come a draft which will propose the standard order of getting a key, when one doesn't have it or wants to get it again. This release of GnuPG allows one to already specify it. It would be really good if this was standardized and also implemented. Especially in combination with a domain policy (which could be incorporated in say SPF). Thus, eg I mail from jeroen@unfix.org, one can lookup _policy.unfix.org, which will say "mail:PGP:required" or something similar. SMTP clients/servers receiving mail signed by me, can then use one, or more, of the key retrieval techniques to fetch the key. PKA + Cert become very good for this and thus allow automatic verification. When the mail is not signed or falsely signed, one can discard the message based on the policy. For ease of deployment SMTP gateways, which receive mails from authenticated (IP or user/pass etc based) can auto-sign unsigned email with a generic 'automatic' key. Existing clients won't thus be affected, unless they don't use the ISP's SMTP gateway. If they want to avoid using the ISP's gateway, they need to have their key in DNS though. This all though leads to a concern on the placing of the CERTS. Having a large user base would mean that one has say 600k records or more in the main zone for a domain, which gets reloaded every now and then when one needs to update it. It would IMHO be better to be able to off load those records to say _cert.example.org. Which has several benefits, one can then run their normal DNS adminstration and delegate the CERT records to a dedicated DNS server set which can handle the updates easier or simply runs out of a DNSBackend. This will also be easier management wise with DNSSEC I expect and remove the strain from the main boxes, which currently might have maybe upto 100 RR's on average in a zone, especially in the case of webhosting farms where one only specifies the www.example.org and nothing else. Of course this will also require a lot of software to make it working, but this is going in the right direction! :) Greets, Jeroen (Who sees this way as one of the better ways of killing of forged mail, bounces etc...) --=-lwUCbinrZMZaJRJjYJ/f Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEABECADUFAkQyZXIuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I980AJ4lyfYM4AIC7toYNpYzFK1INBXP jACfXxGvCyDIMN8niZppXtzUOi3yYFw= =83+P -----END PGP SIGNATURE----- --=-lwUCbinrZMZaJRJjYJ/f-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 10:13:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmI3-0004uS-BF for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:13:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmI1-0007cn-TC for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:13:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmDs-000HDw-6W for namedroppers-data@psg.com; Tue, 04 Apr 2006 14:09:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [195.30.85.225] (helo=io.link-m.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmDr-000HDW-6W for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 14:09:31 +0000 Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,56bits,EXP1024-RC4-SHA) by io.link-m.de with esmtp; Tue, 04 Apr 2006 14:09:27 +0000 id 0000BE40.44327E18.00000DF3 From: Julian Mehnle To: gnupg-devel@gnupg.org, spf-discuss@v2.listbox.com Subject: Re: Automatic key verification / CERT in DNS / RFC4398 Date: Tue, 4 Apr 2006 13:37:35 +0000 User-Agent: KMail/1.8.3 Cc: namedroppers@ops.ietf.org References: <87lkum26xw.fsf@wheatstone.g10code.de> <1144153458.10586.54.camel@firenze.zurich.ibm.com> In-Reply-To: <1144153458.10586.54.camel@firenze.zurich.ibm.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604041337.36747.julian@mehnle.net> X-UID: 4537 X-Length: 3623 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeroen Massar wrote: > [GnuPG 1.4.3 / Public Key Association (PKA) / CERT in DNS / RFC 4398] > Can we start doing automatic key verification for mail !? > > It would be really good if there would now come a draft which will > propose the standard order of getting a key, when one doesn't have it or > wants to get it again. This release of GnuPG allows one to already > specify it. It would be really good if this was standardized and also > implemented. Especially in combination with a domain policy (which could > be incorporated in say SPF). Indeed the SPF project has plans to introduce another revision of the SPF protocol, now that SPFv1 (v=spf1) will be out as an IETF RFC within the next few weeks. While v=spf1 only supports IP-address-based authenti- cation of the envelope sender, the idea has long been for SPF to be much more than that, i.e. to be a "Sender Policy Framework" allowing domain owners to specify a wide range of policies, covering non-envelope (RFC 2822) identities and authentication methods like DKIM, PGP, and S/MIME. The rough timeline could be for that revision to be released sometime in Q3/2006 to Q1/2007, depending on the feature set chosen (which is still open to debate). > Thus, eg I mail from jeroen@unfix.org, one can lookup _policy.unfix.org, > which will say "mail:PGP:required" or something similar. SMTP > clients/servers receiving mail signed by me, can then use one, or more, > of the key retrieval techniques to fetch the key. PKA + Cert become very > good for this and thus allow automatic verification. When the mail is > not signed or falsely signed, one can discard the message based on the > policy. > [...] > This all though leads to a concern on the placing of the CERTS. Having a > large user base would mean that one has say 600k records or more in the > main zone for a domain, which gets reloaded every now and then when one > needs to update it. It would IMHO be better to be able to off load those > records to say _cert.example.org. [...] While for v=spf1 mostly TXT RRs are used in practice, SPF has been assigned a dedicated "SPF" RR type (code 99), which is already being used (queried) by a few implementations. Also, SPF's macro feature would be useful for specifying custom DNS zone layouts for where to search for key records. (Are there ones besides CERT/RFC2538/RFC4398?) What do folks -- especially the gnupg-devel ones -- think about using SPF for that purpose? Are there any non-obvious fundamental issues that need to be taken into account? Julian. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEMnagwL7PKlBZWjsRAqKmAKDbwBS6mMeL5iTJXs6hruyVg7wHqACeMyVg nP5IOM8KGtZE8+v9P9Jdj+s= =IowF -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 10:25:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmT9-0006Qt-7U for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:25:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmT7-0008Io-TS for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:25:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmQn-000IKv-LT for namedroppers-data@psg.com; Tue, 04 Apr 2006 14:22:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmQm-000IKf-JO for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 14:22:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id A8EC626C165; Tue, 4 Apr 2006 16:22:51 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 7513A26C081; Tue, 4 Apr 2006 16:22:50 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6FE8F58ED51; Tue, 4 Apr 2006 16:22:50 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 447B916AA06; Tue, 4 Apr 2006 16:22:50 +0200 (CEST) Date: Tue, 4 Apr 2006 16:22:50 +0200 From: Stephane Bortzmeyer To: Paul Vixie Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404142250.GA15822@nic.fr> References: <52230.1144086423@sa.vix.com> <20060403184633.GA2107@outpost.ds9a.nl> <59245.1144090871@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59245.1144090871@sa.vix.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Mon, Apr 03, 2006 at 07:01:11PM +0000, Paul Vixie wrote a message of 11 lines which said: > > I hope you aren't telling me Bind *does* accept the answers the > > 'modern & paranoid' recursor rejects? How can that be secure? > > not at all. bind is perfectly modern and paranoid in this respect. Examining the queries received by our BIND nameserver ns3.nic.fr (which is authoritative for both nic.fr and afnic.fr and therefore send out-of-zone replies when queried for www.afnic.fr), I notice that one third of queries for www.afnic.fr are *not* followed by a query for rigolo.nic.fr, the canonical name. We can conclude that one third of the resolvers in the wild are not paranoid enough? Or that BIND (and may be others) nameservers which try to be helpful by following out-of-zone CNAME work for only one third of their clients? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 10:44:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmm0-0005ml-1B for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:44:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmlw-0000zC-MT for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:44:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmk7-000K4Q-VT for namedroppers-data@psg.com; Tue, 04 Apr 2006 14:42:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmk7-000K2C-0N for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 14:42:51 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id C766E3FE2; Tue, 4 Apr 2006 16:42:43 +0200 (CEST) Date: Tue, 4 Apr 2006 16:42:43 +0200 From: bert hubert To: Stephane Bortzmeyer Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404144243.GA8788@outpost.ds9a.nl> References: <52230.1144086423@sa.vix.com> <20060403184633.GA2107@outpost.ds9a.nl> <59245.1144090871@sa.vix.com> <20060404142250.GA15822@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404142250.GA15822@nic.fr> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Tue, Apr 04, 2006 at 04:22:50PM +0200, Stephane Bortzmeyer wrote: > send out-of-zone replies when queried for www.afnic.fr), I notice that > one third of queries for www.afnic.fr are *not* followed by a query > for rigolo.nic.fr, the canonical name. They might still have it in the cache - records have a way of not expiring in sync. $ dig rigolo.nic.fr @127.0.0.1 -p 5300 ;; QUESTION SECTION: ;rigolo.nic.fr. IN A ;; ANSWER SECTION: rigolo.nic.fr. 172800 IN A 192.134.4.20 $ dig www.afnic.fr @127.0.0.1 -p 5300 ;; QUESTION SECTION: ;www.afnic.fr. IN A ;; ANSWER SECTION: www.afnic.fr. 172800 IN CNAME rigolo.nic.fr. rigolo.nic.fr. 172792 IN A 192.134.4.20 -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 10:45:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmmK-0006aE-W0 for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:45:09 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmmK-0000zz-IM for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:45:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmkn-000K6u-UY for namedroppers-data@psg.com; Tue, 04 Apr 2006 14:43:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS, SPF_PASS autolearn=no version=3.1.1 Received: from [65.201.175.9] (helo=mail.verisignlabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmkl-000K6Z-BQ for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 14:43:31 +0000 Received: from [10.131.244.197] ([::ffff:216.168.239.87]) (AUTH: PLAIN davidb, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by mail.verisignlabs.com with esmtp; Tue, 04 Apr 2006 10:43:27 -0400 id 002C4091.4432860F.000065C9 In-Reply-To: <6.2.5.6.2.20060403150010.033084e8@ogud.com> References: <52230.1144086423@sa.vix.com> <20060403183447.GA29373@hermes.walkereng.com> <6.2.5.6.2.20060403150010.033084e8@ogud.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9407456A-F8B1-45B7-8CB3-E4A1D054C867@verisignlabs.com> Cc: namedroppers@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: David Blacka Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Date: Tue, 4 Apr 2006 10:43:26 -0400 To: "=?ISO-8859-1?Q?=D3lafur_Gu=F0mundsson?=" X-Mailer: Apple Mail (2.749.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 On Apr 3, 2006, at 3:08 PM, =D3lafur Gu=F0mundsson wrote: > Because the server in question is trying to be helpful and save > round trips. > > > IMHO fundamental problem here is > #1. that the RFC1034/5 does not exploit say > that a server MUST NOT execute the CNAME algorithm when the CNAME =20 > chain > crosses zone boundary. I think that 1034 *implicitly* says the opposite, actually. > #2 The CNAME processing is split between the authorative server and > the recursive resolver. If all the work was supposed to be done by the > recursive resolver we would not have the possibility of a cache =20 > poisoning > in this case. Agreed. > In this case my reading of the scriptures is different from what I =20 > think > is a safe behavior and recursors should fetch all data from =20 > authorative > sources, including the second and subsequent CNAME's if there is a > possibility the CNAME is from a different zone than the preceding =20 > CNAME. I am thinking that, in this case, 1034 is now essentially out-of-=20 date. Since it has become apparent over the years that modern (and =20 properly paranoid) resolvers must ignore CNAME targets that appear to =20= be out of zone, then it makes no sense for authoritative servers to =20 continue to follow CNAMEs out of zone when constructing responses. =20 Although, OTOH, those authoritative servers that do so are (for the =20 most part) just wasting time and bandwidth. So, at the moment, I am thinking that the new rules should be: 1. Authoritative servers SHOULD not follow CNAME chains across zone =20 boundaries, and MAY choose to not follow CNAME chains at all (which, =20 I gather, is tinydns' behavior). 2. Recursive resolvers MUST ignore CNAME targets that appear to be =20 outside the zone of the response. Although, I am curious about how resolvers actually go about =20 implementing #2. I suppose that it would be quite easy to always =20 ignore CNAME targets in responses (that is, always issue a query-=20 restart for the target of the first CNAME). However, if you wanted =20 to allow in zone CNAME chains to be returned, the resolver would need =20= a rule that described which CNAMEs to accept and which to ignore (or =20 discard). The best rule that I could come up with was: Let Z be the name of the last referral followed. Then ignore CNAMEs whose ownernames are not at or below Z, and =20 ignore any following CNAMEs. This doesn't exactly equate to ignore all "out of zone" CNAMEs since =20 a CNAME could be in a child zone, but I think it is good enough -- =20 based on the principle that if your parent is trying to poison you, =20 you are doomed anyway. -- David Blacka Sr. Engineer VeriSign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 10:46:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQmnw-0007vv-M6 for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:46:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQmnu-00013f-WB for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 10:46:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmlm-000KDg-U2 for namedroppers-data@psg.com; Tue, 04 Apr 2006 14:44:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [217.144.230.29] (helo=serenity.infeline.org) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQmll-000KDE-1f for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 14:44:33 +0000 Received: (qmail 1004 invoked by uid 1036); 4 Apr 2006 14:44:50 -0000 Received: from 213.239.78.130 by serenity (envelope-from , uid 1006) with qmail-scanner-1.25 ( Clear:RC:0(213.239.78.130):. Processed in 0.631798 secs); 04 Apr 2006 14:44:50 -0000 Received: from unknown (HELO ?10.14.0.57?) (213.239.78.130) by serenity.infeline.org with SMTP; 4 Apr 2006 14:44:49 -0000 Message-ID: <4432864D.6050206@ketil.froyn.name> Date: Tue, 04 Apr 2006 16:44:29 +0200 From: Ketil Froyn User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? References: <52230.1144086423@sa.vix.com> <20060403184633.GA2107@outpost.ds9a.nl> <59245.1144090871@sa.vix.com> <20060404142250.GA15822@nic.fr> In-Reply-To: <20060404142250.GA15822@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Stephane Bortzmeyer wrote: > We can conclude that one third of the resolvers in the wild are not > paranoid enough? Wouldn't surprise me, actually. Has anyone done research on software versions that are running in the wild and compared that to software versions that are known to be susceptible to poisoning? Stephane, it would be interesting if you could check your logs and see if the name servers that _didn't_ follow up with a query for rigolo.nic.fr had queried that name already within the TTL, before the query for www.afnic.fr appeared (ie. it was cached already). Ketil Froyn ketil@froyn.name http://ketil.froyn.name/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 11:11:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnBU-0002q2-Da for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:11:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnBT-0002GN-4N for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:11:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQn9M-000Mml-9X for namedroppers-data@psg.com; Tue, 04 Apr 2006 15:08:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQn9L-000MmW-Jw for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 15:08:55 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id DAB5E26C134; Tue, 4 Apr 2006 17:08:54 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id ECA6426C081; Tue, 4 Apr 2006 17:08:53 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id E7B9958ED51; Tue, 4 Apr 2006 17:08:53 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id D3AF916AA06; Tue, 4 Apr 2006 17:08:53 +0200 (CEST) Date: Tue, 4 Apr 2006 17:08:53 +0200 From: Stephane Bortzmeyer To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404150853.GA23048@nic.fr> References: <52230.1144086423@sa.vix.com> <20060403184633.GA2107@outpost.ds9a.nl> <59245.1144090871@sa.vix.com> <20060404142250.GA15822@nic.fr> <20060404144243.GA8788@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404144243.GA8788@outpost.ds9a.nl> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On Tue, Apr 04, 2006 at 04:42:43PM +0200, bert hubert wrote a message of 29 lines which said: > They might still have it in the cache - records have a way of not > expiring in sync. Since the two records have the same TTL, I believe it is unlikely. (In your example, you explicitely queried rigolo.nic.fr first, something that the typical Web browser does not do.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 11:21:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnL3-0002C7-Jc for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:21:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnL2-0002lZ-Ar for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:21:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnIG-000Nks-3h for namedroppers-data@psg.com; Tue, 04 Apr 2006 15:18:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnIF-000Nke-52 for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 15:18:07 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 2A0173FEB; Tue, 4 Apr 2006 17:17:58 +0200 (CEST) Date: Tue, 4 Apr 2006 17:17:58 +0200 From: bert hubert To: Stephane Bortzmeyer Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404151758.GB8788@outpost.ds9a.nl> References: <52230.1144086423@sa.vix.com> <20060403184633.GA2107@outpost.ds9a.nl> <59245.1144090871@sa.vix.com> <20060404142250.GA15822@nic.fr> <20060404144243.GA8788@outpost.ds9a.nl> <20060404150853.GA23048@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404150853.GA23048@nic.fr> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Tue, Apr 04, 2006 at 05:08:53PM +0200, Stephane Bortzmeyer wrote: > > They might still have it in the cache - records have a way of not > > expiring in sync. > > Since the two records have the same TTL, I believe it is unlikely. (In > your example, you explicitely queried rigolo.nic.fr first, something > that the typical Web browser does not do.) sure - but perhaps other hosts CNAME to rigolo.nic.fr? -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 11:26:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnQb-0002Y2-Sn for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:26:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnQa-00039g-Gf for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:26:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnOy-000OUO-AT for namedroppers-data@psg.com; Tue, 04 Apr 2006 15:25:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [131.111.8.130] (helo=ppsw-0.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnOw-000OTR-VO for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 15:25:03 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from libra.cus.cam.ac.uk ([131.111.8.19]:62629) by ppsw-0.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.130]:25) with esmtp id 1FQnOo-0007K2-0o (Exim 4.54) (return-path ); Tue, 04 Apr 2006 16:24:54 +0100 Received: from cet1 by libra.cus.cam.ac.uk with local (Exim 4.61) (envelope-from ) id 1FQnOo-0000my-2K; Tue, 04 Apr 2006 16:24:54 +0100 Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? To: bortzmeyer@nic.fr (Stephane Bortzmeyer) Date: Tue, 4 Apr 2006 16:24:54 +0100 (BST) Cc: bert.hubert@netherlabs.nl, namedroppers@ops.ietf.org In-Reply-To: <20060404150853.GA23048@nic.fr> from "Stephane Bortzmeyer" at Apr 4, 6 05:08:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 973 Message-Id: From: Chris Thompson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a bortzmeyer@nic.fr (Stephane Bortzmeyer) writes: > > On Tue, Apr 04, 2006 at 04:42:43PM +0200, > bert hubert wrote > a message of 29 lines which said: > > > They might still have it in the cache - records have a way of not > > expiring in sync. > > Since the two records have the same TTL, I believe it is unlikely. (In > your example, you explicitely queried rigolo.nic.fr first, something > that the typical Web browser does not do.) "Caching nameserver being used by the typical Web browser", surely? There's also the possibility that the subsequent requests for rigolo.nic.fr went to a different authoritative nameserver - that is, assuming you weren't correlating the logs for all seven of them? -- Chris Thompson Email: cet1@cam.ac.uk -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 11:29:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnT0-0002m4-Qg for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:29:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnSy-0003HG-Gi for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:29:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnRQ-000OoO-Ul for namedroppers-data@psg.com; Tue, 04 Apr 2006 15:27:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnRQ-000Oo7-6W for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 15:27:36 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6EC1426C14E; Tue, 4 Apr 2006 17:27:35 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 5862126C081; Tue, 4 Apr 2006 17:27:34 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 552B358ED5D; Tue, 4 Apr 2006 17:27:34 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 4A60F16AA06; Tue, 4 Apr 2006 17:27:34 +0200 (CEST) Date: Tue, 4 Apr 2006 17:27:34 +0200 From: Stephane Bortzmeyer To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404152734.GA27212@nic.fr> References: <52230.1144086423@sa.vix.com> <20060403184633.GA2107@outpost.ds9a.nl> <59245.1144090871@sa.vix.com> <20060404142250.GA15822@nic.fr> <20060404144243.GA8788@outpost.ds9a.nl> <20060404150853.GA23048@nic.fr> <20060404151758.GB8788@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404151758.GB8788@outpost.ds9a.nl> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 On Tue, Apr 04, 2006 at 05:17:58PM +0200, bert hubert wrote a message of 13 lines which said: > perhaps other hosts CNAME to rigolo.nic.fr? No, I checked. (Only very unused names like www.nic.yt that no one knows.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 11:31:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQnVT-0003Xg-RT for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:31:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQnVT-0003PX-IX for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:31:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnTr-000PDl-Po for namedroppers-data@psg.com; Tue, 04 Apr 2006 15:30:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnTr-000PDW-4D for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 15:30:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7B18226C16C; Tue, 4 Apr 2006 17:30:06 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 6F5E526C14E; Tue, 4 Apr 2006 17:30:05 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6B4C758ED5D; Tue, 4 Apr 2006 17:30:05 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 5AE3B16AA06; Tue, 4 Apr 2006 17:30:05 +0200 (CEST) Date: Tue, 4 Apr 2006 17:30:05 +0200 From: Stephane Bortzmeyer To: Chris Thompson Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404153005.GB27212@nic.fr> References: <20060404150853.GA23048@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On Tue, Apr 04, 2006 at 04:24:54PM +0100, Chris Thompson wrote a message of 22 lines which said: > There's also the possibility that the subsequent requests for > rigolo.nic.fr went to a different authoritative nameserver That's why I tried on ns3, which has a very distinctive Internet connection (unlike ns1 and ns2 which are in the same room) so I believe there is little chance that a resolver switched. (And, anyway, switching nameservers could as well produce the opposite effect.) > assuming you weren't correlating the logs for all seven of them? No, I wasn't. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 11:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQncd-0003TB-K4 for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:39:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQncd-00041a-8P for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 11:39:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnbE-0000Cj-Rf for namedroppers-data@psg.com; Tue, 04 Apr 2006 15:37:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQnbD-0000CO-Ti for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 15:37:44 +0000 Received: from [198.18.182.87] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k34FbUjc032188; Tue, 4 Apr 2006 11:37:31 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <49390.1144084708@sa.vix.com> References: <49390.1144084708@sa.vix.com> Date: Tue, 4 Apr 2006 08:37:36 -0700 To: Paul Vixie From: Edward Lewis Subject: Re: another question about interpretation of the scriptures: cname chains Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 17:18 +0000 4/3/06, Paul Vixie wrote: >i know that an authority server can emit an incomplete cname chain if it >leads outside the servers's authority zone(s). but what should a recursive >server return if a cname chain from the qname leads to an NXDOMAIN? my >intuition says "return NXDOMAIN" since the nonterminal cname chain has no >value and no meaning to an RD=1 initiator. but i note with dismay that BIND >actually emits the nonterminal chain as if it were an answer to the question. This is a dilemma for the same reason why the query count can't be more than 1. There's only one RCODE field, that's the problem. Let's say there's "first CNAME second", with first in the authority of the server and second not, further, not even existent. If the RCODE is for the first, then it ought to be "NO ERROR" as you've found the name ("name error" means the name lookup failed). There's no RCODE for "PARTIAL ANSWER" which is most appropriate when just a CNAME set is returned but not asked for. If the RCODE is for the second, then "NAME ERROR" is appropriate. Hmm, what's a server to do? First question, is this a real problem, is it begging to be solved? Second question, does it matter? Won't resolvers be smart enough, if properly implemented, to deal with the two responses? I mean, coherency doesn't mean consistency. Up to me, using a 30 seconds-of-thought heuristic, I would say that the server use the RCODE for first if there is a problem with second. Let the resolver discover the problem (too), force the work back on them. Yes, that means the recursive work goes unused - but that's operational slop. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 12:09:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQo6P-00079b-3M for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 12:09:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQo6N-0005An-Qb for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 12:09:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQo4C-0003GH-0n for namedroppers-data@psg.com; Tue, 04 Apr 2006 16:07:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQo4B-0003G2-CX for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 16:07:39 +0000 Received: from [198.18.182.87] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k34G7K1w032333; Tue, 4 Apr 2006 12:07:30 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <9407456A-F8B1-45B7-8CB3-E4A1D054C867@verisignlabs.com> References: <52230.1144086423@sa.vix.com> <20060403183447.GA29373@hermes.walkereng.com> <6.2.5.6.2.20060403150010.033084e8@ogud.com> <9407456A-F8B1-45B7-8CB3-E4A1D054C867@verisignlabs.com> Date: Tue, 4 Apr 2006 09:07:05 -0700 To: David Blacka From: Edward Lewis Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Cc: =?iso-8859-1?Q?=22=D3lafur_Gu=F0mundsson=22?= , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 This is pretty much/exactly what my previous message is urging. At 10:43 -0400 4/4/06, David Blacka wrote: >So, at the moment, I am thinking that the new rules should be: > >1. Authoritative servers SHOULD not follow CNAME chains across zone >boundaries, and MAY choose to not follow CNAME chains at all (which, >I gather, is tinydns' behavior). > >2. Recursive resolvers MUST ignore CNAME targets that appear to be >outside the zone of the response. > >Although, I am curious about how resolvers actually go about >implementing #2. I suppose that it would be quite easy to always >ignore CNAME targets in responses (that is, always issue a >query-restart for the target of the first CNAME). However, if you >wanted to allow in zone CNAME chains to be returned, the resolver >would need a rule that described which CNAMEs to accept and which to >ignore (or discard). The best rule that I could come up with was: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 12:10:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQo6e-0007B3-08 for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 12:10:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQo6d-0005BM-KN for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 12:10:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQo45-0003Fi-S5 for namedroppers-data@psg.com; Tue, 04 Apr 2006 16:07:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQo44-0003FM-HG for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 16:07:32 +0000 Received: from [198.18.182.87] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k34G7K1u032333; Tue, 4 Apr 2006 12:07:23 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <70733.1144099761@sa.vix.com> References: <52230.1144086423@sa.vix.com> <44318EB5.6080906@cisco.com> <70733.1144099761@sa.vix.com> Date: Tue, 4 Apr 2006 09:03:30 -0700 To: Paul Vixie From: Edward Lewis Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a At 21:29 +0000 4/3/06, Paul Vixie wrote: >so ultimately the BCP on this would just say, don't bother emitting CNAME >chains that cross zone boundaries. if an authority zone has a nonterminal >CNAME in it, then the authority servers for that zone should just emit it >and let the recursive agents of the world follow it. Why not make it easier by saying that a resolver ought to ignore anything that is "not obviously" in the same zone as the qname? Let servers continue to run the old way (as we don't have a means to do field upgrades of old versions), just recommend that new resolvers be more conservative. (But we don't want to pressure stub resolvers into having to iterate CNAMEs.) There's gonna be tradeoffs between sound protocol engineering and operational load. I.e., if I had to do it, I would not let any server "chase" a CNAME, just return the CNAME to the querier and let the querier restart the operation. This is cleaner from a protocol engineering point of view but leads to worst case traffic load. OTOH, if we keep slapping on rules to lower the operational traffic load, we are 1) complicating the servers and 2) changing the servers. The latter means implementation/deployment churn which may be worse than just buying bigger pipes. (Which is what the ISP operators keep telling us, funny, huh?) >sadly, this is the opposite of the advice i gave yahoo a week ago, and so i >apologize for suggesting stub zones. akamai, if you're listening, you ought >to ask each of your clients for a subzone of their main domain, so that you >can work your DNS tricks in-ballywick and cut down on the wide area DNS load. This isn't a "told-you-so" in any sense, but flipping between recommendations is a sign that the problem really is in a trade-off state. Some problems are destined not to be decided "correctly" so we have to live with compromises. We're bound to stay in this state until someone comes up with a load balancing solution that is not DNS but is as scaleable as the DNS. E.g., something ought to be designed that converts a web site name (as opposed to a domain name) into a domain name based on load considerations. This conversion has to happen between the web browser and the stub resolver it uses, not afterwards, if we are to break out of this state. The DNS isn't dying from this, it's being used outside its design parameters. >i'm just as happy that there's no practical reason to pursue this approach, >since it feels intuitively like a deep swamp waiting to swallow us all. I prefer to think of it as job security. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 12:22:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQoIx-0002fT-Pd for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 12:22:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQoIv-0005dN-G8 for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 12:22:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQoFt-0004aj-KQ for namedroppers-data@psg.com; Tue, 04 Apr 2006 16:19:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQoFs-0004aO-El for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 16:19:44 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id F21303FEB; Tue, 4 Apr 2006 18:19:36 +0200 (CEST) Date: Tue, 4 Apr 2006 18:19:36 +0200 From: bert hubert To: Stephane Bortzmeyer Cc: Chris Thompson , namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060404161935.GA10770@outpost.ds9a.nl> References: <20060404150853.GA23048@nic.fr> <20060404153005.GB27212@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060404153005.GB27212@nic.fr> User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Tue, Apr 04, 2006 at 05:30:05PM +0200, Stephane Bortzmeyer wrote: > That's why I tried on ns3, which has a very distinctive Internet > connection (unlike ns1 and ns2 which are in the same room) so I > believe there is little chance that a resolver switched. (And, anyway, > switching nameservers could as well produce the opposite effect.) I seem to recall older versions of Bind had more complex 'trust rules' which might allow it to 'benefit' from the records other nameservers ignore. Perhaps some people here remember. 1:3 seems plausible for bind 8, although I don't know how bind 8 treats these answers. 1:3 might also be plausible for any Microsoft product. Bert. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 16:45:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQsPD-0004mQ-9i for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 16:45:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQsPB-0000QN-Tt for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 16:45:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQsLA-0002BP-Ow for namedroppers-data@psg.com; Tue, 04 Apr 2006 20:41:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.1.1 Received: from [69.31.8.124] (helo=zeke.ecotroph.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQsL9-0002B4-Mx for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 20:41:27 +0000 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Tue, 04 Apr 2006 16:40:27 -0400 id 01588188.4432D9BC.00007ED1 Message-ID: <4432D9FB.7020901@hxr.us> Date: Tue, 04 Apr 2006 16:41:31 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Olaf M. Kolkman" CC: Namedroppers Subject: Re: Continuing the work on key-rollover References: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> In-Reply-To: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Olaf M. Kolkman wrote: > No other issues have been brought up. If you have any other issues or > requirements then please speak up next week[*]. The editors promised to > stay on top of the document (by volunteering Suresh for the job, thanks!). [..snip..] > [*] Somebody told me that they would like to see the ability to add a > 'time-delay' as a property of the rollover scheme. To paraphrase: That > way one cannot compromise the system and immediately run with it. A > mala-fide roller will have to sit on the compromised system for a while > before it can be abused. (I can't recall who mentioned this but if > somebody supports this requirement, please speak up). While I wasn't the one who mentioned it to you (don't know who it was), this sounds like a good idea. A key compromise MUST NOT allow attackers to replace trust anchors instantly. -andy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 04 19:07:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuc4-0005RY-Vj for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 19:07:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQuc0-0006Tw-Jb for dnsext-archive@lists.ietf.org; Tue, 04 Apr 2006 19:07:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQuWG-000FFa-Oa for namedroppers-data@psg.com; Tue, 04 Apr 2006 23:01:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQuWF-000FFO-T9 for namedroppers@ops.ietf.org; Tue, 04 Apr 2006 23:01:03 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id CD3E2E6108 for ; Tue, 4 Apr 2006 23:01:02 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.4) with ESMTP id k34N0sbu031445; Wed, 5 Apr 2006 09:00:54 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200604042300.k34N0sbu031445@drugs.dv.isc.org> To: Edward Lewis Cc: Paul Vixie , namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: another question about interpretation of the scriptures: cname chains In-reply-to: Your message of "Tue, 04 Apr 2006 08:37:36 MST." Date: Wed, 05 Apr 2006 09:00:53 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 > At 17:18 +0000 4/3/06, Paul Vixie wrote: > >i know that an authority server can emit an incomplete cname chain if it > >leads outside the servers's authority zone(s). but what should a recursive > >server return if a cname chain from the qname leads to an NXDOMAIN? my > >intuition says "return NXDOMAIN" since the nonterminal cname chain has no > >value and no meaning to an RD=1 initiator. but i note with dismay that BIND > >actually emits the nonterminal chain as if it were an answer to the question. > > This is a dilemma for the same reason why the query count can't be > more than 1. There's only one RCODE field, that's the problem. No. The problem is that NXRRSET didn't exist in RFC 1034 and that authoritative servers stopped emitting SOA records in the authority section on NXRRSET/NXDOMAIN to work around a broken client (the later is hearsay). You can disambiguate a NXRRSET from a incomplete answer if the SOA record is always there. Note: this was pointed out in RFC 2308. > Let's say there's "first CNAME second", with first in the authority > of the server and second not, further, not even existent. > > If the RCODE is for the first, then it ought to be "NO ERROR" as > you've found the name ("name error" means the name lookup failed). > There's no RCODE for "PARTIAL ANSWER" which is most appropriate when > just a CNAME set is returned but not asked for. If the RCODE is for > the second, then "NAME ERROR" is appropriate. > > Hmm, what's a server to do? The presence of tha CNAME / DNAME indicates that the original QNAME exists. You can't look at the RCODE in isolation. > First question, is this a real problem, is it begging to be solved? > > Second question, does it matter? Won't resolvers be smart enough, if > properly implemented, to deal with the two responses? I mean, > coherency doesn't mean consistency. > > Up to me, using a 30 seconds-of-thought heuristic, I would say that > the server use the RCODE for first if there is a problem with second. > Let the resolver discover the problem (too), force the work back on > them. Yes, that means the recursive work goes unused - but that's > operational slop. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar > > Nothin' more exciting than going to the printer to watch the toner drain... > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 05:27:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR4IH-0002Ps-Hi for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 05:27:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR4IG-0005Px-8L for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 05:27:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR4DO-000Ilg-BX for namedroppers-data@psg.com; Wed, 05 Apr 2006 09:22:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,BIZ_TLD, FORGED_RCVD_HELO,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [80.67.170.53] (helo=mail.bortzmeyer.org) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR4DM-000IlM-DP for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 09:22:12 +0000 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 1AA0B240815; Wed, 5 Apr 2006 11:22:09 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 060ED11C61; Wed, 5 Apr 2006 11:19:35 +0200 (CEST) Date: Wed, 5 Apr 2006 11:19:35 +0200 From: Stephane Bortzmeyer To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? Message-ID: <20060405091935.GA27075@sources.org> References: <52230.1144086423@sa.vix.com> <44318EB5.6080906@cisco.com> <70733.1144099761@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On Tue, Apr 04, 2006 at 09:03:30AM -0700, Edward Lewis wrote a message of 61 lines which said: > There's gonna be tradeoffs between sound protocol engineering and > operational load. "load" is too vague. I am not really worried about the number of bytes that fly through the network, but I'm more concerned with the extra round-trip time if the resolver has to wait for a reply, then do another one. And, before you ask, no, I do not have an algorithm for the resolver to find out if the extra out-of-zone answer is safe or not (in the case of our www.afnic.fr, the out-of-zone answer *is* safe because the same nameserver is authoritative for both domains; so, it is out-of-zone but not out-of-responsability. The trick is to formalize it.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 08:00:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR6g9-0004Z7-TO for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 08:00:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR6g7-0002fK-Fj for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 08:00:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR6dT-00085L-OR for namedroppers-data@psg.com; Wed, 05 Apr 2006 11:57:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR6dR-00084s-S8 for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 11:57:18 +0000 Received: from [IPv6:2001:620:20:1000:202:55ff:fee6:21e8] (unknown [IPv6:2001:620:20:1000:202:55ff:fee6:21e8]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id CE8BC7FB5; Wed, 5 Apr 2006 13:57:10 +0200 (CEST) Subject: Re: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) From: Jeroen Massar To: Brad Knowles Cc: Werner Koch , gnupg-devel@gnupg.org, spf-discuss@v2.listbox.com, namedroppers@ops.ietf.org In-Reply-To: References: <44332B60.5080006@ntp.isc.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2LrAt1LeteMtICy1yur9" Organization: Unfix Date: Wed, 05 Apr 2006 13:57:03 +0200 Message-Id: <1144238223.17442.20.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 --=-2LrAt1LeteMtICy1yur9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-04-05 at 02:17 -0500, Brad Knowles wrote: > At 10:28 PM -0400 2006-04-04, Danny Mayer wrote: >=20 > > These three lead to one big question though: > > Can we start doing automatic key verification for mail !? >=20 > See DKIM. Which is not there yet and will take the coming X years to be designed, developed and deployed. While PGP is working already for several years and has been proven to work very reliably. > > This all though leads to a concern on the placing of the CERTS. Having= a > > large user base would mean that one has say 600k records or more in th= e > > main zone for a domain, which gets reloaded every now and then when on= e > > needs to update it. >=20 > Think about ten million users, or fifty million. Each user=20 > having several hundred bytes (or even several KB) of data stored for=20 > them. Stored in the DNS. In a single flat zone. Bad idea. Like,=20 > really bad idea. Like, one of the worst DNS-related ideas I think=20 > I've ever heard of, at least in a very long time. Checking http://dailychanges.com/ status of domains on 4/4/2006: 49,340,982 .com 7,425,723 .net etc. so what was the issue again of storing a couple of million records in DNS? If you claim it is a 'bad idea' then why does the CERT record exist at all when it has the intentions of allowing PGP keys to be stored? ;) Using for instance nsd (http://www.nlnetlabs.nl/nsd/) should not pose a problem in serving these amounts of contents. It is more a 'separation' question I am asking, so that one has a subzone for these records, which will allow one to have say 3 nameservers, which are registered at the tld servers thus can't easily be changed, for example.org but have 20, which you stuff in example.org, handling the load for _certs.example.org where the CERTS are stored. It's a choice item giving the possility of doing it. > And it shares most of the same problems in this respect with=20 > DKIM, if you try to push DKIM to process data at the individual level=20 > as opposed to the domain level. >=20 > Very highly non-scalable. See below and also in my original message... > > Of course this will also require a lot of software to make it working, > > but this is going in the right direction! :) >=20 > Possibly, but I'm not convinced. There's lots of scalability=20 > issues that need to be given some serious thought before you just=20 > leap into the fray and start spraying about large DNS records for=20 > each user, regardless of any other factors that are involved. Which is why I noted that one could have a single pgp key for a complete domain could cover all the cases where one doesn't have the enduser signing the messages but a central system doing it for them. Which is in effect what DKIM does but allowing the freedom to have per-user keys too. Eg large sites like hotmail/gmail/yahoo/whatever could have a 'websign key' where the outbound webengine signs the message for the user. Presto, 60M users served with one key. This situation is the case for a large percentage of the ISP's around the globe, especially as they should be 'forcing' their clients to send outbound mail over their SMTP gateways (using submit :) instead of using the one which is acting like an open relay. And the good parts: - this can work today - MTA or MUA only have to do a PGP verification of the message - very easy to deploy and setup - no transition needed, just deploy at the ISP and it works. of course many/all sites have to participate otherwise it doesn't have much effect, though one could say "drop/bounce anything not signed" at a certain point. I don't care if we go for PKA or CERT records as long as the silly spoofing of source addresses gets halted. Spam and virusses are easily discarded using things like SpamAsssassin and ClamAV etc, but bounces might be legit so one still gets those and lots of them from all the virusses and spams spoofing your email address toward non-existent addresses or folks with auto-replies etc. Greets, Jeroen --=-2LrAt1LeteMtICy1yur9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEABECADUFAkQzsI4uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I7rGAJ9SAUeQBmkFD9lI8r11TNQ8Z7AP 3ACeKyWY4d6ppsiicqcENRamEgyM0Ms= =sZ98 -----END PGP SIGNATURE----- --=-2LrAt1LeteMtICy1yur9-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 09:30:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR85s-0001eE-Rh for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 09:30:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR85s-0006eh-Ea for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 09:30:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR825-000Gmj-VD for namedroppers-data@psg.com; Wed, 05 Apr 2006 13:26:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [195.30.85.225] (helo=io.link-m.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR824-000GmP-Pf for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 13:26:49 +0000 Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,56bits,EXP1024-RC4-SHA) by io.link-m.de with esmtp; Wed, 05 Apr 2006 13:26:43 +0000 id 0000063C.4433C593.0000410E From: Julian Mehnle To: gnupg-devel@gnupg.org, spf-discuss@v2.listbox.com, namedroppers@ops.ietf.org Subject: Re: Automatic key verification / CERT in DNS / RFC4398 Date: Wed, 5 Apr 2006 13:26:37 +0000 User-Agent: KMail/1.8.3 References: <87lkum26xw.fsf@wheatstone.g10code.de> <200604041337.36747.julian@mehnle.net> <87fyksi443.fsf@wheatstone.g10code.de> In-Reply-To: <87fyksi443.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604051326.38720.julian@mehnle.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Koch wrote: > On Tue, 4 Apr 2006 13:37:35 +0000, Julian Mehnle said: > > What do folks -- especially the gnupg-devel ones -- think about using > > SPF for that purpose? Are there any non-obvious fundamental issues > > that need to be taken into account? > > I consider SPF far to complex to solve the simple goal of > authenticating the source of an email. It does not stop spam, as > this requires content filters and the jurisdiction and won't > authenmticate the full message. Let me say this in advance: I do NOT want to start a lengthy discussion across several mailing lists about that. But I think there are a few misconceptions to be clarified: SPF does not aim to stop spam, it aims to stop forgery -- not necessarily by directly doing the authentication itself (SPFv1 cares about the envelope sender only, the next revision aims to do more than that). In particular, SPF does NOT aim to replace DKIM or PGP, but to complement them by giving domain owners the means to publicly specify their mail sending policies in a standardized way. (BTW, if you think SPF is "too complex", then you should take into account that the SPFv1 spec is over 40 pages long only because it already includes lots of lessons learned, security considerations, and other non-authorita- tive stuff.) > The goal of PKA is much simpler: Authenticate the From: header and > allow the MUA or MTA to detected spoofed messages this way. > > The ability to do an opportunistic encryption using the PKA framework > is just a very welcome side-effect. It is exactly that side-effect of opportunistic encryption that SPF aims to support. Is that support (i.e. the standardized means to publicly specify your sending/signing policy) not something worth to be considered? If you think that PKA already does the part _you_ want, then you may be missing the fact that not every sender may choose PGP+PKA as their authentication method, and that receivers may not want to check _all_ the methods out there for a given message until they find one that actually authenticates the message. SPF could act as an arbitrator for the various existing authentication methods. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEM8WOwL7PKlBZWjsRArGYAJ404uYC5ifZyJCTP6ZvvVHnPP56iQCeNDTr Q1JErdzYRDbDM9I0ya/6cNU= =i1jf -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 09:40:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8Fb-00061B-V6 for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 09:40:47 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8FZ-0006uN-MV for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 09:40:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR8DX-000IAb-1w for namedroppers-data@psg.com; Wed, 05 Apr 2006 13:38:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS,UPPERCASE_25_50 autolearn=ham version=3.1.1 Received: from [195.30.85.225] (helo=io.link-m.de) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR8DV-000IAI-Sg for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 13:38:38 +0000 Received: from cl-40.muc-02.de.sixxs.net (cl-40.muc-02.de.sixxs.net [2001:a60:f000:27::2]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,56bits,EXP1024-RC4-SHA) by io.link-m.de with esmtp; Wed, 05 Apr 2006 13:38:34 +0000 id 0000063C.4433C85A.000041CE From: Julian Mehnle To: spf-discuss@v2.listbox.com Subject: Re: Automatic key verification / CERT in DNS / RFC4398 Date: Wed, 5 Apr 2006 13:38:31 +0000 User-Agent: KMail/1.8.3 Cc: gnupg-devel@gnupg.org, namedroppers@ops.ietf.org References: <87lkum26xw.fsf@wheatstone.g10code.de> <87fyksi443.fsf@wheatstone.g10code.de> <200604051326.38720.julian@mehnle.net> In-Reply-To: <200604051326.38720.julian@mehnle.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604051338.32759.julian@mehnle.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Mehnle wrote: > Werner Koch wrote: > > The goal of PKA is much simpler: Authenticate the From: header and > > allow the MUA or MTA to detected spoofed messages this way. > > > > The ability to do an opportunistic encryption using the PKA framework > > is just a very welcome side-effect. > > It is exactly that side-effect of opportunistic encryption that SPF aims > to support. Oops, please read that as "opportunistic authentication". But that's not all that different. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEM8hYwL7PKlBZWjsRAn9YAKCIsQPyGnlsU9OSh5T4MNpWpMonhQCfeOGx hnjEHXKVpAS8emYIiUvT+4c= =Gkh2 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 11:03:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR9Y3-0002Of-Uy for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 11:03:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR9Y2-00026r-K3 for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 11:03:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR9V6-0001IE-Om for namedroppers-data@psg.com; Wed, 05 Apr 2006 15:00:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR9V5-0001Hw-MJ for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 15:00:52 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k35F0cD5037563; Wed, 5 Apr 2006 11:00:40 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060405105049.03424d70@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Apr 2006 10:58:41 -0400 To: Jeroen Massar , Brad Knowles From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Re: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) Cc: Werner Koch , namedroppers@ops.ietf.org, gnupg-devel@gnupg.org, spf-discuss@v2.listbox.com In-Reply-To: <1144238223.17442.20.camel@firenze.zurich.ibm.com> References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c At 07:57 05/04/2006, Jeroen Massar wrote: >On Wed, 2006-04-05 at 02:17 -0500, Brad Knowles wrote: > > At 10:28 PM -0400 2006-04-04, Danny Mayer wrote: Please remove namedroppers from future postings on this tread. I'm not approving any messages as the discussion is about possible DNS operational issues, not DNS protocol issues. Olafur (namedroppers moderator of the day) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 14:29:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRCkp-0006Bv-OD for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 14:29:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRBwi-0000Rd-TQ for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 13:37:32 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FRBjQ-00040g-5A for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 13:23:50 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRBfX-000F34-QQ for namedroppers-data@psg.com; Wed, 05 Apr 2006 17:19:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRBfW-000F2s-W4 for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 17:19:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 763871142E; Wed, 5 Apr 2006 17:19:46 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Jeroen Massar , Brad Knowles , Werner Koch , namedroppers@ops.ietf.org, gnupg-devel@gnupg.org, spf-discuss@v2.listbox.com Subject: Re: Automatic key verification / CERT in DNS / RFC4398 (Was: [Announce] GnuPG 1.4.3 released) In-Reply-To: Your message of "Wed, 05 Apr 2006 10:58:41 -0400." <6.2.5.6.2.20060405105049.03424d70@ogud.com> References: <44332B60.5080006@ntp.isc.org> <1144238223.17442.20.camel@firenze.zurich.ibm.com> <6.2.5.6.2.20060405105049.03424d70@ogud.com> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 05 Apr 2006 17:19:46 +0000 Message-ID: <42466.1144257586@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 also note that dns operational issues are welcome on dns-operations@lists.oarci.net, which is a mailman-run list whose url is lists.oarci.net/mailman/listinfo/. re: > Please remove namedroppers from future postings on this tread. > I'm not approving any messages as the discussion is about possible > DNS operational issues, not DNS protocol issues. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 18:16:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGJ3-0000bJ-Tu for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 18:16:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGJ3-0000Jk-FZ for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 18:16:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRGE3-000Hne-Ke for namedroppers-data@psg.com; Wed, 05 Apr 2006 22:11:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRGE2-000HnS-HY for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 22:11:42 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k35MBRnb041743; Wed, 5 Apr 2006 18:11:28 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200604042300.k34N0sbu031445@drugs.dv.isc.org> References: <200604042300.k34N0sbu031445@drugs.dv.isc.org> Date: Wed, 5 Apr 2006 15:03:55 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: another question about interpretation of the scriptures: cname chains Cc: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Mark, I don't understand your reply. When I say that there is only one RCODE, I mean that the response can only reply with one "state." I.e., in the case that there is a CNAME record matching the original query but the server gets a service failure trying to follow the chain, should the lone RCODE field report that the query name was found and a CNAME was successfully matched there, or that a service failure occurred following the CNAME. What I meant by multiple queries and one return code field was that if one of the queries ended in a service failure and another in a name error, how do you indicate this? You can report only one. CNAME processing is akin to multiple queries - because the sought name keeps changing. At 9:00 +1000 4/5/06, Mark Andrews wrote: >> At 17:18 +0000 4/3/06, Paul Vixie wrote: >> >i know that an authority server can emit an incomplete cname chain if it >> >leads outside the servers's authority zone(s). but what should a recursive >> >server return if a cname chain from the qname leads to an NXDOMAIN? my >> >intuition says "return NXDOMAIN" since the nonterminal cname chain has no >> >value and no meaning to an RD=1 initiator. but i note with >>dismay that BIND >> >actually emits the nonterminal chain as if it were an answer to >>the question. >> >> This is a dilemma for the same reason why the query count can't be >> more than 1. There's only one RCODE field, that's the problem. > > No. The problem is that NXRRSET didn't exist in RFC 1034 and > that authoritative servers stopped emitting SOA records in the > authority section on NXRRSET/NXDOMAIN to work around a broken > client (the later is hearsay). > > You can disambiguate a NXRRSET from a incomplete answer if > the SOA record is always there. > > Note: this was pointed out in RFC 2308. > >> Let's say there's "first CNAME second", with first in the authority >> of the server and second not, further, not even existent. >> >> If the RCODE is for the first, then it ought to be "NO ERROR" as >> you've found the name ("name error" means the name lookup failed). >> There's no RCODE for "PARTIAL ANSWER" which is most appropriate when >> just a CNAME set is returned but not asked for. If the RCODE is for >> the second, then "NAME ERROR" is appropriate. >> >> Hmm, what's a server to do? > > The presence of tha CNAME / DNAME indicates that the original > QNAME exists. You can't look at the RCODE in isolation. > >> First question, is this a real problem, is it begging to be solved? >> >> Second question, does it matter? Won't resolvers be smart enough, if >> properly implemented, to deal with the two responses? I mean, >> coherency doesn't mean consistency. >> >> Up to me, using a 30 seconds-of-thought heuristic, I would say that >> the server use the RCODE for first if there is a problem with second. >> Let the resolver discover the problem (too), force the work back on >> them. Yes, that means the recursive work goes unused - but that's >> operational slop. >> >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Edward Lewis +1-571-434-5468 >> NeuStar >> >> Nothin' more exciting than going to the printer to watch the toner drain... >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >-- >Mark Andrews, ISC >1 Seymour St., Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 18:22:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGO3-0003DL-04 for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 18:22:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGO2-0000WY-Gl for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 18:22:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRGLl-000IXF-UJ for namedroppers-data@psg.com; Wed, 05 Apr 2006 22:19:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [200.23.30.77] (helo=mail.nic.mx) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRGLj-000IWz-Ea for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 22:19:39 +0000 Received: from localhost (localhost.nic.mx [127.0.0.1]) by mail.nic.mx (Postfix) with ESMTP id 52BDC181B00; Wed, 5 Apr 2006 17:19:37 -0500 (CDT) Received: from mail.nic.mx ([127.0.0.1]) by localhost (mail.nic.mx [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18611-03; Wed, 5 Apr 2006 17:19:37 -0500 (CDT) Received: from GLOZANO.nic.mx (unknown [200.33.1.76]) by mail.nic.mx (Postfix) with ESMTP id 2370C181104; Wed, 5 Apr 2006 17:19:37 -0500 (CDT) Message-Id: <6.2.5.6.2.20060405170439.044b7b30@nic.mx> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 05 Apr 2006 17:19:36 -0500 To: "Olaf M. Kolkman" , Namedroppers From: Gustavo Lozano Subject: Re: Continuing the work on key-rollover In-Reply-To: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> References: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at nic.mx Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a I think that the following requirement is obvious=20 but just in case I am sending it to the list. Requirement: If the solution uses the DNS as transport then=20 the queries and answers involved in a normal case=20 scenario MUST fit in a 4096 bytes UDP packet. Why? Because, I don't want resolvers opening TCP connections to my servers. At 09:56 AM 3/30/2006 +0200, Olaf M. Kolkman wrote: >Dear Colleagues, > >After Re-issuing issue 1 [1] and asking for a hum at the physical >meeting I plan to close the issue next week and ask the editors to >add the text. > >No other issues have been brought up. If you have any other issues or >requirements then please speak up next week[*]. The editors promised >to stay on top of the document (by volunteering Suresh for the job, >thanks!). > >I hope that Suresh can whip up a new revision in a week or two and if >there are no further comments we'll last call it. > >In the mean time, please look at the various proposals on the table. >The document that Alberto Mart=EDnez Herrera=20 >provided to us in November [2] might, or even=20 >will, be useful. (URL: http://=20 >docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf). There >are other people that did comparison matrices, can they please >provide links? > >If there are folk that have any other rollover-proposals to add then >please submit that seem to fit to the requirements; better start >writing text but please do realize that you add entropy :-) . > >I hope we can converge to one spec before next IETF. > > >--Olaf > >[1] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00370.html >[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ msg01546.html > >[*] Somebody told me that they would like to see the ability to add >a 'time-delay' as a property of the rollover scheme. To paraphrase: >That way one cannot compromise the system and immediately run with >it. A mala-fide roller will have to sit on the compromised system for >a while before it can be abused. (I can't recall who mentioned this >but if somebody supports this requirement, please speak up). > > >----------------------------------------------------------- >Olaf M. Kolkman >NLnet Labs >http://www.nlnetlabs.nl/ > > > > > gus=20 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 05 19:07:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRH6A-0004NC-76 for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 19:07:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRH68-000222-SX for dnsext-archive@lists.ietf.org; Wed, 05 Apr 2006 19:07:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRH3Q-000MnQ-E0 for namedroppers-data@psg.com; Wed, 05 Apr 2006 23:04:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRH3P-000MnE-Sc for namedroppers@ops.ietf.org; Wed, 05 Apr 2006 23:04:47 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7E5511142E for ; Wed, 5 Apr 2006 23:04:47 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: another question about interpretation of the scriptures: cname chains In-Reply-To: Your message of "Wed, 05 Apr 2006 15:03:55 -0400." References: <200604042300.k34N0sbu031445@drugs.dv.isc.org> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 05 Apr 2006 23:04:47 +0000 Message-ID: <70931.1144278287@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de > ... CNAME processing is akin to multiple queries - > because the sought name keeps changing. i don't agree. each cname changes the name being described by the rcode. therefore the rcode describes the status of the final cname target name. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 00:19:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRLy9-0006S3-7v for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 00:19:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRLy7-0005dl-Vu for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 00:19:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRLtC-00020b-71 for namedroppers-data@psg.com; Thu, 06 Apr 2006 04:14:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRLtA-00020M-Et for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 04:14:32 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k364EI35044601; Thu, 6 Apr 2006 00:14:19 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <70931.1144278287@sa.vix.com> References: <200604042300.k34N0sbu031445@drugs.dv.isc.org> <70931.1144278287@sa.vix.com> Date: Thu, 6 Apr 2006 00:14:30 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: another question about interpretation of the scriptures: cname chains Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab At 23:04 +0000 4/5/06, Paul Vixie wrote: >> ... CNAME processing is akin to multiple queries - >> because the sought name keeps changing. > >i don't agree. each cname changes the name being described by the rcode. Where's the disagreement? "cname changes the name" is what I mean. >therefore the rcode describes the status of the final cname target name. Is that in the specs? Or is that one interpretation? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 00:37:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRMFm-0005As-Ub for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 00:37:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRMFl-0006I4-Lf for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 00:37:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRMD4-00044q-L5 for namedroppers-data@psg.com; Thu, 06 Apr 2006 04:35:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRMD4-00044d-3d for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 04:35:06 +0000 Received: from drugs.dv.isc.org (localhost.isc.org [IPv6:::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 55D74E611C for ; Thu, 6 Apr 2006 04:35:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.13.4/8.13.4) with ESMTP id k364Z00T054284; Thu, 6 Apr 2006 14:35:00 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200604060435.k364Z00T054284@drugs.dv.isc.org> To: Edward Lewis Cc: namedroppers@ops.ietf.org From: Mark Andrews Subject: Re: another question about interpretation of the scriptures: cname chains In-reply-to: Your message of "Thu, 06 Apr 2006 00:14:30 -0400." Date: Thu, 06 Apr 2006 14:35:00 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > At 23:04 +0000 4/5/06, Paul Vixie wrote: > >> ... CNAME processing is akin to multiple queries - > >> because the sought name keeps changing. > > > >i don't agree. each cname changes the name being described by the rcode. > > Where's the disagreement? "cname changes the name" is what I mean. > > >therefore the rcode describes the status of the final cname target name. > > Is that in the specs? Or is that one interpretation? - A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 07:47:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRSxm-0008Dk-8U for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 07:47:46 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRSxk-0004zH-LD for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 07:47:46 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRSsu-0007AT-DD for namedroppers-data@psg.com; Thu, 06 Apr 2006 11:42:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [131.193.178.160] (helo=stoneport.math.uic.edu) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRSss-0007AC-5x for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 11:42:42 +0000 Received: (qmail 69371 invoked by uid 1016); 6 Apr 2006 11:43:13 -0000 Date: 6 Apr 2006 11:43:13 -0000 Message-ID: <20060406114313.69365.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? References: <52230.1144086423@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Out-of-zone chaining sometimes breaks service (because the chains become so long that resolvers give up), often causes extra delays for DNS resolvers, and often causes delays visible to users. Out-of-zone chaining can always be eliminated by proper configuration on the server side. The server provides the IP addresses instead of forcing the client to go chasing the IP addresses around the Internet. > "even though the > zone of the target isn't within the zone of my question, i know that the > zone of the target is served by the same nameservers as the zone of my > question, so it is allowed to give me this out-of-zone data"? That can be made secure, and would eliminate _some_ of the damage caused by out-of-zone chaining, but having the server do the right thing would produce much larger benefits for less effort. ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 08:49:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTvE-0001L8-UO for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 08:49:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTvD-00076A-Ek for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 08:49:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRTsa-000CS0-Fs for namedroppers-data@psg.com; Thu, 06 Apr 2006 12:46:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRTsY-000CRY-Nl for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 12:46:27 +0000 Received: from [127.0.0.1] (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]) by open.nlnetlabs.nl (8.13.4/8.13.4) with ESMTP id k36CkH8T074644; Thu, 6 Apr 2006 14:46:18 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) In-Reply-To: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> References: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-26-664136210" Message-Id: <10D66664-7768-4DCC-BC39-29932F1B7E20@NLnetLabs.nl> Cc: albertof_mtzherrera@itesm.mx Content-Transfer-Encoding: 7bit From: "Olaf M. Kolkman" Subject: Re: Continuing the work on key-rollover Date: Thu, 6 Apr 2006 14:46:16 +0200 To: Namedroppers X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.749.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-26-664136210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On Mar 30, 2006, at 9:56 AM, Olaf M. Kolkman wrote: > The document that Alberto Mart=EDnez Herrera provided to us in =20 > November[2] might, or even will, be useful. (URL: http://=20 > docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf). Some people have had issues with opening this document. Alberto just explained to me: > I have been trying to use any browsers to check the document. There =20= > is a > strange behaviour on IE. It does not allow to check the document =20 > when the > adobe plug-in is used. However when the document is downloaded to =20 > the PC > there is not any trouble to read it using Adobe 6.0/7.0 . With =20 > Mozilla (all > versions) and Opera there is not any trouble to check the document. =20= > I'm going > to investigate the origin of the trouble when IE is used and solve =20 > it soon. > I guess that explains things a bit and provides you alternatives to =20 open the document. --Olaf ----------------------------------------------------------- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ --Apple-Mail-26-664136210 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: This message is locally signed. iD8DBQFENQ2ZtN/ca3YJIocRAsicAKDBdXLpgnJmQ7Q5DBkYNAA/j5F1OwCgi47c zXlWlhosMgvss7HuZRKp1rQ= =kUpV -----END PGP SIGNATURE----- --Apple-Mail-26-664136210-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 09:12:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUHy-0003cQ-6x for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 09:12:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRUHw-0007wQ-Uj for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 09:12:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRUGI-000Enk-Ia for namedroppers-data@psg.com; Thu, 06 Apr 2006 13:10:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRUGH-000EnY-Qi for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 13:10:58 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k36DAhsw048891; Thu, 6 Apr 2006 09:10:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <200604060435.k364Z00T054284@drugs.dv.isc.org> References: <200604060435.k364Z00T054284@drugs.dv.isc.org> Date: Thu, 6 Apr 2006 09:09:23 -0400 To: Mark Andrews From: Edward Lewis Subject: Re: another question about interpretation of the scriptures: cname chains Cc: Edward Lewis , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 At 14:35 +1000 4/6/06, Mark Andrews wrote: >> Is that in the specs? Or is that one interpretation? > > - A name error indicating that the name does not exist. This > may include CNAME RRs that indicate that the original query > name was an alias for a name which does not exist. "may"...(I know, here we go again) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 09:55:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUxp-00070F-ML for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 09:55:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRUxl-0000wl-8N for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 09:55:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRUuv-000IkI-4j for namedroppers-data@psg.com; Thu, 06 Apr 2006 13:52:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRUuu-000Ik2-1L for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 13:52:56 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k36Dqidk030878 for ; Thu, 6 Apr 2006 09:52:45 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k36DqbS2025262 for ; Thu, 6 Apr 2006 09:52:38 -0400 (EDT) From: "Scott Rose" To: "Namedroppers" Subject: RE: Continuing the work on key-rollover Date: Thu, 6 Apr 2006 09:52:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4432D9FB.7020901@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Andrew Newton > > Olaf M. Kolkman wrote: > > No other issues have been brought up. If you have any other issues or > > requirements then please speak up next week[*]. The editors promised to > > stay on top of the document (by volunteering Suresh for the > job, thanks!). > [..snip..] > > [*] Somebody told me that they would like to see the ability to add a > > 'time-delay' as a property of the rollover scheme. To paraphrase: That > > way one cannot compromise the system and immediately run with it. A > > mala-fide roller will have to sit on the compromised system for a while > > before it can be abused. (I can't recall who mentioned this but if > > somebody supports this requirement, please speak up). > > > While I wasn't the one who mentioned it to you (don't know who it was), > this sounds like a good idea. A key compromise MUST NOT allow attackers > to replace trust anchors instantly. > I agree with this requirement for scheduled rollovers, I don't feel certain it should apply for emergency rollovers. Mainly the issue in replacing a compromised key. I would like to see the vulnerability period of a compromised key be as small as possible. Scott > -andy > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 13:12:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRY2K-00050h-Jo for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 13:12:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRY2J-00088r-6j for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 13:12:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRXyV-0007ki-CA for namedroppers-data@psg.com; Thu, 06 Apr 2006 17:08:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRXyE-0007j9-H7 for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 17:08:34 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k36H8GIV003969; Thu, 6 Apr 2006 17:08:16 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k36H8EVf003968; Thu, 6 Apr 2006 17:08:14 GMT Date: Thu, 6 Apr 2006 17:08:14 +0000 From: bmanning@vacation.karoshi.com To: "Olaf M. Kolkman" Cc: Namedroppers , albertof_mtzherrera@itesm.mx Subject: Re: Continuing the work on key-rollover Message-ID: <20060406170814.GC3862@vacation.karoshi.com.> References: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> <10D66664-7768-4DCC-BC39-29932F1B7E20@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <10D66664-7768-4DCC-BC39-29932F1B7E20@NLnetLabs.nl> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 On Thu, Apr 06, 2006 at 02:46:16PM +0200, Olaf M. Kolkman wrote: > > On Mar 30, 2006, at 9:56 AM, Olaf M. Kolkman wrote: > > > The document that Alberto Martínez Herrera provided to us in > >November[2] might, or even will, be useful. (URL: http:// > >docs.nicmxlabs.org.mx/itesm/dnsseckeyrolloverproposals.pdf). > > Some people have had issues with opening this document. > > Alberto just explained to me: > >I have been trying to use any browsers to check the document. There > >is a > >strange behaviour on IE. It does not allow to check the document > >when the > >adobe plug-in is used. However when the document is downloaded to > >the PC > >there is not any trouble to read it using Adobe 6.0/7.0 . With > >Mozilla (all > >versions) and Opera there is not any trouble to check the document. > >I'm going > >to investigate the origin of the trouble when IE is used and solve > >it soon. > > > > I guess that explains things a bit and provides you alternatives to > open the document. > > > --Olaf > > ----------------------------------------------------------- > Olaf M. Kolkman > NLnet Labs > http://www.nlnetlabs.nl/ > > > well... safari has problems (just the first page is downloaded) and mozilla/firefox downloads something that gives a 110 error. using adobe 6.0.2 pro. ... on a Mac-G4. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Apr 06 13:13:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRY2q-0005TY-J7 for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 13:13:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRY2o-00089g-8B for dnsext-archive@lists.ietf.org; Thu, 06 Apr 2006 13:13:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRXyF-0007jb-94 for namedroppers-data@psg.com; Thu, 06 Apr 2006 17:08:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRXyE-0007it-DE for namedroppers@ops.ietf.org; Thu, 06 Apr 2006 17:08:34 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7328D1142E for ; Thu, 6 Apr 2006 17:08:13 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: another out-of-zone cname question-- anti-aliasing of zone servers? In-Reply-To: Your message of "Tue, 04 Apr 2006 18:19:36 +0200." <20060404161935.GA10770@outpost.ds9a.nl> References: <20060404150853.GA23048@nic.fr> <20060404153005.GB27212@nic.fr> <20060404161935.GA10770@outpost.ds9a.nl> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Thu, 06 Apr 2006 17:08:13 +0000 Message-ID: <66112.1144343293@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > I seem to recall older versions of Bind had more complex 'trust rules' which > might allow it to 'benefit' from the records other nameservers ignore. > Perhaps some people here remember. i remember nothing like that. > 1:3 seems plausible for bind 8, although I don't know how bind 8 treats > these answers. bind8 will throw away out-of-zone cnames, and behave iteratively at the point of the zone crossing. > 1:3 might also be plausible for any Microsoft product. clarifying this thread's role on namedroppers, here's my understanding. any followups specific to bind belong on bind-workers@isc.org. any followups concerning operational issues like "why do some folks only query for the initial name and fail to iterate at the point of the zone crossing?" belong on dns-operations@lists.oarci.net, where stephane has already begun discussing his original point. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From bgedj@yahoo.co.jp Fri Apr 07 02:10:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRkBM-0008Uq-Bj for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 02:10:56 -0400 Received: from [218.24.126.124] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRkBB-0006sr-8u for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 02:10:56 -0400 To: From: =?iso-2022-jp?B?ZnRycg==?= Subject: =?iso-2022-jp?B?GyRCPCtLfU9DJE8kYiQmSzAkLSQ/JEMhKhsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 $B<+M3Nx0&$rE0DlJ,@O!"=P2q$$$N6b%a%@%j%9%HC#%j%K%e%"%k!#(B http://wxxo.com/syb/ $B) id 1FRsoN-000IWK-Mh for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:23:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRsoM-000IVm-OI for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:23:46 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37FN2f1012521 for ; Fri, 7 Apr 2006 11:23:02 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxbaGBy; Fri, 7 Apr 06 11:22:59 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Namedroppers From: Suresh Krishnaswamy Subject: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:23:41 -0400 X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 In a short while I'll be sending out a list of pending issues (currently 7 in number) for draft-ietf-dnsext-rollover- requirements-00. All of these issues were extracted from e-mails that were sent to namedroppers relative to this topic over the last month. Sample text appears in most places. If you don't agree with the wording in the sample text please speak up. In places where there is no sample text, silence will be interpreted as an implicit agreement by the Working Group to close this issue without further changes. The hope is to have each of these issues resolved over the next two weeks so that the next version of the requirements draft can be rolled out and last-called in the relatively near future. Suresh (on behalf of the editors) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:35:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRszV-0006r7-GQ for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:35:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRszV-0000UP-7C for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:35:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRsxp-000JLe-Ow for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:33:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRsxp-000JLM-27 for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:33:33 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37FWhIk014054 for ; Fri, 7 Apr 2006 11:32:43 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAATAaOAB; Fri, 7 Apr 06 11:32:38 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F1DFB82-5354-4A60-A348-17CBF1828193@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 1: IPR, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:33:20 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ISSUE 1: IPR STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00267.html http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00370.html DESCRIPTION: The following change was made to section 5.2 Old Text: The solution SHOULD not have any intellectual property encumbrance on either the technologies used by the solution nor implementations of the solution. The technology used by the solution SHOULD permit implementers to provide complete, running implementations that have Berkley open source type of licensing. New Text: Because trust anchor rollover is considered "mandatory-to-implement", section 8 of [RFC3979] requires that the technology solution chosen must be unencumbered or must be available under royalty-free terms. For this purpose, "royalty-free" is defined as follows: world wide, perpetual right to use, without fee, in commerce or otherwise, where "use" includes descriptions of algorithms, distribution and/or use of hardware implementations, distribution and/or use of software systems in source and/or binary form, in all DNS or DNSSEC applications including registry, registrar, domain name service including authority, recursion, caching, forwarding, stub resolver, or similar. In summary, no implementor, distributor, or operator of the technology chosen for trust anchor management shall be expected or required to pay any fee to any IPR holder for the right to implement, distribute, or operate a system which includes the chosen mandatory-to-implement solution. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:37:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt1Z-0007dm-E2 for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:37:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt1Z-0000W6-5t for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:37:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt0J-000JbK-0S for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:36:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt0I-000Jb7-AO for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:36:06 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37FZM1x014481 for ; Fri, 7 Apr 2006 11:35:22 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4XaWqC; Fri, 7 Apr 06 11:35:19 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <329E8F22-900E-41F9-898B-B088F8502C9C@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 2: Mandatory to Implement, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:36:01 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ISSUE 2: Mandatory to Implement STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00307.html http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00333.html http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00334.html DESCRIPTION: For which zones is the automated trust anchor rollover mechanism "mandatory-to-implement"? Possible answers: root zone; root and "public" zones; all zones -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:39:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt3p-0000xo-HD for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:39:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt3p-0000YI-8v for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:39:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt1v-000Jmz-Az for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:37:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt1u-000Jml-LP for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:37:46 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37Fb309014761 for ; Fri, 7 Apr 2006 11:37:03 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAAIWaOZC; Fri, 7 Apr 06 11:36:57 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 3: presentation flaws, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:37:40 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ISSUE 3: Requirements draft has presentation flaws STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html DESCRIPTION: There was some concern expressed in the mailing list that the WG submission contradicted itself on some places. In order that this document express a clear set of requirements, there needs to be a clear statement from the Working Group about what these presentation flaws are and how they may be corrected. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:40:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt4x-0001Xb-63 for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:40:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt4v-0000Zo-Tk for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:40:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt3M-000Jya-So for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:39:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt3M-000JyN-7J for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:39:16 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37FcWrF015001 for ; Fri, 7 Apr 2006 11:38:32 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3iaOrD; Fri, 7 Apr 06 11:38:29 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C96E235-28D9-4F1E-902E-96A186D2DF65@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 4: Key "lifetimes", was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:39:11 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 ISSUE 4: Requirements draft does not explicitly mention advertising key "lifetimes" STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html DESCRIPTION: Keys don't have lifetimes; however, is this concept useful in the context of trust anchor rollover solutions? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:42:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt6A-0002Ul-4g for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:42:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt69-0000db-SK for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:42:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt4s-000KEX-En for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:40:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt4r-000KEG-Rj for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:40:50 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37Fe6iU015229 for ; Fri, 7 Apr 2006 11:40:06 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAAz6aaUD; Fri, 7 Apr 06 11:40:02 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <91652889-221F-47E3-9E9C-0ABC482A290F@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 5: Embedded requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:40:44 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ISSUE 5: WG submission has embedded requirements in definitions STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00206.html http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00228.html DESCRIPTION: Added the following text to the "Timeliness" requirement: Operators of security-aware resolvers using RR(s) from that zone as Trust Anchors need to acquire new and remove revoked Trust Anchors such that no old key is used for long after revocation. Added the following text to the "Scalability" requirement: The automated Trust Anchor Rollover solution MUST be able to support Trust Anchors for multiple zones and multiple Trust Anchors for each DNS zone. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:43:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt7M-0002nO-CO for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:43:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt7M-0000f7-40 for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:43:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt6F-000KS4-CS for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:42:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt6E-000KRk-OK for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:42:14 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37FfVsk015534 for ; Fri, 7 Apr 2006 11:41:31 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAAV2aauE; Fri, 7 Apr 06 11:41:24 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B248C8B-4AC2-48DB-8143-4FB4A1B70D08@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 6: Requirements in draft-moreau-dnsext-tak-req-00, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:42:06 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 ISSUE 6: draft-moreau-dnsext-tak-req-00 has other useful requirements STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html DESCRIPTION: Added the following requirement: 5.11. Non-degrading Trust The method or methods used for Trust Anchor Distribution MUST be deemed sufficiently trustworthy by the operator of the security- aware resolver to ensure source authenticity and integrity of the new RR (s) to maintain the Initial Trust Relationship required to designate those RR(s) as Trust Anchor(s). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:45:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRt90-0003Hk-TM for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:45:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRt90-0000j2-KZ for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:45:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt7r-000Kfy-KF for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:43:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRt7q-000Kfg-Uc for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:43:55 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37FhBTG015847 for ; Fri, 7 Apr 2006 11:43:11 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQvay7E; Fri, 7 Apr 06 11:43:04 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A795F6F-2F64-4A84-B93C-1195FFB12A62@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 7: New requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 11:43:47 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 ISSUE 7: Text for new requirements STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00233.html http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00530.html http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00539.html DESCRIPTION: Added the following requirements based on inputs received: 5.12. Support for graceful consolidation of islands-of-trust The automated Trust Anchor Rollover solution MUST allow a zone to gracefully transition from an island-of-trust to a chain from its parent. 5.13. Time Delay In order to limit the damage that can be caused by an attacker using a compromised key, the automated Trust Anchor Rollover solution MUST NOT allow trust anchors in security-aware resolvers to be replaced instantly. This feature MUST NOT prevent instant invalidation of trust anchors that are known to be non-trustworthy. 5.14. DNS Response Size If the solution is implemented using the DNS, the queries and answers involved in the key rollover solution for a normal case scenario MUST fit in the upper UDP limit of EDNS0 (4096 bytes). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 11:51:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtFX-0007f3-9A for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:51:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtFV-00014s-RG for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 11:51:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtDl-000LWL-1M for namedroppers-data@psg.com; Fri, 07 Apr 2006 15:50:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtDk-000LVe-7M for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 15:50:00 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 5DD415682F; Fri, 7 Apr 2006 08:49:59 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060407114807.03dc2c38@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 07 Apr 2006 11:51:31 -0400 To: "Olaf M. Kolkman" , Namedroppers From: Mike StJohns Subject: Re: Continuing the work on key-rollover In-Reply-To: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> References: <1872072C-2972-4232-A7D7-C9AF5E9DFC3A@NLnetLabs.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 At 03:56 AM 3/30/2006, Olaf M. Kolkman wrote: >[*] Somebody told me that they would like to see the ability to add >a 'time-delay' as a property of the rollover scheme. To paraphrase: >That way one cannot compromise the system and immediately run with >it. A mala-fide roller will have to sit on the compromised system for >a while before it can be abused. (I can't recall who mentioned this >but if somebody supports this requirement, please speak up). Might have been me... this was one of the things I considered in my draft. I'd probably restate this as "protection against N-1 compromise". E.g. you can recover as long as at least one key is not compromised. The time-delay in my draft was a derivative from this - a specific mechanism rather than a base requirement. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 12:07:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtUq-0000tp-Oh for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 12:07:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtUp-0001oH-Fc for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 12:07:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtSw-000My6-Fk for namedroppers-data@psg.com; Fri, 07 Apr 2006 16:05:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtSv-000Mxp-Kh for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 16:05:41 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id A5F7F5682F; Fri, 7 Apr 2006 09:05:40 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060407120342.03bb05b8@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 07 Apr 2006 12:07:12 -0400 To: Suresh Krishnaswamy , Namedroppers From: Mike StJohns Subject: Re: ISSUE 2: Mandatory to Implement, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 In-Reply-To: <329E8F22-900E-41F9-898B-B088F8502C9C@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <329E8F22-900E-41F9-898B-B088F8502C9C@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Having it phrased this way makes it a nonsensical requirement. Mandatory to implement is a product requirement not a zone requirement. The text that goes into the standards document should be something like: "Any compliant resolver MUST implement the key rollover mechanism for trust anchors. A compliant resolver MAY, subject to configuration, decline to update its trust anchors for any given trust point using this mechanism." At 11:36 AM 4/7/2006, Suresh Krishnaswamy wrote: >ISSUE 2: Mandatory to Implement > >STATUS: OPEN > >REFERENCE: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00307.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00333.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00334.html > >DESCRIPTION: > > For which zones is the automated trust anchor rollover mechanism > "mandatory-to-implement"? > Possible answers: root zone; root and "public" zones; all zones > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 12:11:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtYn-0001Qq-SB for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 12:11:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtYn-00026E-Jp for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 12:11:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtX0-000NLR-N2 for namedroppers-data@psg.com; Fri, 07 Apr 2006 16:09:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtX0-000NLF-5o for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 16:09:54 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 637F256835; Fri, 7 Apr 2006 09:09:53 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060407120752.03d2b5d0@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 07 Apr 2006 12:11:25 -0400 To: Suresh Krishnaswamy , Namedroppers From: Mike StJohns Subject: Re: ISSUE 4: Key "lifetimes", was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 In-Reply-To: <0C96E235-28D9-4F1E-902E-96A186D2DF65@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <0C96E235-28D9-4F1E-902E-96A186D2DF65@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Keys don't have lifetimes, signatures do. Any given key in the DNS should last until its superceded or revoked. Anything else would be a base change to the protocol (and orthogonal to the concept of key rollover) Which in turn implies that the rollover document doesn't need to/shouldn't deal with this concept. At 11:39 AM 4/7/2006, Suresh Krishnaswamy wrote: >ISSUE 4: Requirements draft does not explicitly mention advertising >key "lifetimes" > >STATUS: OPEN > >REFERENCE: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html > > >DESCRIPTION: > > Keys don't have lifetimes; however, is this concept useful in the > context of trust anchor rollover solutions? > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 12:25:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRtm1-0004ty-Bm for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 12:25:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRtm1-0002fc-2T for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 12:25:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtk3-000OUo-TV for namedroppers-data@psg.com; Fri, 07 Apr 2006 16:23:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRtk2-000OUU-SM for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 16:23:22 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id CCF8E56848; Fri, 7 Apr 2006 09:23:21 -0700 (PDT) (envelope-from Mike.StJohns@nominum.com) Message-Id: <7.0.1.0.2.20060407121736.03de9950@nominum.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 07 Apr 2006 12:24:53 -0400 To: Suresh Krishnaswamy , Namedroppers From: Mike StJohns Subject: Re: ISSUE 7: New requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 In-Reply-To: <9A795F6F-2F64-4A84-B93C-1195FFB12A62@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <9A795F6F-2F64-4A84-B93C-1195FFB12A62@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 At 11:43 AM 4/7/2006, Suresh Krishnaswamy wrote: >ISSUE 7: Text for new requirements > >STATUS: OPEN > >REFERENCE: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00233.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00530.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00539.html > >DESCRIPTION: > > Added the following requirements based on inputs received: > > 5.12. Support for graceful consolidation of islands-of-trust > > The automated Trust Anchor Rollover solution MUST allow a zone to > gracefully transition from an island-of-trust to a chain from its > parent. I'm trying to figure out if this is a valid requirement or moot. Here's the deal. If an island of trust (IOT)chains to a superior trust anchor, I *think* data validates if it chains either to the IOT trust anchor or to the superior trust anchor. (E.g. I start with a nominum.com trust anchor and later add a .com trust anchor and stop signing stuff with my nominum.com key - I think this just works). It may be better to restate this as requiring a method to delete an embedded trust point (e.g. all the trust anchors at nominum.com that were previously configured in end resolvers). > 5.13. Time Delay > > In order to limit the damage that can be caused by an attacker > using a compromised key, the automated Trust Anchor Rollover > solution MUST NOT allow trust anchors in security-aware > resolvers to be replaced instantly. This feature MUST NOT prevent > instant invalidation of trust anchors that are known to be > non-trustworthy. change "replaced" to "added". We need to talk about "replacement" as the two separate actions "add" and "revoke" since these two actions will generally be separated in time. > 5.14. DNS Response Size > > If the solution is implemented using the DNS, the queries > and answers involved in the key rollover solution for a > normal case scenario MUST fit in the upper UDP limit of > EDNS0 (4096 bytes). This bothers me. I don't think this is a requirement we can or should enforce. I think this translates to "DNSSEC can't use TCP" in some ways. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From otto.janda@yemendir.com Fri Apr 07 14:14:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvU0-000552-LS for dnsext-archive@ietf.org; Fri, 07 Apr 2006 14:14:56 -0400 Received: from mue-88-130-110-057.dsl.tropolys.de ([88.130.110.57] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRvTv-00005c-4Z for dnsext-archive@ietf.org; Fri, 07 Apr 2006 14:14:56 -0400 Message-ID: <000001c65a99$33ab5380$0100007f@localhost> From: "[%from_name%]" <[%from_email%]> To: <[%to%]> Subject: Photoshop, Windows, Office Date: Fri, 07 Apr 2006 20:14:19 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0001_01C65A99.33AB5380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C65A99.33AB5380 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C65A99.33AB5380" ------=_NextPart_001_000E_01C65A99.33AB5380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable By the time Scarlett had undressed and blown out the candle, her plan for tomorrow had worked itself out in every detail. It was a ------=_NextPart_001_000E_01C65A99.33AB5380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software






------=_NextPart_001_000E_01C65A99.33AB5380-- ------=_NextPart_000_0001_01C65A99.33AB5380 Content-Type: image/gif; name="Lf.gif" Content-Transfer-Encoding: base64 Content-ID: <000801c63b06$0762dd00$0403a8c0@mlto> R0lGODlhmwBtAaIAAO3uygAzmQAAZv///8xmAAAAAAAAAAAAACH5BAAAAAAALAAAAACbAG0B AAP/OKrS/jDKSau9OOtNlx9cKI5kaXbeqa5sSy5uLM8yQ994noF67/+jD+/jIEpsDRiEl0ym BLYoE0pMCakPI3UKLDKRUmdEiUWKm9jscD2emsFubrS7/NrPZq8+r2TXy1xngmmEhYZ0gnB4 gYQMfGVOZI4geYNvd16SlV2Ki2R/Yo9bg5GlbWqoloyHQJ1pm6mAS3qsYUdxsZezrD+XmhVP o7toWq+rcK5VwZ+Izc7P0NHS09TV1tfY2dozAN3e3+Dh4uPk5ebn6Onq6+zeQu/w8fLz9PX2 9/j59936/f7/AAMKFMJvoMGDCBPmK6iwocOHAxlCnEixIjyJCglo1LiA/4AHjx82huTYEaSC jSQ7fiwp8iRIkjBNQsSIMGVMlR9f5pSZckDPnDhtvhzqsihFmgeFutQJdKRPkz1/sjxp9GlJ q0qPAniY1SNHmUuBZl3606vXqkq/QgXrEKnBrmHfCW1p9arcuGNb0pXa0O1AuFWp1u3Kk63g wWub8tUKESXUlSMTG3X8lO5hnyzLErU70a/Fz6APeg5NuvTCraZTqz7drrXr17Bjy55Nu7bt 27hz697Nu7fv38CDCx9OvLjx48iTK1/OvLnz5gECdIv+vPo6AeyiS/e2HUD37uq0gw9PnXv5 6ee9p2fuYN137vBfv3cff779+M+xpxsvXbx47//mbaedOPcJuF44AtaH34LN6YcOf9Phl6CE CNY3IYDjzIehhupZB4CD50CI4YgXqjcgOP9FqOKIKH5z34oMskffihqWOF6LOJJIYI4X9pjf A+SBV2OA6B14o5AHmnjeiUW6mKSHUEapnH9UVmnllVhmqeWW/knp5ZdghinmmGSWaeaZaKap 5ppstunmm3DGKeecdNZp5514knljjO3sGZufzrUXXobkAJohk4byWehsTKL45DkOglhOfzsS OuOGD14qX4zSDcBia5IuiuSSpKbXKIVKOmlgeY2emGKTRe7JIY2whWoppiq+iOunOvaqq660 +srnq6iCGiSrCuZq4an/qQb7q4RDCgtjhS16mig5ti6q7La7lkiti8l2y6CP0vJa7KzpQBAi jq8i2iqzR0KLJKwmnluqn6aqmidx1zLH5b8AByzwwAT3u+/BCCes8MIMN+zwwxBHLPHEFFds 8cUYZ6xxjhsLuq6zmTK6rKzMQhlpyL3uR9uzPJKZbYWU2vduqfbKmnK8yq5aXQODxhwuuQXu emvKqCI7rYyZ+swt0ApSih6h35XcbrHKnawyjEwvDR/O4HJbaddEV83zoFgH22y9WxP5rbcc Y/3oxhgXLPfccsNt991456333nz37fffgAcu+OCEF74voAav/ObLX7cNtqaQDx2gkSXvNnbS /407vm7ij2vrOdW8Ycd4i6NGbfqoUOvrtLumslq5zTnTK5t+oxf9M8hHA2u0uOxO+rWBZsem bogpsiwzvMWDzXKziB+6JOizX8278b57HS31knMKvfAo58r65KqKuCyLrJdu3rfou8254R7S 7f778GfJ/vz012///fjnr//+/Pfv//8ADE7i1vew4ZmjSwOcVNSCpzbZwUtKtWtbAgu1wLCV i1xPixKQukei1q3KZkoDUKKypiMCHieCyeud8mAmws6t7XZCgyAHT3c+BuLqPc2znfcqh7QP zZCBGExWEMcFQ0UF6nIH5JGrnpc7FfKqSw40UgAPF78qzm2KWMyiFv+3yMUuevGLYAyjGMdI xs9pDInEM2HueNga/rxtZ9kxYhJbJptWyTFQcSTQ83TWxKbRC11HC6R1NvgxOu6ObULKYNdC qDk1FsdqczTk5BC5yPBFyGnpM5fJvBHBC9qQa9EqoRkdeUI0HtCDC0qhJVOJKHNBEYplZJMV ZwmwWNrylrjMpS53ycte+vKXwAwmngxYPU1qLnJ0zGSfUNlAWL4GhWzLXBwNRUrpkTCarulk CFv5ynulLlbgnJA4W0ijt10TnNzDHNAwOERPSkucJPTc8u5ojk5u6Jy4e6IqszZOsz0qkVo7 ZrrINr1zfRKGNVqe+DqHPWNC6lKmY+UfiQj/roR2MFzMSxIsZ6YvYbqGliANKcE8StKSmvSk KE2pSlfK0pb6rZoH81gkgWVG2HC0gWhD0BuBA8liArKmH0VoEbc3nJ76bpvoTGory0nNfHJt WHvsVlRBZUpRkbOgAVXata4nUT1er58yyyYnVYZUdwatgo2bpyB3eEi2YhMdRvVpJbNKoadS FKtPxKjbtPfMqspzrh2kWdpkN0mc3lSn5iNfYmH6S5E69rHyc6lkJ0vZylr2spjNrGY9ytg1 7bQdMi1kDPeDVkbBzoLIrGZcv+lQ4tVQZLf6qfRcyI7V7uhXzKzoVZcaUWXqFpM57ZHrqNMf YoE2tLH1mnJ/m9fR/x7pdS2EXT+lulbQPiiFNFTkXLMrXCkG0meLdas/aaNNIQKRWtNFK7p+ yiGL9hG1tS2vbgPLRwmCj5Ua/ee43LXK9nbWS/+NE2QHTODNGvjACE6wghfM4AY7WE45DGpr 5SQp5CoqwqSdrmiLmUfaCg+JqwWuEQlIUw6b+Lqoyw2IQqxYwZ4tp5K8GXEHtLrh1lfE773N iscaY7y28516LW1A75m9AH9jx90I1SuFKt4X8q5DwdunXl1oZB4n2co69HF1gTwtdhbxrXad jQGRK6J2efO+He1ufTuUWCgv1VFLZONlCUxnKz74znjOs573zGeX+hVS9vyShUt5HdpVOP/Q R7wyewI9tj+77NCXI2SSgeSxDfLs0qEdXqNXTIFJT9rRPzK0pzd9ZFF/SHSiloCnOZlqU7N6 1Zg+tZkwTWliklrWpI60rU0taVi3+tSDhiOuDz2OW8d62K8Wh7GRu2xZJ1vQuhbUrn39aVcD G8SS9qumUX1t9oH6f9/u856DDcBwP9t+5l61xNRVaWlbutXtIWStt43sdzubTc0utbOPfWt9 o7HZqh42uR9N7WtzG9n7jlStwQFwhS8cTg0f9a8TTu1/8/rg91a3m/LN7ou7m9XujrbBM95x cZv85ChPucpXznLAfRZipNqyhCf8sJjvRrYSAy9TyXnYODuzYjqtF1pbP6VWi4G1bP7kqsxr vi0bgQ6fGSszkVIM4zdDueUCrDOVsM71rnv962APu9jHTvY/vXzmeMP5n/aGsw9W/czFy23O mehlJ9a9ygJues2uqUqKufdmTj3oxU4VSu5CS6lnbxje86b1yJb98ZCPvOQnT/nKWz6SvjUc voCqeVdyvnDANXN2Cdu3hkL9pVI2q3H5Zvp8Bq7M30vqiy+vG5HS/va4z73ud2+bBAAAOw== ------=_NextPart_000_0001_01C65A99.33AB5380 Content-Type: image/gif; name="MW.gif" Content-Transfer-Encoding: base64 Content-ID: <000b01c63b06$076ec3e0$0403a8c0@mlto> R0lGODlhNgFWAKIAAP//////zP/MmcxmM5lmM5kAAAAAAAAAACH5BAAAAAAALAAAAAA2AVYA AAP/CLrc/jDKSau9OOvNu/9gqBiGKJKkyaQbq74whpavGwO2vbL6bfUSnZAGrBR9I9ouOTs2 UaBjVHnLAaFIzjCyXX6kvh6PiiMvuh1wdrozz9YtslNOZ8Md1rPbXMbzL2p3WlQlQn2HTGNM eliMQ41lWE8PLm9JepeWbYWEmoiflZ5+l5gNV3ukjU2bnZCRVqqteaKvnSugnKSIKbySSqGl u7ZeEJUjwWO/w5HIysSHwMVEy8HPqZyKup/CzbrZ3Iva0aDe19qMpnXb5+Pn6ebgXfLq4PUU omJ8+eHV9vOU+qa92zZHHLxsp0Z5wUcPjTRouUr9W9hw2jdaAB2uY+ds/2A3R6tepZsokV6i bzgwdUTZj6CyWB41jiKEi6NNlxKP4XI1EFbIjD/XocnDxdNPlkg7wtMp8mBAhf0sDTUJdBPF nuocSuXZFKC4P16LQvVGTdojgTjTkkxZDeFTj+4gxqSasQ3Wu1efbS0YliwgsEIrWhOrMOnN tdQuOkvot3HNwWMPC+bX7uvcviX/Bnn7uC1auUvHIUYJmPRWs2fpuMrH15phRzsZuws6mOXm 20DpTgLJyjOkqVBsCxpOvLjx48iTK1/OvLnz59CjS59Ovbr169iza98+QEF3AN/Dex8Pnrz4 8ujPqzfPPn3789vjy78xYECA+vft49+vf4AA/v/5BQjggP3l91+BBB4oYH/zNeigCPYJEICE EwZQoYQUZljhhRxiaKGHIH64YYgkiujhhd89qOKKFvg3oogbdmjhiybWGGOIMtKIY4n3segg YGkMxxUD9k1IQAH/EfBfAQQoWYB/TwqA5JEE+DcAk/YVoGWEATS55H1MKnkkkxOGKSGSXVJZ ppgEfJiij/IBSVhLa9AEAZdUSmmkABKyKeZ9SloYKIaDTnhlmnyiiSiSen5oQJlnCorkAIH2 COd8cj4EWRZ2OuBin01SumSTaTZpqgCm+nckl1GKiCSalFaJapVtCmCAkmcm2SeUqaJ4aZzM MMWWKcMWwpQmERkVSyj/vfRwX4WxHgmpfloGgCWiFA5gAKEnomrrhFK6SOm2hBZQ5rmidhmt m7/G+Yuw+hTLFhG37FKvG/UOq28DeDrJpodkFvAoqi5WKKu1tRrMJKiEVmkuhmhua22iueZp aLvxdUovJcdsvDGxZ9yLR76d8otim2TaKq2UYqJJJZtoeqthuODeai6lE1Oa8sPrEkxzthhr p7GwIntMNLwkGxMy0nfqCKOGTkcN9dRPV/0i1f8FEHR2Q++7tLzzcvy11x+DffQCn8pY4tpq t832225DuzXX+W507NJl5123Tl2f7R2CgC8oOIGDB0744Ya/OTd1tDkh9kvvWpWI5ET30F2P /5hfrjkAltpXXuacbw565lqLN7roqIdO3uKYsu7669FlCvvstMcge+2456777rz37vvvsd8u g/DAF//cPnPWAlYgXzALOWx+OG/87MzrpVRxxhobMk0l66u939O3i3wt5MeTi/OQl1WM1x3f 0j33e4cfNPLjmx/cZ718NMH3xMI/tvcAlN/i6KeVlQxjfNVDB8f8Vzn3xU+Av0IgTEByPds8 gXgXzKAGN8hB4kFwO/ULFlHgYkEPLpBkDvwfA9n3QR+FEDRxIQowRJOp7I1thXJIIfhaqKIL QuQ3whnhUZRlhJSUDYDv0yELechEISXDF9I71rJM2MQqmoCKVsyiFv+3yMUuevGLYAyjGMdI xjKa8YxohE4CPVCANBaPNj+AI51i0EY3+q4yRrhecbTExwdoiQF8/CMEAllHBRCykHZkDkkU kT9zNLJ8kLRbA/5YR0QCoI+GLKQgJ6nJTiZSOou0yCOfmKzFKCUQlPTjJT2ZST+ycpWfDB5e YGi+vBBjjavc5AIq+Upd7rKXgYxlc0L5FWQdcA9ypAAhd/nLZrbSAZv05TOFmRxidsZ6s8Ei JwV5SG4u05XBhKYlqWkcGoZjhNjkhjkv0EZpSnOaEfCmM8lZTYaUEjJCNCYQK1BJWHLSlYAc ZzRfSU8wfvOfv/TlQBUazoKOcZwOjSgHICr/0Ypa9KIYzahGN8rRjnr0ow6iaHNEagKSghGd GUjmcChqyYM2VJy6PCg0B+nShmLSkJNMI0o1ExdB1LSlM2VmUHFKVAmYVKiXHGo/h2pG00wQ hujTX1BQmVRVApKpEEWkJpXJz6vmFKcsdSMRQ2OR/eHvrHPMaVi9ytaqfrWoJj1qUd2K1HbG U6yToSEQT0PWDbyTrrncKlLb2sm/yrWlN81lUhM716bmVY8iPGVElEdFxgLWq1q1amM3e1nN MhWsg+3sGKfSmGiYE49+baxIl8rZzH6Ws2/1LGhVi9fL/LC0FcxnWoMK1MGy1q2CJaprYzvI 2PY2uLAVI2tgIYy9L+51JDsFZ0xtmtiXarW6lg3ta19KV8bKFaTG+e4eVwpe6Yh3vHA4b3l/ p97UojEBADs= ------=_NextPart_000_0001_01C65A99.33AB5380 Content-Type: image/gif; name="A.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c63b06$077134e0$0403a8c0@mlto> R0lGODlh9QBXAKIAAP//////zP/MmcxmM5lmM5kAAAAAAAAAACH5BAAAAAAALAAAAAD1AFcA AAP/CLrcbsZJKKu9i+LNr+5gKI5kyXxetKEm5Lqnas4KS2Mvm8vAbtm2zGs1rAQfvF+ypJMd OU9Q9CbkfVAa7LK2PF63wjBy2gM3yNCuCm00S91U7nmdzNa3QPy9PR/rKVowYUUxghNqcoRV gYY5c40RilyGZWVPUWxyhzF8nJueYk1VYpWTpKWofaqQoFqqqF+mmrNfTmCYmV5Wt3ufp6Wu nqKpwL2vob3DqcNBzMnGoG2Uvp+X0NHLu792q887eq/O4drC0+Llx7/Sujh0KaPU2a3P3fVp Ptvu89i1sej/6oi1Q9Ru1jqBBrPhI8YNoCY2uOyRCpavITKJCTMWxKYk/5NGhraQJLT4kF6a dw5hkQtIshhGhCBHriTikaKyPBP9qQx5qpmbmzxl5ry4j5bOMQ4pdsilTCVHRgpdSbI0LWC+ Qnn63WEVzdGgqn4YiZ2a7pDPRx7jqF3LlkbatnDjyp1LF+7bunjz6t1L9y7fv4ADCx5MuLBh AAMUJEasuDHjx4sjO5YMebLlypgpaz7MuTOGAQMCgBY9QMDo06FRmy6NmvRq0q5Vt56duvZr 0Ks96969ILSAAAF+Axf+m/jw4MeRF0eunLnx586bQ28efDHv64Z9H18uvbv35dyNRwe/PTl1 8r+tY68Lx62HEtoJFDBNwHQBAgQCFCi9X8B8+f8EpHZfaAXcl99v+NlnH34ByHdfcAZCWJ18 vt0nAIPpradXezi89wN8yFHoX3D1kTgAfvXld2Jx9S0X4HIDFNDggSXS5599xxnw23w3Nvif duppOBeHHhpRZAilhZhgfTEyiOKTF+IXGoUAQBjefwIsmN+TwRlQ43wnkpjlk9qZJiR7lmRw wodb9aMmJWQhJtyTMvpX2pgyFjhliwj212CZM8qIGJOBJnnhfPqJqR+BJ2Io2pnsOVHDmkZa QamlsEyqpgOGrmiho/oZEKqJ4GHY4nEAFoeojXVKKICoN74qJoDIBQlpW5j2oOkEm+q6KabA UspAaEr62KV8JKZYIn7/DzKr6oHKGeAbgDIGGICOJ1qoX3oDjslfjY/eGleua3y4a7C/XupV A4YmF5678EYnr3j0xlvvvOGKa5ew5a4jaboAawqHaN2hV/DBBieM8MIJ26pvHLnC5GvAWVxq ca/D1gYbbRtrzPHHHofc8ci0PWyXJJecMYotWmElQWKPhhsaYzHDbHOVN9eM8846V6bzzznb HMBjJuNFZNFIJ82E0kw3fcPRTkct9dRUV2311VhnrfXWXHfdmV8beS12CwR1MglYH60FiSCE kNU22mNT8ZZNULMVia91rBnxxLruHTfEZTvilT+ARMJyy1apvLeli+st7N9q4SQQ3WcbbpRT /2k7vivGd2PMd+ebQy43QeasRFJLmIewdsWJbKN56KK7FThXlQflElpw+/vN7rz3/k3sgItU iEFnEcURCaB7znfojD8O/AySJwWO8YUPtULfD2Sv8uPJ1/287pZTtYs+xyAu/vHZ3928wMqv D/v3wK8Ojyznyg///e/jr//+/Pfv//8ADKAAB0jAAhrwgHIBmwgKgMDCrEt1DyxLXBjYQMEc ZSm2+0uBNtiADVJQAR78oANCyIAQitCA53BJ9UpSCfM9EA0FAgAFPxjDDtLwhCC84QJqWEGh YE5wPAHi5XQCQwaekIcl1OEIlShDHCIwhacLIjmi9xYP2tCKOdyhE/95yEUsNhCK5BOf7VD3 uxGQMIto7KIE1LjECoKReNNjoQRJgEU2NtGLV+RgG90YFDuEsXhybGEfoWbEGTIxiRuooR2/ iLIVKqUnh4sk+joIwiai0ZI2RGQmL4nEHjbtjDnUYyiPeMNOgtKTUnMiKg2oylW68pWwjKUs Z0nLWtrylp1ppWF0GQde7uaREMxdXnAISjziMY9JFOUILWBMZTqTkrcCJgYTh5diLnOHlcTm NbMpw0Qys4Tc7KY4xblFcUWRdhZx4SDhxCEjblOb2RRhOeHpy1bKM5wzxKYqfakbRRBOinBI J/kuWAF3QvOb40woPMfJS13eM6H5rKQ99QWmlMtVDisCtegCialMeoLznaXcJwaaiUQOFpKY FDVGRh+h0RWK0XuhLKgmtdhRfK7xpgiN50fBScODQqqiP5TiUAhKx3B69ALzNKpSFerTiCrV oArlp2eA6keLHoWd1uNARB/a0J1ydadgBalNP9rTsAopK4HYyViGh9FJJrOkojQhTZvqzJou dIlwNWUyfYpLme5Gqr3s60ivA1gaFFawujlsUcWVAAA7 ------=_NextPart_000_0001_01C65A99.33AB5380 Content-Type: image/gif; name="MO.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c63b06$076ec3e0$0403a8c0@mlto> R0lGODlhbQFWAKIAAP//////mcyZZsxmM5kAAAAAAP//zAAAACH5BAAAAAAALAAAAABtAVYA AAP/CLrcWsXJSasFEN7NcnwZ9nFkuXnmOaacxjauK8lvbU90F693n7cengi2+tWCoZuxB2JW jMjk7LMcOhdIR1CL0nWx0OqVlRNLRUWeWKkWmtbjeJNbCsuJuvx8L6P5f193R21PQn94goBu JHCCTnaMbo02ZVSEVmB7fJgPVn9JOyNbXpVno1mIdGihO6RpZ6mZnn2BoyCwtquir4eBt4eq FCituhGfvbAWxLKVwqKcGsu0Q13TfLuympyxetvAmNKLik3V2NnX2eHo1+br29qpoO3g7VKT s4jNUx2b+O9o3JZ1cwfvXDd9cyAZhBcq4Dx9CvVAvLTvX5R5/qBZykex/5BBgd5wJdyYcaA2 Vg4/LvpHLxbIX7lULkR47BSumydJqixXsefIcyCDrgR6CaHLTOZevqP5hSk3k+k6Kp10EarT ha6y/pRIEVjElC2ZFe3oM2ROZ1jAWJtqiCzPg2ShEtRYkOrQcXDlEilFciLHv8ECZ/Q69qnV wnrBDST21ayqq1hnpnGpM7FhyfEmq6go9KzjxjLDbhV72SJi0gcX65ym0JrobwXVejH5ba3m 0qaJUl5nO2roT3Xv7lp927XRxK5f38bgUaM8HL5iSm9bBRXt5bms414ynUut7/Z4LacXgm0U UiWHib8+5bxaRTd9OZpPv779+/jz69/Pv7////8ABijggAQWaOCBCCao4IIMNujggxBGSMEA ClAIgIUYVqjhhRtmyOGHHobY4YggkuihhCimqGIJAwxgQIsvugjjjDIOEACNMeaI4441xnhj jzz+qGONKxZp5JELuBiAAUsyaYCTSzYppZNQVhnlk1dmiSWVWna55ZVQWojkmGQ2aCOXW1Jp 5ZNofummmlqu2WacXr5Y5p39DXVEfsk04CKTAxAQgAA2CkAAATYSIIChiwoaqKKDHiqAAYcq 6mSLkRpgKKI3Hqqkp0sKqmmgnxKQI6B4pqqfnmhZlgg/Eyj5IqKGamrqkgMQSmuNTVoaZa5Q 1opprU9iKiixTN4qaAD/plKqKKbFqiqtfaxCh9uraUlwJq6BGhopjS2G22munU4aqgBTCmqp oeSGq6yNoUZ6LrPhynrjtPi+ag+sMDDXCRXvpYVSwL8ELN+Fl7pr66K2mippjAzPai6wUuZ6 K6OTPoruqMraCuikihYAI6r5ljxGH51k2+8zAPubMsrZGsJvERMmHIDI8jp5qLOAnmkzpeZe yqmtv1oMpahIB8Dsuez+avLTTND8Mg7/Tu0yv1e3jPUzKvsZZqKmbvpup7iCqnGyGzvJKJNi 56jopp+y/fCN6CJKpZhQ5/3GzClrUbW/Wm89M8x9S63tnGlOifjiijee+ONoOn6v3pTXwffV /5cD3rfgXVtdONZ+ein6mqOXTvrppl+Jd+WsC7P1SlxrnvXmhsecOeYM8Djk7rr3DuTvvAPv e+vEO4MT1X673NRew/EC+g8ilih99NSbaP30159Y/PbKcO/99ylWC/745Jdv/vnop6/++uy3 7/778MfP4D11iC///UjiZe171dk/SPOWkEcYaEE//KmvgHSJDbWYE7jNzU5wtTMg/vS3BZuQ JhoA5J+r/uZAzEWQZhGUoPzwor+wVJA4yjmB8pLHua4ZA3QijB8JjdIb1OTlDQRkReDUwI8Q xvB9FAyPKx5SGZgU8CJITKISq/LDEbZlL5qIyEsQOAPcyeyDPYRhE//bV8LR5MaGGPTNBV4o s5U9L4ud2yIXs6DD2XyRHTkcD9XIiEYOerCOuFOjHh0UnhwSTHl99N8eBykgQRLykIhMpCIX ychGOvKRkIykJCdJyUpaUpFUZAEBLsnImADhYAqMwyY5mcjkACEy96nUoRqgSgaocpQSeKUr ZUlKqPnlJ2HEpTEyCJMNAmCVo4TlKlkpTFjOcgHD/KUxa2nL07TRNuVBoXGqBUxixrKY10Qm Npmpt1umJymaCWIKWjlLcipTm9lUQDJpyc2SeVMg1iGMd0BpAXauM5jbtKY6l7nPdrrTmZWR YhFZMs5K9fOgyjQnMRWKTn/ma5q3iKIkwon/DYiSYJPDvGc6K5DRfDp0WtPZpUR9EkcNotKV 6jynSlfaUIS2VKMfjek+DapNms50mfdM5k35KVOH8rSnQK3PT4NK1KIa9ahITapSl8rUpjp1 qUMVUFSdMNWnJpAM9MTPUI2pUIaWk6teRSYFzPnKYnKVlVZtTijVmkmqMnSdKP1lXNEq1pTW c6xzjasw7UrXtHJmPbypR1MEawpqytUBGK2rXc+K2LlWdat55etef1rVp34HjAFUBgpTeIHE 0nWvdWVsXw9L2glEVbSKnSxe/bo/MU6zsG8ZjCFZSlqwwlWxeTUrZetpU9wmVK695StrwSJb 77gjl8WY7W93Ws3QgUZWuDyNLkcju1vQ+na4nimuCQUrGhsEs7HQDS94hXvd0o63tJC1Lnmx 6xh/PGc0wBEjQcHLT/V+N7W4ve96zTta1OrVt5V1KnyAU1L+vYJ5crxmcKHb265+9cGm5Whw pVvT0bJXWgHeT4aZsOELq6jD+QHxC0Ts4R+SuAQnLmoCAAA7 ------=_NextPart_000_0001_01C65A99.33AB5380-- From owner-namedroppers@ops.ietf.org Fri Apr 07 14:22:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvaq-0001W3-RA for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 14:22:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvap-0000Ge-Hp for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 14:22:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRvXd-0007gv-9Z for namedroppers-data@psg.com; Fri, 07 Apr 2006 18:18:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRvXc-0007ge-AV for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 18:18:40 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k37IHt52011949 for ; Fri, 7 Apr 2006 14:17:55 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAABgayux; Fri, 7 Apr 06 14:17:49 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <15212CDA-534C-4E2F-80EC-06C333036162@tislabs.com> Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: ISSUE 8: Wording in existing requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 14:18:31 -0400 To: Namedroppers X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ISSUE 8: Wording in some existing requirements needs to be changed STATUS: OPEN REFERENCE: http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00203.html DESCRIPTION: Requirement 5.5 currently states that "the solution MUST support rollover for security-aware resolvers that have been disconnected from the network for up to twelve months." There is disagreement over the choice of twelve months as the disconnection period that MUST be supported. Is there a better value? If not, is there any benefit for the resolver to support the ability to buffer some amount of outage, and if so, can this be stated more generically as a requirement? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 07 14:54:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRw6G-0001hF-Hu for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 14:54:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRw6F-0001Id-6a for dnsext-archive@lists.ietf.org; Fri, 07 Apr 2006 14:54:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRw41-000AKl-8D for namedroppers-data@psg.com; Fri, 07 Apr 2006 18:52:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRw3z-000AKT-GY for namedroppers@ops.ietf.org; Fri, 07 Apr 2006 18:52:07 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k37Iq1aB016063 for ; Fri, 7 Apr 2006 14:52:02 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k37IpY3J003756 for ; Fri, 7 Apr 2006 14:51:35 -0400 (EDT) From: "Scott Rose" To: "Namedroppers" Subject: RE: ISSUE 4: Key "lifetimes", was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Fri, 7 Apr 2006 14:51:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <7.0.1.0.2.20060407120752.03d2b5d0@nominum.com> Importance: Normal X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Mike StJohns I agree with Mike. Key operational periods are more policy issues, not protocol issues. There would be no way of expressing this lifetime in the DNSKEY record. I don't support this requirement. Scott > > > Keys don't have lifetimes, signatures do. Any given key in the DNS > should last until its superceded or revoked. Anything else would be > a base change to the protocol (and orthogonal to the concept of > key rollover) > > Which in turn implies that the rollover document doesn't need > to/shouldn't deal with this concept. > > At 11:39 AM 4/7/2006, Suresh Krishnaswamy wrote: > > >ISSUE 4: Requirements draft does not explicitly mention advertising > >key "lifetimes" > > > >STATUS: OPEN > > > >REFERENCE: > > > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ > msg00228.html > > > > > >DESCRIPTION: > > > > Keys don't have lifetimes; however, is this concept useful in the > > context of trust anchor rollover solutions? > > > >-- > >to unsubscribe send a message to namedroppers-request@ops.ietf.org with > >the word 'unsubscribe' in a single line as the message text body. > >archive: > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Apr 08 18:21:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSLo4-0006OS-Ef for dnsext-archive@lists.ietf.org; Sat, 08 Apr 2006 18:21:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSLo4-000510-5H for dnsext-archive@lists.ietf.org; Sat, 08 Apr 2006 18:21:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSLhi-000BFb-6w for namedroppers-data@psg.com; Sat, 08 Apr 2006 22:14:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSLhg-000BFK-8v for namedroppers@ops.ietf.org; Sat, 08 Apr 2006 22:14:48 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 27BB533C1C; Sat, 8 Apr 2006 23:14:42 +0100 (BST) Message-ID: <4438358E.40405@algroup.co.uk> Date: Sat, 08 Apr 2006 23:13:34 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060305) MIME-Version: 1.0 To: Suresh Krishnaswamy CC: Namedroppers Subject: Re: ISSUE 6: Requirements in draft-moreau-dnsext-tak-req-00, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <0B248C8B-4AC2-48DB-8143-4FB4A1B70D08@tislabs.com> In-Reply-To: <0B248C8B-4AC2-48DB-8143-4FB4A1B70D08@tislabs.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Suresh Krishnaswamy wrote: > ISSUE 6: draft-moreau-dnsext-tak-req-00 has other useful requirements > > STATUS: OPEN > > REFERENCE: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00228.html > > DESCRIPTION: > > Added the following requirement: > > 5.11. Non-degrading Trust > > The method or methods used for Trust Anchor Distribution MUST be > deemed sufficiently trustworthy by the operator of the security-aware > resolver to ensure source authenticity and integrity of the new RR(s) > to maintain the Initial Trust Relationship required to designate > those RR(s) as Trust Anchor(s). Woah! This appears to make it impossible to implement any kind of federated solution (for example, my I-D on key seeding, which could also be used for rollover). It would also rule out changing the authority for the keys. Cheers, Ben. -- http://www.links.org/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Apr 08 18:21:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSLo5-0006RJ-35 for dnsext-archive@lists.ietf.org; Sat, 08 Apr 2006 18:21:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSLo1-00050x-G9 for dnsext-archive@lists.ietf.org; Sat, 08 Apr 2006 18:21:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSLjw-000BOH-Oz for namedroppers-data@psg.com; Sat, 08 Apr 2006 22:17:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSLjw-000BO5-2G for namedroppers@ops.ietf.org; Sat, 08 Apr 2006 22:17:08 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 4296033C1C; Sat, 8 Apr 2006 23:17:02 +0100 (BST) Message-ID: <44383617.3090202@algroup.co.uk> Date: Sat, 08 Apr 2006 23:15:51 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060305) MIME-Version: 1.0 To: Suresh Krishnaswamy CC: Namedroppers Subject: Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> In-Reply-To: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Suresh Krishnaswamy wrote: > In a short while I'll be sending out a list of pending issues (currently > 7 in number) for draft-ietf-dnsext-rollover-requirements-00. All of > these issues were extracted from e-mails that were sent to namedroppers > relative to this topic over the last month. > > Sample text appears in most places. If you don't agree with the wording > in the sample text please speak up. In places where there is no sample > text, silence will be interpreted as an implicit agreement by the > Working Group to close this issue without further changes. > > The hope is to have each of these issues resolved over the next two > weeks so that the next version of the requirements draft can be rolled > out and last-called in the relatively near future. The issue that some of the definitions are actually requirements appears to have been dropped. Cheers, Ben. -- http://www.links.org/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Apr 09 12:22:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FScgC-0005im-8R for dnsext-archive@lists.ietf.org; Sun, 09 Apr 2006 12:22:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FScgB-000528-PU for dnsext-archive@lists.ietf.org; Sun, 09 Apr 2006 12:22:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FScYG-0002DB-27 for namedroppers-data@psg.com; Sun, 09 Apr 2006 16:14:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FScYD-0002Cp-8p for namedroppers@ops.ietf.org; Sun, 09 Apr 2006 16:14:09 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k39GE7IV031014; Sun, 9 Apr 2006 16:14:07 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k39GE6Cp031013; Sun, 9 Apr 2006 16:14:06 GMT Date: Sun, 9 Apr 2006 16:14:06 +0000 From: bmanning@vacation.karoshi.com To: Mike StJohns Cc: Suresh Krishnaswamy , Namedroppers Subject: Re: ISSUE 7: New requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Message-ID: <20060409161406.GA30667@vacation.karoshi.com.> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <9A795F6F-2F64-4A84-B93C-1195FFB12A62@tislabs.com> <7.0.1.0.2.20060407121736.03de9950@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20060407121736.03de9950@nominum.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.3 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Fri, Apr 07, 2006 at 12:24:53PM -0400, Mike StJohns wrote: > At 11:43 AM 4/7/2006, Suresh Krishnaswamy wrote: > >ISSUE 7: Text for new requirements > > > >STATUS: OPEN > > > >REFERENCE: > > > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00228.html > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00233.html > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00530.html > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg00539.html > > > >DESCRIPTION: > > > > Added the following requirements based on inputs received: > > > > 5.12. Support for graceful consolidation of islands-of-trust > > > > The automated Trust Anchor Rollover solution MUST allow a zone to > > gracefully transition from an island-of-trust to a chain from its > > parent. > > I'm trying to figure out if this is a valid requirement or > moot. Here's the deal. If an island of trust (IOT)chains to a > superior trust anchor, I *think* data validates if it chains either > to the IOT trust anchor or to the superior trust anchor. (E.g. I > start with a nominum.com trust anchor and later add a .com trust > anchor and stop signing stuff with my nominum.com key - I think this > just works). > > It may be better to restate this as requiring a method to delete an > embedded trust point (e.g. all the trust anchors at nominum.com that > were previously configured in end resolvers). i'm actually concerned about network mobility... there may need to be a set of IOT chains that can be augmented with "learned" data, but i'm not sure they should be automaticially deleted. but yes, there should be a way/method to maintian IOTs... even when the IOT is the whole tree. :) --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Apr 09 12:22:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FScgD-0005jB-7m for dnsext-archive@lists.ietf.org; Sun, 09 Apr 2006 12:22:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FScgB-000527-PU for dnsext-archive@lists.ietf.org; Sun, 09 Apr 2006 12:22:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FScZ9-0002Ha-EA for namedroppers-data@psg.com; Sun, 09 Apr 2006 16:15:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FScZ9-0002HN-03 for namedroppers@ops.ietf.org; Sun, 09 Apr 2006 16:15:07 +0000 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id k39GF6IV031125; Sun, 9 Apr 2006 16:15:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id k39GF6jn031124; Sun, 9 Apr 2006 16:15:06 GMT Date: Sun, 9 Apr 2006 16:15:06 +0000 From: bmanning@vacation.karoshi.com To: Suresh Krishnaswamy Cc: Namedroppers Subject: Re: ISSUE 8: Wording in existing requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Message-ID: <20060409161506.GB30667@vacation.karoshi.com.> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <15212CDA-534C-4E2F-80EC-06C333036162@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15212CDA-534C-4E2F-80EC-06C333036162@tislabs.com> User-Agent: Mutt/1.4.1i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.3 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Fri, Apr 07, 2006 at 02:18:31PM -0400, Suresh Krishnaswamy wrote: > ISSUE 8: Wording in some existing requirements needs to be changed > > STATUS: OPEN > > REFERENCE: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00203.html > > DESCRIPTION: > > Requirement 5.5 currently states that "the solution MUST support > rollover for security-aware resolvers that have been disconnected > from the network for up to twelve months." > > There is disagreement over the choice of twelve months as the > disconnection period that MUST be supported. > > Is there a better value? If not, is there any benefit for the resolver > to support the ability to buffer some amount of outage, and if so, > can this be stated more generically as a requirement? > we are designing for 60 months. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 10 09:17:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSwH7-0006NV-GH for dnsext-archive@lists.ietf.org; Mon, 10 Apr 2006 09:17:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSwH4-0001JB-Un for dnsext-archive@lists.ietf.org; Mon, 10 Apr 2006 09:17:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSwBs-0007lT-Fy for namedroppers-data@psg.com; Mon, 10 Apr 2006 13:12:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSwBp-0007l9-03 for namedroppers@ops.ietf.org; Mon, 10 Apr 2006 13:12:21 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k3ADBaGM015469; Mon, 10 Apr 2006 09:11:36 -0400 (EDT) Received: from unknown(158.69.81.113) by nutshell.tislabs.com via csmap (V6.0) id srcAAAsbaGnE; Mon, 10 Apr 06 09:11:33 -0400 In-Reply-To: <44383617.3090202@algroup.co.uk> References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <44383617.3090202@algroup.co.uk> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Namedroppers Content-Transfer-Encoding: 7bit From: Suresh Krishnaswamy Subject: Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Mon, 10 Apr 2006 09:12:13 -0400 To: Ben Laurie X-Mailer: Apple Mail (2.746.3) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Issue 5 "Embedded requirements" was meant to capture this. Do you have suggestions for any new requirements that fall under this category? Feel free to send text. Thanks! Suresh On Apr 8, 2006, at 6:15 PM, Ben Laurie wrote: > Suresh Krishnaswamy wrote: >> In a short while I'll be sending out a list of pending issues >> (currently >> 7 in number) for draft-ietf-dnsext-rollover-requirements-00. All of >> these issues were extracted from e-mails that were sent to >> namedroppers >> relative to this topic over the last month. >> >> Sample text appears in most places. If you don't agree with the >> wording >> in the sample text please speak up. In places where there is no >> sample >> text, silence will be interpreted as an implicit agreement by the >> Working Group to close this issue without further changes. >> >> The hope is to have each of these issues resolved over the next two >> weeks so that the next version of the requirements draft can be >> rolled >> out and last-called in the relatively near future. > > The issue that some of the definitions are actually requirements > appears > to have been dropped. > > Cheers, > > Ben. > > -- > http://www.links.org/ > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org > with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 10 20:28:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT6kD-00064q-Tw for dnsext-archive@lists.ietf.org; Mon, 10 Apr 2006 20:28:33 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT5Ps-0001Bw-4L for dnsext-archive@lists.ietf.org; Mon, 10 Apr 2006 19:03:28 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FT5Gh-0008EW-Lc for dnsext-archive@lists.ietf.org; Mon, 10 Apr 2006 18:54:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FT5D0-000HWS-QQ for namedroppers-data@psg.com; Mon, 10 Apr 2006 22:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FT5Cz-000HWG-W9 for namedroppers@ops.ietf.org; Mon, 10 Apr 2006 22:50:10 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k3AMo10e025694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FT5Cr-0000ac-P3; Mon, 10 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-experiments-03.txt Message-Id: Date: Mon, 10 Apr 2006 18:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC Experiments Author(s) : D. Blacka Filename : draft-ietf-dnsext-dnssec-experiments-03.txt Pages : 15 Date : 2006-4-10 This document describes a methodology for deploying alternate, non- backwards-compatible, DNSSEC methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also 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-dnsext-dnssec-experiments-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-dnssec-experiments-03.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: <2006-4-10160908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-experiments-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-experiments-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-10160908.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 07:44:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTHIE-0002ek-Ax for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 07:44:22 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTHI9-0005tF-8B for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 07:44:22 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHCQ-00060j-IV for namedroppers-data@psg.com; Tue, 11 Apr 2006 11:38:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHCN-00060S-86 for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 11:38:19 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id BC05544FD; Tue, 11 Apr 2006 13:38:10 +0200 (CEST) Date: Tue, 11 Apr 2006 13:38:10 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: should a pure recursor know about localhost/1.0.0.127.in-addr.arpa? Message-ID: <20060411113809.GD19636@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi people, The PowerDNS recursor is currently in very big production for the first time, I've been asked why it doesn't answer for localhost. The recursor of PowerDNS is a pure recursor and has zero authoritative facilities, so I've added some hardcoded support for localhost and 1.0.0.127.in-addr.arpa. But I wonder if this is right and proper? And, if it is, should I hardcode the IPv6 equivalents as well? And, additionally, does it all matter? Have people heard of problems with not being able to resolve localhost? I know DJBDNS hardcodes it too. I've searched the namedroppers archive but localhost is kind of an awkward search term, it pops up a lot. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 08:02:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTHZz-0000x5-70 for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 08:02:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTHZx-0006UJ-T5 for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 08:02:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHYG-0007cn-Fj for namedroppers-data@psg.com; Tue, 11 Apr 2006 12:00:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP,UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHYB-0007c7-A7 for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 12:00:51 +0000 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43162) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FTHXu-0004Hz-Pl (Exim 4.54) (return-path ); Tue, 11 Apr 2006 13:00:35 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FTHXu-0001Vv-US (Exim 4.53) (return-path ); Tue, 11 Apr 2006 13:00:34 +0100 Date: Tue, 11 Apr 2006 13:00:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: should a pure recursor know about localhost/1.0.0.127.in-addr.arpa? In-Reply-To: <20060411113809.GD19636@outpost.ds9a.nl> Message-ID: References: <20060411113809.GD19636@outpost.ds9a.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Tue, 11 Apr 2006, bert hubert wrote: > > The recursor of PowerDNS is a pure recursor and has zero authoritative > facilities, so I've added some hardcoded support for localhost and > 1.0.0.127.in-addr.arpa. > > But I wonder if this is right and proper? And, if it is, should I hardcode > the IPv6 equivalents as well? Shouldn't it know about all the relevant RFC 3330 nets, to prevent bogus queries from loading the root or AS112? Tony. -- f.a.n.finch http://dotat.at/ BERWICK ON TWEED TO WHITBY: WEST OR SOUTHWEST 5 OR 6, PERHAPS INCREASING 7 LATER IN NORTH. RAIN AT FIRST. MAINLY GOOD. SLIGHT OR MODERATE. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 08:08:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTHfo-0003Ib-Pd for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 08:08:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTHfo-0006mw-9o for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 08:08:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHeG-00089x-JM for namedroppers-data@psg.com; Tue, 11 Apr 2006 12:07:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.1 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHeF-00089d-4t for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 12:07:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 3F82326C0F6; Tue, 11 Apr 2006 14:07:06 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 4517C26C0CB; Tue, 11 Apr 2006 14:07:04 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 406DE58ECFA; Tue, 11 Apr 2006 14:07:04 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 3786816AAFB; Tue, 11 Apr 2006 14:07:04 +0200 (CEST) Date: Tue, 11 Apr 2006 14:07:04 +0200 From: Stephane Bortzmeyer To: bert hubert Cc: namedroppers@ops.ietf.org Subject: Re: should a pure recursor know about localhost/1.0.0.127.in-addr.arpa? Message-ID: <20060411120704.GA16858@nic.fr> References: <20060411113809.GD19636@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060411113809.GD19636@outpost.ds9a.nl> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On Tue, Apr 11, 2006 at 01:38:10PM +0200, bert hubert wrote a message of 28 lines which said: > But I wonder if this is right and proper? RFC 1912 says so and our Zonecheck tool tests it: Certain zones should always be present in nameserver configurations: primary localhost localhost primary 0.0.127.in-addr.arpa 127.0 primary 255.in-addr.arpa 255 primary 0.in-addr.arpa 0 These are set up to either provide nameservice for "special" addresses, or to help eliminate accidental queries for broadcast or local address to be sent off to the root nameservers. All of these files will contain NS and SOA records just like the other zone files you maintain, the exception being that you can probably make the SOA timers very long, since this data will never change. The "localhost" address is a "special" address which always refers to the local host. It should contain the following line: localhost. IN A 127.0.0.1 The "127.0" file should contain the line: 1 PTR localhost. There has been some extensive discussion about whether or not to append the local domain to it. The conclusion is that "localhost." would be the best solution. The reasons given include: "localhost" by itself is used and expected to work in some systems. Translating 127.0.0.1 into "localhost.dom.ain" can cause some software to connect back to the loopback interface when it didn't want to because "localhost" is not equal to "localhost.dom.ain". The "255" and "0" files should not contain any additional data beyond the NS and SOA records. Note that future BIND versions may include all or some of this data automatically without additional configuration. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 08:20:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTHqo-0008Dg-LV for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 08:20:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTHqo-0007IY-2V for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 08:20:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHoj-00092A-83 for namedroppers-data@psg.com; Tue, 11 Apr 2006 12:17:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP autolearn=ham version=3.1.1 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTHof-00091i-I7 for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 12:17:53 +0000 Received: from tyrannia.TechFak.Uni-Bielefeld.DE (tyrannia.TechFak.Uni-Bielefeld.DE [129.70.137.5]) by momotombo.TechFak.Uni-Bielefeld.DE (8.12.11/8.12.11/TechFak/2005/05/30/sjaenick) with ESMTP id k3BCHo63015316; Tue, 11 Apr 2006 14:17:51 +0200 (MEST) Received: from localhost (pk@localhost) by tyrannia.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id k3BCHoO22015; Tue, 11 Apr 2006 14:17:50 +0200 (MEST) Message-Id: <200604111217.k3BCHoO22015@tyrannia.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: tyrannia.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: IETF DNSEXT WG From: Peter Koch Subject: Re: should a pure recursor know about localhost/1.0.0.127.in-addr.arpa? In-reply-to: Your message of "Tue, 11 Apr 2006 14:07:04 +0200." <20060411120704.GA16858@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22012.1144757868.1@tyrannia.TechFak.Uni-Bielefeld.DE> Date: Tue, 11 Apr 2006 14:17:50 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Stephane Bortzmeyer wrote: > RFC 1912 says so and our Zonecheck tool tests it: > > Certain zones should always be present in nameserver configurations: > > primary localhost localhost > primary 0.0.127.in-addr.arpa 127.0 > primary 255.in-addr.arpa 255 > primary 0.in-addr.arpa 0 RFC 1912 is informational only and has some outdated parts. In the dnsop WG there's a draft under consideration (although not an official wg document: draft-andrews-full-service-resolvers-02.txt), that aims at BCP and seeds a list of zones each recurive server should authoritatively treat as empty. > There has been some extensive discussion about whether or not to > append the local domain to it. The conclusion is that "localhost." > would be the best solution. The reasons given include: > > "localhost" by itself is used and expected to work in some > systems. > > Translating 127.0.0.1 into "localhost.dom.ain" can cause some > software to connect back to the loopback interface when it didn't > want to because "localhost" is not equal to "localhost.dom.ain". There are two different schools of thought for this. One lets the rev map for 127.0.0.1 point to "localhost." (the localhost. TLD was reserved in RFC 2606, yet not delegated), the other lets it point to a localhost in some appropriate domain, also setting up the correspinding A RR there. The "localhost." approach either relies upon some search path and/or on the presence of a "localhost." zone on the respective resursive server. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 11:09:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKUf-00042c-8c for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:09:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKUd-0005Ok-TY for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:09:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTKQr-000JUZ-VZ for namedroppers-data@psg.com; Tue, 11 Apr 2006 15:05:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, NORMAL_HTTP_TO_IP,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTKQr-000JUL-0D for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 15:05:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 11B45114A6; Tue, 11 Apr 2006 15:05:28 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: bert hubert cc: namedroppers@ops.ietf.org Subject: Re: should a pure recursor know about localhost/1.0.0.127.in-addr.arpa? In-Reply-To: Your message of "Tue, 11 Apr 2006 13:38:10 +0200." <20060411113809.GD19636@outpost.ds9a.nl> References: <20060411113809.GD19636@outpost.ds9a.nl> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 11 Apr 2006 15:05:28 +0000 Message-ID: <51467.1144767928@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 as the developer of several caching recursive nameservers, i can tell you that the user community for them generally MUST have the ability to hardcode localhost and its PTR's, in ipv4 and ipv6 space; also some NS RRs for rfc1918 PTRs (to avoid hitting AS112); also some NS RRs for their own local zones (to be able to resolve their own names when their transit pipe is down.) as attractive as it is to do a "pure" nameserver with nearly zero config, it's unrealistic in today's polluted local namespaces. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 11:21:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKge-0000uq-8f for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:21:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKgc-0005zi-Q1 for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:21:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTKeP-000KUN-5P for namedroppers-data@psg.com; Tue, 11 Apr 2006 15:19:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,SPF_PASS autolearn=ham version=3.1.1 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTKeM-000KU1-KC for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 15:19:26 +0000 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k3BFJOd0028271; Tue, 11 Apr 2006 08:19:24 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 08:19:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Date: Tue, 11 Apr 2006 08:19:23 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0055_01C65D59.C91DBE40" Message-ID: <198A730C2044DE4A96749D13E167AD37A49683@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New DSA key sizes RE: draft-ietf-dnsext-rfc2536bis-dsa-06.txt Thread-Index: AcZRvrqACtxzM9FySdCHbcbNLkHKFAAqFAaQAsR8PjA= From: "Hallam-Baker, Phillip" To: "Eastlake III Donald-LDE008" , X-OriginalArrivalTime: 11 Apr 2006 15:19:24.0525 (UTC) FILETIME=[50D6C1D0:01C65D7B] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C65D59.C91DBE40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit NIST has recently proposed a new version of DSA that supports 2048 bit (and larger) keys and SHA2. I think that the draft should be updated to cover this new algorithm as it overcomes one of the principle difficulties with DNSSEC deployment, the size of the signature keys. DSA-2048 with a 256 byte subgroup has the same key size as RSA: 256 bytes. But the signature blob is only 64 bits. The cipher strength is equivalent to 112 bit symmetric key cryptography as opposed to 80 bits for DSA. ECC certainly has benefits but at this point I can't see us navigating the patent thicket quickly. It is much easier to get cipher hardware vendors to support the new DSA than an entirely new algorithm. I propose that we reserve 2 signature algorithm identifiers for the new DSA signatures: ID#1 for the DSA algorithm as currently specified. ID#2 to be issued on completion of the hash algorithm competition for DSA+NewHash I don't know if this would be best done as a separate draft or as a continuation of this draft. My preferred solution would be to create a new draft using the same text. The one drawback to using DSA is that public key operations are slower than private key operations. If you operate a large domain this is not exactly a drawback :-) but my interest here is independent of the registry, my concern is DKIM where this pushes the computation load in an unfortunate direction. ------=_NextPart_000_0055_01C65D59.C91DBE40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MTExNTE5MjNaMCMGCSqGSIb3DQEJBDEWBBRZ SWjGCigCLvb+uHi5kMuTTNllZDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYA0KhzMmS+fgG2q0NfrPdMVoskO uXZq2tua2A8manhMt3j6dlocQTnqyV+8ysq+Xco//Pbyt9eC+XeLIynB4R5W6XnWC9/Ec60fLuGE STpuouYtLRUEzffnBzByBkV9aGo6BP208pgqVIEgft3jm4ORzOdnpjTpuKGeTu19aNzBzAAAAAAA AA== ------=_NextPart_000_0055_01C65D59.C91DBE40-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 11:45:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL3C-00036u-Gm for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:45:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTL3C-00070i-4M for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:45:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTL0K-000M94-3C for namedroppers-data@psg.com; Tue, 11 Apr 2006 15:42:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [149.8.64.32] (helo=mclmx2.mail.saic.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTL0I-000M8r-VF for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 15:42:07 +0000 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 11:41:51 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006041111415128097 for ; Tue, 11 Apr 2006 11:41:51 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Tue, 11 Apr 2006 11:41:51 -0400 Message-Id: From: "Loomis, Rip" To: Namedroppers Subject: RE: ISSUE 4: Key "lifetimes", was Re: Pending issues for draft-i etf-dnsext-rollover-requirements-00 Date: Tue, 11 Apr 2006 11:41:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 > > >ISSUE 4: Requirements draft does not explicitly mention advertising > > >key "lifetimes" Correct, and that lack of mention is also correct. (More comments below, plus comments inline on what Mike St. Johns and Scott Rose previously said on this.) > > Keys don't have lifetimes, signatures do. Respectfully, I disagree slightly on terminology. Keys do have "lifetimes", and so do signatures. Key "lifetime" is the key effectivity period, which is initially defined by the operator, is generally not known to the end user or security aware resolver, and can be changed at any time. Scott referred to this below as a "key operational period"--it's something of which only the DNS zone administrator should be aware, in the same way that the master/slave status of an authoritative server should not be apparent to an end user. Signature "lifetime" is the signature validity period, which is defined initially by the operator but (for a given signature) then cannot be changed and can be objectively verified by the end user/security aware resolver. > > Any given key in the DNS > > should last until its superceded or revoked. Anything > > else would be a base change to the protocol (and orthogonal to > > the concept of key rollover). Agree with this part. > I agree with Mike. Key operational periods are more policy > issues, not protocol issues. There would be no way of expressing > this lifetime in the DNSKEY record. > > I don't support this requirement. Some additional thoughts: It Might Seem Nice If the key effectivity period for a Trust Anchor (TA) was known to the security-aware resolvers and could be figured into the "how often do I check for a new TA" calculation--similar to how SOA values are used. However, if there is a key compromise that results in an emergency key supersession (emergency rollover), though, then by definition the key effectivity period will be changed--and to me this fact (and the related requirement for timeliness in section 5.8 of the -00 draft) is an essential difference between conventional DNS as currently practiced and DNS+DNSSEC+key management. There's no place in the DNSKEY record for effectivity period, nor does there need to be, nor is it something that (IMHO) should be communicated to security-aware resolvers as part of establishing/changing a TA. (What MSJ and Scott said). It does still seem to me that there's going to be an issue, because of this essential difference, in how the requirements draft (and the automated rollover draft(s)) flesh out the "timeliness" requirement. How often is too often/not often enough to pull/push/verify status? --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 11:45:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTL3I-000376-Cs for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:45:12 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTL3G-00070p-3a for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 11:45:12 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTL1W-000MEh-Mb for namedroppers-data@psg.com; Tue, 11 Apr 2006 15:43:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.1.1 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTL1V-000MES-8u for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 15:43:21 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k3BFgbeO019342 for ; Tue, 11 Apr 2006 11:42:37 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAC4aWWL; Tue, 11 Apr 06 11:42:34 -0400 Received: from localhost (localhost [127.0.0.1]) by tislabs.com (8.12.9/8.12.9) with ESMTP id k3BFf4qb020664 for ; Tue, 11 Apr 2006 11:41:04 -0400 (EDT) Date: Tue, 11 Apr 2006 11:42:46 -0400 (EDT) From: Sam Weiler X-X-Sender: weiler@lemon.samweiler.com To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-experiments-03.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f I've skimmed the changes between -02 and -03, and I support the publication of -03 on the standards track. My single substantive comment was addressed by the signifigant reframing of Section 7. While I continue to believe that using message digest identifiers for versioning is a better choice than using algoritm identifiers, the draft no longer suggests a preference for using algorithm identifiers over other choices. (I actually liked the old Section 7 better -- it seemed more substantive and useful.) All of the nits I found seem to have been addressed, also. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 12:51:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTM5F-0006r5-Px for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 12:51:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTM5F-00010O-Dp for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 12:51:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTM19-0000P2-EA for namedroppers-data@psg.com; Tue, 11 Apr 2006 16:47:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.6.16.227] (helo=smtp.nist.gov) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTM18-0000Oo-Ec for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 16:47:02 +0000 Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k3BGl11g025632 for ; Tue, 11 Apr 2006 12:47:01 -0400 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.13.6/8.13.6) with SMTP id k3BGkm40011913 for ; Tue, 11 Apr 2006 12:46:49 -0400 (EDT) From: "Scott Rose" To: "Namedroppers" Subject: RE: ISSUE 5: Embedded requirements, was Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 Date: Tue, 11 Apr 2006 12:46:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal In-Reply-To: <91652889-221F-47E3-9E9C-0ABC482A290F@tislabs.com> X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr@nist.gov Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Suresh Krishnaswamy I have one question about one of the additions. > > ISSUE 5: WG submission has embedded requirements in definitions > > STATUS: OPEN > > REFERENCE: > > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00206.html > http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg00228.html > > DESCRIPTION: > > Added the following text to the "Timeliness" requirement: > Operators of security-aware resolvers using RR(s) from that > zone as Trust Anchors need to acquire new and remove revoked > Trust Anchors such that no old key is used for long after > revocation. > I support this requirement in principle, but I am unsure what a "long time period" would be. How about the TTL of the DNSKEY RR? Just thinking out loud, but when a rollover is seen, the old trust anchor should be purged as if it were part of the cache at that point. > Added the following text to the "Scalability" requirement: > The automated Trust Anchor Rollover solution MUST be > able to support Trust Anchors for multiple zones and > multiple Trust Anchors for each DNS zone. > I support this requirement. Scott > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 11 13:12:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTMPt-000752-1Y for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 13:12:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTMPo-00021d-NJ for dnsext-archive@lists.ietf.org; Tue, 11 Apr 2006 13:12:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTMNF-000291-Cu for namedroppers-data@psg.com; Tue, 11 Apr 2006 17:09:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.224] (helo=mail4.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTMND-00028S-KH for namedroppers@ops.ietf.org; Tue, 11 Apr 2006 17:09:51 +0000 Received: by mail4.sea.safepages.com (Postfix, from userid 1012) id E1A062E049; Tue, 11 Apr 2006 17:09:49 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.214]) by mail4.sea.safepages.com (Postfix) with ESMTP id 2E8F22DFAC; Tue, 11 Apr 2006 17:08:30 +0000 (GMT) Message-ID: <443BE259.6080100@connotech.com> Date: Tue, 11 Apr 2006 13:07:37 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Loomis, Rip" Cc: Namedroppers Subject: Re: ISSUE 4: Key "lifetimes", was Re: Pending issues for draft-i etf-dnsext-rollover-requirements-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Loomis, Rip wrote: > > Some additional thoughts: > > It Might Seem Nice If the key effectivity period for a Trust > Anchor (TA) was known to the security-aware resolvers and > could be figured into the "how often do I check for a new > TA" calculation--similar to how SOA values are used. > See e.g. draft-moreau-dnsext-sdda-rr-01.txt, Authentication Expiration/Inception Fields. > However, if there is a key compromise that results in an > emergency key supersession (emergency rollover), though, > then by definition the key effectivity period will be > changed--and to me this fact (and the related requirement > for timeliness in section 5.8 of the -00 draft) is an > essential difference between conventional DNS as currently > practiced and DNS+DNSSEC+key management. > Then the zone manager re-issues the SDDA RR with more restrictive Authentication Expiration/Inception Fields. > There's no place in the DNSKEY record for effectivity > period, nor does there need to be, nor is it something > that (IMHO) should be communicated to security-aware > resolvers as part of establishing/changing a TA. (What > MSJ and Scott said). > > It does still seem to me that there's going to be an > issue, because of this essential difference, in how the > requirements draft (and the automated rollover draft(s)) > flesh out the "timeliness" requirement. How often is > too often/not often enough to pull/push/verify status? > A mere operational issue, once the SDDA Expiration/Inception protocol support is accepted: A local policy for *paranoid* DNS resolvers is to query authoritative key management *often*. An ordinary DNS resolver implementation may have a manual command/button for "emergency trust anchor rollover queries" so that a publicised DNS root private key compromise has a cure, and otherwise do the queries according to the SDDA expiration time. OK, these are solution space elements, just in reaction to your "additional thoughts". Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 12 01:08:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTXaK-0000jJ-51 for dnsext-archive@lists.ietf.org; Wed, 12 Apr 2006 01:08:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTXaG-0005n7-SA for dnsext-archive@lists.ietf.org; Wed, 12 Apr 2006 01:08:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTXWS-000L88-3K for namedroppers-data@psg.com; Wed, 12 Apr 2006 05:04:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.1.1 Received: from [217.155.92.109] (helo=mail.links.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTXWQ-000L7s-QJ for namedroppers@ops.ietf.org; Wed, 12 Apr 2006 05:04:07 +0000 Received: from [IPv6:::1] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id D93B933C1C; Wed, 12 Apr 2006 06:04:02 +0100 (BST) Message-ID: <443C89F9.90805@algroup.co.uk> Date: Wed, 12 Apr 2006 06:02:49 +0100 From: Ben Laurie User-Agent: Thunderbird 1.5 (X11/20060305) MIME-Version: 1.0 To: Suresh Krishnaswamy CC: Namedroppers Subject: Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 References: <1DF6C5DF-1CD7-4371-B90C-A722205F5C19@tislabs.com> <44383617.3090202@algroup.co.uk> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Suresh Krishnaswamy wrote: > Issue 5 "Embedded requirements" was meant to capture this. Do you have > suggestions for any new requirements that fall under this category? Feel > free to send text. Whoops, sorry. I think that looks good. > > Thanks! > Suresh > > > On Apr 8, 2006, at 6:15 PM, Ben Laurie wrote: > >> Suresh Krishnaswamy wrote: >>> In a short while I'll be sending out a list of pending issues (currently >>> 7 in number) for draft-ietf-dnsext-rollover-requirements-00. All of >>> these issues were extracted from e-mails that were sent to namedroppers >>> relative to this topic over the last month. >>> >>> Sample text appears in most places. If you don't agree with the wording >>> in the sample text please speak up. In places where there is no sample >>> text, silence will be interpreted as an implicit agreement by the >>> Working Group to close this issue without further changes. >>> >>> The hope is to have each of these issues resolved over the next two >>> weeks so that the next version of the requirements draft can be rolled >>> out and last-called in the relatively near future. >> >> The issue that some of the definitions are actually requirements appears >> to have been dropped. >> >> Cheers, >> >> Ben. >> >> --http://www.links.org/ >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: > > -- http://www.links.org/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 12 13:51:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTjVR-0003Kl-Ok for dnsext-archive@lists.ietf.org; Wed, 12 Apr 2006 13:51:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTjVP-0006ok-Aa for dnsext-archive@lists.ietf.org; Wed, 12 Apr 2006 13:51:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTjP7-0009gr-6w for namedroppers-data@psg.com; Wed, 12 Apr 2006 17:45:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [216.127.148.222] (helo=mail2.sea.safepages.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTjP5-0009gV-Qx for namedroppers@ops.ietf.org; Wed, 12 Apr 2006 17:45:19 +0000 Received: by mail2.sea.safepages.com (Postfix, from userid 1012) id 2C9EB696E5; Wed, 12 Apr 2006 17:45:16 +0000 (GMT) Received: from connotech.com (unknown [165.154.49.93]) by mail2.sea.safepages.com (Postfix) with ESMTP id 0679C6952D; Wed, 12 Apr 2006 17:45:13 +0000 (GMT) Message-ID: <443D3C73.4030507@connotech.com> Date: Wed, 12 Apr 2006 13:44:19 -0400 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dnssec-deployment@shinkuro.com, dnsop@lists.uoregon.edu, Namedroppers Subject: Nomination of O.Kolkman at the IAB - good news for advances in DNS technology Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Dear all: I just noticed that Olaf Kolkman was nominated on the IAB as of March 2006 (http://www.iab.org/about/members-plus.html). The Internet Architecture Board is responsible, among other things, for liaison activities for the IETF, including liaison with ICANN. The expertise of Olaf in DNS matters is certainly going to be put into good use these days with DNS operational challenges, e.g. Internationalized Domain Names and DNSSEC deployment ("signing the root"). I'm sure this is an understatement of the reasons why this nomination is good news. Congratulations to Olaf, good luck with this new assignment, and thanks for handling these matters to the benefit of Internet community. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From disciple@uswebregister.com Fri Apr 14 03:26:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUIh3-0001YF-LS for dnsext-archive@ietf.org; Fri, 14 Apr 2006 03:26:13 -0400 Received: from [61.184.253.156] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUIgy-0007E7-Cj for dnsext-archive@ietf.org; Fri, 14 Apr 2006 03:26:13 -0400 Message-ID: <000001c65fbf$3806cd80$0100007f@localhost> From: "Jeremiah Wilson" To: Subject: 0EM Software Date: Sun, 12 Mar 2006 23:24:57 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C65FBF.3806CD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C65FBF.3806CD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C65FBF.3806CD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C65FBF.3806CD80-- From owner-namedroppers@ops.ietf.org Fri Apr 14 03:48:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUJ2Z-0003uf-BC for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 03:48:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUJ2T-0007sf-KY for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 03:48:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUIwy-000G4g-PW for namedroppers-data@psg.com; Fri, 14 Apr 2006 07:42:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUIwv-000G4T-Pj for namedroppers@ops.ietf.org; Fri, 14 Apr 2006 07:42:38 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 41DCD4052; Fri, 14 Apr 2006 09:42:27 +0200 (CEST) Date: Fri, 14 Apr 2006 09:42:27 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: heads up: some practical DNS real life things you might want to know Message-ID: <20060414074226.GB6380@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi namedroppers, Thanks for the verbose and useful answers to my recent question about 127.in-addr.arpa and other important zones. In the not too far future, the PowerDNS recursor will get a small authoritative part to serve these zones, out of the box. Some things I want to share: 1) Mandatory compression There are domestic routers out there that proxy DNS queries, so computers behind it configure the router as their nameserver. In the course of migrating a large access provider to the PowerDNS recursor, the helpdesk received a slow trickle of calls from owners of certain brands of router who lost the ability to resolve domains, and hence use the internet. A long period of study later it was discovered a recent change in PowerDNS disabled compression of the first DNS answer against the original question, and that these routers consider 'c0 0c' to be a magic 'Start of Answer' marker. And crash when they can't find it. More gory detail over at http://blog.netherlabs.nl So be aware, in the real world, compression is no longer optional but mandatory. 2) question count = 0 There is a nameserver implementation out there that zeroes the original question upon replying for domains it is not authoritative for: $ dig ds9a.nl @xx.1x9.1.61 ; <<>> DiG 9.3.1 <<>> ds9a.nl @xx.1x9.1.61 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33769 ;; flags: qr rd ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; Query time: 35 msec ;; WHEN: Fri Apr 14 09:37:06 2006 ;; MSG SIZE rcvd: 12 $ dig +norecurs ds9a.nl @xx.1x9.1.61 ; <<>> DiG 9.3.1 <<>> +norecurs ds9a.nl @xx.1x9.1.61 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 15698 ;; flags: qr ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; Query time: 35 msec ;; WHEN: Fri Apr 14 09:37:51 2006 ;; MSG SIZE rcvd: 12 fpdns.pl outputs: q0r?1,IQUERY,0,0,1,1,0,0,REFUSED,0,0,0,0 This makes the PowerDNS spoofing detection act up, so I'm special casing the question count = 0 case. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 14 08:44:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUNea-0004Kw-LS for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 08:44:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUNeX-0000EE-7s for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 08:44:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUNa9-0009l2-90 for namedroppers-data@psg.com; Fri, 14 Apr 2006 12:39:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUNa5-0009kg-Mr; Fri, 14 Apr 2006 12:39:21 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 14 Apr 2006 13:39:20 +0100 X-IronPort-AV: i="4.04,120,1144018800"; d="scan'208"; a="3467098:sNHT34518556" In-Reply-To: <20060414074226.GB6380@outpost.ds9a.nl> To: bert hubert Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: heads up: some practical DNS real life things you might want to know MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Fri, 14 Apr 2006 14:39:07 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 04/14/2006 01:39:07 PM, Serialize complete at 04/14/2006 01:39:07 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 owner-namedroppers@ops.ietf.org wrote on 04/14/2006 09:42:27 AM: > Hi namedroppers, > > Thanks for the verbose and useful answers to my recent question about > 127.in-addr.arpa and other important zones. In the not too far future, the > PowerDNS recursor will get a small authoritative part to serve these zones, > out of the box. > > Some things I want to share: > > 1) Mandatory compression > There are domestic routers out there that proxy DNS queries, so computers > behind it configure the router as their nameserver. In the course of > migrating a large access provider to the PowerDNS recursor, the helpdesk > received a slow trickle of calls from owners of certain brands of router who > lost the ability to resolve domains, and hence use the internet. > > A long period of study later it was discovered a recent change in PowerDNS > disabled compression of the first DNS answer against the original question, > and that these routers consider 'c0 0c' to be a magic 'Start of Answer' > marker. And crash when they can't find it. More gory detail over at > http://blog.netherlabs.nl Oooh, that is so wrong. Good catch! What did the e-tech folks say? > So be aware, in the real world, compression is no longer optional but > mandatory. > > 2) question count = 0 > > There is a nameserver implementation out there that zeroes the original > question upon replying for domains it is not authoritative for: > > $ dig ds9a.nl @xx.1x9.1.61 > > ; <<>> DiG 9.3.1 <<>> ds9a.nl @xx.1x9.1.61 > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33769 > ;; flags: qr rd ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; Query time: 35 msec > ;; WHEN: Fri Apr 14 09:37:06 2006 > ;; MSG SIZE rcvd: 12 > > $ dig +norecurs ds9a.nl @xx.1x9.1.61 > > ; <<>> DiG 9.3.1 <<>> +norecurs ds9a.nl @xx.1x9.1.61 > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 15698 > ;; flags: qr ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; Query time: 35 msec > ;; WHEN: Fri Apr 14 09:37:51 2006 > ;; MSG SIZE rcvd: 12 > > fpdns.pl outputs: > q0r?1,IQUERY,0,0,1,1,0,0,REFUSED,0,0,0,0 > > This makes the PowerDNS spoofing detection act up, so I'm special casing the > question count = 0 case. I'd love to add this thing to the fpdns list. Please let me know if you've figured out which code this is, or if you need any help fingerprinting it. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 14 08:52:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUNnD-0001F0-Ek for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 08:52:55 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUNnC-0000Qi-5E for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 08:52:55 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUNlP-000Abw-L9 for namedroppers-data@psg.com; Fri, 14 Apr 2006 12:51:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUNlN-000Abf-DW for namedroppers@ops.ietf.org; Fri, 14 Apr 2006 12:51:01 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id 512263F87; Fri, 14 Apr 2006 14:50:53 +0200 (CEST) Date: Fri, 14 Apr 2006 14:50:53 +0200 From: bert hubert To: Roy Arends Cc: namedroppers@ops.ietf.org Subject: Re: heads up: some practical DNS real life things you might want to know Message-ID: <20060414125052.GC6380@outpost.ds9a.nl> References: <20060414074226.GB6380@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On Fri, Apr 14, 2006 at 02:39:07PM +0200, Roy Arends wrote: > > marker. And crash when they can't find it. More gory detail over at > > http://blog.netherlabs.nl > > Oooh, that is so wrong. Good catch! What did the e-tech folks say? About as wrong as your lotus notes client mailing the namedroppers-owner, Roy! :-) I'm still trying to penetrate the e-tech helpdesk. > I'd love to add this thing to the fpdns list. Please let me know if you've > figured out which code this is, or if you need any help fingerprinting it. I know who owns it and will ask. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 14 10:21:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPAc-00053v-LG for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 10:21:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPAZ-0003Hb-93 for dnsext-archive@lists.ietf.org; Fri, 14 Apr 2006 10:21:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUP7c-000GEm-0Q for namedroppers-data@psg.com; Fri, 14 Apr 2006 14:18:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUP7b-000GEX-4k for namedroppers@ops.ietf.org; Fri, 14 Apr 2006 14:18:03 +0000 Received: from [10.31.32.240] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3EEHovi006885; Fri, 14 Apr 2006 10:17:51 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060414074226.GB6380@outpost.ds9a.nl> References: <20060414074226.GB6380@outpost.ds9a.nl> Date: Fri, 14 Apr 2006 10:17:50 -0400 To: bert hubert From: Edward Lewis Subject: Re: heads up: some practical DNS real life things you might want to know Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 At 9:42 +0200 4/14/06, bert hubert wrote: >A long period of study later it was discovered a recent change in PowerDNS >disabled compression of the first DNS answer against the original question, >and that these routers consider 'c0 0c' to be a magic 'Start of Answer' >marker. And crash when they can't find it. More gory detail over at >http://blog.netherlabs.nl > >So be aware, in the real world, compression is no longer optional but >mandatory. An age-old dilemma; when do you engineer to the way things are and when do you engineer for the way things need to be? I think the fault here lies with the bad heuristics of the security software. But I can see why the DNS implementation is the "victim" and has to "get fixed." While "fixing" PowerDNS I hope you also got a whip and beat the security coders mercilessly. ;) >2) question count = 0 >This makes the PowerDNS spoofing detection act up... It's always the security, isn't it? ;) The first question in enforcing security is "is everything as it should be?" That's why we have these security failures - when the sensed environment changes, security needs to react. The unfortunate part is that the reaction is not always right - security entities sometimes (or "often" it seems when you are getting bit by it) misinterpret change, i.e., use bad heuristics. It's not that security folks are weaker than other folks when it comes to protocol and network engineering, it's that a faulty effect is more noticeable. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From paulajoy@mxwall.com Sun Apr 16 03:59:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV2AC-0000MJ-AE for dnsext-archive@ietf.org; Sun, 16 Apr 2006 03:59:20 -0400 Received: from c-24-11-71-59.hsd1.mi.comcast.net ([24.11.71.59] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FV2A8-0001CT-W5 for dnsext-archive@ietf.org; Sun, 16 Apr 2006 03:59:18 -0400 Message-ID: <000001c66156$5fdc6980$0100007f@localhost> From: "Ivan Green" To: Subject: Obtaining a DIPLOMA has never been so easy! Date: Sun, 16 Apr 2006 03:59:10 -0900 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.5 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 NO ONE is turned down. According to the U.S. Census Bureau, with the following degrees, here's how much you can expect to make in your lifetime: High School Diploma: $1,100,000 Bachelor's Degree: $2,100,000 Master's Degree: $2,500,000 Doctorate: $4,400,000 You Need a Better Degree, and we can Help! Obtain degrees from Prestigious non-accredited Universities based on you life experience. NO ONE is turned down. Call Now 7 days a week. "1-718-504-5376" From owner-namedroppers@ops.ietf.org Sun Apr 16 15:34:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVD0m-0007F3-P0 for dnsext-archive@lists.ietf.org; Sun, 16 Apr 2006 15:34:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVD0l-00040u-Cu for dnsext-archive@lists.ietf.org; Sun, 16 Apr 2006 15:34:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVCwq-0008g9-U4 for namedroppers-data@psg.com; Sun, 16 Apr 2006 19:30:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVCwo-0008fp-6I for namedroppers@ops.ietf.org; Sun, 16 Apr 2006 19:30:14 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 92B141142C for ; Sun, 16 Apr 2006 19:30:13 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: isc dlv spec published X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 16 Apr 2006 19:30:13 +0000 Message-ID: <84748.1145215813@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 i apologize for the tardiness of this. we released this logic in BIND9 9.3.2 without describing it in a way that would permit other validator implementors, or other dlv registries, to release compatible logic. ("oops! try it now.") at you can find ISC-TN-2006-1 "DNSSEC Lookaside Validation" (or more directly, http://www.isc.org/pubs/tn/isc-tn-2006-1.html). see also message-id <20050516152525.64389139A3@sa.vix.com> (from namedroppers) and (press release). for information about isc's dlv registry, contact joao damas . -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From taramattiec@befriendafamily.com Mon Apr 17 01:19:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVM8d-0000Bm-G3 for dnsext-archive@ietf.org; Mon, 17 Apr 2006 01:19:03 -0400 Received: from [218.58.243.11] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVM8W-0000nA-K0 for dnsext-archive@ietf.org; Mon, 17 Apr 2006 01:19:01 -0400 Message-ID: <000001c66208$dcc81b80$0100007f@localhost> From: "Patrick Jackson" To: Subject: Academic Qualifications available from prestigious NON-ACCREDITED universities Date: Mon, 17 Apr 2006 13:19:00 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.8 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 NO ONE is turned down. According to the U.S. Census Bureau, with the following degrees, here's how much you can expect to make in your lifetime: High School Diploma: $1,100,000 Bachelor's Degree: $2,100,000 Master's Degree: $2,500,000 Doctorate: $4,400,000 You Need a Better Degree, and we can Help! Obtain degrees from Prestigious non-accredited Universities based on you life experience. NO ONE is turned down. Call Now 7 days a week. "1-718-504-5376" From owner-namedroppers@ops.ietf.org Mon Apr 17 10:17:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUXm-0001EQ-Dg for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 10:17:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVUXk-0000Lw-2Z for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 10:17:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVURu-0001kF-RH for namedroppers-data@psg.com; Mon, 17 Apr 2006 14:11:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, SPF_PASS autolearn=no version=3.1.1 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVURt-0001jz-NK for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 14:11:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id E93411142C; Mon, 17 Apr 2006 14:11:28 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: paul@vix.com To: namedroppers@ops.ietf.org cc: Florian Weimer Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name In-Reply-To: Your message of "Mon, 17 Apr 2006 11:16:26 +0200." <87y7y4a7f9.fsf@mid.deneb.enyo.de> References: <87psjkfrg5.fsf@mid.deneb.enyo.de> <87slogcpgi.fsf@mid.deneb.enyo.de> <36258.1145039666@sa.vix.com> <87y7y4a7f9.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 7.93; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 17 Apr 2006 14:11:28 +0000 Message-ID: <68956.1145283088@sa.vix.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 folks, i think florian's got a valid point here. (i'm not cross-posting, i'm changing mailing lists for this thread. i'll post a summary back to dns-operations@ when namedroppers@ is done chewing on this.) re: > From: Florian Weimer > To: dns-operations@lists.oarci.net > Date: Mon, 17 Apr 2006 11:16:26 +0200 > Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing > name > Sender: dns-operations-bounces@lists.oarci.net > > * Paul Vixie: > > > to me, b.example.net exists because that's what we decided for dnssec, > > Post-RFC-4035, I assume? Because RFC 4035 says, in section 3.1.32: > > | Note that this form of response includes cases in which SNAME > | corresponds to an empty non-terminal name within the zone (a name > | that is not the owner name for any RRset but that is the parent name > | of one or more RRsets). > > This also follows from the prohibition of NSEC generation for empty > non-terminals (section 2.3, "An NSEC record (and its associated RRSIG > RRset) MUST NOT be the only RRset at any particular owner name."), as > you would need such an NSEC RR for responding with NODATA. This means > that the draft-ietf-dnsext-wcard-clarify (thanks Peter and Edward!) is > in conflict with DNSSEC (as a simple update of the DNSSEC spec is not > possible). > > Ah, draft-ietf-dnsext-nsec3 handles this case differently, maching the > draft-ietf-dnsext-wcard-clarify. > _______________________________________________ > dns-operations mailing list > dns-operations@lists.oarci.net > http://lists.oarci.net/mailman/listinfo/dns-operations -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 11:11:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVNW-0005ZP-Rq for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 11:11:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVNW-0002rj-QT for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 11:11:02 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FVV3Y-0006ti-0z for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 10:50:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVV1D-0003zj-JL for namedroppers-data@psg.com; Mon, 17 Apr 2006 14:47:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVV1C-0003zT-LH for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 14:47:59 +0000 Received: from [10.31.32.79] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3HElhLT025447; Mon, 17 Apr 2006 10:47:44 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <68956.1145283088@sa.vix.com> References: <87psjkfrg5.fsf@mid.deneb.enyo.de> <87slogcpgi.fsf@mid.deneb.enyo.de> <36258.1145039666@sa.vix.com> <87y7y4a7f9.fsf@mid.deneb.enyo.de> <68956.1145283088@sa.vix.com> Date: Mon, 17 Apr 2006 10:47:46 -0400 To: paul@vix.com From: Edward Lewis Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name Cc: namedroppers@ops.ietf.org, Florian Weimer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -0.4 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 I don't get the point. (I need clarification.) I will say I don't understand the last paragraph of 3.1.3.2 in 4035 (as quoted by Florian). When it comes to name errors, empty non-terminals need not apply. NSEC3 breaks rules. It has to. The reason is that when the design choices were make for NSEC (nee NXT), a set of rules were included assuming NXT and making NXR more reasonable. Deviating from NSEC into NSEC3 means upending design decisions and rules set forth. I don't see the conflict between DNSSEC and the wild card document. Maybe this is the missed point: You don't need an NSEC at a name to prove it has no RRsets. example. NSEC a.example. soa ns nsec dnskey rrsig a.example. NSEC a.b.example. a txt nsec rrsig a.b.example. NSEC c.example. a txt nsec rrsig c.example. NSEC example. ns nsed rrsig These records indicate that there are 5 names in the zone, 4 of which have records. "b.example." does not have any records, not even an NSEC. A query for "b.example. A" would get 0 answer records, and "a.example. NSEC a.b.example. a txt nsec rrsig" in the authority section. The verifier can infer that b.example exists (since a.b.example exists) and that by "pointing" past b.example, the NSEC says there is nothing to see at b.example. At 14:11 +0000 4/17/06, paul@vix.com wrote: >folks, i think florian's got a valid point here. > >> From: Florian Weimer >> To: dns-operations@lists.oarci.net >> Date: Mon, 17 Apr 2006 11:16:26 +0200 >> Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing >> name >> >> * Paul Vixie: >> >> > to me, b.example.net exists because that's what we decided for dnssec, >> >> Post-RFC-4035, I assume? Because RFC 4035 says, in section 3.1.32: >> >> | Note that this form of response includes cases in which SNAME >> | corresponds to an empty non-terminal name within the zone (a name >> | that is not the owner name for any RRset but that is the parent name >> | of one or more RRsets). >> >> This also follows from the prohibition of NSEC generation for empty >> non-terminals (section 2.3, "An NSEC record (and its associated RRSIG >> RRset) MUST NOT be the only RRset at any particular owner name."), as >> you would need such an NSEC RR for responding with NODATA. This means >> that the draft-ietf-dnsext-wcard-clarify (thanks Peter and Edward!) is >> in conflict with DNSSEC (as a simple update of the DNSSEC spec is not >> possible). >> >> Ah, draft-ietf-dnsext-nsec3 handles this case differently, matching the >> draft-ietf-dnsext-wcard-clarify. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 13:42:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXjx-0006hI-RL for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 13:42:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXjx-00037t-Fr for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 13:42:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVXgY-000IOU-5M for namedroppers-data@psg.com; Mon, 17 Apr 2006 17:38:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVXgX-000IOC-6i for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 17:38:49 +0000 Received: from thangorodrim.hactrn.net (thangorodrim.hactrn.net [IPv6:2002:425c:4242:0:240:5ff:fe8f:8cf3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 97A8A63E; Mon, 17 Apr 2006 13:38:47 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 07DD911446; Mon, 17 Apr 2006 17:38:45 +0000 (UTC) Date: Mon, 17 Apr 2006 13:38:45 -0400 From: Rob Austein To: namedroppers@ops.ietf.org cc: Florian Weimer Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name In-Reply-To: References: <87psjkfrg5.fsf@mid.deneb.enyo.de> <87slogcpgi.fsf@mid.deneb.enyo.de> <36258.1145039666@sa.vix.com> <87y7y4a7f9.fsf@mid.deneb.enyo.de> <68956.1145283088@sa.vix.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060417173846.07DD911446@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 At Mon, 17 Apr 2006 10:47:46 -0400, Edward Lewis wrote: > > I will say I don't understand the last paragraph of 3.1.3.2 in 4035 > (as quoted by Florian). When it comes to name errors, empty > non-terminals need not apply. The text in question: Note that this form of response includes cases in which SNAME corresponds to an empty non-terminal name within the zone (a name that is not the owner name for any RRset but that is the parent name of one or more RRsets). DNSSECbis talks about existance and non-existance of -RRsets-; it does -not- talk about existance or nonexistance of -names-. The first paragraph of 3.1.3.2 describe the case covered by this kind of response: "the zone does not contain any RRsets matching either exactly or via wildcard name expansion". Ie, for the purposes described in 3.1.3.2, an empty node is an empty node ("name error") whether it's terminal or not. The proof described in 3.1.3.2 applies regardless of the RCODE. DNSSECbis does not cover the RCODE, that'd have to be covered by a channel security mechanism. This bugaboo about whether a name exists when there are no RRsets attached to it has been a source of confusion for twenty years. DNSSECbis takes pains to avoid it. Please don't reintroduce it. :) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 14:33:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVYXc-00083n-Tt for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 14:33:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVYXc-0005x6-Ef for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 14:33:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVYUA-000Mjb-M0 for namedroppers-data@psg.com; Mon, 17 Apr 2006 18:30:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVYU9-000Mix-Ed for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 18:30:05 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 17 Apr 2006 19:30:04 +0100 X-IronPort-AV: i="4.04,126,1144018800"; d="scan'208"; a="3067420:sNHT31123988" In-Reply-To: <68956.1145283088@sa.vix.com> To: namedroppers@ops.ietf.org Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Mon, 17 Apr 2006 20:30:15 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 04/17/2006 07:30:16 PM, Serialize complete at 04/17/2006 07:30:16 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Paul Vixie wrote on 04/17/2006 04:11:28 PM: > folks, i think florian's got a valid point here. > > (i'm not cross-posting, i'm changing mailing lists for this thread. i'll post > a summary back to dns-operations@ when namedroppers@ is done chewing on this.) > > re: > > > From: Florian Weimer > > To: dns-operations@lists.oarci.net > > Date: Mon, 17 Apr 2006 11:16:26 +0200 > > Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing > > name > > Sender: dns-operations-bounces@lists.oarci.net > > > > * Paul Vixie: > > > > > to me, b.example.net exists because that's what we decided for dnssec, > > > > Post-RFC-4035, I assume? Because RFC 4035 says, in section 3.1.32: > > > > | Note that this form of response includes cases in which SNAME > > | corresponds to an empty non-terminal name within the zone (a name > > | that is not the owner name for any RRset but that is the parent name > > | of one or more RRsets). > > > > This also follows from the prohibition of NSEC generation for empty > > non-terminals (section 2.3, "An NSEC record (and its associated RRSIG > > RRset) MUST NOT be the only RRset at any particular owner name."), as > > you would need such an NSEC RR for responding with NODATA. This means > > that the draft-ietf-dnsext-wcard-clarify (thanks Peter and Edward!) is > > in conflict with DNSSEC (as a simple update of the DNSSEC spec is not > > possible). > > > > Ah, draft-ietf-dnsext-nsec3 handles this case differently, maching the > > draft-ietf-dnsext-wcard-clarify. Yes. During the Dallas IETF dnsext wg meeting I gave a presentation (rfc4035 omissions) on this exact point. I noted that rfc4035's statement (3.1.3.2) is wrong. One example why this is wrong is that a resolver implementing negative caching will cease to resolve a.b.example if it previously received and cached a name error for the empty non-terminal b.example. regards, Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 14:39:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVYdd-0001gA-E7 for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 14:39:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVYdd-0006Bf-1w for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 14:39:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVYbR-000NMV-Ge for namedroppers-data@psg.com; Mon, 17 Apr 2006 18:37:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVYbQ-000NM6-D3 for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 18:37:36 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 17 Apr 2006 19:37:35 +0100 X-IronPort-AV: i="4.04,126,1144018800"; d="scan'208"; a="3490330:sNHT31429104" In-Reply-To: <20060417173846.07DD911446@thangorodrim.hactrn.net> To: namedroppers@ops.ietf.org Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Mon, 17 Apr 2006 20:37:46 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 04/17/2006 07:37:47 PM, Serialize complete at 04/17/2006 07:37:47 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Rob Austein wrote on 04/17/2006 07:38:45 PM: > At Mon, 17 Apr 2006 10:47:46 -0400, Edward Lewis wrote: > > > > I will say I don't understand the last paragraph of 3.1.3.2 in 4035 > > (as quoted by Florian). When it comes to name errors, empty > > non-terminals need not apply. > > The text in question: > > Note that this form of response includes cases in which SNAME > corresponds to an empty non-terminal name within the zone (a name > that is not the owner name for any RRset but that is the parent name > of one or more RRsets). > > DNSSECbis talks about existance and non-existance of -RRsets-; it does > -not- talk about existance or nonexistance of -names-. The first > paragraph of 3.1.3.2 describe the case covered by this kind of > response: "the zone does not contain any RRsets matching SCLASS> either exactly or via wildcard name expansion". If we're about to re-issue the term NAME ERROR to mean 'non-existance of RRsets" we should introduce a new rcode. Otherwise this is just confusing. > Ie, for the purposes described in 3.1.3.2, an empty node is an empty > node ("name error") whether it's terminal or not. The proof described > in 3.1.3.2 applies regardless of the RCODE. DNSSECbis does not cover > the RCODE, that'd have to be covered by a channel security mechanism. > > This bugaboo about whether a name exists when there are no RRsets > attached to it has been a source of confusion for twenty years. > DNSSECbis takes pains to avoid it. Please don't reintroduce it. :) This confuses even more. So, what do you suggest the rcode (yeah yeah unsigned) is on the specific response that is covered by rfc 4035 3.1.3.2 ? Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 14:48:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVYm3-0003sH-4E for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 14:48:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVYm1-0006Tk-Rg for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 14:48:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVYjs-000OF6-Pu for namedroppers-data@psg.com; Mon, 17 Apr 2006 18:46:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVYjq-000OEH-57 for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 18:46:18 +0000 Received: from [10.31.32.79] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3HIjwNP027653; Mon, 17 Apr 2006 14:45:59 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060417173846.07DD911446@thangorodrim.hactrn.net> References: <87psjkfrg5.fsf@mid.deneb.enyo.de> <87slogcpgi.fsf@mid.deneb.enyo.de> <36258.1145039666@sa.vix.com> <87y7y4a7f9.fsf@mid.deneb.enyo.de> <68956.1145283088@sa.vix.com> <20060417173846.07DD911446@thangorodrim.hactrn.net> Date: Mon, 17 Apr 2006 14:46:04 -0400 To: Rob Austein From: Edward Lewis Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name Cc: namedroppers@ops.ietf.org, Florian Weimer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 13:38 -0400 4/17/06, Rob Austein wrote: >Ie, for the purposes described in 3.1.3.2, an empty node is an empty >node ("name error") whether it's terminal or not. The proof described >in 3.1.3.2 applies regardless of the RCODE. DNSSECbis does not cover >the RCODE, that'd have to be covered by a channel security mechanism. My confusion is from the title of the section: "3.1.3.2. Including NSEC RRs: Name Error Response" When I read that I assume the section is all about situations with a return code of "name error." That's why I say that the quoted paragraph is oddly placed. >The quoted paragraph: > Note that this form of response includes cases in which SNAME > corresponds to an empty non-terminal name within the zone (a name > that is not the owner name for any RRset but that is the parent name > of one or more RRsets). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 15:14:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVZAi-0002T7-Qi for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 15:14:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVZAh-0007oN-En for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 15:14:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVZ8W-0000MG-ST for namedroppers-data@psg.com; Mon, 17 Apr 2006 19:11:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVZ8W-0000Km-02 for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 19:11:48 +0000 Received: from thangorodrim.hactrn.net (thangorodrim.hactrn.net [IPv6:2002:425c:4242:0:240:5ff:fe8f:8cf3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id C0C2E63E for ; Mon, 17 Apr 2006 15:11:46 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 756B6116B7 for ; Mon, 17 Apr 2006 19:11:44 +0000 (UTC) Date: Mon, 17 Apr 2006 15:11:42 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name In-Reply-To: References: <20060417173846.07DD911446@thangorodrim.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060417191144.756B6116B7@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 At Mon, 17 Apr 2006 20:37:46 +0200, Roy Arends wrote: > Rob Austein wrote on 04/17/2006 07:38:45 PM: > > > DNSSECbis talks about existance and non-existance of -RRsets-; it does > > -not- talk about existance or nonexistance of -names-. The first > > paragraph of 3.1.3.2 describe the case covered by this kind of > > response: "the zone does not contain any RRsets matching > SCLASS> either exactly or via wildcard name expansion". > > If we're about to re-issue the term NAME ERROR to mean 'non-existance of > RRsets" we should introduce a new rcode. Otherwise this is just confusing. None of the other three cases in 3.1.3 exactly corresponds to an RCODE. Why do you expect that this one will? People, please -read- the entire section (3.1.3 and its children). The cases (all four of them) are spelled out, and nowhere does it say that -any- of this corresponds to any particular RCODE. I guess some text about this (that these cases do not correspond to RCODEs) needs to go into the bis clarification doc, since apparently people are reading this as isolated paragraphs without checking the immediately preceding definitions. > So, what do you suggest the rcode (yeah yeah unsigned) is on the specific > response that is covered by rfc 4035 3.1.3.2 ? RCODE zero or three, depending on whether the name is an empty nonterminal or not, not that a validating resolver should care. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 15:38:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVZYA-0007uo-U3 for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 15:38:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVZY9-0000KI-Im for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 15:38:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVZVg-0002Yo-SQ for namedroppers-data@psg.com; Mon, 17 Apr 2006 19:35:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVZVg-0002YV-8q for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 19:35:44 +0000 Received: from [10.31.32.79] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3HJZPRA027975; Mon, 17 Apr 2006 15:35:25 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060417191144.756B6116B7@thangorodrim.hactrn.net> References: <20060417173846.07DD911446@thangorodrim.hactrn.net> <20060417191144.756B6116B7@thangorodrim.hactrn.net> Date: Mon, 17 Apr 2006 15:35:30 -0400 To: Rob Austein From: Edward Lewis Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 At 15:11 -0400 4/17/06, Rob Austein wrote: >People, please -read- the entire section (3.1.3 and its children). >The cases (all four of them) are spelled out, and nowhere does it say >that -any- of this corresponds to any particular RCODE. After doing that, I would conclude the 3.1.3 needs more work. Not in content, but in language. At least make "Name Error" mean the same thing in RFC 1035/1034 as in RFC 4035. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 15:51:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVZkT-0005Gn-Bf for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 15:51:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVZkT-0000oB-1x for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 15:51:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVZhw-0003nq-Nq for namedroppers-data@psg.com; Mon, 17 Apr 2006 19:48:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVZhv-0003nS-N7; Mon, 17 Apr 2006 19:48:23 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 17 Apr 2006 20:48:22 +0100 X-IronPort-AV: i="4.04,126,1144018800"; d="scan'208"; a="3067620:sNHT32500504" In-Reply-To: <20060417191144.756B6116B7@thangorodrim.hactrn.net> To: Rob Austein Cc: namedroppers@ops.ietf.org, owner-namedroppers@ops.ietf.org Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Mon, 17 Apr 2006 21:48:33 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 04/17/2006 08:48:34 PM, Serialize complete at 04/17/2006 08:48:34 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 owner-namedroppers@ops.ietf.org wrote on 04/17/2006 09:11:42 PM: > At Mon, 17 Apr 2006 20:37:46 +0200, Roy Arends wrote: > > Rob Austein wrote on 04/17/2006 07:38:45 PM: > > > > > DNSSECbis talks about existance and non-existance of -RRsets-; it does > > > -not- talk about existance or nonexistance of -names-. The first > > > paragraph of 3.1.3.2 describe the case covered by this kind of > > > response: "the zone does not contain any RRsets matching > > SCLASS> either exactly or via wildcard name expansion". > > > > If we're about to re-issue the term NAME ERROR to mean 'non-existance of > > RRsets" we should introduce a new rcode. Otherwise this is just confusing. > > None of the other three cases in 3.1.3 exactly corresponds to an > RCODE. Why do you expect that this one will? Because NAME ERROR (in the 3.1.3.2 section title) is an explicit rcode. > People, please -read- the entire section (3.1.3 and its children). > The cases (all four of them) are spelled out, and nowhere does it say > that -any- of this corresponds to any particular RCODE. Confusion happens when a document redefines (or re-uses) the term NAME ERROR, but apparently not talking about the rcode..... > I guess some text about this (that these cases do not correspond to > RCODEs) needs to go into the bis clarification doc, since apparently > people are reading this as isolated paragraphs without checking the > immediately preceding definitions. This is a wrong assumption. Wrt including NSEC in a response I expect that the sections under 3.1.3 would cover all different response types including the NOERROR/NODATA response for an empty non-terminal. This NOERROR/NODATA response type is under the section that deals with (some definition of) NAME ERROR. > > So, what do you suggest the rcode (yeah yeah unsigned) is on the specific > > response that is covered by rfc 4035 3.1.3.2 ? > > RCODE zero or three, depending on whether the name is an empty > nonterminal or not, not that a validating resolver should care. The validating resolver might not care. But something talking to it might care. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 16:17:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVaAD-0006f2-De for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 16:17:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVaAD-0002zr-2H for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 16:17:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVa8E-0006ao-CR for namedroppers-data@psg.com; Mon, 17 Apr 2006 20:15:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVa8D-0006aS-EF for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 20:15:33 +0000 Received: from thangorodrim.hactrn.net (thangorodrim.hactrn.net [IPv6:2002:425c:4242:0:240:5ff:fe8f:8cf3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 33A4563E for ; Mon, 17 Apr 2006 16:15:32 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 78BB91144E for ; Mon, 17 Apr 2006 20:15:26 +0000 (UTC) Date: Mon, 17 Apr 2006 16:15:25 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name In-Reply-To: References: <20060417173846.07DD911446@thangorodrim.hactrn.net> <20060417191144.756B6116B7@thangorodrim.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060417201527.78BB91144E@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 At Mon, 17 Apr 2006 15:35:30 -0400, Edward Lewis wrote: > > At 15:11 -0400 4/17/06, Rob Austein wrote: > > >People, please -read- the entire section (3.1.3 and its children). > >The cases (all four of them) are spelled out, and nowhere does it say > >that -any- of this corresponds to any particular RCODE. > > After doing that, I would conclude the 3.1.3 needs more work. Not in > content, but in language. At least make "Name Error" mean the same > thing in RFC 1035/1034 as in RFC 4035. Well, the conditions in 3.1.3 don't exactly map to anything from RFC 1035. As Roy may recall, at one point the DNSSECbis drafts had made up terms for all of these, for precisely this reason. We changed to the current wording because the made up terms were unreadable. So, while accepting your criticism, I'd phrase it a bit differently. Serious question: what would you suggest as names for the four DNSSECbis-specific conditions described in 3.1.3 and its children? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 16:49:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVafW-0007ZN-Ij for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 16:49:58 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVafW-0004Vj-9a for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 16:49:58 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVadM-0009yV-Fo for namedroppers-data@psg.com; Mon, 17 Apr 2006 20:47:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVadL-0009y0-H5 for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 20:47:43 +0000 Received: from [10.31.32.79] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3HKlNCS028554; Mon, 17 Apr 2006 16:47:24 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20060417201527.78BB91144E@thangorodrim.hactrn.net> References: <20060417173846.07DD911446@thangorodrim.hactrn.net> <20060417191144.756B6116B7@thangorodrim.hactrn.net> <20060417201527.78BB91144E@thangorodrim.hactrn.net> Date: Mon, 17 Apr 2006 16:47:23 -0400 To: Rob Austein From: Edward Lewis Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 16:15 -0400 4/17/06, Rob Austein wrote: >So, while accepting your criticism, I'd phrase it a bit differently. >Serious question: what would you suggest as names for the four >DNSSECbis-specific conditions described in 3.1.3 and its children? I understand that desire to divorce the notion of names existence from RRset existence because of how negative answers work in DNSSEC, but I think you can't. Well, completely divorce them, that is. My personal way to classify the cases is: 1) For return code of "name error" - NSECs are needed proving that neither the sought name nor a source of synthesis exists. 2) For an answer count of 0 - NSECs are needed proving that either the sought name exists without a matching set or the triple of the sought name does not exist, a source of synthesis does, and there is no matching set (from which to synthesize). 3) For synthesized answers - NSECs are needed proving that the sought name does not exist but that there is a source of synthesis with a matching set (from which to synthesize). I have three cases because the "answer count of 0" includes two of the original four cases. (Mind you, this is all textual, the underlying content is okay.) As DNSSEC is an extension to the base protocol, if we can show the extensions as building upon the response messages, we'll likely have a cleaner description. (Granted, that's a hypothetical statement.) Likely - because we may discover hidden inconsistencies in the base specification as in the conflict of an NS RRset at a source of synthesis. Of course, this is one way to answer this. Maybe tomorrow I'd have answered differently. The perspective I've adopted is from the protocol's architecture. It might be better to describe this from the protocol server's state machine. But that might be too obtuse as none of the rest of the documents use that perspective. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 17:13:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVb2B-0008Q4-3N for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 17:13:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVb2A-0005gY-Qu for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 17:13:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVazV-000CYf-Ts for namedroppers-data@psg.com; Mon, 17 Apr 2006 21:10:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVazV-000CYQ-4c for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 21:10:37 +0000 Received: from thangorodrim.hactrn.net (thangorodrim.hactrn.net [IPv6:2002:425c:4242:0:240:5ff:fe8f:8cf3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id CC7CD1AA for ; Mon, 17 Apr 2006 17:10:35 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id A79A611460 for ; Mon, 17 Apr 2006 21:10:28 +0000 (UTC) Date: Mon, 17 Apr 2006 17:10:27 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name In-Reply-To: References: <20060417173846.07DD911446@thangorodrim.hactrn.net> <20060417191144.756B6116B7@thangorodrim.hactrn.net> <20060417201527.78BB91144E@thangorodrim.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20060417211029.A79A611460@thangorodrim.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab The organization we used in RFC 4035 is based on grouping the cases that return identical NSEC attestations together. I may be missing something, but Ed's three case grouping doesn't appear to do that, thus to my mind is at least as confusing as the current text. Note that even before DNSSEC we were well down the path of protocol that had to be deduced from the packet rather than just being read off cleanly (see, for example, the gyrations that Mark had to go through in classifying RCODE 3 responses in RFC 2308). That said, Roy's recent work on null-hash NSEC3 suggests that we may want to rethink the explanation of the attestations we're supplying anyway. If I understand Roy's work correctly, his claim is that, in one or more of the cases where RFC 4035 says there are two things we have to prove, there are really three things we have to prove, and it's just an accident of ordering that always lets us prove all three things with at most two NSEC RRs. Might be worth thinking through how we'd like to explain all this for the bis-updates document. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 17 18:54:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcbp-0002IG-B5 for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 18:54:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcbo-0002LP-Sr for dnsext-archive@lists.ietf.org; Mon, 17 Apr 2006 18:54:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVcXm-000KO9-8d for namedroppers-data@psg.com; Mon, 17 Apr 2006 22:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVcXj-000KN5-TR for namedroppers@ops.ietf.org; Mon, 17 Apr 2006 22:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3HMo29W004314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FVcXi-0005HV-2X; Mon, 17 Apr 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-46.txt Message-Id: Date: Mon, 17 Apr 2006 18:50:02 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : B. Aboba, et al. Filename : draft-ietf-dnsext-mdns-46.txt Pages : 30 Date : 2006-4-17 The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-46.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also 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-dnsext-mdns-46.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-46.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: <2006-4-17154429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-46.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-46.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-17154429.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 18 12:03:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVsfQ-000324-RN for dnsext-archive@lists.ietf.org; Tue, 18 Apr 2006 12:03:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVsfQ-0006vD-G8 for dnsext-archive@lists.ietf.org; Tue, 18 Apr 2006 12:03:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVsa2-000NrQ-Ce for namedroppers-data@psg.com; Tue, 18 Apr 2006 15:57:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.23] (helo=mx3.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVsa0-000NrE-SP for namedroppers@ops.ietf.org; Tue, 18 Apr 2006 15:57:29 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 18 Apr 2006 16:57:28 +0100 X-IronPort-AV: i="4.04,131,1144018800"; d="scan'208"; a="3498969:sNHT34140944" In-Reply-To: <20060417211029.A79A611460@thangorodrim.hactrn.net> To: namedroppers@ops.ietf.org Subject: proving NAME ERROR (was: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 18 Apr 2006 17:57:41 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 04/18/2006 04:57:41 PM, Serialize complete at 04/18/2006 04:57:41 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Rob Austein wrote on 04/17/2006 11:10:27 PM: > That said, Roy's recent work on null-hash NSEC3 suggests that we may > want to rethink the explanation of the attestations we're supplying > anyway. If I understand Roy's work correctly, his claim is that, in > one or more of the cases where RFC 4035 says there are two things we > have to prove, there are really three things we have to prove, and > it's just an accident of ordering that always lets us prove all three > things with at most two NSEC RRs. Might be worth thinking through how > we'd like to explain all this for the bis-updates document. This is what Rob referred to: During the NSEC3 pre-workshop, we determined that the content of NSEC3's when using the identity hash (effectively no hashing at all) are essentially the same as NSEC. And thus the method (proving absence) used for NSEC3 must work on NSEC as well. It does work, and I'll try to describe here how. The 'closest encloser' (CE) is the magic word. The CE is the nearest existing ancestor of QNAME. This terminology was introduced by Ed's wildcard-clarify draft. Ben invented this specific proving method (mistakes below are all mine). Proving method: In order to prove nonexistence of QNAME: assert the CE and prove that assertion. A two step process. 1) Assert CE using an NSEC record. Since all NSEC records in a response show the same CE (that is a fact, not a requirement), pick any. Given an NSEC and a QNAME, the CE is asserted as follows: Function NCA = Nearest Common Ancestor (NAME, NAME). CE = longest( NCA(NSEC ownername,QNAME), NCA(NSEC nxtdname,QNAME)) 2) To prove asserted CE, prove nonexistence of immediate descendent of CE relative to QNAME. Since the CE is now known, it is trivial to prove the nonexistence of a matching wildcard. (which is *.CE) As an example resolver queries server for a.b.c.example A server is authoritative for: ZONE: example.com SOA ... example.com NS c.example.com example.com NSEC c.example.com c.example.com A c.example.com NSEC example.com ... The server responds: QNAME: a.b.c.example.com auth: c.example.com NSEC example.com 1) validator asserts CE: CE = longest ( NCA(c.example.com, a.b.c.example.com), NCA(example.com, a.b.c.example.com)) -> CE = longest (c.example.com, example.com) -> CE = c.example.com The asserted CE is c.example.com 2) prove that b.c.example.com does not exist (immidiate descendant of CE (CE is c.example.com) relative to QNAME (QNAME is a.b.c.example.com)) this is proven by the NSEC record: c.example.com NSEC example.com since we have proven that b.c.example.com does not exist, we can infer that a.b.c.example.com does not exist as well. The two NSEC's used in (1) and (2) are always the same since the canonical ordering of names in the zone is exactly the same as the NSEC chain. This is not the case for NSEC3. For NSEC3, asserting the CE is done by taking QNAME and continuesly stripping the leftmost label of the QNAME, hash it and match it with all NSEC3's ownernames in a response (until the stripped qname is equal to the signers name, see NSEC3 draft for the specifics). So, all in all. With NSEC, A NAME ERROR (rcode=3) response has at most 2 NSECs. One to prove CE and one to prove absence of *.CE. With NSEC3, a NAME ERROR (rcode=3) response has at most 3 NSEC3s. One to assert the CE, one to prove the CE and one to prove the absence of *.CE. I say at most, since for both NSEC and NSEC3 it is true that less NSEC(3)s might be sufficient to satisfy the CE proof, the absence of *.CE and (in the NSEC3 case) the assertion of the CE. What a validator really needs to prove is everything in step 2 and 3 of the server algorithm in rfc1034 4.3.2. This might be a good approach for the bis-updates draft. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 18 16:15:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVwbG-0003Td-FM for dnsext-archive@lists.ietf.org; Tue, 18 Apr 2006 16:15:02 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVwbF-0003wa-Ud for dnsext-archive@lists.ietf.org; Tue, 18 Apr 2006 16:15:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVwXQ-000GE0-LX for namedroppers-data@psg.com; Tue, 18 Apr 2006 20:11:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVwXP-000GDp-Gf for namedroppers@ops.ietf.org; Tue, 18 Apr 2006 20:11:03 +0000 Received: from [10.31.32.79] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3IKAkL9035534; Tue, 18 Apr 2006 16:10:47 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 18 Apr 2006 16:10:51 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: proving NAME ERROR (was: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name) Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 I'm going to respond to this email before reading all of it - as a thought exercise. At 17:57 +0200 4/18/06, Roy Arends wrote: >During the NSEC3 pre-workshop, we determined that the content of NSEC3's >when using the identity hash (effectively no hashing at all) are >essentially the same as NSEC. And thus the method (proving absence) used >for NSEC3 must work on NSEC as well. It does work, and I'll try to >describe here how. Off the cuff, I don't think that's a valid assertion. The reason is that NSEC deals with identities in tree-space, NSEC3 deals with identities in a flattened space. I.e., you can tell how a.b.c.example. and c.example. are related according to the tree, but what can you tell about 1294753.example. and 938424.example.? (I attached "example" to illustrate that these are domain names.) ...For those following the exercise, this is not a conclusion, but my hypothesis is that NSEC3 with a null salt is not a good indicator of NSEC3 with a salt. >The 'closest encloser' (CE) is the magic word. The CE is the nearest >existing ancestor of QNAME. This terminology was introduced by Ed's >wildcard-clarify draft. Ben invented this specific proving method >(mistakes below are all mine). I agree that the CE is the clue you need. But when comparing the hash of the name desired and the hash of its CE, what can you tell from two seemingly random numbers? >is not the case for NSEC3. For NSEC3, asserting the CE is done by taking >QNAME and continuesly stripping the leftmost label of the QNAME, hash it >and match it with all NSEC3's ownernames in a response (until the stripped >qname is equal to the signers name, see NSEC3 draft for the specifics). So, you are counting on the validator having to pick up the slack, i.e., having to do more work to confirm the structure of the tree-space from the flattened hash-space, relying on the constrained nature of domain relationships. (Aka, guess-and-test.) What if the zone is multi-label deep? example. *.example. a.b.c.d.example. z.x.c.d.example. e.f.g.h.example. i.j.g.h.example. And I query for a.b.c.d.e.g.g.h.example.? I should get (NSEC-speak): z.x.c.d.example. NSEC e.f.g.h.example. to prove that the name isn't there, plus establish g.h.example. as the CE. The CE is an empty non-terminal. To show that there is no *.g.h.example., well, I have already done that here, as it takes the same record. NSEC3 (still) adds records to the empty non-terminals, right? Let's assume this hash value table then: example. 21 *.example. 39 d.example. 12 c.d.example. 23 b.c.d.example. 48 a.b.c.d.example. 14 x.c.d.example. 2 z.x.c.d.example. 10 h.example. 26 g.h.example. 13 f.g.h.example. 17 e.f.g.h.example. 5 j.g.h.example. 11 i.j.g.h.example. 4 I also need to define these hashes as these are the ones the validator has to guess. g.g.h.example. 8 e.g.g.h.example. 22 d.e.g.g.h.example. 19 c.d.e.g.g.h.example. 6 b.c.d.e.g.g.h.example. 50 a.b.c.d.e.g.g.h.example. 30 So I would need: 13 NSEC3 14 to show there's a g.h.example. 5 NSEC3 10 to show there's no g....=8 21 NSEC3 22 to show there's no e.g...=22 17 NSEC3 21 to show there's no d.e.g...=19 I've already shown there's no c.d.e.g.g...=6 48 NSEC3 2 to show there's no b.c.d.e.g.g...=50 26 NSEC3 39 to show there's no a.b.c.d.e.f.g...=30 Note that "z.x.c.d.example. NSEC e.f.g.h.example." proves all of that in one. That's 6 NSEC's to show the CE and prove it is a CE. (The * proof is trivial.) The problem is that the hashing "destroys" the efficiency of hierarchy. There are details of the records too, zone cut things. But I'll stop here and let someone pick apart my faulty logic. (I feel deju vu here - I think I typed this message a few years ago too. I know I did, but I can't find it easily in the archives.) >So, all in all. With NSEC, A NAME ERROR (rcode=3) response has at most 2 >NSECs. One to prove CE and one to prove absence of *.CE. Either way, that's the goal, in showing that the algorithm of 4.3.2. is properly followed. PS - A CE can own an NS set without an SOA set only when the query type is DS and maybe NSEC and RRSIG. Humph. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 18 16:46:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVx61-0001oW-39 for dnsext-archive@lists.ietf.org; Tue, 18 Apr 2006 16:46:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVx5z-0005UY-Fd for dnsext-archive@lists.ietf.org; Tue, 18 Apr 2006 16:46:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVx3m-000IKf-Lo for namedroppers-data@psg.com; Tue, 18 Apr 2006 20:44:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.248.199.24] (helo=mx4.nominet.org.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVx3k-000IKR-Vs for namedroppers@ops.ietf.org; Tue, 18 Apr 2006 20:44:29 +0000 Received: from wds1.okna.nominet.org.uk (HELO notes1.nominet.org.uk) ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Apr 2006 21:44:27 +0100 X-IronPort-AV: i="4.04,131,1144018800"; d="scan'208"; a="3078712:sNHT35838324" In-Reply-To: To: namedroppers@ops.ietf.org Subject: Re: proving NAME ERROR (was: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Roy Arends Date: Tue, 18 Apr 2006 22:44:40 +0200 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 6.5.3|September 14, 2004) at 04/18/2006 09:44:41 PM, Serialize complete at 04/18/2006 09:44:41 PM Content-Type: text/plain; charset="US-ASCII" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Ed Lewis wrote on 04/18/2006 10:10:51 PM: > I'm going to respond to this email before reading all of it - as a > thought exercise. > > At 17:57 +0200 4/18/06, Roy Arends wrote: > > >During the NSEC3 pre-workshop, we determined that the content of NSEC3's > >when using the identity hash (effectively no hashing at all) are > >essentially the same as NSEC. And thus the method (proving absence) used > >for NSEC3 must work on NSEC as well. It does work, and I'll try to > >describe here how. > > Off the cuff, I don't think that's a valid assertion. The reason is > that NSEC deals with identities in tree-space, NSEC3 deals with > identities in a flattened space. I.e., you can tell how > a.b.c.example. and c.example. are related according to the tree, but > what can you tell about 1294753.example. and 938424.example.? (I > attached "example" to illustrate that these are domain names.) > For the method I tried to show it does not matter. The method is: assert a CE and prove it. Asserting the CE is done differently for NSEC than for NSEC3. I was not trying to describe a general one size fits all magic algorithm. > ...For those following the exercise, this is not a conclusion, but my > hypothesis is that NSEC3 with a null salt is not a good indicator of > NSEC3 with a salt. > > >The 'closest encloser' (CE) is the magic word. The CE is the nearest > >existing ancestor of QNAME. This terminology was introduced by Ed's > >wildcard-clarify draft. Ben invented this specific proving method > >(mistakes below are all mine). > > I agree that the CE is the clue you need. But when comparing the > hash of the name desired and the hash of its CE, what can you tell > from two seemingly random numbers? > > >is not the case for NSEC3. For NSEC3, asserting the CE is done by taking > >QNAME and continuesly stripping the leftmost label of the QNAME, hash it > >and match it with all NSEC3's ownernames in a response (until the stripped > >qname is equal to the signers name, see NSEC3 draft for the specifics). > > So, you are counting on the validator having to pick up the slack, > i.e., having to do more work to confirm the structure of the > tree-space from the flattened hash-space, relying on the constrained > nature of domain relationships. (Aka, guess-and-test.) > > What if the zone is multi-label deep? > > example. > *.example. > a.b.c.d.example. > z.x.c.d.example. > e.f.g.h.example. > i.j.g.h.example. > > And I query for a.b.c.d.e.g.g.h.example.? > > I should get (NSEC-speak): > > z.x.c.d.example. NSEC e.f.g.h.example. to prove that the name isn't > there, plus establish g.h.example. as the CE. The CE is an empty > non-terminal. To show that there is no *.g.h.example., well, I have > already done that here, as it takes the same record. 'zactly. > NSEC3 (still) adds records to the empty non-terminals, right? Right. > Let's assume this hash value table then: > > example. 21 > *.example. 39 > d.example. 12 > c.d.example. 23 > b.c.d.example. 48 > a.b.c.d.example. 14 > x.c.d.example. 2 > z.x.c.d.example. 10 > h.example. 26 > g.h.example. 13 > f.g.h.example. 17 > e.f.g.h.example. 5 > j.g.h.example. 11 > i.j.g.h.example. 4 > > I also need to define these hashes as these are the ones the > validator has to guess. > > g.g.h.example. 8 > e.g.g.h.example. 22 > d.e.g.g.h.example. 19 > c.d.e.g.g.h.example. 6 > b.c.d.e.g.g.h.example. 50 > a.b.c.d.e.g.g.h.example. 30 > > So I would need: > > 13 NSEC3 14 to show there's a g.h.example. > 5 NSEC3 10 to show there's no g....=8 > 21 NSEC3 22 to show there's no e.g...=22 > 17 NSEC3 21 to show there's no d.e.g...=19 > I've already shown there's no c.d.e.g.g...=6 > 48 NSEC3 2 to show there's no b.c.d.e.g.g...=50 > 26 NSEC3 39 to show there's no a.b.c.d.e.f.g...=30 Wrong. The response would include 13 NSEC3 14 to show there's a g.h.example. 5 NSEC3 10 to show there's no g.g.h.example. And that is the beauty of the closest encloser. Since you've proved that g.h.example is the closest encloser, by showing g.g.h.example does not exist, you don't have to prove anything CLOSER exist. Since there is no g.... there is no e.g... no d.e.g etc etc etc. > Note that "z.x.c.d.example. NSEC e.f.g.h.example." proves all of that in one. Sure. > That's 6 NSEC's to show the CE and prove it is a CE. No. I guess you misunderstood the general concept. > (The * proof is > trivial.) The problem is that the hashing "destroys" the efficiency > of hierarchy. > > There are details of the records too, zone cut things. But I'll stop > here and let someone pick apart my faulty logic. Hope I've done it. Please read the NSEC3 draft. > (I feel deju vu here - I think I typed this message a few years ago > too. I know I did, but I can't find it easily in the archives.) > > >So, all in all. With NSEC, A NAME ERROR (rcode=3) response has at most 2 > >NSECs. One to prove CE and one to prove absence of *.CE. > > Either way, that's the goal, in showing that the algorithm of 4.3.2. > is properly followed. Roy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 19 11:34:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWEgt-0003BQ-5E for dnsext-archive@lists.ietf.org; Wed, 19 Apr 2006 11:34:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWEgr-0000eT-Qi for dnsext-archive@lists.ietf.org; Wed, 19 Apr 2006 11:34:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWEc3-000C39-2V for namedroppers-data@psg.com; Wed, 19 Apr 2006 15:29:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWEc2-000C2P-6A for namedroppers@ops.ietf.org; Wed, 19 Apr 2006 15:29:02 +0000 Received: from Puki.ogud.com (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3JFSsxI041164 for ; Wed, 19 Apr 2006 11:28:54 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <6.2.5.6.2.20060419112703.0360c490@ogud.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 19 Apr 2006 11:28:55 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= /DNSEXT co-chair Subject: Draft minutes posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 I posted the draft minutes on meetings web site: http://www3.ietf.org/proceedings/06mar/minutes/dnsext.txt Please send in any comments or corrections before noon (eastern) on Friday. Sorry for the late posting. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Apr 19 12:52:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWFus-0007Kx-AR for dnsext-archive@lists.ietf.org; Wed, 19 Apr 2006 12:52:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWFuq-00048q-VB for dnsext-archive@lists.ietf.org; Wed, 19 Apr 2006 12:52:34 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWFr9-000His-OK for namedroppers-data@psg.com; Wed, 19 Apr 2006 16:48:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWFr8-000HiZ-Rn for namedroppers@ops.ietf.org; Wed, 19 Apr 2006 16:48:43 +0000 Received: from [192.168.1.101] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3JGmWDu041520; Wed, 19 Apr 2006 12:48:33 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 19 Apr 2006 12:48:39 -0400 To: Roy Arends From: Edward Lewis Subject: Re: proving NAME ERROR (was: Re: [dns-operations] NXDOMAIN vs NODATA for suffixes of existing name) Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 22:44 +0200 4/18/06, Roy Arends wrote: >The response would include > >13 NSEC3 14 to show there's a g.h.example. >5 NSEC3 10 to show there's no g.g.h.example. > >And that is the beauty of the closest encloser. Since you've proved that >g.h.example is the closest encloser, by showing g.g.h.example does not >exist, you don't have to prove anything CLOSER exist. Okay, it's not as bad as I thought. The second NSEC3 record to me is a significant difference from the NSEC approach, the difference is caused by losing the tree structure in hashing. I still wonder what the impact of the validator's guessing of the "meaning" of the CE hash will be on performance, as well as the rules at the cut points. (The latter is also a problem with the NSEC, you need to know if you have the upper or lower NSEC in the proof and if it is the right one.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From bob_ohio2000@realestateagentnc.com Thu Apr 20 09:20:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWZ5A-00068e-Rl for dnsext-archive@ietf.org; Thu, 20 Apr 2006 09:20:28 -0400 Received: from [60.1.58.84] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FWZ58-0007PL-PD for dnsext-archive@ietf.org; Thu, 20 Apr 2006 09:20:28 -0400 Message-ID: <000001c664a7$9d6b2a80$0100007f@localhost> From: "Zion Perry" To: Subject: Need S0ftware? Date: Thu, 20 Apr 2006 21:20:18 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C664A7.9D6B2A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.5 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C664A7.9D6B2A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C664A7.9D6B2A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C664A7.9D6B2A80-- From owner-namedroppers@ops.ietf.org Fri Apr 21 23:15:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX8aS-0008DM-JP for dnsext-archive@lists.ietf.org; Fri, 21 Apr 2006 23:15:08 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX8aR-0001fO-5r for dnsext-archive@lists.ietf.org; Fri, 21 Apr 2006 23:15:08 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FX8Uw-000IYf-VI for namedroppers-data@psg.com; Sat, 22 Apr 2006 03:09:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FX8Uv-000IYO-Rd for namedroppers@ops.ietf.org; Sat, 22 Apr 2006 03:09:26 +0000 Received: from [172.16.69.155] (ns.ogud.com [66.92.146.160]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3M393ir057539; Fri, 21 Apr 2006 23:09:07 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Sat, 22 Apr 2006 05:09:03 +0200 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: NSEC3 draft comments Cc: ed.lewis@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Random comments on: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-04.txt At the bottom of section 7: When validating a NOERROR/NODATA response, validators MUST check for a NSEC3 RRset with ownername equals to QNAME, and MUST accept that (validated) NSEC3 RRset as proof that QNAME exists. The validator MUST also check for an NSEC3 RRset that covers the hash of QNAME as proof that QTYPE doesn't exist. With all the recent haggling over CNAME, well, CNAMEs do count in the answer count, so strictly it's not "NoERROR/NoData". But you can have a lookup return negatively without a NSEC(3) for the QNAME. In 8.1 In order to prove there exist no RRs for a domain, as well as no source of synthesis, an RR must be shown for the closest encloser, and non-existence must be shown for all closer labels and for the wildcard at the closest encloser. "for all closer labels"...that is misleading. You only have to show that the domain one label below the CE on the would-be path to the sought name is non-existent. Also, the "wildcard" is not "at" the CE, but is one (asterisk) label below. I can interpret the paragraph a few different ways, but I think you are trying to say "there is no RRset to respond to a query" and not "there exist no RRs for a domain." In reality, no one every checks for there being no RRsets at a domain, they check the validity of a response. This can be done as follows. If the QNAME in the query is omega.alfa.beta.example, and the closest encloser is beta.example (the nearest ancestor to omega.alfa.beta.example), then the server should return an NSEC3 that demonstrates the nonexistence of alfa.beta.example, an NSEC3 that demonstrates the nonexistence of *.beta.example, and an NSEC3 that demonstrates the existence of beta.example. This takes between one and three NSEC3 records, since a single record can, by chance, prove more than one of these facts. This is for a name error...the other interpretation of the previous. In practice, never try to analyze a query without including the type. You can pretty much ignore the class as all classes act the same, but types do behave differently. (DS, anyone?) It's true that DNS does do a two-part search, name first, then type. But you need to consider both to get understand what's in a response. The section 8.1 name "Proving non-existence" ought to be "Validating a Name Error response. In: 8.4.2. Second Preimage Requirement Analysis A cryptographic hash function has a second-preimage resistance property. Someone needs to explain what that means. Either in the document or via a reference. (In general, the doc needs to have more references, like whenever a term is used that is not defined local to the doc.) Okay, there is a definition of second-preimage following, but in the first sentence, is the meaning that all functions have this? Maybe this section needs to be restructured to say what the point is to an DNS protocol engineer. Like, it's remotely possible that a second name could hash to the same value as the first, and if an attacker wants to shutdown access to the first, it uses the second's hash to do this. With different salts and iterations in a zone, doesn't this increase the likelyhood of a second-preimage? Skipping ahead ('cuz I need an example): In the above example, the name 'x.w.example' hashes to '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might But above that is 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 ( deadbeaf dw4o7j64wnel3j4jh7fb3c5n7w3js2yb MX NSEC3 RRSIG ) So, x.w hashes to the 7nom...a2 value, not the x.w.example. Multi-label names are in the hash? Not individual labels? This means that the NSEC3 for the upper part of a cut point will have a different name than the NSEC3 for the lower part of a cut point. E.g., for a cutpoint named abc.def.example. will have hashvalue1.example. NSEC3 .... NS, no SOA, ... and hashvalue2.abc.def.example. NSEC3 .... NS SOA ... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Nothin' more exciting than going to the printer to watch the toner drain... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Apr 24 22:23:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYDDV-0006Cb-FO for dnsext-archive@lists.ietf.org; Mon, 24 Apr 2006 22:23:53 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYDDT-00029h-Oo for dnsext-archive@lists.ietf.org; Mon, 24 Apr 2006 22:23:53 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYD7h-000Kwx-M3 for namedroppers-data@psg.com; Tue, 25 Apr 2006 02:17:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO, HEADER_SPAM autolearn=no version=3.1.1 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYD7g-000Kwh-1m for namedroppers@ops.ietf.org; Tue, 25 Apr 2006 02:17:52 +0000 Received: from mail.ogud.com (localhost [127.0.0.1]) by ogud.com (8.13.1/8.13.1) with ESMTP id k3P2HfQa080782 for ; Mon, 24 Apr 2006 22:17:42 -0400 (EDT) (envelope-from namedroppers@mail.ogud.com) Received: (from namedroppers@localhost) by mail.ogud.com (8.13.1/8.13.1/Submit) id k3P2HfBl080781 for namedroppers@ops.ietf.org; Mon, 24 Apr 2006 22:17:41 -0400 (EDT) (envelope-from namedroppers) Received: from [66.119.143.51] (helo=mail.rfburst.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSMB8-000D3D-Gu for namedroppers@ops.ietf.org; Sat, 08 Apr 2006 22:45:14 +0000 Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k38Mj670004760 for ; Sat, 8 Apr 2006 16:45:07 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k38MkHSg022305 for ; Sat, 8 Apr 2006 16:46:17 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k38MkH3Q022301; Sat, 8 Apr 2006 16:46:17 -0600 Date: Sat, 8 Apr 2006 16:46:17 -0600 Message-Id: <200604082246.k38MkH3Q022301@localhost.localdomain> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: namedroppers@ops.ietf.org In-reply-to: Yourmessage <44383617.3090202@algroup.co.uk> Subject: Re: Pending issues for draft-ietf-dnsext-rollover-requirements-00 X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu X-Scanned-By: MIMEDefang 2.56 on 66.92.146.160 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 [ Moderators note: Post was moderated, either because it was posted by a non-subscriber, or because it was over 20K. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subscribers. Please fix your subscription addresses. ] The problem of definitions containing requirements is part of "presentation flaws". Other flaws include at least one unused definition, a definition that contradicts requirements, and an unfortunate ordering of definitions (alphabetical, which causes most definitions to depend on other definitions appearing later in the ordering). Ben Laurie wrote: > Suresh Krishnaswamy wrote: > > In a short while I'll be sending out a list of pending issues (currently > > 7 in number) for draft-ietf-dnsext-rollover-requirements-00. All of > > these issues were extracted from e-mails that were sent to namedroppers > > relative to this topic over the last month. > > > > Sample text appears in most places. If you don't agree with the wording > > in the sample text please speak up. In places where there is no sample > > text, silence will be interpreted as an implicit agreement by the > > Working Group to close this issue without further changes. > > > > The hope is to have each of these issues resolved over the next two > > weeks so that the next version of the requirements draft can be rolled > > out and last-called in the relatively near future. > The issue that some of the definitions are actually requirements appears > to have been dropped. > Cheers, > Ben. Hilarie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Apr 25 07:10:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYLRP-0005qM-Hg for dnsext-archive@lists.ietf.org; Tue, 25 Apr 2006 07:10:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYJQn-0002HV-VQ for dnsext-archive@lists.ietf.org; Tue, 25 Apr 2006 05:02:01 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYISV-0005e0-D9 for dnsext-archive@lists.ietf.org; Tue, 25 Apr 2006 03:59:47 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYIP7-000GtP-JL for namedroppers-data@psg.com; Tue, 25 Apr 2006 07:56:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [213.244.168.210] (helo=outpost.ds9a.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYIP5-000Gt9-C3 for namedroppers@ops.ietf.org; Tue, 25 Apr 2006 07:56:11 +0000 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id A0D2B3F86; Tue, 25 Apr 2006 09:56:01 +0200 (CEST) Date: Tue, 25 Apr 2006 09:56:01 +0200 From: bert hubert To: namedroppers@ops.ietf.org Subject: PowerDNS recursor algorithm review Message-ID: <20060425075600.GA2396@outpost.ds9a.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: -2.0 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Dear namedroppers, The open source PowerDNS recursor is currently being deployed by some very large access providers, and now has millions of users. This has me worrying a bit if I'm doing everything correctly (enough). To test this, I've documented the inner workings of the PowerDNS recursor, including its algorithm here: http://doc.powerdns.com/recursor-design-and-engineering.html and more specifically here: http://doc.powerdns.com/recursor-design-and-engineering.html#AEN2878 If things progess as they appear to be progressing, the recursor might soon leave the single digit market share it currently boasts, so I very much hope I/we can prevent foisting broken code or algorithms on so many people. If you could spare the time, could you browse through the documentation and tell me what is broken? And yes, I'll address the lack of local zones for RFC 1918 / AS112 serving shortly. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 28 14:58:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZYB4-0000eh-NR for dnsext-archive@lists.ietf.org; Fri, 28 Apr 2006 14:58:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZYB4-0004UY-Dc for dnsext-archive@lists.ietf.org; Fri, 28 Apr 2006 14:58:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZY6a-0008kY-DY for namedroppers-data@psg.com; Fri, 28 Apr 2006 18:54:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-16.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, USER_IN_DEF_WHITELIST autolearn=no version=3.1.1 Received: from [128.9.160.116] (helo=nit.isi.edu) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZY6W-0008k9-Rf for namedroppers@ops.ietf.org; Fri, 28 Apr 2006 18:54:12 +0000 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k3SIs9Qq005706; Fri, 28 Apr 2006 11:54:09 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k3SIs94M005705; Fri, 28 Apr 2006 11:54:09 -0700 Date: Fri, 28 Apr 2006 11:54:09 -0700 Message-Id: <200604281854.k3SIs94M005705@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4470 on Minimally Covering NSEC Records and DNSSEC On-line Signing From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 A new Request for Comments is now available in online RFC libraries. RFC 4470 Title: Minimally Covering NSEC Records and DNSSEC On-line Signing Author: S. Weiler, J. Ihren Status: Standards Track Date: April 2006 Mailbox: weiler@tislabs.com, johani@autonomica.se Pages: 8 Characters: 17471 Updates: RFC4035, RFC4034 See-Also: I-D Tag: draft-ietf-dnsext-dnssec-online-signing-02.txt URL: http://www.rfc-editor.org/rfc/rfc4470.txt This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. [STANDARDS TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 28 15:52:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZ0q-0005l7-L1 for dnsext-archive@lists.ietf.org; Fri, 28 Apr 2006 15:52:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZ0q-0007nh-9F for dnsext-archive@lists.ietf.org; Fri, 28 Apr 2006 15:52:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZYyd-000Cn0-TB for namedroppers-data@psg.com; Fri, 28 Apr 2006 19:50:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZYyc-000Cmi-Ok for namedroppers@ops.ietf.org; Fri, 28 Apr 2006 19:50:06 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3SJo1BX000391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FZYyX-0007W5-Fh; Fri, 28 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-09.txt Message-Id: Date: Fri, 28 Apr 2006 15:50:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Elliptic Curve Keys and Signatures in the Domain Name System (DNS) Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-09.txt Pages : 16 Date : 2006-4-28 The standard format for storing elliptic curve cryptographic keys and elliptic curve SHA-1 based signatures in the Domain Name System (DNS) is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also 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-dnsext-ecc-key-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ecc-key-09.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: <2006-4-28135044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ecc-key-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ecc-key-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-28135044.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Apr 28 16:16:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZZNh-00053K-8t for dnsext-archive@lists.ietf.org; Fri, 28 Apr 2006 16:16:01 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZZNf-00015v-Ry for dnsext-archive@lists.ietf.org; Fri, 28 Apr 2006 16:16:01 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZZL5-000Ejt-GI for namedroppers-data@psg.com; Fri, 28 Apr 2006 20:13:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.188.136.8] (helo=motgate8.mot.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZZL2-000Ejc-Pq for namedroppers@ops.ietf.org; Fri, 28 Apr 2006 20:13:16 +0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k3SKU2WL007515 for ; Fri, 28 Apr 2006 13:30:02 -0700 (MST) Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k3SKRE3u000201 for ; Fri, 28 Apr 2006 15:27:14 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-dnsext-ecc-key-09.txt Date: Fri, 28 Apr 2006 16:13:08 -0400 Message-ID: <3870C46029D1F945B1472F170D2D9790DCDAAA@de01exm64.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-dnsext-ecc-key-09.txt Thread-Index: AcZq/l433/1zfEiWTJSOLzPR4xL1EQAAY55g From: "Eastlake III Donald-LDE008" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This submission was primarily to stop the draft from timing out. There has been some indication that people would like some common curves or the like to be pre-defined and easily specifiable. Any suggests on which this should apply to or where to find such? Thanks, Donald=20 -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, April 28, 2006 3:50 PM To: i-d-announce@ietf.org Cc: namedroppers@ops.ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ecc-key-09.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Elliptic Curve Keys and Signatures in the Domain Name System (DNS) Author(s) : R. Schroeppel, D. Eastlake Filename : draft-ietf-dnsext-ecc-key-09.txt Pages : 16 Date : 2006-4-28 =09 The standard format for storing elliptic curve cryptographic keys and elliptic curve SHA-1 based signatures in the Domain Name System (DNS) is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also 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-dnsext-ecc-key-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ecc-key-09.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: