From owner-namedroppers@ops.ietf.org Mon Mar 1 02:40:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26045 for ; Mon, 1 Mar 2004 02:40:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxhxA-000CD7-Hp for namedroppers-data@psg.com; Mon, 01 Mar 2004 07:35:04 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axhx8-000CCf-S7 for namedroppers@ops.ietf.org; Mon, 01 Mar 2004 07:35:03 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 85ABD51E66; Mon, 1 Mar 2004 08:35:02 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 068104FEA3 for ; Mon, 1 Mar 2004 08:35:02 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i217Z1Xf026158 for ; Mon, 1 Mar 2004 08:35:02 +0100 Received: (from olaf@localhost) by x50.ripe.net (8.12.10/8.12.6) id i217Z1SK001368 for namedroppers@ops.ietf.org; Mon, 1 Mar 2004 08:35:01 +0100 Date: Mon, 1 Mar 2004 08:35:01 +0100 From: Olaf Kolkman Message-Id: <200403010735.i217Z1SK001368@x50.ripe.net> To: namedroppers@ops.ietf.org Subject: DNSEXT list policy X-RIPE-Spam-Status: N 0.500000 / 0.0 / 0.0 X-RIPE-Signature: 32d842149ec8e2859401da1280faf172 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk - 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". 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 - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- 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.4 2003/09/25 08:26:13 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 2 00:30:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03071 for <dnsext-archive@lists.ietf.org>; Tue, 2 Mar 2004 00:30:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ay2PC-000JOd-VB for namedroppers-data@psg.com; Tue, 02 Mar 2004 05:25:22 +0000 Received: from [218.37.225.116] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ay2P8-000JOC-Rg for namedroppers@ops.ietf.org; Tue, 02 Mar 2004 05:25:19 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i225Ojxc007927; Tue, 2 Mar 2004 00:24:45 -0500 To: Andras Salamon <andras@dns.net> Cc: Bernard Aboba <aboba@internaut.com>, huitema@microsoft.com, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> <20040226144216.GA7166@dns.net> From: Derek Atkins <derek@ihtfp.com> Date: Tue, 02 Mar 2004 00:24:45 -0500 In-Reply-To: <20040226144216.GA7166@dns.net> (Andras Salamon's message of "Thu, 26 Feb 2004 16:42:16 +0200") Message-ID: <sjmr7wb6cte.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Andras Salamon <andras@dns.net> writes: > On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: >> If there is to be a "compromise" I believe that it should be >> to set TTL=255 on responses and (optionally) check on the sender, while >> *always* setting TTL=1 on queries. > > Sounds reasonable to me. But now you're open to smurf attacks, where I send a LLMNR request to a responder, setting YOUR ip address as the source, and setting the TTL to make sure the packet arrives "properly". Or do we just not care about this? I can make sure you send the packet, and with TTL=255 the response will always make it back to the "sender" (which is YOUR ip address in this case). So, what is the threat(s) we're trying to solve? In particular, what threat does TTL=255 on responses actually solve? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 3 06:13:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18852 for <dnsext-archive@lists.ietf.org>; Wed, 3 Mar 2004 06:13:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AyUFM-0008x4-LW for namedroppers-data@psg.com; Wed, 03 Mar 2004 11:09:04 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AyUFK-0008w7-W0 for namedroppers@ops.ietf.org; Wed, 03 Mar 2004 11:09:03 +0000 Received: from forastero.wireless.ietf59.or.kr (forastero.wireless.ietf59.or.kr [218.37.225.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 828D11951C for <namedroppers@ops.ietf.org>; Wed, 3 Mar 2004 12:08:59 +0100 (CET) Date: Wed, 3 Mar 2004 20:08:54 +0900 (KST) From: Jakob Schlyter <jakob@rfc.se> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: draft-ietf-dnsext-nsec-rdata-04 Message-ID: <Pine.OSX.4.58.0403032002290.9286@forastero.dynamic.schlyter.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've just submitted an updated version of this draft to the drafts editor. For those who want to read it now, you can find a copy (and a diff against -03) at the following location: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.txt http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.wdiff jakob -- 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://ops.ietf.org/lists/namedroppers/> From ghyinfonet@mail.com Wed Mar 3 18:21:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05518 for <dnsext-archive@ietf.org>; Wed, 3 Mar 2004 18:21:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayffp-0006eQ-00 for dnsext-archive@ietf.org; Wed, 03 Mar 2004 18:21:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayfef-0006LS-00 for dnsext-archive@ietf.org; Wed, 03 Mar 2004 18:19:58 -0500 Received: from [200.52.174.17] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1AyfdA-0005jJ-00; Wed, 03 Mar 2004 18:18:26 -0500 From: "Fórum Social / Bombay . inb" <ghyinfonet@mail.com> To: disman-request@ietf.org Subject: Preocupante articulação - Informe exclusivo ref.: X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1AyfdA-0005jJ-00@ietf-mx> Date: Wed, 03 Mar 2004 18:18:26 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=13.1 required=5.0 tests=FORGED_MUA_EUDORA,HTML_50_60, HTML_FONT_BIG,HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES, SUBJ_HAS_UNIQ_ID,SUBJ_ILLEGAL_CHARS autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 2.7 SUBJ_ILLEGAL_CHARS Subject contains too many raw illegal characters * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <META NAME="Template" CONTENT="C:\Arquivos de programas\Microsoft Office\Office\html.dot"> </HEAD> <BODY LINK="#0000ff" VLINK="#800080"> <P ALIGN="CENTER"><!-- Please, follow the links: http://www.hotmail.com http://www.spamcop.net mailto:abernardico@yahoo.com?subject=Remove andrediniz@nonaarte.com.br andredogon@simbolo.com.br mailto:andredogon@simbolo.coml.sys.intranet?subject=Subscribir braulinojr@bol.com.br mailto:camera3@mail.telepac.pt?subject=IAgree caparroz@wanadoo.es mailto:carlospi@adinet.com.uy?subject=Adquirir DADEAN1@aol.com df01a8c0@xdata1.com.uy mailto:efigge@arnet.com.ar?subject=Unsubscribe elrey@123.com emancipacordoba@hotmail.com mailto:FabianF@exo.com.ar?subject=MyOpinion fuckspam@attbi.com gcv2000@adinet.com.uy gindre@indecs.org.br grupeiro@uol.com.br gsya@arnet.com.ar igge@arnet.com.ar iica@reuna.cl iranzo@fa.upc.es itiro@openlink.c itiro@openlink.com.br jaabril@comcast.net jaabril@mail.comcast.net jbarloccod@medynet.com jerez@adinet.com.uy --><FONT SIZE=2>Ref. Addr. Book: (fdp) </FONT><A HREF="mailto:livrariacultural@yahoo.com.br?subject=FSM-Bombay:e-BookGratuitoEnEspañol"><FONT SIZE=2>EnEspañol</FONT></A><FONT SIZE=2> - </FONT><A HREF="mailto:livrariacultural@yahoo.com.br?subject=English:LinkToFreeAutomaticTranslator"><FONT SIZE=2>English:FreeAutomaticTranslator</FONT></A> - <A HREF="mailto:livrariacultural@yahoo.com.br?subject=Retirar-Remover"><FONT SIZE=2>Retirar-Remover</FONT></A> <P>Caros amigos, </P> <P>Temos o prazer de oferecer-lhes com exclusividade e gratuitamente o e-Book "4º Fórum Social Mundial: preocupante articulação revolucionária" (Bombay, 2004), elaborado pela agência hispana Destaque Internacional. Na continuação, transcrevemos o índice de tal Informe. Simplesmente faça clic em <A HREF="mailto:livrariacultural@yahoo.com.br?subject=FSM-Bombay:e-BookGratuitoBr">FSM-Bombay:e-BookGratuitoBr</A> . Cordialmente, Ferreira-Passos, Atualidade Brasileira, Rio de Janeiro (RJ). Postdata importante: Para receber, também gratuitamente, o Informe sobre as próximas eleições presidenciais em El Salvador, veja links no final.</P> <B><FONT SIZE=5><P ALIGN="CENTER">4o. Fórum Social Mundial:</P> <P ALIGN="CENTER">preocupante articulação revolucionária</P> <P ALIGN="CENTER">(Bombay, Janeiro 16-21, 2004)</P> </FONT><I><P ALIGN="CENTER">A verdade sobre um evento alter-mundialista desdenhado por uns e admirado por outros, a respeito do qual muito se falou, porém pouco se conheceu</P> </I><P>1. Neo-imperialismo de uma potência mundial "emergente"</P> </B><I><P>Os milhares de ativistas presentes em Bombay reconhecem que a meta é transformar suas redes na "segunda potência mundial", capaz de modificar radicalmente o panorama da Índia, da Ásia e do mundo</P> </I><B><P>2. O porquê da Índia</P> </B><I><P>Instrumentação revolucionária de "excluídos" e galvanização das esquerdas, duas metas do FSM para o país de segunda maior população do mundo</P> </I><B><P>3. "Dalits", "adivasis" e teologia da libertação</P> </B><I><P>Correntes "liberacionistas" da Índia e da Ásia tentam anular o efeito sócio-político paralizante da religião brahmânica, para impulsionar a revolução socia.</P> </I><B><P>4. Mumbai Resistance 2004 e MST</P> </B><I><P>Evento paralelo ao 4º FSM contribui à "politização" e radicalização deste, com a colaboração do brasileiro Movimento dos Trabalhadores Rurais Sem Terra (MST)</P> </I><B><P>5. Eixo contestatário Índia-Brasil</P> </B><I><P>O FSM como "novo protagonista" e "ponte" para alcançar uma esquerdização da atual correlação de forças internacional</P> </I><B><P>6. "Catalisação" alter-mundialista, "sinergia" e nova "racionalidade"</P> </B><I><P>O evento de Bombay, enquanto enorme e preocupante articulação revolucionária, deve ser analisado segundo o sábio ensinamento de Santo Tomás: "ver, julgar e atuar"</P> </I><B><FONT SIZE=2><P>Redação: Destaque Internacional, de Madri, com a colaboração de seus enviados especiais a Bombay, Suresh Noronha, T. F. Joseph e Sunil Abrahan. Tradução: Graça Salgueiro, Brasil.</P> </B></FONT><P>LINKS:</P> <P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=FSM-Bombay:MinhaOpinião">FSM-Bombay:MinhaOpinião</A></P> <P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=FSM-Bombay:e-BookGratuitoBr">FSM-Bombay:e-BookGratuitoBr</A></P> <P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=DestaqueInternacional:Subscrever">DestaqueInternacional:Subscrever</A></P> <P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=InformeElSalvador(ResumoEmPortuguês">InformeElSalvador(ResumoEmPortuguês)</A></P> <P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=InformeElSalvador(TextoCompletoEmEspanhol">InformeElSalvador(TextoCompletoEmEspanhol)</A></P> <P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=NextMessages:OnlyInEnglish">NextMessages:OnlyInEnglish</A><FONT SIZE=4> </P> </FONT><P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=ProximosEnvios:SoloEnEspañol">ProximosEnvios:SoloEnEspañol</A></P> <P><A HREF="mailto:livrariacultural@yahoo.com.br?subject=DestaqueInternacional:Retirar-Remover">DestaqueInternacional:Retirar-Remover</A> (nota importante: por um lamentável acidente digital foram apagados, sem serem processados, os pedidos de remoção chegados no mes de janeiro de 2004; àqueles que o tiverem feito, apresentamos nossas mais sinceras desculpas, e solicitamos re-enviarem o pedido de Remoção).</P> <I><P> </I> </P> <P> </P> <P> </P></BODY> </HTML> From owner-namedroppers@ops.ietf.org Thu Mar 4 09:23:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21355 for <dnsext-archive@lists.ietf.org>; Thu, 4 Mar 2004 09:23:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aytdm-000AFr-Fb for namedroppers-data@psg.com; Thu, 04 Mar 2004 14:15:58 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aytdj-000AFX-K2 for namedroppers@ops.ietf.org; Thu, 04 Mar 2004 14:15:55 +0000 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i24DdAPf028397 for <namedroppers@ops.ietf.org>; Thu, 4 Mar 2004 08:39:10 -0500 (EST) Message-ID: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: comment on NSEC RDATA format draft -04 Date: Thu, 4 Mar 2004 08:37:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The text states that there are no special TTL requirements for the NSEC RR. However, in the new DNSSECbis specs, we have the following suggestion for TTL values (records draft-07): The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308]. Minor difference since the above is a suggestion, and there are no real special requirements for the TTL. I think the NSEC data draft should include the above for consistancy. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 09:08:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17653 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 09:08:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzcLJ-0006sl-6i for namedroppers-data@psg.com; Sat, 06 Mar 2004 13:59:53 +0000 Received: from [193.252.22.29] (helo=mwinf0204.wanadoo.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzcL7-0006nx-Rj for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 13:59:42 +0000 Received: from BARRYS2GDELL (Mix-Toulouse-115-1-240.w80-9.abo.wanadoo.fr [80.9.40.240]) by mwinf0204.wanadoo.fr (SMTP Server) with SMTP id 927FEA0001E6 for <namedroppers@ops.ietf.org>; Sat, 6 Mar 2004 14:59:39 +0100 (CET) Message-ID: <001001c40383$c996f850$643264c8@BARRYS2GDELL> From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> To: <namedroppers@ops.ietf.org> Subject: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:03:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, being new to rfc2782, I have a number of questions. I would be grateful for any enlightenment anyone could provide. Regards Barry Desborough Barry.Desborough@wanadoo.fr SRV RR FORMAT From rfc2782 page 2 "The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target" But rfc1035 page 29 describes the generic RR header as being NAME TYPE CLASS TTL RDLENGTH RDATA According to 1035, and assuming that 'SRV' refers to TYPE, (not specified in 2782), it seems that the SRV RR should be _Service._Proto.Name SRV Class TTL RDLENGTH Priority Weight Port Target where _Service._Proto.Name corresponds to NAME SRV is the TYPE (33) Class, TTL and RDLENGTH are 1035 standard and Priority Weight, Port and Target correspond to RDATA Q1) Which rfc is correct? Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? Could not the contents of Target have been be reported in the NAME field and the Target field be dispensed with? TARGET SELECTION From page 3 of rfc2782 " ............................................ The following algorithm SHOULD be used to order the SRV RRs of the same priority: To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority." Let's say we have only two targets of the same priority, with weights 1 and 2. If the weights are ordered 1 then 2, then we have Wt Sum ----------- 1 1 2 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 1 1 2 2 2nd contact 2 2 1 1 This gives each target equal probability of being contacted first. If the weights are ordered 2 then 1, then we have Wt Sum ----------- 2 2 1 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 2 2 2 1 2nd contact 1 1 1 2 The weight 2 target is contacted first with a probability of 3/4. Overall the probabilities for 1st contact are 3/8 and 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ _order_is_randomly_chosen_, but this is not specified. According to my reckoning, consistent, correct results are obtained if the random number is chosen to be between _ONE_ and the sum computed. Q3) Does anyone agree or disagree with this? If what is meant by 1st contact is the 1st successful attempt to find a Target, from whereupon this target's service is always used until it's TTL expiry or failure, then load sharing is only effected by different clients choosing different 1st contacts. On the other hand, if it means that a client which is a frequent, heavy user of a service client works down a sequence of targets to select which one provides the service next, all targets are selected with equal frequency. It seems to me that there is an assumption here that target contact selection from any particular client is very infrequent, and that load sharing occurs by virtue of different clients making 1st contact to different targets. In a system who's application makes frequent heavy of a service, service selection should be purely probabilistic based on the relative weights of the highest priority records available. Q4) Can anyone clarify this matter? Q5) Does anyone have any DNS SRV sniffer trace they could send directly to me to throw more light on the message format? (Please mail the group to say you have responded to this one, to save me being flooded!) -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 09:59:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19695 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 09:59:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzdFK-000IOX-0Y for namedroppers-data@psg.com; Sat, 06 Mar 2004 14:57:46 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzdF9-000IMo-Br for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 14:57:35 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i26EvXR10574; Sat, 6 Mar 2004 06:57:33 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200403061457.i26EvXR10574@karoshi.com> Subject: Re: comment on NSEC RDATA format draft -04 To: scottr@nist.gov (Scott Rose) Date: Sat, 6 Mar 2004 06:57:33 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> from "Scott Rose" at Mar 04, 2004 08:37:31 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The > text states that there are no special TTL requirements for the NSEC RR. > However, in the new DNSSECbis specs, we have the following suggestion for > TTL values (records draft-07): > > The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL > field. This is in the spirit of negative caching [RFC2308]. > > Minor difference since the above is a suggestion, and there are no real > special requirements for the TTL. I think the NSEC data draft should > include the above for consistancy. > > Scott ack. this is a reasonable thing to do. --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 10:38:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23001 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 10:38:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azdp4-000PXy-Ul for namedroppers-data@psg.com; Sat, 06 Mar 2004 15:34:42 +0000 Received: from [18.7.7.76] (helo=fort-point-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azdom-000PSU-3g for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 15:34:24 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i26FYLI9022585; Sat, 6 Mar 2004 10:34:23 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id i26FVxNt007873; Sat, 6 Mar 2004 10:31:59 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i26FVvQ7007134; Sat, 6 Mar 2004 10:31:57 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id i26FVtmN000490; Sat, 6 Mar 2004 10:31:55 -0500 Subject: Re: DNS SRV Clarification sought From: Greg Hudson <ghudson@MIT.EDU> To: Barry Desborough <Barry.Desborough@wanadoo.fr> Cc: namedroppers@ops.ietf.org In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1078587114.9992.126.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 06 Mar 2004 10:31:55 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > From page 3 of rfc2782 > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive) > Random number case 0 1 2 3 > 1st contact 1 1 2 2 > 2nd contact 2 2 1 1 You appear to be computing a random integer, rather than a random real number, as was intended. If you choose a random real number, you'll get the appropriate distribution (a server with weight 2 is chosen twice as often with a server of weight 1). I would have much preferred a statement which used random integers (which is something you can actually do on a computer), but the working group was having a little trouble coming up with an algorithm statement that actually worked, so we decided to go with one which we strongly believed was correct even if it wasn't very clear and which didn't translate easily into code. It's particularly galling to me that we didn't even state explicitly what kind of number is to be chosen (integer, rational, computable, real, complex...), and then we threw in this parenthetical note "(inclusive)" which actually has no effect on the outcome if real numbers are being chosen. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. Neither of these choices seems appropriate. The TTL only applies to the DNS data itself, not the processing of it, so it would be wrong to choose a server once and then stick with it until the TTL expires. It would also be wrong to walk the list of choices when making multiple successful contacts; the idea is to walk the list when making a single contact until you are successful, then throw the list away. The next time you make a contact, you should start all over again and choose a new contact order randomly according to the weights. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 12:12:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25960 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 12:12:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzfI9-000L5w-VJ for namedroppers-data@psg.com; Sat, 06 Mar 2004 17:08:49 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzfHy-000L3j-Mk for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 17:08:39 +0000 Received: from hypatia.dns.net (c16-rba-39.dial-up.net [196.33.198.39]) by mercury.is.co.za (Postfix) with ESMTP id 34713BF6A4; Sat, 6 Mar 2004 19:08:35 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i26H8lw24321; Sat, 6 Mar 2004 19:08:47 +0200 Date: Sat, 6 Mar 2004 19:08:47 +0200 From: Andras Salamon <andras@dns.net> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought Message-ID: <20040306170847.GB24117@dns.net> References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Mar 06, 2004 at 03:03:22PM +0100, Barry Desborough wrote: > Here is the format of the SRV RR, whose DNS type code is 33: > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > NAME TYPE CLASS TTL RDLENGTH RDATA RFC1035 deals with the on-the-wire encoding, while the SRV text above seems to be related to the usual BIND-style zone file format. The examples in RFC 2782 bear this out. However, re-reading RFC 2782 and RFC 2052, I could not determine a definitive on-the-wire encoding of SRV records -- this seems to be undefined. Presumably, implementors have just looked at how BIND returns SRV records and gone with that. > According to 1035, and assuming that 'SRV' refers to TYPE, > (not specified in 2782), The section "Usage rules" mentions QTYPE=SRV, and there is further text the SRV RR, whose DNS type code is 33 and The IANA has assigned RR type value 33 to the SRV RR which seems to tie SRV to TYPE, although perhaps not very directly. > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? I tried to find an online deployment of SRV records to feed to tcpdump, but the closest I came was an SOA record for _tcp.microsoft.com (one of the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no appear to have _tcp subdomains. Does anyone actually have a deployment of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? I also tried to find the IANA assignments for the Service tags, as referred to in RFC 2782, and couldn't locate any. Have any actually been standardized? If so, a pointer would be appreciated! -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 12:37:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27420 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 12:37:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azfi4-000Pyx-HN for namedroppers-data@psg.com; Sat, 06 Mar 2004 17:35:36 +0000 Received: from [18.7.7.76] (helo=fort-point-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azfhl-000Pui-SY for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 17:35:17 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i26HZGHx019854; Sat, 6 Mar 2004 12:35:16 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id i26HTosJ011086; Sat, 6 Mar 2004 12:29:52 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i26HTlQ7008968; Sat, 6 Mar 2004 12:29:47 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id i26HTgtL000732; Sat, 6 Mar 2004 12:29:42 -0500 Subject: Re: DNS SRV Clarification sought From: Greg Hudson <ghudson@MIT.EDU> To: Andras Salamon <andras@dns.net> Cc: namedroppers@ops.ietf.org In-Reply-To: <20040306170847.GB24117@dns.net> References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1078594181.9992.134.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 06 Mar 2004 12:29:42 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? We appear to have: _sip._tcp.mit.edu _sip._udp.mit.edu _sip._tcp.sipxchange.mit.edu _sip._udp.sipxchange.mit.edu _kerberos._udp.athena.mit.edu _kerberos-master._udp.athena.mit.edu _kerberos-adm._tcp.athena.mit.edu -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 13:41:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29877 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 13:41:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzggX-000E0s-Nt for namedroppers-data@psg.com; Sat, 06 Mar 2004 18:38:05 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azgfw-000Doz-TE for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 18:37:28 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 3DD4C14C4F for <namedroppers@ops.ietf.org>; Sat, 6 Mar 2004 18:37:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-Reply-To: Message from "Barry Desborough" <Barry.Desborough@wanadoo.fr> of "Sat, 06 Mar 2004 15:03:22 +0100." <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 06 Mar 2004 18:37:28 +0000 Message-Id: <20040306183728.3DD4C14C4F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From rfc2782 page 2 > > "The format of the SRV RR > > Here is the format of the SRV RR, whose DNS type code is 33: > > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > > NAME TYPE CLASS TTL RDLENGTH RDATA > ... > Q1) Which rfc is correct? both. rdlength is a protocol element describing rdata. the <rdlength,rdata> tuple is used to represent the rr data, which in this case is itself a tuple: <Priority,Weight,Port,Target>. in "dns master file" format as entered into zone files and as displayed by utilities such as "dig", rdlength is used to encode and decode the rr data but is never specified or displayed directly. > Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? > Could not the contents of Target have been be reported in the NAME field > and the Target field be dispensed with? because the names of the servers capable of responding to requests may not have names equal or similar to the name of the service. this is analagous to MX records, where the target name can be a service provider even though the query name is that of a customer. > ... > Overall the probabilities for 1st contact are 3/8 and > 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ > _order_is_randomly_chosen_, but this is not specified. > > According to my reckoning, consistent, correct results are > obtained if the random number is chosen to be between > _ONE_ and the sum computed. > > Q3) Does anyone agree or disagree with this? it seems reasonable to me, but i didn't write that part of the rfc and i'm not sure i ever understood it. greg hudson's answer was that the numbers had to be real not integer, and this may indeed be the case. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. > > It seems to me that there is an assumption here that target contact > selection from any particular client is very infrequent, and that > load sharing occurs by virtue of different clients making 1st contact > to different targets. no, actually we contemplated a web-like service where an object and all of the sub-objects (such as images) mentioned in that object should ideally be fetched from the same server, in case that server was capable of opportunistic pipelining or prefetching. > In a system who's application makes frequent heavy of a service, > service selection should be purely probabilistic based on the relative > weights of the highest priority records available. > > Q4) Can anyone clarify this matter? we contemplated making "sticky-ness" or "re-use" a protocol element but we felt that the SRV algorythm was already beyond its complexity horizon. the right thing to do now is: remove that part of the spec and designate re-use as "requestor-specific local policy". > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? (Please > mail the group to say you have responded to this one, to save me being > flooded!) ;; QUESTION SECTION: ;_kerberos._udp.vix.com. IN SRV ;; ANSWER SECTION: _kerberos._udp.vix.com. 3600 IN SRV 0 1 88 kerberos-0.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-1.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-2.vix.com. ;; AUTHORITY SECTION: vix.com. 3178 IN NS ns.lah1.vix.com. vix.com. 3178 IN NS ns.sql1.vix.com. vix.com. 3178 IN NS ns-ext.isc.org. ;; ADDITIONAL SECTION: ns.lah1.vix.com. 2429 IN A 204.152.188.234 ns.lah1.vix.com. 2429 IN AAAA 2001:4f8:2::9 ns.sql1.vix.com. 2429 IN A 204.152.184.135 ns.sql1.vix.com. 2429 IN AAAA 2001:4f8:3::9 ns-ext.isc.org. 3055 IN A 204.152.184.64 ns-ext.isc.org. 3057 IN AAAA 2001:4f8:0:2::13 -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 13:49:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29998 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 13:49:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzgqU-000GK0-Ia for namedroppers-data@psg.com; Sat, 06 Mar 2004 18:48:22 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzgqK-000GHb-32 for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 18:48:12 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B96C914C51 for <namedroppers@ops.ietf.org>; Sat, 6 Mar 2004 18:48:11 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 06 Mar 2004 19:08:47 +0200." <20040306170847.GB24117@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 06 Mar 2004 18:48:11 +0000 Message-Id: <20040306184811.B96C914C51@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... > RFC1035 deals with the on-the-wire encoding, while the SRV text > above seems to be related to the usual BIND-style zone file format. > The examples in RFC 2782 bear this out. However, re-reading RFC 2782 > and RFC 2052, I could not determine a definitive on-the-wire encoding > of SRV records -- this seems to be undefined. Presumably, implementors > have just looked at how BIND returns SRV records and gone with that. note that if BIND is shown to be wrong, we (isc) will of course fix it. > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? vix.com has no SRV-discovered services that use tcp as their transport. (presumably if we were a macintosh shop or a windows shop, we would?) _kerberos._udp.vix.com/IN/SRV has some data for you, though. > I also tried to find the IANA assignments for the Service tags, as > referred to in RFC 2782, and couldn't locate any. Have any actually > been standardized? If so, a pointer would be appreciated! here's the problem. SRV is experimental. 2052 was "snuck through" the ietf process when iesg's attention was focused elsewhere, and they got Really Angry about it when they found out. i've apologized, since mostly i was acting in ignorance and without malice, but it hasn't helped. so, in spite of the significant deployment of SRV in the community (like with the service discovery protocols currently shipped by microsoft and apple), SRV remains experimental. and as long as it's only experimental, iana's charter does not cover it. what we need to do is in two stages. first, iesg has to tell me how i can mend relations and achieve some kind of pardon for past SRV-related misdeeds. (perhaps a public apologia at an iesg plenary would suffice?) second, iana should create a registry of service identifiers, by importing the BSD file "/etc/services" and then periodically amending it for new standards -- and new standards should allocate a service name not just a default port number. i don't know how to do either of those things but that's the list, anyway. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 14:04:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00368 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 14:04:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Azh48-000JXi-I0 for namedroppers-data@psg.com; Sat, 06 Mar 2004 19:02:28 +0000 Received: from [158.38.62.85] (helo=festningen.uninett.no) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Azh3Z-000JNM-KU for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 19:01:53 +0000 Received: from localhost (localhost [127.0.0.1]) by festningen.uninett.no (Postfix) with ESMTP id AAE1E2D0C1; Sat, 6 Mar 2004 20:01:52 +0100 (CET) Date: Sat, 06 Mar 2004 20:01:52 +0100 (CET) Message-Id: <20040306.200152.46801952.jarle@uninett.no> To: andras@dns.net Cc: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought From: Jarle Greipsland <jarle@uninett.no> In-Reply-To: <20040306170847.GB24117@dns.net> References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andras Salamon <andras@dns.net> writes: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV > outside pseudo-DNS dynamic zones tied to DHCP servers? _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV -jarle -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 14:11:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00703 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 14:11:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzhAP-000L8O-MH for namedroppers-data@psg.com; Sat, 06 Mar 2004 19:08:57 +0000 Received: from [18.7.7.76] (helo=fort-point-station.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzhAF-000L5m-4u for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 19:08:47 +0000 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id i26J8ebm014126; Sat, 6 Mar 2004 14:08:40 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id i26J8dpU014353; Sat, 6 Mar 2004 14:08:39 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i26J8cQ7010490; Sat, 6 Mar 2004 14:08:38 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.12.9) id i26J8aSd001047; Sat, 6 Mar 2004 14:08:36 -0500 Subject: Re: DNS SRV Clarification sought From: Greg Hudson <ghudson@MIT.EDU> To: Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> References: <20040306184811.B96C914C51@sa.vix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1078600115.9992.140.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 06 Mar 2004 14:08:35 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_NJABL_RELAY autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2004-03-06 at 13:48, Paul Vixie wrote: > here's the problem. SRV is experimental. 2052 was "snuck through" the > ietf process when iesg's attention was focused elsewhere, and they got > Really Angry about it when they found out. Your history seems to be omitting the part where we got RFC 2782 published as a proposed standard (with you as one of the authors). That one certainly wasn't snuck through the IESG; we got significant feedback about the static weighting system, among other things. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 14:52:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01603 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 14:52:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AzhnM-0002cv-G9 for namedroppers-data@psg.com; Sat, 06 Mar 2004 19:49:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AzhnB-0002ah-Si for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 19:49:01 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7C9B014C7E for <namedroppers@ops.ietf.org>; Sat, 6 Mar 2004 19:49:01 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU> of "Sat, 06 Mar 2004 14:08:35 EST." <1078600115.9992.140.camel@error-messages.mit.edu> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 06 Mar 2004 19:49:01 +0000 Message-Id: <20040306194901.7C9B014C7E@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > here's the problem. SRV is experimental. 2052 was "snuck through" the > > ietf process when iesg's attention was focused elsewhere, and they got > > Really Angry about it when they found out. > > Your history seems to be omitting the part where we got RFC 2782 > published as a proposed standard (with you as one of the authors). That > one certainly wasn't snuck through the IESG; we got significant feedback > about the static weighting system, among other things. indeed. i was thinking only of 2052 in my recounting. in that case there's nothing stopping someone from writing an rfc to immortalize /etc/services and making that file an iana database. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 6 15:17:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03230 for <dnsext-archive@lists.ietf.org>; Sat, 6 Mar 2004 15:17:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AziBc-00083q-GA for namedroppers-data@psg.com; Sat, 06 Mar 2004 20:14:16 +0000 Received: from [128.220.13.173] (helo=foobar.cs.jhu.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AziBB-0007yE-J7 for namedroppers@ops.ietf.org; Sat, 06 Mar 2004 20:13:49 +0000 Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id i26KDlS10169 for <namedroppers@ops.ietf.org>; Sat, 6 Mar 2004 15:13:48 -0500 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i26KDh205097 for namedroppers@ops.ietf.org; Sat, 6 Mar 2004 15:13:43 -0500 Date: Sat, 6 Mar 2004 15:13:42 -0500 From: David Shaw <dshaw@jabberwocky.com> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought Message-ID: <20040306201342.GE18595@jabberwocky.com> Mail-Followup-To: namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040306170847.GB24117@dns.net> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Mar 06, 2004 at 07:08:47PM +0200, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV outside > pseudo-DNS dynamic zones tied to DHCP servers? _hkp._tcp.pgp.net to help find PGP keyservers. David -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Mar 7 21:24:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20913 for <dnsext-archive@lists.ietf.org>; Sun, 7 Mar 2004 21:24:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0AKd-000Ogu-8p for namedroppers-data@psg.com; Mon, 08 Mar 2004 02:17:27 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0AKR-000Oeu-US for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 02:17:16 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i282Guna030615 for <namedroppers@ops.ietf.org>; Sun, 7 Mar 2004 21:16:56 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i282GtQU030614 for namedroppers@ops.ietf.org; Sun, 7 Mar 2004 21:16:56 -0500 (EST) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B014n-0007IK-G6 for namedroppers@ops.ietf.org; Sun, 07 Mar 2004 16:24:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i27GORa05087 for <namedroppers@ops.ietf.org>; Sun, 7 Mar 2004 18:24:27 +0200 Date: Sun, 7 Mar 2004 18:24:27 +0200 (EET) From: Pekka Savola <pekkas@netcore.fi> To: namedroppers@ops.ietf.org Subject: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Message-ID: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Hi, [[ note: I'm not subscribed... ]] I took a quick look at the DNSSEC intro document; it was in a very good shape. Two major comments: 1) the document requires the use of EDNS0. However, current EDNS0 implementations typically advertise the larger sizes than they can handle at the IP layer, causing fragmentation. You can argue that this is OK as long as the result of NOT fragmenting would end up with a worse result than as you would be without it (e.g., requiring falling back to TCP, or whatever). With DNSSEC, I'm not sure that this holds anymore. It seems to me that the best behaviour would be to avoid IP fragmentation by having correct implementations of EDNS0, and if some data must be left out, that it would be fetched separately, over second, third, ..., nth query over UDP. Shouldn't that be possible and reasonable? 2) Security considerations lists a number of threats, but does not discuss whether they have been fixed or mitigated at all (e.g., relating to dynamic updates and signing). It might not hurt to be a bit more explicit on this. Similarly, maybe some of this text could be included in the DNS security analysis document as well... editorial --------- page 4, chapter 2, replace "RRsets forms" with "RRsets forming" -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Mar 7 22:11:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22493 for <dnsext-archive@lists.ietf.org>; Sun, 7 Mar 2004 22:11:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0B93-000A0I-L5 for namedroppers-data@psg.com; Mon, 08 Mar 2004 03:09:33 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0B8t-0009yF-5t for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 03:09:23 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AB3E714C51; Mon, 8 Mar 2004 03:09:22 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Cc: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Sun, 07 Mar 2004 18:24:27 +0200." <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 08 Mar 2004 03:09:22 +0000 Message-Id: <20040308030922.AB3E714C51@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). most of <http://research.compaq.com/wrl/techreports/abstracts/87.3.html>'s concerns about fragmentation have been addressed, and the ones which still apply are relevant to small-mtu connections ("don't do that") and to high performance/demand mobygram applications (nfs, tcp). for dns, it's okay. > With DNSSEC, I'm not sure that this holds anymore. It seems to me > that the best behaviour would be to avoid IP fragmentation by having > correct implementations of EDNS0, and if some data must be left out, > that it would be fetched separately, over second, third, ..., nth > query over UDP. Shouldn't that be possible and reasonable? no, that really would force tcp, which really would be worse than ip-frag. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sun Mar 7 23:48:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25604 for <dnsext-archive@lists.ietf.org>; Sun, 7 Mar 2004 23:48:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0Cda-0001LN-B1 for namedroppers-data@psg.com; Mon, 08 Mar 2004 04:45:10 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0CdP-0001I0-Es for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 04:44:59 +0000 Received: (qmail 69836 invoked from network); 8 Mar 2004 04:46:07 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 8 Mar 2004 04:46:07 -0000 Message-ID: <404BFAD9.80109@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Mar 2004 13:47:21 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <20040308030922.AB3E714C51@sa.vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; > no, that really would force tcp, which really would be worse than ip-frag. If message size is 1400B or so, it is definitely so. If message size is 4200B or so, it can still be a valid argument. However, if message size is 64000B, TCP is far better than IP-frag. I understand the problem is not of DNSSEC but of EDNS0. But with the current EDNS0 specification lacking rational upper limit on message size, it will be safe if DNSSEC says: messages over UDP MUST NOT be larger than 4000 Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 00:05:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25911 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 00:05:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0Cv7-0007YC-7A for namedroppers-data@psg.com; Mon, 08 Mar 2004 05:03:17 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Cug-0007Nb-P4 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 05:02:50 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 7E53114C73; Mon, 8 Mar 2004 05:02:50 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Cc: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 13:47:21 +0900." <404BFAD9.80109@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 08 Mar 2004 05:02:50 +0000 Message-Id: <20040308050250.7E53114C73@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > no, that really would force tcp, which really would be worse than ip-frag. > > If message size is 1400B or so, it is definitely so. > > If message size is 4200B or so, it can still be a valid argument. > > However, if message size is 64000B, TCP is far better than IP-frag. yes, that's true. the crossover is probably closer to 4*PMTU. > I understand the problem is not of DNSSEC but of EDNS0. > > But with the current EDNS0 specification lacking rational upper > limit on message size, it will be safe if DNSSEC says: > > messages over UDP MUST NOT be larger than 4000 it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E is for Estimated) but this isn't the time or place to make that change. so perhaps an advisory statement like "Note: advertising a buffer size larger than EPMTU could lead to unfortunate overaggressive IP fragmentation" would be enough to tell the dnssec implementor crowd -- who is likely to be the first real stress-testers of EDNS0's buffer size extension -- what they need to know, without actually amending the EDNS0 specification by side effect. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 00:58:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27949 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 00:58:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0Dk9-000HR8-Nl for namedroppers-data@psg.com; Mon, 08 Mar 2004 05:56:01 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0Djy-000HPT-RB for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 05:55:51 +0000 Received: (qmail 70075 invoked from network); 8 Mar 2004 05:56:59 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 8 Mar 2004 05:56:59 -0000 Message-ID: <404C0B75.3000303@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Mar 2004 14:58:13 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <20040308050250.7E53114C73@sa.vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; >> messages over UDP MUST NOT be larger than 4000 > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. I meant DNSSEC entities MUST NOT send messages larger than 4000 over UDP Can it be within the scope of DNSSEC? > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E > is for Estimated) but this isn't the time or place to make that change. If EDNS0 is to be changed (in the future, of course), reference to PMTUD should be clarified (removed entirely), because EDNS0 seemingly assumes fragmentation is always enabled, which means there is no room for PMTUD, which means, with IPv6, packets must be fragmented at the source. Or, if you think some form of PMTUD should be performed, it should be documented (though I think PMTUD practically impossible). > so perhaps an advisory statement like "Note: advertising a buffer size larger > than EPMTU could lead to unfortunate overaggressive IP fragmentation" would > be enough to tell the dnssec implementor crowd -- who is likely to be the > first real stress-testers of EDNS0's buffer size extension -- what they need > to know, without actually amending the EDNS0 specification by side effect. :-) Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 01:29:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28839 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 01:29:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0EDq-000Mrw-IN for namedroppers-data@psg.com; Mon, 08 Mar 2004 06:26:42 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0EDg-000Mqq-1R for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 06:26:32 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id C827814750; Mon, 8 Mar 2004 06:26:31 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Cc: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Mon, 08 Mar 2004 07:37:47 +0200." <Pine.LNX.4.44.0403080733160.16733-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 08 Mar 2004 06:26:31 +0000 Message-Id: <20040308062631.C827814750@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... would force tcp, which really would be worse than ip-frag. > > Seems like a flaw in DNS spec -- too coarse granularity: > 1) "everything fits in one UDP datagram", or > 2) "just use TCP". > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > datagram of specific size, query again, but only the missing data this > time". sense, yes, but the atomicity requirements are hard to adjust in that light. for example, if what you're trying to send is a referral, and the query and authority sections are all that fits, and you decide to just send that much and let the initiator re-query for the parts that would have been in the additional-data section, then it might end up being the case that they can never query for it. consider an authority section whose names are all under the referral cut. in earlier work once proposed as part of EDNS0 and then reintroduced as EDNS1, the idea came up to indicate in a response that there were multiple messages in the answer. we called it MD ("more data"). ultimately this turned out to be a lot more complicated than it sounded, and it's since been abandoned. i dearly wish that EDNS0 had made TTCP its prerequisite. ("ah, hindsight.") > Not sure if that would make sense but instead of forcing everything in > one, probably fragmented message, it would seem to encourage "proper" > operation with big DNS replies. in general, if you think the response might be larger than 3*EPMTU, use tcp, and that will amortize the complexity nicely. note that PMTUD hasn't been a raging success, and that EPMTU is probably 1500 octets most of the time, and that's where masataka's "4000" number comes from. > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. yes but on such a host, the EDNS0 initiator would presumably be able to discover this limitation and advertise a 1500-octet buffer. that's what the EDNS0 spec says it should do, at any rate. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 01:31:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28881 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 01:31:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0EGh-000NIu-Dd for namedroppers-data@psg.com; Mon, 08 Mar 2004 06:29:39 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0EGX-000NHj-0O for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 06:29:29 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A818E14C73; Mon, 8 Mar 2004 06:29:28 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Cc: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 14:58:13 +0900." <404C0B75.3000303@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 08 Mar 2004 06:29:28 +0000 Message-Id: <20040308062928.A818E14C73@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > of scope. > > I meant > > DNSSEC entities MUST NOT send messages larger than 4000 > over UDP > > Can it be within the scope of DNSSEC? then it would be within scope for this docset, but extremely controversial since it places a requirement more stringent than EDNS0. far better to make it advisory and avoid the fight. > > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU > > (where E is for Estimated) but this isn't the time or place to make > > that change. > > If EDNS0 is to be changed (in the future, of course), reference to > PMTUD should be clarified (removed entirely), because EDNS0 seemingly > assumes fragmentation is always enabled, which means there is no room > for PMTUD, which means, with IPv6, packets must be fragmented at the > source. > > Or, if you think some form of PMTUD should be performed, it should be > documented (though I think PMTUD practically impossible). i think that you're right and that all hope of PMTUD should be abandoned in the next update of EDNS, which at this point would be EDNS1 rather than a reissue of EDNS0. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 04:15:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20274 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 04:15:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0GoJ-000Pvq-7v for namedroppers-data@psg.com; Mon, 08 Mar 2004 09:12:31 +0000 Received: from [192.134.4.152] (helo=maya20.nic.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Go7-000Puh-RP for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 09:12:20 +0000 Received: from vespucci.nic.fr (postfix@vespucci.nic.fr [192.134.4.68]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id i289B3SI1114182; Mon, 8 Mar 2004 10:11:03 +0100 (CET) Received: by vespucci.nic.fr (Postfix, from userid 1055) id EB034101C6; Mon, 8 Mar 2004 10:11:02 +0100 (CET) Date: Mon, 8 Mar 2004 10:11:02 +0100 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: Jarle Greipsland <jarle@uninett.no> Cc: andras@dns.net, namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought Message-ID: <20040308091102.GA27580@nic.fr> References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <20040306.200152.46801952.jarle@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040306.200152.46801952.jarle@uninett.no> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.25-1-k7 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sat, Mar 06, 2004 at 08:01:52PM +0100, Jarle Greipsland <jarle@uninett.no> wrote a message of 16 lines which said: > _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV Which is documented in: http://mailbox.univie.ac.at/~gw/draft-sanz-whois-srv-00.txt -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 05:27:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23266 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 05:27:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0HvQ-000Co1-ME for namedroppers-data@psg.com; Mon, 08 Mar 2004 10:23:56 +0000 Received: from [193.252.22.29] (helo=mwinf0203.wanadoo.fr) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0HvD-000Cm8-BM for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 10:23:43 +0000 Received: from BARRYS2GDELL (Mix-Toulouse-104-2-101.w193-249.abo.wanadoo.fr [193.249.224.101]) by mwinf0203.wanadoo.fr (SMTP Server) with SMTP id 69B7710001FD; Mon, 8 Mar 2004 11:23:40 +0100 (CET) Message-ID: <000201c404f7$f3f46590$643264c8@BARRYS2GDELL> From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> To: "Greg Hudson" <ghudson@MIT.EDU> Cc: "Attila" <Attila.Sipos@VegaStream.com>, <namedroppers@ops.ietf.org> References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <1078587114.9992.126.camel@error-messages.mit.edu> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 11:10:08 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C404FD.EAE798E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your help, Greg. There's a note below about selection using random integers. ----- Original Message -----=20 From: "Greg Hudson" <ghudson@MIT.EDU> To: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Cc: <namedroppers@ops.ietf.org> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: DNS SRV Clarification sought > On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > > From page 3 of rfc2782 > > Compute the sum of the weights of those RRs, and with each = RR > > associate the running sum in the selected order. Then choose = a > > uniform random number between 0 and the sum computed > > (inclusive) > > > Random number case 0 1 2 3 > > 1st contact 1 1 2 2 > > 2nd contact 2 2 1 1 > > You appear to be computing a random integer, rather than a random real > number, as was intended. If you choose a random real number, you'll = get > the appropriate distribution (a server with weight 2 is chosen twice = as > often with a server of weight 1). > > I would have much preferred a statement which used random integers > (which is something you can actually do on a computer), but the = working > group was having a little trouble coming up with an algorithm = statement > that actually worked, so we decided to go with one which we strongly > believed was correct even if it wasn't very clear and which didn't > translate easily into code. Demonstration of selection using random integers. (Hope the fixed font is preserved and there's no line folding) Item Cumulative (weight) sum ---- -----=20 a a b a+b c a+b+c . . . . n a+b+c+...+n i.e.(sum(a...n)) Choosing a random integer between 1 and sum(a...n) inclusive and = selecting the first item greater than or equal to the random integer, we have - Random integer range 1...a a+1...a+b a+b+1...a+b+c Random integer frequency a (a+b)-(a+1)+1=3Db = (a+b+c)-(a+b+1)+1=3Dc Probability a/sum(a...n) b/sum(a...n) c/sum(a...n) For any item say, i, h being the previous item, Random integer range sum(a...h)+1...sum(a...i) Random integer frequency sum(a...i)-(sum(a...h)+1)+1=3Di Probability i/sum(a...n) Barry Desborough ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV><FONT face=3DArial size=3D2>Thanks for your help, = Greg.<BR><BR>There's a note=20 below about selection using random integers.<BR><BR>----- Original = Message -----=20 <BR>From: "Greg Hudson" <</FONT><A = href=3D"mailto:ghudson@MIT.EDU"><FONT=20 face=3DArial size=3D2>ghudson@MIT.EDU</FONT></A><FONT face=3DArial = size=3D2>><BR>To:=20 "Barry Desborough" <</FONT><A = href=3D"mailto:Barry.Desborough@wanadoo.fr"><FONT=20 face=3DArial size=3D2>Barry.Desborough@wanadoo.fr</FONT></A><FONT = face=3DArial=20 size=3D2>><BR>Cc: <</FONT><A = href=3D"mailto:namedroppers@ops.ietf.org"><FONT=20 face=3DArial size=3D2>namedroppers@ops.ietf.org</FONT></A><FONT = face=3DArial=20 size=3D2>><BR>Sent: Saturday, 06 March, 2004 16:31 PM<BR>Subject: Re: = DNS SRV=20 Clarification sought<BR><BR><BR>> On Sat, 2004-03-06 at 09:03, Barry=20 Desborough wrote:<BR>> > From page 3 of rfc2782<BR>>=20 >         Compute the sum of = the=20 weights of those RRs, and with each RR<BR>>=20 >         associate the = running sum=20 in the selected order. Then choose a<BR>>=20 >         uniform random = number=20 between 0 and the sum computed<BR>>=20 >         = (inclusive)<BR>><BR>>=20 > Random number case 0 1 2 3<BR>> > 1st=20 contact           =      =20 1 1 2 2<BR>> > 2nd=20 contact           =     =20 2 2 1 1<BR>><BR>> You appear to be computing a random integer, = rather than=20 a random real<BR>> number, as was intended.  If you choose a = random real=20 number, you'll get<BR>> the appropriate distribution (a server with = weight 2=20 is chosen twice as<BR>> often with a server of weight = 1).<BR>><BR>> I=20 would have much preferred a statement which used random integers<BR>> = (which=20 is something you can actually do on a computer), but the working<BR>> = group=20 was having a little trouble coming up with an algorithm = statement<BR>> that=20 actually worked, so we decided to go with one which we strongly<BR>> = believed=20 was correct even if it wasn't very clear and which didn't<BR>> = translate=20 easily into code.<BR><BR><FONT face=3D"Courier New">Demonstration of = selection=20 using random integers.<BR>(Hope the fixed font is preserved and there's = no line=20 folding)<BR><BR>Item     =20 Cumulative</FONT></FONT></DIV> <DIV><FONT face=3D"Courier New" size=3D2>(weight) =20 sum<BR>----      -----=20 <BR>a        =20 a<BR>b        =20 a+b<BR>c        =20 a+b+c<BR>.        =20 .<BR>.        =20 .<BR>n         a+b+c+...+n  = i.e.(sum(a...n))<BR><BR>Choosing a random integer between 1 and = sum(a...n)=20 inclusive and selecting<BR>the first item greater than or equal to the = random=20 integer, we have -</FONT></DIV> <DIV><BR><FONT face=3D"Courier New" size=3D2>Random integer=20 range     =20 1...a       =20 a+1...a+b        = a+b+1...a+b+c<BR>Random=20 integer frequency =20 a           =20 (a+b)-(a+1)+1=3Db =20 (a+b+c)-(a+b+1)+1=3Dc<BR>Probability      &= nbsp;       =20 a/sum(a...n) b/sum(a...n)     = c/sum(a...n)<BR><BR>For any=20 item say, i, h being the previous item,</FONT></DIV> <DIV><BR><FONT face=3D"Courier New" size=3D2>Random integer=20 range      sum(a...h)+1...sum(a...i)<BR>Random = integer=20 frequency =20 sum(a...i)-(sum(a...h)+1)+1=3Di<BR>Probability    &nb= sp;         =20 i/sum(a...n)<BR><BR>Barry Desborough<BR></FONT></DIV></BODY></HTML> ------=_NextPart_000_0007_01C404FD.EAE798E0-- -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 10:35:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07745 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 10:35:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0Mgm-00065I-25 for namedroppers-data@psg.com; Mon, 08 Mar 2004 15:29:08 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Mgb-0005zN-2k for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 15:28:57 +0000 Received: from lapdancer (asynce026.nist.gov [129.6.31.26]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i28FSSPf027106; Mon, 8 Mar 2004 10:28:29 -0500 (EST) Message-ID: <000301c40521$f3ba77c0$1a1f0681@lapdancer> From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Cc: "Pekka Savola" <pekkas@netcore.fi> References: <20040308062928.A818E14C73@sa.vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:59:49 -0500 Organization: NIST MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Paul Vixie" <paul@vix.com> > > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > > of scope. > > > > I meant > > > > DNSSEC entities MUST NOT send messages larger than 4000 > > over UDP > > > > Can it be within the scope of DNSSEC? > > then it would be within scope for this docset, but extremely controversial > since it places a requirement more stringent than EDNS0. far better to make > it advisory and avoid the fight. > It would also be an arbitrary limit based on current underlying network layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or EDNS0. It would best not be made a strict constraint that might be made obsolete by non-DNS factors. I agree with Paul in that it would be better to be an advisory statement, but not necessary to the specification. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 10:58:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09730 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 10:58:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0N7F-000I9Z-Qb for namedroppers-data@psg.com; Mon, 08 Mar 2004 15:56:29 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0N74-000I5I-5e for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 15:56:18 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i28Ftsna033175 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 10:55:54 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i28FtsIY033174 for namedroppers@ops.ietf.org; Mon, 8 Mar 2004 10:55:54 -0500 (EST) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0DSc-000Dyz-Ju for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 05:37:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i285blI16810; Mon, 8 Mar 2004 07:37:47 +0200 Date: Mon, 8 Mar 2004 07:37:47 +0200 (EET) From: Pekka Savola <pekkas@netcore.fi> To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Message-ID: <Pine.LNX.4.44.0403080733160.16733-100000@netcore.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > With DNSSEC, I'm not sure that this holds anymore. It seems to me > > that the best behaviour would be to avoid IP fragmentation by having > > correct implementations of EDNS0, and if some data must be left out, > > that it would be fetched separately, over second, third, ..., nth > > query over UDP. Shouldn't that be possible and reasonable? > > no, that really would force tcp, which really would be worse than ip-frag. Seems like a flaw in DNS spec -- too coarse granularity: 1) "everything fits in one UDP datagram", or 2) "just use TCP". Would it make sense to add 1.5) there, "if it doesn't fit to a UDP datagram of specific size, query again, but only the missing data this time". Not sure if that would make sense but instead of forcing everything in one, probably fragmented message, it would seem to encourage "proper" operation with big DNS replies. Btw: note that IPv6 implementations aren't even required to defragment a datagram which is larger than 1500 bytes once assembled.. so we're in a bit murky waters here. I'd certainly want to try to avoid packet sizes >= ~1500. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 10:58:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09733 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 10:58:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0N8H-000Igs-Ti for namedroppers-data@psg.com; Mon, 08 Mar 2004 15:57:33 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0N74-000I5c-S0 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 15:56:19 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i28Fttna033185 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 10:55:55 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i28FttLh033184 for namedroppers@ops.ietf.org; Mon, 8 Mar 2004 10:55:55 -0500 (EST) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0FOM-000AI7-86 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 07:41:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i287fYR18342; Mon, 8 Mar 2004 09:41:34 +0200 Date: Mon, 8 Mar 2004 09:41:34 +0200 (EET) From: Pekka Savola <pekkas@netcore.fi> To: Mark Andrews <Mark_Andrews@isc.org> cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: <200403080658.i286wXcq013551@drugs.dv.isc.org> Message-ID: <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > What's your issue here? > > IPv4 has reassembly buffer size limits. > IPv6 has reassembly buffer size limits. > > In either case you don't advertise a EDNS UDP buffer bigger > than this limit. It would be nice if EDNS0 implementations conformed to these buffer sizes then. Currently it seems they have zero relation to MTU or PMTU, or buffer sizes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 10:59:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09776 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 10:59:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0N8Y-000Io7-9X for namedroppers-data@psg.com; Mon, 08 Mar 2004 15:57:50 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0N75-000I5o-51 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 15:56:19 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i28Fttna033190 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 10:55:55 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i28FttWW033189 for namedroppers@ops.ietf.org; Mon, 8 Mar 2004 10:55:55 -0500 (EST) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Fq6-000F4c-Gb for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 08:10:18 +0000 Received: from drugs.dv.isc.org (localhost [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 007C8A83E for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 08:10:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i288AAcq036874; Mon, 8 Mar 2004 19:10:10 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200403080810.i288AAcq036874@drugs.dv.isc.org> To: Pekka Savola <pekkas@netcore.fi> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-reply-to: Your message of "Mon, 08 Mar 2004 09:41:34 +0200." <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Date: Mon, 08 Mar 2004 19:10:10 +1100 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > What's your issue here? > > > > IPv4 has reassembly buffer size limits. > > IPv6 has reassembly buffer size limits. > > > > In either case you don't advertise a EDNS UDP buffer bigger > > than this limit. > > It would be nice if EDNS0 implementations conformed to these buffer > sizes then. On what platforms do the existing implementation not take these into account. Note most *nix platforms support 4k UDP datagrams already. > Currently it seems they have zero relation to MTU or PMTU, or buffer > sizes. There doesn't have to be a *explict* relationship to these. The current recommendations already take these into account. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 10:59:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09801 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 10:59:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0N7l-000IMW-Ud for namedroppers-data@psg.com; Mon, 08 Mar 2004 15:57:01 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0N74-000I5Y-GA for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 15:56:18 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i28Ftsna033180 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 10:55:54 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i28FtsXF033179 for namedroppers@ops.ietf.org; Mon, 8 Mar 2004 10:55:54 -0500 (EST) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Eir-00039c-GN for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 06:58:45 +0000 Received: from drugs.dv.isc.org (localhost [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 AC7C7A82B for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 06:58:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i286wXcq013551; Mon, 8 Mar 2004 17:58:33 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200403080658.i286wXcq013551@drugs.dv.isc.org> To: namedroppers@ops.ietf.org Cc: Pekka Savola <pekkas@netcore.fi> From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-reply-to: Your message of "Mon, 08 Mar 2004 06:26:31 -0000." <20040308062631.C827814750@sa.vix.com> Date: Mon, 08 Mar 2004 17:58:33 +1100 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. What's your issue here? IPv4 has reassembly buffer size limits. IPv6 has reassembly buffer size limits. In either case you don't advertise a EDNS UDP buffer bigger than this limit. Mark -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 11:10:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10898 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 11:10:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0NJ8-000OWd-US for namedroppers-data@psg.com; Mon, 08 Mar 2004 16:08:46 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0NIy-000OSz-4n for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 16:08:36 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 834481; Mon, 08 Mar 2004 10:08:35 -0600 Message-ID: <404C9A81.2040708@ehsco.com> Date: Mon, 08 Mar 2004 10:08:33 -0600 From: "Eric A. Hall" <ehall@ehsco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought References: <20040306184811.B96C914C51@sa.vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3/6/2004 12:48 PM, Paul Vixie wrote: > iana should create a registry of service identifiers, by importing the > BSD file "/etc/services" and then periodically amending it for new > standards Is that really feasible? Service definitions may require weighting values and client-selection algorithms to be useful, all of which requires some level of agreement among implementors. If we start with a list of defaults and then update the list on-the-fly, how does the client know which version of the list entry is in use for those SRV RRs that they encounter? The nice thing about the current model is that an entry in the list connotes agreement among implementors, or at least carries a footnote. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 11:27:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12070 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 11:27:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0NZZ-0005ig-Dc for namedroppers-data@psg.com; Mon, 08 Mar 2004 16:25:45 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0NZO-0005eE-8U for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 16:25:34 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id i28GPXv08300 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 17:25:33 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i28GPWj26118 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 17:25:32 +0100 (MET) Message-Id: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-reply-to: Your message of "Mon, 08 Mar 2004 10:08:33 CST." <404C9A81.2040708@ehsco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26114.1078763131.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 08 Mar 2004 17:25:32 +0100 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Eric A. Hall wrote: > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards which would be different from <http://www.iana.org/assignments/port-numbers>? > Is that really feasible? Service definitions may require weighting values What weighting values are you talking about? Those in the SRV RR are not supposed to carry any additional meaning. RFC 2782 is pretty clear about the service names to be used: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. [...] Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. STD 2 is obsoleted by RFC 3232, again pointing to the URL above (although rather indirectly). What may be missing is a list of services without portnumber. In the whois case mentioned earlier inthis thread (which, btw uses "nicname" instead of the more prominent "whois" because of the "Service" requirement cited above) one would sometimes like to further differentiate the service without really using a different protocol, e.g. _ripe_whois.tcp... -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 12:21:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14766 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 12:21:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0OOf-000342-6s for namedroppers-data@psg.com; Mon, 08 Mar 2004 17:18:33 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0OOE-0002pT-61 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 17:18:06 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i28HHfna033588 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 12:17:42 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i28HHfDL033587 for namedroppers@ops.ietf.org; Mon, 8 Mar 2004 12:17:41 -0500 (EST) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0NZB-0005aj-20 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 16:25:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i28GPGk25738; Mon, 8 Mar 2004 18:25:17 +0200 Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET) From: Pekka Savola <pekkas@netcore.fi> To: Paul Vixie <paul@vix.com> cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: <20040308062631.C827814750@sa.vix.com> Message-ID: <Pine.LNX.4.44.0403081821250.25661-100000@netcore.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > > ... would force tcp, which really would be worse than ip-frag. > > > > Seems like a flaw in DNS spec -- too coarse granularity: > > 1) "everything fits in one UDP datagram", or > > 2) "just use TCP". > > > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > > datagram of specific size, query again, but only the missing data this > > time". > > sense, yes, but the atomicity requirements are hard to adjust in that light. Precisely -- but IMHO we need to figure out whether such atomicity requirements exist. They very certainly exist with 512 byte limit and DNSSEC. But do they exist e.g., with 1400 bytes? I'm a bit doubtful.. but I'd be interested in hearing what might be a "typical case", a "bad case", and "worst case". (We'll never be able to handle the last one, of course.) > > Not sure if that would make sense but instead of forcing everything in > > one, probably fragmented message, it would seem to encourage "proper" > > operation with big DNS replies. > > in general, if you think the response might be larger than 3*EPMTU, use tcp, > and that will amortize the complexity nicely. note that PMTUD hasn't been a > raging success, and that EPMTU is probably 1500 octets most of the time, and > that's where masataka's "4000" number comes from. Yep, EPMTU is 1500 bytes or a bit less -- but isn't that sufficient for about all intents and purposes? > > Btw: note that IPv6 implementations aren't even required to defragment > > a datagram which is larger than 1500 bytes once assembled.. so we're > > in a bit murky waters here. I'd certainly want to try to avoid packet > > sizes >= ~1500. > > yes but on such a host, the EDNS0 initiator would presumably be able to > discover this limitation and advertise a 1500-octet buffer. that's what > the EDNS0 spec says it should do, at any rate. Should, yes :). Does, no. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 12:21:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14785 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 12:21:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0OOO-0002vg-W9 for namedroppers-data@psg.com; Mon, 08 Mar 2004 17:18:16 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0OOD-0002pJ-Ls for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 17:18:05 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i28HHfna033583 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 12:17:41 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i28HHfIM033582 for namedroppers@ops.ietf.org; Mon, 8 Mar 2004 12:17:41 -0500 (EST) Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0NVM-0003wk-IE for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 16:21:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i28GLKI25686; Mon, 8 Mar 2004 18:21:21 +0200 Date: Mon, 8 Mar 2004 18:21:20 +0200 (EET) From: Pekka Savola <pekkas@netcore.fi> To: Mark Andrews <Mark_Andrews@isc.org> cc: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: <200403080810.i288AAcq036874@drugs.dv.isc.org> Message-ID: <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > > It would be nice if EDNS0 implementations conformed to these buffer > > sizes then. > > On what platforms do the existing implementation not take > these into account. Note most *nix platforms support 4k > UDP datagrams already. I don't know, maybe some embedded systems have restrictions. In any case 4000 byte UDP buffers does not equal being able to defragment datagrams worth of 4000 bytes total, right? > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > sizes. > > There doesn't have to be a *explict* relationship to these. > The current recommendations already take these into account. Well, about all the implementations I've seen set the EDNS0 irrespective of the MTU or PMTU configured on the system, which might make sense. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 13:05:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17392 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 13:05:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0P66-000NSz-Eg for namedroppers-data@psg.com; Mon, 08 Mar 2004 18:03:26 +0000 Received: from [207.65.203.98] (helo=goose.ehsco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0P5n-000NCg-SJ for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 18:03:07 +0000 Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 834491 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 12:03:07 -0600 Message-ID: <404CB559.4060007@ehsco.com> Date: Mon, 08 Mar 2004 12:03:05 -0600 From: "Eric A. Hall" <ehall@ehsco.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought References: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 3/8/2004 10:25 AM, Peter Koch wrote: > Eric A. Hall wrote: >> Is that really feasible? Service definitions may require weighting >> values > > What weighting values are you talking about? Those in the SRV RR are > not supposed to carry any additional meaning. The 'priority' field is different from the 'weight' field. RFC2782 says the following about the weight: | In the absence of a protocol whose specification calls for the | use of other weighting information, a client arranges the SRV | RRs of the same Priority in the order in which target hosts, | specified by the SRV RRs, will be contacted. > RFC 2782 is pretty clear about the service names to be used: Well, that's not the whole ball of wax. Service names can vary for reasosn other than protocol (http != www). Service names are relative labels which do not describe behavioral rules which may be associated with the service in general (algorithm may require SRV for in-addr space, or domain-wide space, or host-specific maps). Etc. Really, it seems to me that it's best to leave the list of well-known definitions for those SRV mappings and algorithms which are actually defined by the affected community. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 13:51:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20503 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 13:51:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0Pn3-000HGP-OV for namedroppers-data@psg.com; Mon, 08 Mar 2004 18:47:49 +0000 Received: from [192.20.225.112] (helo=mail-dark.research.att.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Pmt-000HCx-3E for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 18:47:39 +0000 Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by mail-dark.research.att.com (Postfix) with ESMTP id AB510E8233; Mon, 8 Mar 2004 13:48:23 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by mail-blue.research.att.com (Postfix) with ESMTP id 1E44EF3B06; Mon, 8 Mar 2004 13:40:07 -0500 (EST) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id i28IlbS24713; Tue, 9 Mar 2004 03:47:37 +0900 (JST) From: <fenner@research.att.com> Message-Id: <200403081847.i28IlbS24713@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: pk@TechFak.Uni-Bielefeld.DE Subject: Re: DNS SRV Clarification sought Cc: namedroppers@ops.ietf.org Date: Tue, 9 Mar 2004 03:47:36 +0900 Versions: dmail (solaris) 2.5a/makemail 2.9d X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> > iana should create a registry of service identifiers, by importing the >> > BSD file "/etc/services" and then periodically amending it for new >> > standards > >which would be different from ><http://www.iana.org/assignments/port-numbers>? Actually, I always thought that RFC 2782's [STD 2] reference was to the "PROTOCOL AND SERVICE NAMES" section, aka <http://www.iana.org/assignments/service-names>, and people who looked for the names in port-numbers were confused by the lack of strong binding to the reference (since there's no strong requirement for a port number assignment, just a name). 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 14:35:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22958 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 14:35:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0QV9-000BuL-2C for namedroppers-data@psg.com; Mon, 08 Mar 2004 19:33:23 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0QU4-000BPL-5N for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 19:32:16 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id i28JWEv02845 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 20:32:15 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i28JWEp27144 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 20:32:14 +0100 (MET) Message-Id: <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-reply-to: Your message of "Tue, 09 Mar 2004 03:47:36 +0900." <200403081847.i28IlbS24713@windsor.research.att.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27142.1078774333.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 08 Mar 2004 20:32:14 +0100 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bill Fenner wrote: > was to the "PROTOCOL AND SERVICE NAMES" section, aka > <http://www.iana.org/assignments/service-names>, and people who looked this teaches us that the registry name will need to be specified explicitly, especially since URL references to the IANA registries are (were when I tried) only allowed to point to http://www.iana.org/numbers.html. > for the names in port-numbers were confused by the lack of strong binding Thanks, and increase the number of confused :-) > to the reference (since there's no strong requirement for a port number > assignment, just a name). The document you mention references WKS RRs, and since SRV is an orthogonal, though not totally unrelated, concept, it may be useful to use the same registry. However, since WKS uses port numbers (in a bit string) on-the-wire, I'm not too sure I understand the reasoning behind a registry dealing with names *only*. What's more important is some kind of link to the spec describing a) the protocol and b) use of SRV RRs in connection with that protocol. Elevation of 2782 will give us an opportunity to clarify this. -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 15:15:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26018 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 15:15:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0R7P-0001e7-JK for namedroppers-data@psg.com; Mon, 08 Mar 2004 20:12:55 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0R7E-0001cn-C9 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 20:12:44 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i28KCJna034190 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 15:12:19 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i28KCJda034189 for namedroppers@ops.ietf.org; Mon, 8 Mar 2004 15:12:19 -0500 (EST) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Pgr-000EIZ-Ld for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 18:41:25 +0000 Received: from drugs.dv.isc.org (localhost [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 CBCB3A843 for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 18:41:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i28IfIcq077991; Tue, 9 Mar 2004 05:41:18 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200403081841.i28IfIcq077991@drugs.dv.isc.org> To: Pekka Savola <pekkas@netcore.fi> Cc: namedroppers@ops.ietf.org From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-reply-to: Your message of "Mon, 08 Mar 2004 18:21:20 +0200." <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Date: Tue, 09 Mar 2004 05:41:18 +1100 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > > It would be nice if EDNS0 implementations conformed to these buffer > > > sizes then. > > > > On what platforms do the existing implementation not take > > these into account. Note most *nix platforms support 4k > > UDP datagrams already. > > I don't know, maybe some embedded systems have restrictions. Well if you are writing a resolver for such a system you take its IP stack limitations into consideration. There are lots of additional considerations when writing for small memory platforms. Nobody is saying you *MUST* use certain size, just that they are recommended. Named has a switch to set the advertised size to 512. > In any case 4000 byte UDP buffers does not equal being able to > defragment datagrams worth of 4000 bytes total, right? > > > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > > sizes. > > > > There doesn't have to be a *explict* relationship to these. > > The current recommendations already take these into account. > > Well, about all the implementations I've seen set the EDNS0 > irrespective of the MTU or PMTU configured on the system, which might > make sense. With the current Internet the min(MTU,PMTU) will usually be 1500, ethernet/ppp default. Rarely will it be below 1200, slip default. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 16:20:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03381 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 16:20:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0S7o-000181-Rg for namedroppers-data@psg.com; Mon, 08 Mar 2004 21:17:24 +0000 Received: from [65.205.251.73] (helo=peacock.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0S7d-00013w-LP for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 21:17:13 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by peacock.verisign.com (8.12.11/) with ESMTP id i28LH8sw017532; Mon, 8 Mar 2004 13:17:08 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <GJR7ZBYV>; Mon, 8 Mar 2004 13:17:08 -0800 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E0A195E@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Eric A. Hall'" <ehall@ehsco.com>, Paul Vixie <paul@vix.com> Cc: namedroppers@ops.ietf.org Subject: RE: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 13:17:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Registies are over-rated. Look at the number of programs there are on windows that have their own file format. Important name collisions are pretty rare considering that it is essentially a 3 character identifier. All that matters here is that the identifier be unique and plentiful enough that they do not run out. If you try to impose any requirement that is more stringent than first come first served we end up back with the X-Header problem. We could adopt the hash-cash scheme that Microsoft is pushing for anti-spam as a way of rationing code points in tables. All code points are first come first served. To get the code point 'SPAM' in table 'SRV' you have to provide a string s such that SHA1(s) - SHA1('SPAM+SRV') <> 0 AND |SHA1(s) - SHA1('SPAM+SRV')| < 2^(160-n) I.e. the strings must not be the same and the first n bits must match. The value of n would increase as the code points in the registry were exhausted. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eric A. Hall > Sent: Monday, March 08, 2004 11:09 AM > To: Paul Vixie > Cc: namedroppers@ops.ietf.org > Subject: Re: DNS SRV Clarification sought > > > > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by > importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards > > Is that really feasible? Service definitions may require > weighting values > and client-selection algorithms to be useful, all of which > requires some > level of agreement among implementors. > > If we start with a list of defaults and then update the list > on-the-fly, > how does the client know which version of the list entry is in use for > those SRV RRs that they encounter? > > The nice thing about the current model is that an entry in the list > connotes agreement among implementors, or at least carries a footnote. > > -- > Eric A. Hall > http://www.ehsco.com/ > Internet Core Protocols > http://www.oreilly.com/catalog/coreprot/ > > -- > 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://ops.ietf.org/lists/namedroppers/> > -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 18:03:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09330 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 18:03:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0TjX-0003a6-9e for namedroppers-data@psg.com; Mon, 08 Mar 2004 23:00:27 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0TjM-0003Vx-Fu for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 23:00:16 +0000 Received: (qmail 74350 invoked from network); 8 Mar 2004 23:01:38 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 8 Mar 2004 23:01:38 -0000 Message-ID: <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Mar 2004 08:02:38 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Scott Rose <scottr@nist.gov> CC: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <20040308062928.A818E14C73@sa.vix.com> <000301c40521$f3ba77c0$1a1f0681@lapdancer> In-Reply-To: <000301c40521$f3ba77c0$1a1f0681@lapdancer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose; > It would also be an arbitrary limit based on current underlying network > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > EDNS0. 512 byte limit is a bound not by DNS but by the current underlying network and transport layers. So? > but not necessary to the specification. It is necessary that DNS message size has a limit in the specification. Masataka Ohta PS The proper limit bound by minimum reassembly buffer size, maximum IP header length and UDP header length is 508. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 18:47:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12019 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 18:47:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0UQD-000F9N-Te for namedroppers-data@psg.com; Mon, 08 Mar 2004 23:44:33 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0UPu-000F88-T4 for namedroppers@ops.ietf.org; Mon, 08 Mar 2004 23:44:15 +0000 Received: (qmail 74520 invoked from network); 8 Mar 2004 23:45:37 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 8 Mar 2004 23:45:37 -0000 Message-ID: <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Mar 2004 08:46:37 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark Andrews <Mark_Andrews@isc.org> CC: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <200403082335.i28NZOcq081725@drugs.dv.isc.org> In-Reply-To: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Andrews; > Why are we arguing about the minimums that have to be > supported by the architecure? Because the minimums of the infrastructure are maximums of DNS. > For example, named has a upper bound on the size of the > EDNS/UDP response it will send. And, it should be specified. Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 8 20:39:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15823 for <dnsext-archive@lists.ietf.org>; Mon, 8 Mar 2004 20:39:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0WA4-00052t-1z for namedroppers-data@psg.com; Tue, 09 Mar 2004 01:36:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B0W9t-00050S-82 for namedroppers@ops.ietf.org; Tue, 09 Mar 2004 01:35:49 +0000 Received: (qmail 74736 invoked from network); 9 Mar 2004 00:37:12 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 9 Mar 2004 00:37:12 -0000 Message-ID: <404D11F3.60509@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Mar 2004 09:38:11 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Mark Andrews <Mark_Andrews@isc.org> CC: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <200403090023.i290Nhcq082341@drugs.dv.isc.org> In-Reply-To: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark Andrews; > EDNS and DNS are *different* protocols which share a port and > message format. RFC2671 This document describes backward compatible mechanisms for allowing the protocol to *GROW*. Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 9 03:20:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13830 for <dnsext-archive@lists.ietf.org>; Tue, 9 Mar 2004 03:20:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0cMl-000P9I-OW for namedroppers-data@psg.com; Tue, 09 Mar 2004 08:13:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0cMa-000P4S-TN for namedroppers@ops.ietf.org; Tue, 09 Mar 2004 08:13:21 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 3731F4E148; Tue, 9 Mar 2004 09:13:20 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id EA0144E11B; Tue, 9 Mar 2004 09:13:19 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i298DJht002724; Tue, 9 Mar 2004 09:13:19 +0100 Date: Tue, 9 Mar 2004 09:13:19 +0100 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Greg Hudson <ghudson@MIT.EDU> Cc: andras@dns.net, namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought Message-Id: <20040309091319.74e2026d.olaf@ripe.net> In-Reply-To: <1078594181.9992.134.camel@error-messages.mit.edu> References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <1078594181.9992.134.camel@error-messages.mit.edu> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.473609 / 0.0 / 0.0 X-RIPE-Signature: 86a7b34adf4294872cd6cf962183ce6b X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 06 Mar 2004 12:29:42 -0500 Greg Hudson <ghudson@MIT.EDU> wrote: > On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > > I tried to find an online deployment of SRV records to feed to tcpdump, > > but the closest I came was an SOA record for _tcp.microsoft.com (one of > > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > > appear to have _tcp subdomains. Does anyone actually have a deployment > > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? > > We appear to have: > > _sip._tcp.mit.edu > _sip._udp.mit.edu > _sip._tcp.sipxchange.mit.edu > _sip._udp.sipxchange.mit.edu Where the use of SRV for SIP is documented in RFC3263 -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 9 10:37:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01889 for <dnsext-archive@lists.ietf.org>; Tue, 9 Mar 2004 10:37:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0jE6-0007kr-9e for namedroppers-data@psg.com; Tue, 09 Mar 2004 15:33:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0jDu-0007fl-QO for namedroppers@ops.ietf.org; Tue, 09 Mar 2004 15:32:51 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i29FWEna037671 for <namedroppers@ops.ietf.org>; Tue, 9 Mar 2004 10:32:14 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i29FWEeJ037670 for namedroppers@ops.ietf.org; Tue, 9 Mar 2004 10:32:14 -0500 (EST) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0Wu0-000M7d-Us for namedroppers@ops.ietf.org; Tue, 09 Mar 2004 02:23:28 +0000 Received: from drugs.dv.isc.org (localhost [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 5B6D6A84E for <namedroppers@ops.ietf.org>; Mon, 8 Mar 2004 23:35:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i28NZOcq081725; Tue, 9 Mar 2004 10:35:24 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200403082335.i28NZOcq081725@drugs.dv.isc.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-reply-to: Your message of "Tue, 09 Mar 2004 08:02:38 +0900." <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Mar 2004 10:35:24 +1100 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Scott Rose; > > > It would also be an arbitrary limit based on current underlying network > > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > > EDNS0. > > 512 byte limit is a bound not by DNS but by the current underlying > network and transport layers. > > So? > > > but not necessary to the specification. > > It is necessary that DNS message size has a limit in the specification. > > Masataka Ohta > > PS > > The proper limit bound by minimum reassembly buffer size, maximum > IP header length and UDP header length is 508. Why are we arguing about the minimums that have to be supported by the architecure? EDNS is about letting the the other end knowing what you are *capable of handling*. There is *nothing* in to stop a site sending *smaller* EDNS/UDP message than the receiving site is capable of handling. If the client says it can accept a 4k response but you know that your firewall is broken (e.g. drops DNS packets > 512) you are quite entitled to only send a 512 byte EDNS/UDP responses. Set TC as appropriate. For example, named has a upper bound on the size of the EDNS/UDP response it will send. You can advertise a 64k UDP buffer all you want but you will not get more that 4k EDNS/UDP response. Mark -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 9 10:38:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01923 for <dnsext-archive@lists.ietf.org>; Tue, 9 Mar 2004 10:38:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0jEM-0007uW-63 for namedroppers-data@psg.com; Tue, 09 Mar 2004 15:33:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0jDv-0007fo-1C for namedroppers@ops.ietf.org; Tue, 09 Mar 2004 15:32:51 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i29FWJna037676 for <namedroppers@ops.ietf.org>; Tue, 9 Mar 2004 10:32:19 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i29FWJ6U037675 for namedroppers@ops.ietf.org; Tue, 9 Mar 2004 10:32:19 -0500 (EST) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0WCR-0005Ol-DW for namedroppers@ops.ietf.org; Tue, 09 Mar 2004 01:38:27 +0000 Received: from drugs.dv.isc.org (localhost [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 03497A84D for <namedroppers@ops.ietf.org>; Tue, 9 Mar 2004 00:23:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.10/8.12.10) with ESMTP id i290Nhcq082341; Tue, 9 Mar 2004 11:23:43 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200403090023.i290Nhcq082341@drugs.dv.isc.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-reply-to: Your message of "Tue, 09 Mar 2004 08:46:37 +0900." <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Mar 2004 11:23:43 +1100 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Mark Andrews; > > > Why are we arguing about the minimums that have to be > > supported by the architecure? > > Because the minimums of the infrastructure are maximums of DNS. We are talking about EDNS. Nobody is thinking about changing the DNS UDP message size. The DNS is constained in this way, EDNS is not. EDNS and DNS are *different* protocols which share a port and message format. EDNS has a UDP request size limit of 512 bytes (inherited from DNS) unless you have reason to believe a larger request can be handled. e.g. you have just made a request and have been told that a bigger request can be handled. EDNS has a *negotiated* response size limit. This is IP stack dependent and will usually be *bigger* than the infrastructure minimums. It can also be smaller the the infrastructure minimums. e.g. you have a IPv6 firewall which is rejecting DNS packets > 512 bytes so you set the EDNS UDP size advertised to 512. The advertised EDNS UDP size is less than the minimum supported by the IPv6. DNS has a UDP request and response size limit of 512 bytes. > > For example, named has a upper bound on the size of the > > EDNS/UDP response it will send. > > And, it should be specified. Why. This is a *implemtation* limit not a *protocol* limit. RFC 2671 already has guidance for seting this limit. > > Masataka Ohta > > -- 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 9 11:08:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05772 for <dnsext-archive@lists.ietf.org>; Tue, 9 Mar 2004 11:08:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B0jig-000NMD-Cx for namedroppers-data@psg.com; Tue, 09 Mar 2004 16:04:38 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0jiV-000NGV-Br for namedroppers@ops.ietf.org; Tue, 09 Mar 2004 16:04:27 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id A4C044EC9B; Tue, 9 Mar 2004 17:04:26 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 679484EC96; Tue, 9 Mar 2004 17:04:26 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i29G4Qht001545; Tue, 9 Mar 2004 17:04:26 +0100 Date: Tue, 9 Mar 2004 17:04:26 +0100 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Message-Id: <20040309170426.6f57073b.olaf@ripe.net> In-Reply-To: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> References: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.456200 / 0.0 / 0.0 X-RIPE-Signature: 61983aa15b37f75c7f5207c40c99cbab X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). It seems there _could_ be consensus for an advisory note targeted at implementors, if only there were such a note. Can somebody please come up with text that can be put into the document set so we can focus on getting that correct and the editors can cut-n-paste. Let us not try to fix EDNS0, that is not in scope. -- Olaf -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 10 12:06:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20120 for <dnsext-archive@lists.ietf.org>; Wed, 10 Mar 2004 12:06:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B172e-0002ey-W6 for namedroppers-data@psg.com; Wed, 10 Mar 2004 16:58:48 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B172U-0002bZ-C7 for namedroppers@ops.ietf.org; Wed, 10 Mar 2004 16:58:38 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id C4B984E5C5; Wed, 10 Mar 2004 17:58:37 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7B8334E2C1 for <namedroppers@ops.ietf.org>; Wed, 10 Mar 2004 17:58:37 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i2AGwbht004992 for <namedroppers@ops.ietf.org>; Wed, 10 Mar 2004 17:58:37 +0100 Date: Wed, 10 Mar 2004 17:58:37 +0100 From: "Olaf M. Kolkman" <olaf@ripe.net> To: namedroppers@ops.ietf.org Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Message-Id: <20040310175837.572d6a16.olaf@ripe.net> In-Reply-To: <6.0.3.0.2.20040212231103.02da4b80@localhost> References: <20040128203233.08EE614C52@sa.vix.com> <6.0.3.0.2.20040212231103.02da4b80@localhost> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000719 / 0.0 / 0.0 X-RIPE-Signature: 022e6963a054024de5098a486a89bbd4 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > While attempting to summarize what the consensus of the working group > is on this editors question and trying to interpret this block of text. > Does self-consistently apply to a name or the holy Q-trinity? Having reread the threat I think that the answer to Olafurs question was in the proposed text (only for the _security_ RRs so only for specific holy Q-trinities :-) ). I propose the editors use Paul's initial text with the clarification that this only applies to those _security_ RRs that can exist above and below a delegation point. e.g. like: security aware responders who receive queries security RRs (NSEC or RRSIG RRs) which match the content of more than one zone, for example above and below a delegation point, are encouraged to behave self-consistently, which could mean: always return an error; always return above-delegation records; always return below-delegation records; always return no records; always return both above- and below-delegation records; or always something else entirely. We'll consider this question resolved if no further comments are received before the end of the week. -- Olaf -- 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://ops.ietf.org/lists/namedroppers/> From glppress_release@geocities.com Wed Mar 10 14:29:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28006 for <dnsext-archive@ietf.org>; Wed, 10 Mar 2004 14:29:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B19O9-0000Xc-00 for dnsext-archive@ietf.org; Wed, 10 Mar 2004 14:29:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B19Mn-0000Ep-00 for dnsext-archive@ietf.org; Wed, 10 Mar 2004 14:27:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B19Lm-0007fZ-00; Wed, 10 Mar 2004 14:26:42 -0500 Received: from [218.5.5.240] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1B197l-0008GH-DB; Wed, 10 Mar 2004 14:12:14 -0500 From: "Atualidade Brasileira . ivr" <glppress_release@geocities.com> To: dnsext-archive@ietf.org Subject: Ressurgimento da mentalidade estatizante? at.: too User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1B197l-0008GH-DB@mx2.foretec.com> Date: Wed, 10 Mar 2004 14:12:14 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.3 required=5.0 tests=HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,REMOVE_REMOVAL_2WORD, SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META NAME="Generator" CONTENT="Microsoft Word 97"> <META NAME="Template" CONTENT="C:\Arquivos de programas\Microsoft Office\Office\html.dot"> </HEAD> <BODY LINK="#0000ff" VLINK="#800080"> <P><!-- Please, follow the links: http://www.hotmail.com http://www.spamcop.net mailto:abernardico@yahoo.com?subject=Remove andrediniz@nonaarte.com.br andredogon@simbolo.com.br mailto:andredogon@simbolo.coml.sys.intranet?subject=Subscribir braulinojr@bol.com.br mailto:camera3@mail.telepac.pt?subject=IAgree caparroz@wanadoo.es mailto:carlospi@adinet.com.uy?subject=Adquirir DADEAN1@aol.com df01a8c0@xdata1.com.uy mailto:efigge@arnet.com.ar?subject=Unsubscribe elrey@123.com emancipacordoba@hotmail.com mailto:FabianF@exo.com.ar?subject=MyOpinion fuckspam@attbi.com gcv2000@adinet.com.uy gindre@indecs.org.br grupeiro@uol.com.br gsya@arnet.com.ar igge@arnet.com.ar iica@reuna.cl iranzo@fa.upc.es itiro@openlink.c itiro@openlink.com.br jaabril@comcast.net jaabril@mail.comcast.net jbarloccod@medynet.com jerez@adinet.com.uy --> <FONT FACE="Garamond" SIZE=2><P ALIGN="CENTER">ref.: ref - </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:EnEspañol"><FONT SIZE=2>EnEspañol</FONT></A><FONT FACE="Garamond" SIZE=2> - </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:InEnglish(LinkToFreeTranslator"><FONT SIZE=2>InEnglish(LinkToFreeTranslator)</FONT></A></P> <B><FONT FACE="Garamond" SIZE=4><P>Série Temas Patrulhados (4)</P> </FONT><FONT FACE="Garamond" SIZE=5><P ALIGN="CENTER">Preocupante ressurgimento da mentalidade estatizante</P> </B></FONT><I><FONT FACE="Garamond" SIZE=4><P ALIGN="CENTER">"A improbidade, o desmazelo administrativo, a esclerose, o nepotismo em empresas públicas são conseqüência da própria essência do estatismo: não são parasitas de uma árvore sadia, eles constituem o cerne de uma árvore doente", afirma Adolpho Lindenberg em recente artigo</P> </I></FONT><FONT FACE="Garamond"><P>** Adolpho Lindenberg é autor do livro <B>"Os católicos e a economia de mercado"</B>, em que denuncia uma política com viés esquerdista que censura, marginaliza ou encobre com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais" inspiradas na teologia da libertação e nos Fóruns Sociais. Assim, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".</P> <P> ** Em seu recente artigo <B>"Estatização ou Privatização?"</B>, da Série Temas Patrulhados, o autor adverte sobre um preocupante ressurgimento da mentalidade socialista, favorável à estatização da economia ou, pelo menos, desejosa de uma presença mais ativa do Estado.</P> <P>** Fazendo parte dessa corrente encontram-se radicais da esquerda, adeptos da Teologia da Libertação, social-democratas, saudosistas das antigas benesses dos regimes paternalistas e até democratas inconformados com a privatização das estatais, acrescenta o autor, lamentando que não são poucos os católicos que anseiam por uma maior interferência do Estado visando a implantação de políticas mais voltadas para "o social".</P> <P>** Exemplos típicos dessa mentalidade são a limitação à autonomia da Agência Nacional de Energia Elétrica (Aneel) sugerida pela ministra de Minas e Energia, Dilma Rousseff; e o lamentável desinteresse do Poder Público em reformar nossas rodovias mediante a ampliação da privatização dos serviços de manutenção das estradas. Aqueles que criticam a privatização se esquecem que os recursos necessários para a manutenção das estradas só podem provir de duas fontes: ou dos pedágios ou do erário público. Em outras palavras, ou pagam os usuários do serviço -o que é mais lógico- ou acabam pagando todos os contribuintes!</P> <P>** Quando se acumulam denúncias de malversação de fundos e de incapacidade administrativa, geradores dos enormes déficits das estatais, predomina na opinião pública a noção que tais mazelas são frutos da improbidade de seus dirigentes e que seria suficiente nomear diretores honestos e capazes para que cessassem todos esses descalabros. Na verdade, os desmandos são conseqüência da própria essência do estatismo. A improbidade, o desmazelo administrativo, a esclerose, o nepotismo, não são parasitas de uma árvore sadia, eles constituem o cerne de uma árvore doente. Para receber gratuitamente, por e-mail, o artigo completo, basta clicar em: </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:EsteArtigoCompletoGratuitamente(No.4)"><FONT FACE="Garamond">Lindenberg:EsteArtigoCompletoGratuitamente(No.4)</FONT></A></P> <FONT FACE="Garamond"><P>** Outros tópicos abordados no artigo:</P> <P>-- As empresas privadas são recompensadas ou penalizadas por seu desempenho, exceto em situações excepcionais, e os lucros ou os prejuízos são conseqüências forçosas da competência ou incompetência de sua gestão; quando, porém, uma empresa é propriedade do Estado, esta relação de causa e efeito, pura e simplesmente, deixa de existir.</P> <P>-- Nos casos das empresas controladas pelo Estado, não existe o objetivo de recompensar os executivos na proporção de seu desempenho gerencial.</P> <P>-- Nas estatais, a fiscalização diária, eficaz e construtiva, imprescindível para garantir que os funcionários realizem um bom trabalho, é praticamente inexistente; o critério das promoções baseia-se mais no tempo de serviço do que no mérito; órgãos de instância superior deveriam fiscalizar as estatais e tomar medidas tão drásticas quanto as que são tomadas pelos fiscais do governo relativamente às empresas privadas. </P> <P>-- As empresas públicas tornam-se facilmente vítimas do empreguismo. </P> <P>-- Num mundo dominado pela informática, com as economias sujeitas à globalização, só as empresas competitivas sobreviverão, e para isso devem estar em contínua atualização, acompanhando as variações do mercado, cortando custos e inovando produtos; ora, são precisamente estas as qualidades que faltam às empresas públicas.</P> <P>** Para receber gratuitamente, por e-mail, o texto completo deste artigo, clique em:</FONT><FONT FACE="Garamond" SIZE=4> </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:EsteArtigoCompletoGratuitamente(No.4)">Lindenberg:EsteArtigoCompletoGratuitamente(No.4)</A></P> <B><FONT FACE="Garamond"><P>Outros links para receber e-Book e artigos gratuitos </P> </B></FONT><P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:e-BookGratuitoBr">Lindenberg:e-BookGratuitoBr</A><FONT FACE="Garamond" SIZE=4> </FONT><FONT FACE="Garamond">(em formato Word, com 11 artigos de Lindenberg)</P> </FONT><P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:IntroduçãoGratuitaDoLivro">Lindenberg:IntroduçãoGratuitaDoLivro</A><FONT FACE="Garamond" SIZE=4> </FONT><FONT FACE="Garamond">(em formato Word, Introdução do livro "Os católicos e a economia de mercado")</P> </FONT><P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:ArtigosAnteriores">Lindenberg:ArtigosAnteriores</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:ProximosArtigos">Lindenberg:ProximosArtigos</A></P> <B><FONT FACE="Garamond"><P>Links de opinião</P> </B><P>Gostariamos muito de receber seu seu voto eletrônico sobre a temática abordada neste e-mail e, se possível, incluindo sua valiosa opinião:</P> </FONT><P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:Concordo">Lindenberg:Concordo </A><FONT FACE="Garamond" SIZE=4>- </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:Discrepo">Lindenberg:Discrepo </A><FONT FACE="Garamond" SIZE=4>- </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:Minha">Lindenberg:Minha Opinião</A></P> <B><FONT FACE="Garamond"><P>Outros links</P> </B></FONT><P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:DesejoAdquirirLivro">Lindenberg:DesejoAdquirirLivro</A><FONT FACE="Garamond" SIZE=4> </FONT><FONT FACE="Garamond">(receberá instruções sobre como poder adquirir o livro no Brasil)</P> </FONT><P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Lindenberg:Remover">Remover</A><FONT FACE="Garamond" SIZE=4> </FONT><FONT FACE="Garamond">(para ser retirado imediatamente de nosso Address Book).</P> <B><P ALIGN="CENTER">A difusão desta mensagem, com uma finalidade exclusivamente cultural, com o intuito de promover um debate construtivo e respeitoso de idéias, é de exclusiva responsabilidade da ConstruNews.</P> </B></FONT><P> </P> <P> </P></BODY> </HTML> From owner-namedroppers@ops.ietf.org Wed Mar 10 15:44:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03329 for <dnsext-archive@lists.ietf.org>; Wed, 10 Mar 2004 15:44:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1AVW-0002aT-M7 for namedroppers-data@psg.com; Wed, 10 Mar 2004 20:40:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1AVL-0002X2-FO for namedroppers@ops.ietf.org; Wed, 10 Mar 2004 20:40:39 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02830; Wed, 10 Mar 2004 15:40:37 -0500 (EST) Message-Id: <200403102040.PAA02830@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-04.txt Date: Wed, 10 Mar 2004 15:40:37 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-04.txt Pages : 9 Date : 2004-3-10 This document redefines the wire format of the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nsec-rdata-04.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-nsec-rdata-04.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: <2004-3-10150158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150158.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 11 10:39:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07050 for <dnsext-archive@lists.ietf.org>; Thu, 11 Mar 2004 10:39:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1SCg-0005ao-Oz for namedroppers-data@psg.com; Thu, 11 Mar 2004 15:34:34 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1SCV-0005Ux-SB for namedroppers@ops.ietf.org; Thu, 11 Mar 2004 15:34:24 +0000 Received: from ENGILL.ogud.com (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i2BFYSVa007795 for <namedroppers@ops.ietf.org>; Thu, 11 Mar 2004 10:34:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Thu, 11 Mar 2004 10:34:09 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf >Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >From: Derek Atkins <derek@ihtfp.com> >Date: Tue, 24 Feb 2004 22:14:43 -0500 > >It sounds like you want two things here, but it also sounds like all >of them need to happen in the responder. The attacker could >theoretically send packets of any type, with any TTL. So you can't >trust anything you receive from the network. To this affect, I think: > >1) We want the responder to try to determine that a request came from > the local network. The best way to do this is for the responder to > check that TTL=255 to make sure. If a TTL is less than 255 then it > originiated off-net and can be dropped. > >2) We want the responder to make sure response packets don't go > off-net. In other words, we want the responder to respond with > TTL=1, to make sure it can't smurf. > >So, to this affect: > >a) an LLMNR requestor should send requests with TTL=255 >b) an LLMNR responder should verify requests have TTL=255 -- if it is not > 255 then it should drop the packet. >c) an LLMNR responder should respond with TTL=1 >d) I dont' think an LLMNR requestor needs to check the response TTL. > >The only issue this doesn't directly solve is a requester being >spoofed by an off-net attacker, but said attacker would need >to guess the transaction id of the request in order to send a >valid response, which is just as likely in LLMNR as it is in >standard DNS, so it can probably be ignored. > >So, other than this issue, does this solve the 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 11 13:59:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16771 for <dnsext-archive@lists.ietf.org>; Thu, 11 Mar 2004 13:59:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1VIu-00099O-T3 for namedroppers-data@psg.com; Thu, 11 Mar 2004 18:53:12 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1VIj-00095W-VY for namedroppers@ops.ietf.org; Thu, 11 Mar 2004 18:53:02 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i2BIr14A002233 for <namedroppers@ops.ietf.org>; Thu, 11 Mar 2004 10:53:01 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6845f67e3a118064e13cc@mailgate1.apple.com>; Thu, 11 Mar 2004 10:53:00 -0800 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id i2BIqw6O015830; Thu, 11 Mar 2004 18:52:59 GMT In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--207754511; protocol="application/pkcs7-signature" Message-Id: <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> Cc: namedroppers@ops.ietf.org From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:52:56 -0800 To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com> X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-8--207754511 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I have an issue with this. Using a TTL of 255 to verify that requests originate from the local=20 link is not very important. It may be useful to use a unicast query to=20= specific address from off of the local link to ask for records such as=20= HINFO. In the case of multicast, unless something is seriously broken a=20= link-local multicast packet is not going to be forwarded. Setting the TTL to 1 also unnecessarily prohibits unicast=20 request/responses from off of the local link. I would consider it more=20= useful to verify that a response to a link-local multicast came from=20 the local link. To those who are concerned that setting the TTL to 255 on a response=20 would enable another smurf attack, I would encourage them to try=20 pinging the all hosts multicast address. Most hosts will respond to=20 such a ping. This has not lead to any serious problems. The solution to=20= the smurf attack was to drop the subnet broadcast packets in routers=20 (don't forward them). A link local multicast packet will not be=20 forwarded. The defense against the smurf style attack is already=20 implemented. Hosts still respond to pings with subnet broadcasts but=20 routers never forward such packets, so this is only a local=20 vulnerability. If someone is local they could just as easily spoof the=20= source address of their packets as any of the other devices on the=20 local network. If the whole point of changing the TTL is to achieve interoperability=20 with Rendezvous, then the proposal below fails. -josh On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > > The chairs are looking for closure and rough consensus on this only > remaining issue for LLMNR. > The solution below seems like a good solid compromise. > Is there any technical reason why this should not be adopted, please > state so before March 24'th. > > Olafur & Olaf > > >> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >> From: Derek Atkins <derek@ihtfp.com> >> Date: Tue, 24 Feb 2004 22:14:43 -0500 >> >> It sounds like you want two things here, but it also sounds like all >> of them need to happen in the responder. The attacker could >> theoretically send packets of any type, with any TTL. So you can't >> trust anything you receive from the network. To this affect, I = think: >> >> 1) We want the responder to try to determine that a request came from >> the local network. The best way to do this is for the responder = to >> check that TTL=3D255 to make sure. If a TTL is less than 255 then = it >> originiated off-net and can be dropped. >> >> 2) We want the responder to make sure response packets don't go >> off-net. In other words, we want the responder to respond with >> TTL=3D1, to make sure it can't smurf. >> >> So, to this affect: >> >> a) an LLMNR requestor should send requests with TTL=3D255 >> b) an LLMNR responder should verify requests have TTL=3D255 -- if it = is=20 >> not >> 255 then it should drop the packet. >> c) an LLMNR responder should respond with TTL=3D1 >> d) I dont' think an LLMNR requestor needs to check the response TTL. >> >> The only issue this doesn't directly solve is a requester being >> spoofed by an off-net attacker, but said attacker would need >> to guess the transaction id of the request in order to send a >> valid response, which is just as likely in LLMNR as it is in >> standard DNS, so it can probably be ignored. >> >> So, other than this issue, does this solve the 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: <http://ops.ietf.org/lists/namedroppers/> --Apple-Mail-8--207754511 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxMTE4NTI1N1owIwYJKoZIhvcNAQkEMRYEFP0O Ia3W8w/x+47YEoXcV/9pDyndMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAApn zOCUjtzfx/HePoVrW9B92akgPc+74/dwmULkkUhYbv/Iw+gASUnplhFK3mz62o1NZYRGb4RuHmjx ar1KWlU8rIl3QoCNBqY8q3QISGI2oApMtnVXMf0abz/IST8hTndYl02br+7iXmDdyNuUrYQmjRyt QYIV3JUzV7Q8UOBiRwPRYuSeiDvJEsCd1h5IMExVNZOBjD69fu3oMK5bVq3gHNPQyKl59BSFkJlE 3w89yzOFPI67eeDhzDVEraXIW8w04oNM6AkzxjJwNugRReSSZAe635ZDBiMFzowtQf7pdNqpSN7c Jr0s0lkNZg2K8rc+5ALBd7MpnTMj44AxUt4AAAAAAAA= --Apple-Mail-8--207754511-- -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 12 11:43:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02078 for <dnsext-archive@lists.ietf.org>; Fri, 12 Mar 2004 11:43:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1pfH-000Gra-Km for namedroppers-data@psg.com; Fri, 12 Mar 2004 16:37:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1pf6-000Gn8-TL for namedroppers@ops.ietf.org; Fri, 12 Mar 2004 16:37:29 +0000 Received: from ENGILL.ogud.com (gatt.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i2CGbPVa012938 for <namedroppers@ops.ietf.org>; Fri, 12 Mar 2004 11:37:25 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040312111536.02678528@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Fri, 12 Mar 2004 11:37:19 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard In-Reply-To: <6.0.3.0.2.20040228124513.02f35bc8@localhost> References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable At 13:00 2004-02-28, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >This RFC was published about 6 months ago so it is now a candidate to >advance through he standards track. >In order to do that we need > evidence of implementation, > interoperabilty test and report. Jakob Schlyter <jakob@rfc.se> has stepped up and will coordinate the interoperabilty testing and write the report. (Thanks Jakob) He needs help from vendors in identifying support, please contact him to participate in the testing. Jakob and I will be contacting some vendors privately asking explicit questions of support and if they want to participate. Even though IETF rules say only two implementation are needed for the interoperabilty test, the chairs would like to include as many as possible. One important reason is the impact RFC3597 support has on the introduction of new RR types. The interoperabilty testing will address all types of DNS functional units: - Authorative servers (primary and secondary) - Recursive Resolvers (including Caches) - Stub Resolvers - Diagnostic tools The standard IETF interoperabilty rules will apply - List of implementations tested will be provided - Any problem identified will be examined to see if the source of the problem is the documentation - There will be NO public disclosure of what implementations had problems only a list of the problems. The goal here is twofold, advance a better document, allow vendors to address any problems identified sooner than later. Olafur (co-chair). -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 12 15:36:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17432 for <dnsext-archive@lists.ietf.org>; Fri, 12 Mar 2004 15:36:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1tHF-0005PD-8Z for namedroppers-data@psg.com; Fri, 12 Mar 2004 20:29:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1tGg-000576-7I for namedroppers@ops.ietf.org; Fri, 12 Mar 2004 20:28:30 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16927; Fri, 12 Mar 2004 15:28:27 -0500 (EST) Message-Id: <200403122028.PAA16927@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Fri, 12 Mar 2004 15:28:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nsec-rdata-05.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-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152206.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 12 17:03:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21582 for <dnsext-archive@lists.ietf.org>; Fri, 12 Mar 2004 17:03:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1ue9-0000ZR-3O for namedroppers-data@psg.com; Fri, 12 Mar 2004 21:56:49 +0000 Received: from [204.107.200.33] (helo=dogbert.ihtfp.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1udv-0000Lt-Kg for namedroppers@ops.ietf.org; Fri, 12 Mar 2004 21:56:35 +0000 Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i2CLuRpN027480; Fri, 12 Mar 2004 16:56:27 -0500 To: Joshua Graessley <jgraessley@apple.com> Cc: =?iso-8859-1?q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> From: Derek Atkins <derek@ihtfp.com> Date: Fri, 12 Mar 2004 16:56:27 -0500 In-Reply-To: <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> (Joshua Graessley's message of "Thu, 11 Mar 2004 10:52:56 -0800") Message-ID: <sjm65d991bo.fsf@dogbert.ihtfp.org> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Joshua Graessley <jgraessley@apple.com> writes: > Using a TTL of 255 to verify that requests originate from the local > link is not very important. It may be useful to use a unicast query to > specific address from off of the local link to ask for records such as > HINFO. In the case of multicast, unless something is seriously broken > a link-local multicast packet is not going to be forwarded. It's exactly the fact that it's useful in a unicast query that we should do it. You are correct, multicast doesn't care, so we should use the TTL value that gives us the most bang for the buck. What does it hurt us to use TTL=3D255 and verifying it? In neither case does it hurt us. Yes, requests could leave the network, but the responder would drop them (as it should -- it's not link-local!) > Setting the TTL to 1 also unnecessarily prohibits unicast > request/responses from off of the local link. I would consider it more > useful to verify that a response to a link-local multicast came from > the local link. Indeed, this prohibition is EXACTLY WHAT WE WANT! It's not unnecessary. It's a requirement! > To those who are concerned that setting the TTL to 255 on a response > would enable another smurf attack, I would encourage them to try > pinging the all hosts multicast address. Most hosts will respond to > such a ping. Just because a problem exists in another protocol and isn't majorly exploited now does not mean that we should make the same mistake. People HAVE used DNS as a smurf/explosion attack. Pings aren't interesting -- the response is no larger than the request. DNS is VERY interesting, because I could potentially get a LARGE response for a small request. Therefore, we should protect against it. > This has not lead to any serious problems. The solution > to the smurf attack was to drop the subnet broadcast packets in > routers (don't forward them). A link local multicast packet will not > be forwarded. The defense against the smurf style attack is already > implemented. Hosts still respond to pings with subnet broadcasts but > routers never forward such packets, so this is only a local > vulnerability. If someone is local they could just as easily spoof the > source address of their packets as any of the other devices on the > local network. This type of defence does not protect against unicast LLMNR requests. Sure, a properly configured multicast router can stop the multicase requests, but it wont stop the unicast packets. That's yet another reason we should use TTL=3D1 on responses, to make sure unicast messages can't smurf. > If the whole point of changing the TTL is to achieve interoperability > with Rendezvous, then the proposal below fails. No, the whole point of this proposal is to get us out of the deadlock that we've been in by showing how we can use TTLs to get the most bang for the buck. I've listed all the threats that I think we're worried about and I've shown how the largest set of threats can be mitigated by the combined 255/1 TTL. If we can get Apple to move along with us and interoperate, great. But this proposal is not "let's make this look like Rendevous". > -josh So, Olaf and Olafur, I obviously have no technical reason why this should not be adopted ;) -derek > On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > >> >> The chairs are looking for closure and rough consensus on this only >> remaining issue for LLMNR. >> The solution below seems like a good solid compromise. >> Is there any technical reason why this should not be adopted, please >> state so before March 24'th. >> >> Olafur & Olaf >> >> >>> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >>> From: Derek Atkins <derek@ihtfp.com> >>> Date: Tue, 24 Feb 2004 22:14:43 -0500 >>> >>> It sounds like you want two things here, but it also sounds like all >>> of them need to happen in the responder. The attacker could >>> theoretically send packets of any type, with any TTL. So you can't >>> trust anything you receive from the network. To this affect, I think: >>> >>> 1) We want the responder to try to determine that a request came from >>> the local network. The best way to do this is for the responder to >>> check that TTL=3D255 to make sure. If a TTL is less than 255 then it >>> originiated off-net and can be dropped. >>> >>> 2) We want the responder to make sure response packets don't go >>> off-net. In other words, we want the responder to respond with >>> TTL=3D1, to make sure it can't smurf. >>> >>> So, to this affect: >>> >>> a) an LLMNR requestor should send requests with TTL=3D255 >>> b) an LLMNR responder should verify requests have TTL=3D255 -- if it >>> is not >>> 255 then it should drop the packet. >>> c) an LLMNR responder should respond with TTL=3D1 >>> d) I dont' think an LLMNR requestor needs to check the response TTL. >>> >>> The only issue this doesn't directly solve is a requester being >>> spoofed by an off-net attacker, but said attacker would need >>> to guess the transaction id of the request in order to send a >>> valid response, which is just as likely in LLMNR as it is in >>> standard DNS, so it can probably be ignored. >>> >>> So, other than this issue, does this solve the 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: <http://ops.ietf.org/lists/namedroppers/> --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 12 18:31:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27402 for <dnsext-archive@lists.ietf.org>; Fri, 12 Mar 2004 18:31:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1w1K-000Mz1-1u for namedroppers-data@psg.com; Fri, 12 Mar 2004 23:24:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B1w18-000MpR-LX for namedroppers@ops.ietf.org; Fri, 12 Mar 2004 23:24:38 +0000 Received: (qmail 95685 invoked from network); 12 Mar 2004 23:27:13 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 12 Mar 2004 23:27:13 -0000 Message-ID: <4052474B.9010306@necom830.hpcl.titech.ac.jp> Date: Sat, 13 Mar 2004 08:27:07 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <20040308050250.7E53114C73@sa.vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; >>>no, that really would force tcp, which really would be worse than ip-frag. >> >>If message size is 1400B or so, it is definitely so. >> >>If message size is 4200B or so, it can still be a valid argument. >> >>However, if message size is 64000B, TCP is far better than IP-frag. > yes, that's true. the crossover is probably closer to 4*PMTU. Given 1280B of IPv6 minimum MTU, shouldn't message size limitation be somewhere around 3600 or 4800, but not 4000? Masagtaka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 12 18:51:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29265 for <dnsext-archive@lists.ietf.org>; Fri, 12 Mar 2004 18:51:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1wMM-0009gU-US for namedroppers-data@psg.com; Fri, 12 Mar 2004 23:46:34 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B1wMB-0009aM-UD for namedroppers@ops.ietf.org; Fri, 12 Mar 2004 23:46:24 +0000 Received: (qmail 95771 invoked from network); 12 Mar 2004 23:48:59 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 12 Mar 2004 23:48:59 -0000 Message-ID: <40524C64.8090500@necom830.hpcl.titech.ac.jp> Date: Sat, 13 Mar 2004 08:48:52 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> CC: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <20040308050250.7E53114C73@sa.vix.com> <4052474B.9010306@necom830.hpcl.titech.ac.jp> In-Reply-To: <4052474B.9010306@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I wrote: >>yes, that's true. the crossover is probably closer to 4*PMTU. > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? My guess is that current specification of 4000B expects 3 frags over IPv4 that it should be 3600B for IPv6. Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 12 19:41:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02215 for <dnsext-archive@lists.ietf.org>; Fri, 12 Mar 2004 19:41:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1x6j-000Ara-3j for namedroppers-data@psg.com; Sat, 13 Mar 2004 00:34:29 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B1x5m-000AFS-36 for namedroppers@ops.ietf.org; Sat, 13 Mar 2004 00:33:30 +0000 Received: (qmail 95947 invoked from network); 13 Mar 2004 00:36:06 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 13 Mar 2004 00:36:06 -0000 Message-ID: <4052576F.2080507@necom830.hpcl.titech.ac.jp> Date: Sat, 13 Mar 2004 09:35:59 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: Derek Atkins <derek@ihtfp.com> >> 1) We want the responder to try to determine that a request came from >> the local network. No, we don't. Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 12 20:03:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02873 for <dnsext-archive@lists.ietf.org>; Fri, 12 Mar 2004 20:03:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B1xTu-000P60-G7 for namedroppers-data@psg.com; Sat, 13 Mar 2004 00:58:26 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1xTj-000P0w-VU for namedroppers@ops.ietf.org; Sat, 13 Mar 2004 00:58:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id D96AA14D81 for <namedroppers@ops.ietf.org>; Sat, 13 Mar 2004 00:58:15 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Sat, 13 Mar 2004 08:27:07 +0900." <4052474B.9010306@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 13 Mar 2004 00:58:15 +0000 Message-Id: <20040313005815.D96AA14D81@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > yes, that's true. the crossover is probably closer to 4*PMTU. > > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? i think it's all very approximate and 4000 is a very fine and round number. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 13 08:24:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14150 for <dnsext-archive@lists.ietf.org>; Sat, 13 Mar 2004 08:24:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2929-000LSW-TL for namedroppers-data@psg.com; Sat, 13 Mar 2004 13:18:33 +0000 Received: from [196.4.160.243] (helo=fedex.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B291y-000LMK-KJ for namedroppers@ops.ietf.org; Sat, 13 Mar 2004 13:18:22 +0000 Received: from hypatia.dns.net (c16-rba-81.dial-up.net [196.33.198.81]) by fedex.is.co.za (Postfix) with ESMTP id 465AAC041D; Sat, 13 Mar 2004 15:18:01 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i2DD9Mc23486; Sat, 13 Mar 2004 15:09:22 +0200 Date: Sat, 13 Mar 2004 15:09:22 +0200 From: Andras Salamon <andras@dns.net> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought Message-ID: <20040313130922.GA23428@dns.net> References: <200403081847.i28IlbS24713@windsor.research.att.com> <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, Mar 08, 2004 at 08:32:14PM +0100, Peter Koch wrote: > Bill Fenner wrote: > > was to the "PROTOCOL AND SERVICE NAMES" section, aka > > <http://www.iana.org/assignments/service-names>, and people who looked > > this teaches us that the registry name will need to be specified explicitly, > especially since URL references to the IANA registries are (were when I tried) > only allowed to point to http://www.iana.org/numbers.html. RFC 3232 makes reference to http://www.iana.org/ which in turn makes a reference to http://www.iana.org/numbers.html but then the trail gets cold. There are several potential documents that could be relevant, for instance either http://www.iana.org/assignments/port-numbers (this is the classic /etc/services document we have all been using as a reference, but isn't obviously tied in to DNS) or http://www.iana.org/assignments/service-names (which could be relevant since it is explicitly associated with WKS records). > Elevation of 2782 will give us an opportunity to clarify this. I would like to document the "correct" usage of SRV records at DNSRD, so I agree that the next version of 2782 should explicitly refer to the correct registry document. Now, which one is it? port-numbers or service-names? -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 13 12:22:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22518 for <dnsext-archive@lists.ietf.org>; Sat, 13 Mar 2004 12:22:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2Cjg-000Gzl-Gd for namedroppers-data@psg.com; Sat, 13 Mar 2004 17:15:44 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2CjO-000GqF-0p for namedroppers@ops.ietf.org; Sat, 13 Mar 2004 17:15:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 8D6F418F48 for <namedroppers@ops.ietf.org>; Sat, 13 Mar 2004 17:15:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 13 Mar 2004 15:09:22 +0200." <20040313130922.GA23428@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sat, 13 Mar 2004 17:15:25 +0000 Message-Id: <20040313171525.8D6F418F48@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Elevation of 2782 will give us an opportunity to clarify this. > > I would like to document the "correct" usage of SRV records at DNSRD, > so I agree that the next version of 2782 should explicitly refer to the > correct registry document. > > Now, which one is it? port-numbers or service-names? there isn't one. and unless one of you writes an internet-draft which asks iana to import /etc/services and then maintain the master copy of it, then 2782bis will not have anything to point at. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 13 15:09:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28578 for <dnsext-archive@lists.ietf.org>; Sat, 13 Mar 2004 15:09:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2FLS-0008uJ-GL for namedroppers-data@psg.com; Sat, 13 Mar 2004 20:02:54 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2FLH-0008pD-Sc for namedroppers@ops.ietf.org; Sat, 13 Mar 2004 20:02:43 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Sat, 13 Mar 2004 12:02:59 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 13 Mar 2004 12:02:43 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 13 Mar 2004 12:02:47 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 13 Mar 2004 12:02:43 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 13 Mar 2004 12:02:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 12:02:40 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQIfkyla6nOGvrbT9eb4zFEHTUH4QAtGG7A From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Derek Atkins" <derek@ihtfp.com>, "Joshua Graessley" <jgraessley@apple.com> Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 13 Mar 2004 20:02:38.0054 (UTC) FILETIME=[223D4060:01C40936] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Could we agree in any case that the TTL discussion does not apply when = we use TCP?=20 As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=3D255, as = per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of = address ranges is sufficient to guarantee on-link status. Setting = TTL=3D1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of = packet to the local link. On-link attackers can spoof the source = address; off-link attackers generally cannot send multicast packets to = the destination. Checking the TTL provides no protection against on-link = attackers (they can set whatever TTL value is expected). Checking that = the source address belongs to an "on-link" prefix prevents the "smurf = attack to an off-link target". Setting the TTL=3D1 in multicast queries = prevent the side effects of a rare bug in routers, but this bug may not = be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, = including for off-link attackers. Checking TTL=3D255 protects against = spoofing by off-link sources. Checking that the source address belongs = to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the = transaction identifier, which in practice requires an "on-link" = attacker; TTL games do not protect against on-link attackers. Setting = the TTL to 1 protects against unwitting participation in a DOS-attack to = an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some = network topologies that support multicast but require packets to go = through a router -- some wireless networks and some ad hoc networks can = have that property. In practice, checking TTL=3D255 is only useful in UDP unicast queries, = where it provides a slight incremental benefit over a simple check of = the source address prefix. Setting the TTL to 1 provides a limited = benefit in TCP operation, multicast queries and unicast responses, but = contradicts the requirement of TTL=3D255 for IPv6 link-local addresses. = Setting to either value will create operational problems in some future = scenarios. The simplest solution is probably to remove all mentions of TTL checks = from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an = authorized range; 2) The TTL field should be set by the stack to whatever default value is = adequate for the interface and the source address (e.g., TTL=3D255 for = IPv6 link-local addresses.) -- Christian Huitema -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 13 17:35:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04310 for <dnsext-archive@lists.ietf.org>; Sat, 13 Mar 2004 17:35:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2HdV-000Hyl-7r for namedroppers-data@psg.com; Sat, 13 Mar 2004 22:29:41 +0000 Received: from [213.243.180.204] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2HdJ-000Hs5-0w for namedroppers@ops.ietf.org; Sat, 13 Mar 2004 22:29:29 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i2DMTJaL003017; Sun, 14 Mar 2004 00:29:19 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i2DMTGuf003016; Sun, 14 Mar 2004 00:29:16 +0200 Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Mika Liljeberg <mika.liljeberg@welho.com> To: Christian Huitema <huitema@windows.microsoft.com> Cc: Derek Atkins <derek@ihtfp.com>, Joshua Graessley <jgraessley@apple.com>, =?ISO-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, namedroppers@ops.ietf.org In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1079216956.1930.16.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 14 Mar 2004 00:29:16 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. MikaL -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 13 19:25:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08542 for <dnsext-archive@lists.ietf.org>; Sat, 13 Mar 2004 19:25:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2JOX-0007g3-7L for namedroppers-data@psg.com; Sun, 14 Mar 2004 00:22:21 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2JOM-0007az-LF for namedroppers@ops.ietf.org; Sun, 14 Mar 2004 00:22:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 47F5214DE9 for <namedroppers@ops.ietf.org>; Sun, 14 Mar 2004 00:22:10 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal In-Reply-To: Message from Mika Liljeberg <mika.liljeberg@welho.com> of "Sun, 14 Mar 2004 00:29:16 +0200." <1079216956.1930.16.camel@hades> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 14 Mar 2004 00:22:10 +0000 Message-Id: <20040314002210.47F5214DE9@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. "i'll by THAT for a dollar." -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 15 00:11:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24942 for <dnsext-archive@lists.ietf.org>; Mon, 15 Mar 2004 00:11:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2kIe-0004DV-37 for namedroppers-data@psg.com; Mon, 15 Mar 2004 05:06:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B2kIK-00040w-OO for namedroppers@ops.ietf.org; Mon, 15 Mar 2004 05:05:44 +0000 Received: (qmail 6144 invoked from network); 15 Mar 2004 05:09:00 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 15 Mar 2004 05:09:00 -0000 Message-ID: <40553A41.4080504@necom830.hpcl.titech.ac.jp> Date: Mon, 15 Mar 2004 14:08:17 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Paul Vixie <paul@vix.com> CC: namedroppers@ops.ietf.org Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue References: <20040313005815.D96AA14D81@sa.vix.com> In-Reply-To: <20040313005815.D96AA14D81@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; >>>yes, that's true. the crossover is probably closer to 4*PMTU. >> >>Given 1280B of IPv6 minimum MTU, shouldn't message size limitation >>be somewhere around 3600 or 4800, but not 4000? > > > i think it's all very approximate and 4000 is a very fine and round number. It could have been so, if PMTUD were usable, which would have resulted in PMTU of 1450~1500. Without PMTUD, however, assumed MTU MUST be 1280, for which very approximate and round should be 3500 or 3600. Or, are there any cryptographic reason that the size is 4000? Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 15 12:58:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13250 for <dnsext-archive@lists.ietf.org>; Mon, 15 Mar 2004 12:58:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2wGM-000Csf-Vl for namedroppers-data@psg.com; Mon, 15 Mar 2004 17:52:30 +0000 Received: from [129.70.136.245] (helo=mailout.TechFak.Uni-Bielefeld.DE) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2wGB-000Cp6-Hd for namedroppers@ops.ietf.org; Mon, 15 Mar 2004 17:52:19 +0000 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7p1+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id i2FHqIp07683 for <namedroppers@ops.ietf.org>; Mon, 15 Mar 2004 18:52:18 +0100 (MET) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id i2FHqHk25304 for <namedroppers@ops.ietf.org>; Mon, 15 Mar 2004 18:52:17 +0100 (MET) Message-Id: <200403151752.i2FHqHk25304@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-reply-to: Your message of "Sat, 13 Mar 2004 17:15:25 GMT." <20040313171525.8D6F418F48@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25301.1079373136.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Mon, 15 Mar 2004 18:52:17 +0100 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie wrote: > > Now, which one is it? port-numbers or service-names? > > there isn't one. and unless one of you writes an internet-draft which > asks iana to import /etc/services and then maintain the master copy of I'm sorry but I do not see any difference between /etc/services and the "port-numbers" registry except for the non-existence of aliases in the latter. What do you miss? -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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 15 13:36:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15203 for <dnsext-archive@lists.ietf.org>; Mon, 15 Mar 2004 13:36:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2wrj-0000Pf-Ht for namedroppers-data@psg.com; Mon, 15 Mar 2004 18:31:07 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2wrQ-0000JL-GV for namedroppers@ops.ietf.org; Mon, 15 Mar 2004 18:30:48 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i2FIUm6f023777 for <namedroppers@ops.ietf.org>; Mon, 15 Mar 2004 10:30:48 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T685a7b986c118064e13b0@mailgate1.apple.com> for <namedroppers@ops.ietf.org>; Mon, 15 Mar 2004 10:30:48 -0800 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i2FIUkB9006772 for <namedroppers@ops.ietf.org>; Mon, 15 Mar 2004 18:30:46 GMT Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <1079216956.1930.16.camel@hades> References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <1079216956.1930.16.camel@hades> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-136514579; protocol="application/pkcs7-signature" Message-Id: <DFE10060-76AE-11D8-B9EC-000A95B9474C@apple.com> From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Mon, 15 Mar 2004 10:30:45 -0800 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-3-136514579 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Works for me. -josh On Mar 13, 2004, at 2:29 PM, Mika Liljeberg wrote: > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. > > MikaL --Apple-Mail-3-136514579 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNTE4MzA0NlowIwYJKoZIhvcNAQkEMRYEFHrU VLPbNQNtvNopd+r+aqYgPGgTMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAMVP pq29OvSY+jKZQaZQC/DwN6GQ+O7rFsR4Q6EoohlgH38fYMCZ7OwTlKafoMP+kn1kxJK4Cqd8WdQ+ 2PR8K0aTIU9m8SO16+Ou3ddFmgxrB/TpyT75BdB6YsWxdiHMWRrPMXa3udJ4caBrASZ1218a6eM3 fFglGZT8BHoL1bd5ylnjlHbJ5zYOHU9xLliKjacwEwlBV1srKbny1YcRaclaTLPL8rMcwuOggyc9 k3V3G2EgekhjO43lrHH39vU58HqG4fiNUzpsefi9W9KgxyHZntipn2oLO/EUZ1cwsLtZytZLlU0z UHt8+32mJpkXneCh3hLwIAz8cbPUGd4Y53EAAAAAAAA= --Apple-Mail-3-136514579-- -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 15 15:06:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20103 for <dnsext-archive@lists.ietf.org>; Mon, 15 Mar 2004 15:06:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2yGu-000IJQ-E3 for namedroppers-data@psg.com; Mon, 15 Mar 2004 20:01:12 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2yGX-000IH7-TI for namedroppers@ops.ietf.org; Mon, 15 Mar 2004 20:00:49 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id AEE7214C67 for <namedroppers@ops.ietf.org>; Mon, 15 Mar 2004 20:00:49 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: DNS SRV Clarification sought In-Reply-To: Message from Peter Koch <pk@TechFak.Uni-Bielefeld.DE> of "Mon, 15 Mar 2004 18:52:17 +0100." <200403151752.i2FHqHk25304@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 15 Mar 2004 20:00:49 +0000 Message-Id: <20040315200049.AEE7214C67@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I'm sorry but I do not see any difference between /etc/services and > the "port-numbers" registry except for the non-existence of aliases in the > latter. What do you miss? ftp://ftp.iana.org/assignments/port-numbers' "keyword" field (which wasn't there a few years ago when i last looked at this file) seems like the right answer. however, a purely SRV-discovered service might not _have_ a default port number, in which case ftp://ftp.iana.org/assignments/service-names would be the better choice for an SRV's owner name. and, it would be good to know that iana's policy is to keep synchronization between port-numbers keywords, and service-names. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 15 15:48:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23362 for <dnsext-archive@lists.ietf.org>; Mon, 15 Mar 2004 15:48:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B2yvN-000Pzl-JF for namedroppers-data@psg.com; Mon, 15 Mar 2004 20:43:01 +0000 Received: from [65.205.251.71] (helo=pigeon.verisign.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B2yvC-000PwN-Le for namedroppers@ops.ietf.org; Mon, 15 Mar 2004 20:42:50 +0000 Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.11/) with ESMTP id i2FKggkc026776; Mon, 15 Mar 2004 12:42:42 -0800 (PST) Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <G5F2DF87>; Mon, 15 Mar 2004 12:42:42 -0800 Message-ID: <C6DDA43B91BFDA49AA2F1E473732113E0A19C2@mou1wnexm05.vcorp.ad.vrsn.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org Subject: RE: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 12:42:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk however, a purely SRV-discovered service might not > _have_ a default > port number, in which case > ftp://ftp.iana.org/assignments/service-names would > be the better choice for an SRV's owner name. It seems to me that a good long term objective here would be to stop issuing port numbers completely. The logical extension of SRV is that you look up the service in DNS and get back a report of the name of the server that supports the service, the port address to use plus any parameters that describe the use of the port (I support SSL security with profile X). This is where the Internet will be in a few years time. Phill -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 15 16:56:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00350 for <dnsext-archive@lists.ietf.org>; Mon, 15 Mar 2004 16:56:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B300K-000Cpj-Pt for namedroppers-data@psg.com; Mon, 15 Mar 2004 21:52:12 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B300A-000Coz-4e for namedroppers@ops.ietf.org; Mon, 15 Mar 2004 21:52:02 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D2A7318E0; Mon, 15 Mar 2004 16:52:00 -0500 (EST) Date: Mon, 15 Mar 2004 16:52:00 -0500 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: DNSSECbis specification glitch (type/class order reversed in signatures) User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040315215200.D2A7318E0@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Just a notification from your friendly neighborhood DNSSECbis document editors, to avoid suprising anyone. Miek Gieben and Jelte Jansen pointed out what we are certain is an editorial goof in way we specified calculation of the RRSIG signature value. The current drafts (both -protocol and -records) say that the signature is calculated over RR(i) = name | class | type | OrigTTL | RDATA length | RDATA As Miek and Jelte pointed out to us, the class and type fields here are reversed from the normal RFC 1035 ordering for a wire-encoded RR (not to be confused with the RFC 1035 text format, which has the class, type, and TTL fields in reverse order to avoid parse ambiguities). To the best of our knowledge: a) RFC 2535 did not explictly specify the order, but the algorithm has generally been understood as signing the wire representation; b) There has been no WG action since RFC 2535 that would change this; and c) All current implementations of which we're aware use the wire ordering, not what the DNSSECbis specs currently say. So this seems to have just been an editorial goof, we've fixed it in the editors' working sources, and the fix will be in the next revisions of the drafts we post. If anyone has a problem with this change, please send mail to the editors, the WG chairs, or to namedroppers, as appropriate. Thanks to Miek and Jelte for catching this! -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 16 03:41:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18185 for <dnsext-archive@lists.ietf.org>; Tue, 16 Mar 2004 03:41:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A3r-000B36-7o for namedroppers-data@psg.com; Tue, 16 Mar 2004 08:36:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3A3g-000Azl-F0 for namedroppers@ops.ietf.org; Tue, 16 Mar 2004 08:36:20 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D1F8D4E06E; Tue, 16 Mar 2004 09:36:19 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7D7394FD72; Tue, 16 Mar 2004 09:36:19 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i2G8aJht004607; Tue, 16 Mar 2004 09:36:19 +0100 Date: Tue, 16 Mar 2004 09:36:19 +0100 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Rob Austein <sra@isc.org> Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis specification glitch (type/class order reversed in signatures) Message-Id: <20040316093619.257a8303.olaf@ripe.net> In-Reply-To: <20040315215200.D2A7318E0@thrintun.hactrn.net> References: <20040315215200.D2A7318E0@thrintun.hactrn.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.082025 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8ddd797dfea932e40d44a26c70d1f113 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Miek, Jelte, Good Catch!! Rob wrote: > a) RFC 2535 did not explictly specify the order, but the algorithm has > generally been understood as signing the wire representation; It is somewhat hidden through a refference from section 4.1.8 (Signature field): " RR(s) is the RRset of the RR(s)(...) in canonical form and order as defined in Section 8. " RFC 2535 section 8.1 applies: For purposes of DNSsecurity, the canonical form for an RR is the wire format of the RR (...) -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 16 20:13:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10116 for <dnsext-archive@lists.ietf.org>; Tue, 16 Mar 2004 20:13:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3PXa-0007Ku-96 for namedroppers-data@psg.com; Wed, 17 Mar 2004 01:08:14 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3PXP-0007Jy-LW for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 01:08:03 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2H1HCF29383 for <namedroppers@ops.ietf.org>; Tue, 16 Mar 2004 17:17:12 -0800 Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Message-ID: <Pine.LNX.4.56.0403161709190.28827@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Ok, although I would rather suggest: > 1) Nodes should very that the source address of queries belong to an > authorized range; I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. > 2) Use TTL=1 with TCP. This makes sense. > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. This only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 16 20:50:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12270 for <dnsext-archive@lists.ietf.org>; Tue, 16 Mar 2004 20:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3QA1-000GGt-Cb for namedroppers-data@psg.com; Wed, 17 Mar 2004 01:47:57 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q8w-000Fw7-Jl for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 01:46:50 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:36:05 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:45:09 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079426709210; Tue, 16 Mar 2004 08:45:09 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:45:08 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A3r-000B36-7o for namedroppers-data@psg.com; Tue, 16 Mar 2004 08:36:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3A3g-000Azl-F0 for namedroppers@ops.ietf.org; Tue, 16 Mar 2004 08:36:20 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D1F8D4E06E; Tue, 16 Mar 2004 09:36:19 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7D7394FD72; Tue, 16 Mar 2004 09:36:19 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i2G8aJht004607; Tue, 16 Mar 2004 09:36:19 +0100 Date: Tue, 16 Mar 2004 09:36:19 +0100 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Rob Austein <sra@isc.org> Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis specification glitch (type/class order reversed in signatures) Message-Id: <20040316093619.257a8303.olaf@ripe.net> In-Reply-To: <20040315215200.D2A7318E0@thrintun.hactrn.net> References: <20040315215200.D2A7318E0@thrintun.hactrn.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.082025 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8ddd797dfea932e40d44a26c70d1f113 X-OriginalArrivalTime: 16 Mar 2004 08:45:08.0820 (UTC) FILETIME=[FCA5A140:01C40B32] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Miek, Jelte, Good Catch!! Rob wrote: > a) RFC 2535 did not explictly specify the order, but the algorithm has > generally been understood as signing the wire representation; It is somewhat hidden through a refference from section 4.1.8 (Signature field): " RR(s) is the RRset of the RR(s)(...) in canonical form and order as defined in Section 8. " RFC 2535 section 8.1 applies: For purposes of DNSsecurity, the canonical form for an RR is the wire format of the RR (...) -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- 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://ops.ietf.org/lists/namedroppers/> -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 16 20:50:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12306 for <dnsext-archive@lists.ietf.org>; Tue, 16 Mar 2004 20:50:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3Q9c-000G3H-Jv for namedroppers-data@psg.com; Wed, 17 Mar 2004 01:47:32 +0000 Received: from [217.32.164.151] (helo=i2kc04-ukbr.domain1.systemhost.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3Q8v-000Fw7-P4 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 01:46:49 +0000 Received: from mail pickup service by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Wed, 17 Mar 2004 01:36:05 +0000 Received: from i2kc04-ukbr.domain1.systemhost.net ([217.32.164.183]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:45:09 +0000 Received: From smtp4.smtp.bt.com ([10.216.123.44]) by i2kc04-ukbr.domain1.systemhost.net (WebShield SMTP v4.5 MR1a); id 1079426709210; Tue, 16 Mar 2004 08:45:09 +0000 Received: from psg.com ([147.28.0.62]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Mar 2004 08:45:08 +0000 Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3A3r-000B36-7o for namedroppers-data@psg.com; Tue, 16 Mar 2004 08:36:31 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3A3g-000Azl-F0 for namedroppers@ops.ietf.org; Tue, 16 Mar 2004 08:36:20 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id D1F8D4E06E; Tue, 16 Mar 2004 09:36:19 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 7D7394FD72; Tue, 16 Mar 2004 09:36:19 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i2G8aJht004607; Tue, 16 Mar 2004 09:36:19 +0100 Date: Tue, 16 Mar 2004 09:36:19 +0100 From: "Olaf M. Kolkman" <olaf@ripe.net> To: Rob Austein <sra@isc.org> Cc: namedroppers@ops.ietf.org Subject: Re: DNSSECbis specification glitch (type/class order reversed in signatures) Message-Id: <20040316093619.257a8303.olaf@ripe.net> In-Reply-To: <20040315215200.D2A7318E0@thrintun.hactrn.net> References: <20040315215200.D2A7318E0@thrintun.hactrn.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.082025 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8ddd797dfea932e40d44a26c70d1f113 X-OriginalArrivalTime: 16 Mar 2004 08:45:08.0820 (UTC) FILETIME=[FCA5A140:01C40B32] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Miek, Jelte, Good Catch!! Rob wrote: > a) RFC 2535 did not explictly specify the order, but the algorithm has > generally been understood as signing the wire representation; It is somewhat hidden through a refference from section 4.1.8 (Signature field): " RR(s) is the RRset of the RR(s)(...) in canonical form and order as defined in Section 8. " RFC 2535 section 8.1 applies: For purposes of DNSsecurity, the canonical form for an RR is the wire format of the RR (...) -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- 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://ops.ietf.org/lists/namedroppers/> -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 00:58:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21952 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 00:58:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3U11-000PAC-P9 for namedroppers-data@psg.com; Wed, 17 Mar 2004 05:54:55 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3U0r-000P8I-8A for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 05:54:45 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 21:54:58 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Mar 2004 21:54:49 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 21:54:30 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 16 Mar 2004 21:54:38 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 16 Mar 2004 21:52:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 21:54:41 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA07FDEB2A@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQLvatlaIXizGLoR++uJyP8Awx4HgAJaJwg From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Bernard Aboba" <aboba@internaut.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 17 Mar 2004 05:52:47.0441 (UTC) FILETIME=[131E2C10:01C40BE4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > Ok, although I would rather suggest: >=20 > > 1) Nodes should very that the source address of queries belong to an > > authorized range; >=20 > I'm not sure how to define an "authorized range". A host may not know all > the prefixes present on a given link. In IPv6 at least, the host is suppose to learn the list of on-link prefixes from the RA. But you are right, there are many ways to get this test half-right and cause major operation pain.=20 > > 2) Use TTL=3D1 with TCP. >=20 > This makes sense. >=20 > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. >=20 > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. >=20 > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=3D1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Getting rid of unicast UDP query would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=3D1 also guarantees an on-link peering.=20 The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- Christian Huitema -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 01:09:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22652 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 01:09:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3UDF-0002MG-0X for namedroppers-data@psg.com; Wed, 17 Mar 2004 06:07:33 +0000 Received: from [213.243.180.204] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3UD3-0002K3-Rn for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 06:07:22 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i2H67NaL014836; Wed, 17 Mar 2004 08:07:23 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i2H67MHp014835; Wed, 17 Mar 2004 08:07:22 +0200 Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Mika Liljeberg <mika.liljeberg@welho.com> To: Bernard Aboba <aboba@internaut.com> Cc: namedroppers@ops.ietf.org In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1079503642.14820.8.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 17 Mar 2004 08:07:22 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2004-03-17 at 03:17, Bernard Aboba wrote: > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. > > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. Well, section 2.4 already says: "Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries." > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Using different TTLs for different messages is awkward from the implementation standpoint. It would be simplest just to require that all requests and responses must be sent to the local link. E.g. use the SO_DONTROUTE socket option. MikaL -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 09:02:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06913 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 09:02:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3bY1-000Gya-3l for namedroppers-data@psg.com; Wed, 17 Mar 2004 13:57:29 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3bXo-000Gw6-GK for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 13:57:16 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2HE6Mx11662 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 06:06:22 -0800 Date: Wed, 17 Mar 2004 06:06:21 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR Issue 64: TTL Revisited Message-ID: <Pine.LNX.4.56.0403170606040.10517@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 64 is enclosed below. The proposed resolution is as follows: In Section 2.4, change: "Unicast LLMNR queries SHOULD be sent using TCP." To: "Unicast LLMNR queries MUST be sent using TCP." Change: "Unicast UDP queries MAY be responded to with a UDP response containing an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP." To: "Unicast UDP queries MUST be silently discarded." Change: "If an ICMP "Time Exceeded" message is received in response to a unicast UDP query, or if TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). The UDP sender receiving an ICMP "Time Exceeded" message SHOULD verify that the ICMP error payload contains a valid LLMNR query packet, which matches a query that is currently in progress, so as to guard against a potential Denial of Service (DoS) attack. If a match cannot be made, then the sender relies on the retransmission and timeout behavior described in Section 2.7." To: "If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section)." In Section 2.5, change: "In composing LLMNR queries, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). Even when LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Therefore setting the IPv6 Hop Limit or IPv4 TTL field to one provides an additional precaution against leakage of LLMNR queries. In composing a response to an LLMNR query, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). This is done so as to prevent the use of LLMNR for denial of service attacks across the Internet. Section 2.4 discusses use of TCP for LLMNR queries and responses. The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder." To: "Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. For UDP queries and responses the Hop Limit field in the IPv6 header, and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Rendezvous." In Section 5.1, change: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on both queries and responses. A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can be used to launch denial of service attacks. For example, were the TTL of an LLMNR Response to be set to a value larger than one (1), an attacker could send a large volume of queries from a spoofed source address, causing an off-link target to be deluged with responses. Utilizing a TTL of one (1) in LLMNR responses ensures that they will not be forwarded off-link. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender." To: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing UDP queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on TCP queries and responses. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. When LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may enable denial of service attacks across the Internet. However, since LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal." An edited version of the specification incorporating these changes is available at: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-30.txt -------------------------------------------------------------------- Issue 64: TTL Revisited Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: March 15, 2004 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00299.html Document: LLMNR-29 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Derek Atkins <derek@ihtfp.com> Date: Tue, 24 Feb 2004 22:14:43 -0500 It sounds like you want two things here, but it also sounds like all of them need to happen in the responder. The attacker could theoretically send packets of any type, with any TTL. So you can't trust anything you receive from the network. To this affect, I think: 1) We want the responder to try to determine that a request came from the local network. The best way to do this is for the responder to check that TTL=255 to make sure. If a TTL is less than 255 then it originiated off-net and can be dropped. 2) We want the responder to make sure response packets don't go off-net. In other words, we want the responder to respond with TTL=1, to make sure it can't smurf. So, to this affect: a) an LLMNR requestor should send requests with TTL=255 b) an LLMNR responder should verify requests have TTL=255 -- if it is not 255 then it should drop the packet. c) an LLMNR responder should respond with TTL=1 d) I dont' think an LLMNR requestor needs to check the response TTL. The only issue this doesn't directly solve is a requester being spoofed by an off-net attacker, but said attacker would need to guess the transaction id of the request in order to send a valid response, which is just as likely in LLMNR as it is in standard DNS, so it can probably be ignored. So, other than this issue, does this solve the issue? [Christian Huitema] Could we agree in any case that the TTL discussion does not apply when we use TCP? As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=255, as per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of address ranges is sufficient to guarantee on-link status. Setting TTL=1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of packet to the local link. On-link attackers can spoof the source address; off-link attackers generally cannot send multicast packets to the destination. Checking the TTL provides no protection against on-link attackers (they can set whatever TTL value is expected). Checking that the source address belongs to an "on-link" prefix prevents the "smurf attack to an off-link target". Setting the TTL=1 in multicast queries prevent the side effects of a rare bug in routers, but this bug may not be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, including for off-link attackers. Checking TTL=255 protects against spoofing by off-link sources. Checking that the source address belongs to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the transaction identifier, which in practice requires an "on-link" attacker; TTL games do not protect against on-link attackers. Setting the TTL to 1 protects against unwitting participation in a DOS-attack to an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some network topologies that support multicast but require packets to go through a router -- some wireless networks and some ad hoc networks can have that property. In practice, checking TTL=255 is only useful in UDP unicast queries, where it provides a slight incremental benefit over a simple check of the source address prefix. Setting the TTL to 1 provides a limited benefit in TCP operation, multicast queries and unicast responses, but contradicts the requirement of TTL=255 for IPv6 link-local addresses. Setting to either value will create operational problems in some future scenarios. The simplest solution is probably to remove all mentions of TTL checks from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an authorized range; 2) The TTL field should be set by the stack to whatever default value is adequate for the interface and the source address (e.g., TTL=255 for IPv6 link-local addresses.) [Mika Liljeberg] > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. [Bernard Aboba] I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. TTL=255 on UDP request & responses only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. [Christian Huitema] Getting rid of unicast UDP queries would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=1 also guarantees an on-link peering. The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 11:10:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15463 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 11:10:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3dZf-000O3J-Gw for namedroppers-data@psg.com; Wed, 17 Mar 2004 16:07:19 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3dZJ-000O02-Mi for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 16:06:57 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15221; Wed, 17 Mar 2004 11:06:54 -0500 (EST) Message-Id: <200403171606.LAA15221@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 17 Mar 2004 11:06:54 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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 NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nsec-rdata-05.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-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17112510.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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 13:23:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27755 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 13:23:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3fdl-0005wV-6v for namedroppers-data@psg.com; Wed, 17 Mar 2004 18:19:41 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3fda-0005rY-FE for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 18:19:30 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i2HIJUwT003053 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 10:19:30 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6864bdf834118064e13b0@mailgate1.apple.com> for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 10:19:30 -0800 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i2HIJDsM013252 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 18:19:13 GMT Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-308620971; protocol="application/pkcs7-signature" Message-Id: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> From: Joshua Graessley <jgraessley@apple.com> Subject: LLMNR authorized range Date: Wed, 17 Mar 2004 10:19:12 -0800 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-13-308620971 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Mar 16, 2004, at 5:17 PM, Bernard Aboba wrote: >> Ok, although I would rather suggest: > >> 1) Nodes should very that the source address of queries belong to an >> authorized range; > > I'm not sure how to define an "authorized range". A host may not know > all > the prefixes present on a given link. The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. -josh --Apple-Mail-13-308620971 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzE4MTkxMlowIwYJKoZIhvcNAQkEMRYEFPiN 3vLihLmc6g/UXYaume3X1TIJMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBABID 5kspYzWbi7lBMu8pVrGyZZ2/vNLa7cP+3xgscFyqNHBTYzii2NsnmUe97xQWPBtDJ5PpW1GhanVz DK9XwDPbaTHBBWKmVA5LeHqVhsqzOsYRkRWPU8YmVAnPJbPMH5OvADep2yuoAQvDfkybYIEryOMR o2jfRj8mIXTpwxqKf9hG3OwGleTrEg8bzvOCgGruFIAxm+BiMx2ayDeIYvqfXVy8XU2zTWQUKB+w pyFhIkyJkTbX324Y2wlMAlGlv1zB4KsTqJH62Rb+PsXifl2sW+gD6RMn/XwqJgrteyarMyWMZ+D+ 6IDc848v8NteNdCjpEUrprCGxZqx8KB5QSkAAAAAAAA= --Apple-Mail-13-308620971-- -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 14:24:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00827 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 14:24:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3gbO-000MmX-CX for namedroppers-data@psg.com; Wed, 17 Mar 2004 19:21:18 +0000 Received: from [213.243.180.204] (helo=hades.pp.htv.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3gax-000Mgc-Bs for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 19:20:51 +0000 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id i2HJKwaL016732; Wed, 17 Mar 2004 21:20:58 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id i2HJKuhb016731; Wed, 17 Mar 2004 21:20:56 +0200 Subject: Re: LLMNR authorized range From: Mika Liljeberg <mika.liljeberg@welho.com> To: Joshua Graessley <jgraessley@apple.com> Cc: namedroppers@ops.ietf.org In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1079551256.16532.10.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 17 Mar 2004 21:20:56 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Josh, On Wed, 2004-03-17 at 20:19, Joshua Graessley wrote: > The current solution of using TCP with a TTL of 1 makes the "authorized > range" pretty simple to understand. Addresses in the authorized range > are those that the host knows about. This highlights a problem with the > current LLMNR draft. If there are two subnets overlaid on a local > network and the hosts are unaware of the opposite subnet, LLMNR will > make it impossible to resolve names of some devices on the same link > just because they exist on a different subnet. As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? MikaL -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 15:30:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05341 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 15:30:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3hbt-000Ejo-Tk for namedroppers-data@psg.com; Wed, 17 Mar 2004 20:25:53 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3hbj-000Eab-8k for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 20:25:43 +0000 Received: from ENGILL.ogud.com (ns.md.ogud.com [10.20.30.6]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i2HKOtVa038920; Wed, 17 Mar 2004 15:24:55 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.3.0.2.20040317152010.02b37e88@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 17 Mar 2004 15:25:29 -0500 To: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: LLMNR authorized range In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 13:19 2004-03-17, Joshua Graessley wrote: >The current solution of using TCP with a TTL of 1 makes the "authorized >range" pretty simple to understand. Addresses in the authorized range are >those that the host knows about. This highlights a problem with the >current LLMNR draft. If there are two subnets overlaid on a local network >and the hosts are unaware of the opposite subnet, LLMNR will make it >impossible to resolve names of some devices on the same link just because >they exist on a different subnet. Good point, so what TLL <= N works for you ? N = 5 sounds good to me. 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 16:25:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08427 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 16:25:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3iUW-0005kG-P0 for namedroppers-data@psg.com; Wed, 17 Mar 2004 21:22:20 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3iUM-0005iR-80 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 21:22:10 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 05A5514C51 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 21:22:10 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> of "Wed, 17 Mar 2004 15:25:29 EST." <6.0.3.0.2.20040317152010.02b37e88@localhost> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 17 Mar 2004 21:22:10 +0000 Message-Id: <20040317212210.05A5514C51@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > ... If there are two subnets overlaid on a local network and the > > hosts are unaware of the opposite subnet, LLMNR will make it > > impossible to resolve names of some devices on the same link just > > because they exist on a different subnet. that sounds like the right thing, since if they're on different subnets then they will not be able to communicate even though those subnets are in the same broadcast domain. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 17:17:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12053 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 17:17:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3jI0-000MGF-RA for namedroppers-data@psg.com; Wed, 17 Mar 2004 22:13:28 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3jHq-000MDv-9b for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 22:13:18 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i2HMFbsC010742 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 14:15:37 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T6865940441118064e13b0@mailgate1.apple.com> for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 14:13:18 -0800 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i2HMD1Xt001803 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 22:13:01 GMT Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <20040317212210.05A5514C51@sa.vix.com> References: <20040317212210.05A5514C51@sa.vix.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-322649650; protocol="application/pkcs7-signature" Message-Id: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 14:13:00 -0800 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-18-322649650 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit My friends has a problem with his cable modem provider. He has paid extra to get extra addresses. The addresses are handed out using DHCP. The addresses are not always on the same subnet. I see no reason why LLMNR shouldn't work for him. I may soon have a similar situation at home. I've got sDSL for a small server I run. I'm thinking about getting a cable modem connection so I can get stuff quicker. When I have that setup at home, I'll have two or more subnets running on the local network. All of the devices can communicate using their IPv4 addresses (albeit inefficiently). LLMNR should work in this situation but due to the TTL stuff it may not work. I think there is a simple solution for IPv6. Always use the IPv6 link-local addresses. The only solution that would work 100% of the time for IPv4 would be to use the same link-local multicast to send the response. -josh On Mar 17, 2004, at 1:22 PM, Paul Vixie wrote: >>> ... If there are two subnets overlaid on a local network and the >>> hosts are unaware of the opposite subnet, LLMNR will make it >>> impossible to resolve names of some devices on the same link just >>> because they exist on a different subnet. > > that sounds like the right thing, since if they're on different subnets > then they will not be able to communicate even though those subnets are > in the same broadcast domain. --Apple-Mail-18-322649650 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzIyMTMwMVowIwYJKoZIhvcNAQkEMRYEFGC0 xVKoZ+1an/5iMlJX/1xQw6DpMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAHdE tCTuzek3bgT7uCX+FEcQUYwwsv0Dnpcc8LKbMC7ZUwR6N7Am77lCNPIvw/wZfwm+87pxoori9Cl/ JSVyvPiUgiB/yfipwfUJPdoQIbrD8IbcsleoWSP95c+SAX4Odw1utoo9zbg4ig4sO/xtwQtV2JaA xNfDAhhiuk4+5+GtXf5/fJKEZd+gYa831X6fPBDr+rbVEZYnKO4I89iVrGW4XQ66d61LJ26XIs2/ NNsXHQbq/u9+8p0XUNTauhGPjJH9XVDk9mDt0o23xmbwfPzavUtoDBnvSEt6yASMfaZxUMTPdCD/ F30cuturShwPFbcGw4wSZ0fZmIQOFcG0GRUAAAAAAAA= --Apple-Mail-18-322649650-- -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 18:26:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16306 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 18:26:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3kO1-000HmX-SO for namedroppers-data@psg.com; Wed, 17 Mar 2004 23:23:45 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3kNr-000HkY-C3 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 23:23:35 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id EE6DB14C7C for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 23:23:34 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie <paul@vix.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range In-Reply-To: Message from Joshua Graessley <jgraessley@apple.com> of "Wed, 17 Mar 2004 14:13:00 PST." <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 17 Mar 2004 23:23:34 +0000 Message-Id: <20040317232334.EE6DB14C7C@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My friends has a problem with his cable modem provider. He has paid extra > to get extra addresses. The addresses are handed out using DHCP. The > addresses are not always on the same subnet. I see no reason why LLMNR > shouldn't work for him. i guess if your router is sitting on both subnets and you're willing to go through a router to talk to other hosts in the same broadcast domain, you're right there's no reason LLMNR wouldn't work. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 19:01:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18390 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 19:01:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3kwQ-000326-G1 for namedroppers-data@psg.com; Wed, 17 Mar 2004 23:59:18 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3kwF-0002zJ-31 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 23:59:07 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i2HNwNVZ039742 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 18:58:23 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i2HNwNPd039741 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 18:58:23 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3h9w-0006cS-8r for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 19:57:00 +0000 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id E282E1B2C82; Wed, 17 Mar 2004 13:54:10 -0600 (CST) In-Reply-To: <Pine.LNX.4.56.0403170606040.10517@internaut.com> References: <Pine.LNX.4.56.0403170606040.10517@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3EEA77C9-784D-11D8-8027-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@fugue.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 13:56:57 -0600 To: Bernard Aboba <aboba@internaut.com> X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 8:06 AM, Bernard Aboba wrote: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header MAY be set to any value. However, > it is RECOMMENDED that the value 255 be used for compatibility with > Apple Rendezvous." Why not change it to: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header SHOULD be set to 255. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 19:01:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18394 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 19:01:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3kx4-0003NV-I2 for namedroppers-data@psg.com; Wed, 17 Mar 2004 23:59:58 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3kwF-0002zO-H4 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 23:59:07 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i2HNwOVZ039747 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 18:58:24 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i2HNwNFF039746 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 18:58:23 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3iTm-0005WF-Gm for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 21:21:34 +0000 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id BE41B1B2DE3; Wed, 17 Mar 2004 15:18:44 -0600 (CST) In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:21:31 -0600 To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 12:19 PM, Joshua Graessley wrote: > If there are two subnets overlaid on a local network and the hosts are > unaware of the opposite subnet, LLMNR will make it impossible to > resolve names of some devices on the same link just because they exist > on a different subnet. I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 19:02:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18490 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 19:02:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3kwo-0003A3-Rx for namedroppers-data@psg.com; Wed, 17 Mar 2004 23:59:42 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3kwG-0002zR-0g for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 23:59:08 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i2HNwOVZ039752 for <namedroppers@ops.ietf.org>; Wed, 17 Mar 2004 18:58:24 -0500 (EST) (envelope-from namedroppers@hlid.md.ogud.com) Received: (from namedroppers@localhost) by hlid.md.ogud.com (8.12.8p2/8.12.8/Submit) id i2HNwOlf039751 for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 18:58:24 -0500 (EST) Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3k37-000Bkj-AE for namedroppers@ops.ietf.org; Wed, 17 Mar 2004 23:02:09 +0000 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id C6FDE1B2F45; Wed, 17 Mar 2004 16:59:18 -0600 (CST) In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 17:02:06 -0600 To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. It shouldn't work for him because his network is misconfigured. It's not the job of the IETF to arrange for it to be the case that any random configuration error still results in desired behavior, for any arbitrary value of "desired." If you want this to work, you need to go check out the IPv4ll protocol and make sure that it does the right thing in this case. And your friend needs to use IPv4ll. Rendezvous works correctly in this case, doesn't 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 17 23:06:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29185 for <dnsext-archive@lists.ietf.org>; Wed, 17 Mar 2004 23:06:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3ojr-000NkD-VJ for namedroppers-data@psg.com; Thu, 18 Mar 2004 04:02:35 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3ojh-000Nhk-4H for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 04:02:25 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 20:01:56 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 17 Mar 2004 20:02:26 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Mar 2004 20:02:25 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Mar 2004 20:01:24 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 17 Mar 2004 20:03:38 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 17 Mar 2004 20:02:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 20:02:00 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Proposed Resolution to LLMNR Issue 64: TTL Revisited thread-index: AcQMfLkklVWmcimJRgOk4T8n5ZiKvQAIL36g From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Ted Lemon" <mellon@fugue.com>, "Bernard Aboba" <aboba@internaut.com> Cc: <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 18 Mar 2004 04:02:14.0194 (UTC) FILETIME=[CBCEC120:01C40C9D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header MAY be set to any value. However, > > it is RECOMMENDED that the value 255 be used for compatibility with > > Apple Rendezvous." >=20 > Why not change it to: >=20 > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header SHOULD be set to 255. Because this is a trade-off. The proper design is to use a TTL=3D1. The only reason to use the 255 value, which has a larger exposure to DOS exploitation, is compatibility with rendezvous. The text that Bernard proposes is a fine compromise. -- Christian Huitema -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 00:22:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03195 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 00:22:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3pvx-000KlB-Hp for namedroppers-data@psg.com; Thu, 18 Mar 2004 05:19:09 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3pve-000KfU-Rm for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 05:18:50 +0000 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id 188101B3BDA; Wed, 17 Mar 2004 23:15:57 -0600 (CST) In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> References: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <BB8F9703-789B-11D8-8027-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <mellon@nominum.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 23:18:46 -0600 To: "Christian Huitema" <huitema@windows.microsoft.com> X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mar 17, 2004, at 10:02 PM, Christian Huitema wrote: > Because this is a trade-off. The proper design is to use a TTL=1. The > only reason to use the 255 value, which has a larger exposure to DOS > exploitation, is compatibility with rendezvous. The text that Bernard > proposes is a fine compromise. The text I proposed and the text it replaces have exactly the same effect. The difference is that one of them places blame (I think inappropriately, although I think also unintentionally), and the other does not. I can't think of any technical reason to prefer the old text over the new. Can you state such a reason? -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 08:30:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09565 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 08:30:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3xWw-00052r-7M for namedroppers-data@psg.com; Thu, 18 Mar 2004 13:25:50 +0000 Received: from [212.16.99.49] (helo=burp.tkv.asdf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3xWk-00050b-Ir for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 13:25:38 +0000 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i2IDPb79015443 for <namedroppers@ops.ietf.org>; Thu, 18 Mar 2004 15:25:37 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i2IDPake015440; Thu, 18 Mar 2004 15:25:36 +0200 Date: Thu, 18 Mar 2004 15:25:36 +0200 Message-Id: <200403181325.i2IDPake015440@burp.tkv.asdf.org> From: Markku Savela <msa@burp.tkv.asdf.org> To: namedroppers@ops.ietf.org Subject: EDNS0 (RFC-2671) questions X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk 1) assuming I send query, which includes the OPT RR (to increase the packet length). If I receive a reply with TC=1 (truncation) and don't find OPT RR in the reply, then I assume the RCODE is the non-extended one? [Just verifying, that I can trust all implementations do it right: if they build an answer and run out of space before inserting the OPT RR, they also fall back to old plain RCODE?] This extended-RCODE makes it somewhat akward, to find RCODE, you have to traverse through all data in Question, Answer and Authority sections, then look OPT RR from Additional section. Doable, but still icky, just to get few extra bits of RCODE that are rarely used. Would have been easier if there was single RCODE value in fixed header to indicate that extended RCODE is in use. 2) Can UDP payload size be < 512? I didn't see any mention of it. Maybe I missed it. I think RFC should state that attempting to use less than 512 is not allowed (and will be ignored). [If < 512 is accepted, there might be some DOS potential in it also] -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 10:58:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21416 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 10:58:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B3zqS-0007zy-Cw for namedroppers-data@psg.com; Thu, 18 Mar 2004 15:54:08 +0000 Received: from [129.6.16.226] (helo=smtp.nist.gov) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B3zqH-0007yp-CP for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 15:53:57 +0000 Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i2IFrjvo008481 for <namedroppers@ops.ietf.org>; Thu, 18 Mar 2004 10:53:45 -0500 Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i2IFr7LD013889 for <namedroppers@ops.ietf.org>; Thu, 18 Mar 2004 10:53:09 -0500 (EST) From: "Scott Rose" <scottr@nist.gov> To: <namedroppers@ops.ietf.org> Subject: correction to RRSIG presentation format in DNSSECbis -records draft Date: Thu, 18 Mar 2004 10:53:08 -0500 Message-ID: <ANECIHCPCBDLLEJLCOPGMEAMCHAA.scottr@nist.gov> 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.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-NIST-MailScanner-Information: Please contact the ISP for more information X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Recently pointed out by Miek and Erik Rozendaal in the Resource Records draft of the DNSSECbis spec is the discrepancy between the ASCII presentation formats of the RRSIG and NSEC RRs. In the text, the RRSIG Type Covered field is supposed to be represented as a RR type mnemonic or an unsigned integer. This goes against the convention in RFC 3597 which states that unknown RR types should be represented as "TYPE<number>" where <number> is the typecode. The text for the representation of the NSEC RR type bitmap already states this (as it was written after RFC3597). The text for the RRSIG representation was changed to be consistent with RFC 3597 and the NSEC text. Section 3.2 paragraph 2 will now read: The Type Covered field is represented as a RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597] (section 5) MUST be used. Thanks, Scott DNSSECbis 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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 11:15:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22455 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 11:15:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B409f-000BZj-9E for namedroppers-data@psg.com; Thu, 18 Mar 2004 16:13:59 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4096-000BTU-HF for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 16:13:24 +0000 Received: from hypatia.dns.net (c4-rba-384.dial-up.net [196.39.31.85]) by mercury.is.co.za (Postfix) with ESMTP id 8ABE2C081D; Thu, 18 Mar 2004 18:13:20 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i2IGEaD10799; Thu, 18 Mar 2004 18:14:36 +0200 Date: Thu, 18 Mar 2004 18:14:36 +0200 From: Andras Salamon <andras@dns.net> To: Ted Lemon <mellon@fugue.com> Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range Message-ID: <20040318161436.GA10775@dns.net> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 17, 2004 at 03:21:31PM -0600, Ted Lemon wrote: > A host that you > can't talk to without going through a router isn't "local." Why not? Which part of the Internet-Draft does this violate? From ...-29.txt: For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. The network overlay scenario is clearly "on link" according to the above definition. -- Andras Salamon andras@dns.net -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 11:16:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22476 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 11:16:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B409R-000BVh-BM for namedroppers-data@psg.com; Thu, 18 Mar 2004 16:13:45 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4098-000BTc-J6 for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 16:13:26 +0000 Received: from hypatia.dns.net (c4-rba-384.dial-up.net [196.39.31.85]) by mercury.is.co.za (Postfix) with ESMTP id 90F00C0AA4; Thu, 18 Mar 2004 18:13:23 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i2IEsva10203; Thu, 18 Mar 2004 16:54:57 +0200 Date: Thu, 18 Mar 2004 16:54:57 +0200 From: Andras Salamon <andras@dns.net> To: Ted Lemon <mellon@fugue.com> Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range Message-ID: <20040318145457.GE9994@dns.net> References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 17, 2004 at 05:02:06PM -0600, Ted Lemon wrote: > On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > >My friends has a problem with his cable modem provider. He has paid > >extra to get extra addresses. The addresses are handed out using DHCP. > >The addresses are not always on the same subnet. I see no reason why > >LLMNR shouldn't work for him. > > It shouldn't work for him because his network is misconfigured. It's > not the job of the IETF to arrange for it to be the case that any > random configuration error still results in desired behavior, for any > arbitrary value of "desired." Exactly how is overlaying two IP network ranges onto one L2 infrastructure misconfigured? -- Andras Salamon andras@dns.net -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 11:16:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22503 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 11:16:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B409F-000BUD-EN for namedroppers-data@psg.com; Thu, 18 Mar 2004 16:13:33 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4094-000BSz-2i for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 16:13:22 +0000 Received: from hypatia.dns.net (c4-rba-384.dial-up.net [196.39.31.85]) by mercury.is.co.za (Postfix) with ESMTP id 4C071C0323; Thu, 18 Mar 2004 18:13:18 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i2IFWwB10523; Thu, 18 Mar 2004 17:32:58 +0200 Date: Thu, 18 Mar 2004 17:32:58 +0200 From: Andras Salamon <andras@dns.net> To: Joshua Graessley <jgraessley@apple.com> Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range Message-ID: <20040318153258.GF9994@dns.net> References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. This hits at the crux of what "Link-Local" means in the acronym LLMNR. The above scenario (if indeed regarded as acceptable practice) will be regarded by most people as "local". During the original drafting of the document, did the authors have a specific definition of "link-local" in mind? As I recall, the original spec came out of Stuart Cheshire's work on replacing AppleTalk's naming service; this became Rendezvous and branched off into LLMNR. If this is the case, then the "local" definition was pretty broad, and would probably cover the overlaid network scenario. Also, in the above scenario, forcing TTL=1 will cause the router to drop the packet before it is forwarded back onto the "other" part of the local network. Making TTL=5 (or any other number greater than 1 but less than the worst-case diameter of the Internet) seems to be an ugly solution, and also gets away from the "link-local" part of LLMNR -- why not just call it "restricted scope MNR" then? Or why not just drop the TTL restriction altogether and just allow general MNR? I repeat -- TTL checks are a kludge, and do not capture the idea of "local" networks. There are local networks for which TTL must be greater than 1 to capture locality (eg. multiple IP ranges overlaid on the same L2 medium as above), and there are distinctly non-local networks (eg. LANs bridged through long thin pipes) for which any multicast can cause great harm -- even with TTL=1. In a message to this forum from Bernard Aboba in October 2003: As a result, the ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local specification so as to "do no harm". The current specification no longer mandates a test for a TTL value, and prefers a routable address when available. It is perhaps not as "useful" as the early versions -- but it also does not break the basic interoperability of TCP/IP. I've probably taken the above slightly out of context, but perhaps we should go back to the original multicast slant of LLMNR and drop UDP unicast, as suggested by Bernard in another message. For multicast, the TTL is irrelevant unless we are trying to compensate for potential router bugs. On the other hand, for TCP queries, the TTL should not be restricted. Then, interoperability with an existing protocol seems to be a worthwhile goal, as long as it is not bought at a terrible price. (Why was UDP unicast functionality introduced, anyway?) At the end of the day, I just want to see some finality with LLMNR, whatever it is! Either it is going to be useless and Rendezvous will win out in the marketplace, or it will be useful and over time it may grow to take over from Rendezvous. But right now LLMNR is by definition useless, since it hasn't been finalised. -- Andras Salamon andras@dns.net -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 11:53:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24841 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 11:53:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B40jl-000IDT-BS for namedroppers-data@psg.com; Thu, 18 Mar 2004 16:51:17 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B40ja-000ICc-Pi for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 16:51:06 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i2IGos728749; Thu, 18 Mar 2004 08:50:54 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200403181650.i2IGos728749@karoshi.com> Subject: Re: LLMNR authorized range To: andras@dns.net (Andras Salamon) Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST) Cc: jgraessley@apple.com (Joshua Graessley), namedroppers@ops.ietf.org In-Reply-To: <20040318153258.GF9994@dns.net> from "Andras Salamon" at Mar 18, 2004 05:32:58 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > > My friends has a problem with his cable modem provider. He has paid > > extra to get extra addresses. The addresses are handed out using DHCP. > > The addresses are not always on the same subnet. I see no reason why > > LLMNR shouldn't work for him. > > This hits at the crux of what "Link-Local" means in the acronym LLMNR. link-local is an unfortunate terminological choice. it might be useful to consider "single broadcast domain", which pretty much eliminates the overlay scenario. > As I recall, the original spec came out of Stuart Cheshire's > work on replacing AppleTalk's naming service; this became Rendezvous and > branched off into LLMNR. If this is the case, then the "local" definition > was pretty broad, and would probably cover the overlaid network scenario. Hum... there were a series of efforts that hit confluence and then diverged... the TBDS research, what became Rendezvous and what might become LLMNR... all are varients that use DNS or DNSlike stuff. > -- Andras Salamon andras@dns.net --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 13:42:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29873 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 13:42:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B42Nz-00080s-Kn for namedroppers-data@psg.com; Thu, 18 Mar 2004 18:36:55 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B42Np-0007zt-3m for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 18:36:45 +0000 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id 54F741B248C; Thu, 18 Mar 2004 12:33:46 -0600 (CST) In-Reply-To: <20040318145457.GE9994@dns.net> References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> <20040318145457.GE9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <33BC20F4-790B-11D8-8027-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:36:42 -0600 To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mar 18, 2004, at 8:54 AM, Andras Salamon wrote: > Exactly how is overlaying two IP network ranges onto one L2 > infrastructure > misconfigured? It is misconfigured in the sense that it does not do what the customer expects. The customer expects that the two devices he or she has connected to the network will be able to communicate with each other without relying on the service provider. This is unfortunately not true - they will not be able to communicate other than over the service provider's link, unless they implement Rendezvous (I do not believe that the current IPv4ll draft, for example, will allow them to communicate independent of the ISP). -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 18 13:52:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00371 for <dnsext-archive@lists.ietf.org>; Thu, 18 Mar 2004 13:52:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B42Yi-0009mW-LB for namedroppers-data@psg.com; Thu, 18 Mar 2004 18:48:00 +0000 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B42YQ-0009ji-6Z for namedroppers@ops.ietf.org; Thu, 18 Mar 2004 18:47:42 +0000 Received: from [10.0.1.2] (216-80-64-108.c3-0.snb-ubr1.chi-snb.il.cable.rcn.com [216.80.64.108]) by toccata.fugue.com (Postfix) with ESMTP id 5CEA11B2B8C; Thu, 18 Mar 2004 12:44:43 -0600 (CST) In-Reply-To: <20040318153258.GF9994@dns.net> References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <20040318153258.GF9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <BB4C48F3-790C-11D8-8027-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:47:39 -0600 To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mar 18, 2004, at 9:32 AM, Andras Salamon wrote: > During the original drafting of > the document, did the authors have a specific definition of > "link-local" > in mind? Yes. However, the current document bears only a passing resemblance to what the authors had in mind. The original intention was that the two devices we're discussing would both have IPv4ll addresses, and that MDNS, as it was then called, would uses these addresses, not the globally-routable addresses. Both the IPv4ll spec and the MDNS spec have been changed dramatically since then. IPv4ll no longer works the way it did, and LLMNR doesn't either. At this point, I have to say that it is my sincere hope that neither IPv4ll nor LLMNR make it to standard as they are currently constituted. But if they do make it to standard, my next hope is that they do not fail to interoperate with Rendezvous. If they do not interoperate reliably with Rendezvous, then the only purpose they will serve is to make sure that no reliable mechanism exists whereby two arbitrary hosts can automatically communicate with each other on the local link in the event that the DHCP server is not configured to enable this communication - by having two incompatible mechanisms that do roughly the same thing, we eliminate the possibility of dependable interoperability. I sympathize deeply with your motivation to make LLMNR work correctly in the scenario we're talking about in the absence of any competing protocol, but that is not the domain in which we are operating. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 19 01:37:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04132 for <dnsext-archive@lists.ietf.org>; Fri, 19 Mar 2004 01:37:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4DZ8-0007au-HV for namedroppers-data@psg.com; Fri, 19 Mar 2004 06:33:10 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4DYx-0007a8-Mc for namedroppers@ops.ietf.org; Fri, 19 Mar 2004 06:32:59 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2J6ftK00604 for <namedroppers@ops.ietf.org>; Thu, 18 Mar 2004 22:41:56 -0800 Date: Thu, 18 Mar 2004 22:41:55 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range Message-ID: <Pine.LNX.4.56.0403182212040.31338@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >LLMNR will make it impossible to resolve names of some devices on the >same link just because they exist on a different subnet. No. All but PTR RR queries will be sent to the link-scope multicast address, so they will be resolved without a problem. >As far as I can see, that is only a problem with PTR queries, which >often fail anyway. Yes. Only PTR queries are sent via TCP. Given that other queries will work and applications need to be prepared for PTR RR queries to fail anyway, you'll only see somewhat degraded performance. On the other hand, there is a performance improvement for other cases, since TTL=1 causes unresolvable PTR RR queries to fail quickly, rather than having to wait for LLMNR_TIMEOUT. So this is really just an optimization issue and I'm not clear that optimizing for an uncommon case (e.g. TTL=5) makes sense. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 19 03:45:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22678 for <dnsext-archive@lists.ietf.org>; Fri, 19 Mar 2004 03:45:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4FZn-0004PO-1u for namedroppers-data@psg.com; Fri, 19 Mar 2004 08:41:59 +0000 Received: from [196.4.160.243] (helo=fedex.is.co.za) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4FZT-0004NP-QW for namedroppers@ops.ietf.org; Fri, 19 Mar 2004 08:41:40 +0000 Received: from hypatia.dns.net (c12-rba-28.dial-up.net [196.39.1.28]) by fedex.is.co.za (Postfix) with ESMTP id 07C7FC08B7; Fri, 19 Mar 2004 10:41:16 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i2J8GgW12442; Fri, 19 Mar 2004 10:16:42 +0200 Date: Fri, 19 Mar 2004 10:16:42 +0200 From: Andras Salamon <andras@dns.net> To: Ted Lemon <mellon@fugue.com> Cc: namedroppers <namedroppers@ops.ietf.org> Subject: Re: LLMNR authorized range Message-ID: <20040319081642.GA12378@dns.net> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> <20040318161436.GA10775@dns.net> <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, Mar 18, 2004 at 12:34:32PM -0600, Ted Lemon wrote: > On Mar 18, 2004, at 10:14 AM, Andras Salamon wrote: > >The network overlay scenario is clearly "on link" according to the > >above definition. > > Sure, and you could argue that the definition you've quoted is correct > and that mine is wrong. I'm not especially interested in arguing about whose definition is right or wrong. However, the current LLMNR Internet-Draft defines its scope to include the scenario of address ranges overlaid onto the same L2 infrastructure (maybe I'm wrong here, but no-one has yet objected). Hence, either we need to change the wording of the I-D, or we need to accept the wording and its consequences. -- Andras Salamon andras@dns.net -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 20 06:45:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06616 for <dnsext-archive@lists.ietf.org>; Sat, 20 Mar 2004 06:45:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4enw-0006uw-Vk for namedroppers-data@psg.com; Sat, 20 Mar 2004 11:38:16 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4env-0006ua-En for namedroppers@ops.ietf.org; Sat, 20 Mar 2004 11:38:15 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i2KBl2A09685 for <namedroppers@ops.ietf.org>; Sat, 20 Mar 2004 03:47:04 -0800 Date: Sat, 20 Mar 2004 03:47:00 -0800 (PST) From: Bernard Aboba <aboba@internaut.com> To: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range Message-ID: <Pine.LNX.4.56.0403200335280.8666@internaut.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Joshua Graessley] said: The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. [Ted Lemon] replied: I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? [Mika Liljeberg] said: As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? [Bernard Aboba] In practice, I don't believe this issue will arise. Section 1 says: "The assumption is that if a network has a gateway, then the network is able to provide DNS server configuration." Therefore in the "overlapping subnet" case LLMNR assumes that the host has DNS configuration. From early on, LLMNR has assumed that the gateway supports the resolution of the names of local hosts using DHCPv4 and dynamic DNS update. However, this assumption cannot be made for IPv6 at this point. So if we are talking about multiple subnets on a link in IPv4, then a conventional DNS query will be sent first, and local names can be resolved by the gateway. If we are talking about IPV6, then Router Advertisement enables the host to become aware of the multiple subnets, so that TCP-based queries can be sent on the local link, rather than forwarded by a router. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 20 07:27:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08080 for <dnsext-archive@lists.ietf.org>; Sat, 20 Mar 2004 07:27:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4fVo-000E7H-1y for namedroppers-data@psg.com; Sat, 20 Mar 2004 12:23:36 +0000 Received: from [212.16.99.49] (helo=burp.tkv.asdf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4fVk-000E6n-Gz for namedroppers@ops.ietf.org; Sat, 20 Mar 2004 12:23:32 +0000 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i2KCNEJB006635; Sat, 20 Mar 2004 14:23:14 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i2KCNETn006632; Sat, 20 Mar 2004 14:23:14 +0200 Date: Sat, 20 Mar 2004 14:23:14 +0200 Message-Id: <200403201223.i2KCNETn006632@burp.tkv.asdf.org> From: Markku Savela <msa@burp.tkv.asdf.org> To: aboba@internaut.com CC: namedroppers@ops.ietf.org In-reply-to: <Pine.LNX.4.56.0403200335280.8666@internaut.com> (message from Bernard Aboba on Sat, 20 Mar 2004 03:47:00 -0800 (PST)) Subject: Re: LLMNR authorized range References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Bernard Aboba <aboba@internaut.com> > > ... If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, Terminology confusion? What subnets are in RA? RA can have multiple prefixes to be used on the link (if L=1), but they are not subnets. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 20 13:53:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19411 for <dnsext-archive@lists.ietf.org>; Sat, 20 Mar 2004 13:53:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4lWD-000Pg3-0O for namedroppers-data@psg.com; Sat, 20 Mar 2004 18:48:25 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4lWA-000PeL-03 for namedroppers@ops.ietf.org; Sat, 20 Mar 2004 18:48:22 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Sat, 20 Mar 2004 10:48:23 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sat, 20 Mar 2004 10:48:19 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 20 Mar 2004 10:48:22 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 20 Mar 2004 10:48:17 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 20 Mar 2004 10:47:52 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sat, 20 Mar 2004 10:48:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: LLMNR authorized range Date: Sat, 20 Mar 2004 10:48:18 -0800 Message-ID: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: LLMNR authorized range thread-index: AcQOdygluZmu2G4uTO+NBskGu1hyLwANJJKA From: "Christian Huitema" <huitema@windows.microsoft.com> To: "Markku Savela" <msa@burp.tkv.asdf.org>, <aboba@internaut.com> Cc: <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 20 Mar 2004 18:48:03.0805 (UTC) FILETIME=[E04548D0:01C40EAB] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > From: Bernard Aboba <aboba@internaut.com> > > > > ... If we are > > talking about IPV6, then Router Advertisement enables > > the host to become aware of the multiple subnets, >=20 > Terminology confusion? What subnets are in RA? RA can have multiple > prefixes to be used on the link (if L=3D1), but they are not subnets. Uh? There is no official definition of subnet, but the generally agreed definition is "the set of addresses that shares a specified prefix". -- Christian Huitema -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 20 15:17:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23446 for <dnsext-archive@lists.ietf.org>; Sat, 20 Mar 2004 15:17:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4mqD-000L54-Uw for namedroppers-data@psg.com; Sat, 20 Mar 2004 20:13:09 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4mqC-000L4j-PE for namedroppers@ops.ietf.org; Sat, 20 Mar 2004 20:13:08 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i2KKCn418994; Sat, 20 Mar 2004 12:12:49 -0800 From: bill <bmanning@karoshi.com> Message-Id: <200403202012.i2KKCn418994@karoshi.com> Subject: Re: LLMNR authorized range To: huitema@windows.microsoft.com (Christian Huitema) Date: Sat, 20 Mar 2004 12:12:48 -0800 (PST) Cc: msa@burp.tkv.asdf.org (Markku Savela), aboba@internaut.com, namedroppers@ops.ietf.org In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> from "Christian Huitema" at Mar 20, 2004 10:48:18 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > From: Bernard Aboba <aboba@internaut.com> > > > > > > ... If we are > > > talking about IPV6, then Router Advertisement enables > > > the host to become aware of the multiple subnets, > > > > Terminology confusion? What subnets are in RA? RA can have multiple > > prefixes to be used on the link (if L=1), but they are not subnets. > > Uh? There is no official definition of subnet, but the generally agreed > definition is "the set of addresses that shares a specified prefix". That is not generally agreed on in most circles I run in. The working definition here is: "a single broadcast domain" e.g. more layer two'ish. > -- Christian Huitema --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: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 20 16:22:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24996 for <dnsext-archive@lists.ietf.org>; Sat, 20 Mar 2004 16:22:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4nrs-000Bq9-WA for namedroppers-data@psg.com; Sat, 20 Mar 2004 21:18:56 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B4nri-000BnV-59 for namedroppers@ops.ietf.org; Sat, 20 Mar 2004 21:18:46 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 29FEB18F8 for <namedroppers@ops.ietf.org>; Sat, 20 Mar 2004 16:18:45 -0500 (EST) Date: Sat, 20 Mar 2004 16:18:45 -0500 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range In-Reply-To: <200403202012.i2KKCn418994@karoshi.com> References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040320211845.29FEB18F8@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > > > Uh? There is no official definition of subnet, but the generally agreed > > definition is "the set of addresses that shares a specified prefix". > > That is not generally agreed on in most circles I run in. > The working definition here is: "a single broadcast domain" > e.g. more layer two'ish. I think you're both right, but Christian's righter. IP "subnets" (the term's a bit dated given CIDR, but comes from the old subnetting extension to the original class A/B/C extension to the original original IPv4 address architecture's static 255.0.0.0 network mask) are an IP (layer 3) concept referring to a set of IP addresses sharing a particular prefix. The fact that IP subnets usually (but not always) map 1-to-1 with link-layer broadcast domains has led to sloppy terminology even in the IP world, and there are certainly other uses of the term "subnet" which mean something entirely different (eg, at one point I think the entire ARPANET was referred to as a "subnet" of the ARPANET/MILNET system, and some link layer specs do use the term "subnet" to mean link layer broadcast domain, as Bill suggests). So for precision you have to state the context (including layer) in which you're using the term, but since this is the IETF, and around here we mostly talk about IP, any use of the term "subnet" in IETF documents should generally be presumed to be talking about IP addresses with a shared prefix unless stated or proven otherwise. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Sat Mar 20 18:09:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29276 for <dnsext-archive@lists.ietf.org>; Sat, 20 Mar 2004 18:09:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B4pWc-0006nH-PR for namedroppers-data@psg.com; Sat, 20 Mar 2004 23:05:06 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B4pWb-0006mp-FZ for namedroppers@ops.ietf.org; Sat, 20 Mar 2004 23:05:05 +0000 Received: (qmail 36092 invoked from network); 20 Mar 2004 23:10:06 -0000 Received: from yahoobb219178198119.bbtec.net (HELO necom830.hpcl.titech.ac.jp) (219.178.198.119) by necom830.hpcl.titech.ac.jp with SMTP; 20 Mar 2004 23:10:06 -0000 Message-ID: <405CCEC1.3040609@necom830.hpcl.titech.ac.jp> Date: Sun, 21 Mar 2004 08:07:45 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Rob Austein <sra@isc.org> CC: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20040320211845.29FEB18F8@thrintun.hactrn.net> In-Reply-To: <20040320211845.29FEB18F8@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein; > At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > >>>Uh? There is no official definition of subnet, but the generally agreed >>>definition is "the set of addresses that shares a specified prefix". >> >> That is not generally agreed on in most circles I run in. >> The working definition here is: "a single broadcast domain" >> e.g. more layer two'ish. > > > I think you're both right, but Christian's righter. No, Christian is not. According to the CATENET model of the Internet, the Internet is composed from local networks (of RFC791). local network = subnet = link = broadcast domain The proper way to assign a local network multiple addresses is to let all the hosts (of RFC791) in the local network share multiple prefixes of equal length using identiral host parts (intra-subnet) addresses, which still means local network = subnet = link = broadcast domain Confusions caused by any other configuration are the problems of the configuration. The configuration is responsible to make the model visible from other protocols local network = subnet = link = broadcast domain > any use of the term "subnet" in IETF > documents should generally be presumed to be talking about IP > addresses with a shared prefix unless stated or proven otherwise. It's "shared prefixes", not "a shared prefix". Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Mon Mar 22 13:46:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11742 for <dnsext-archive@lists.ietf.org>; Mon, 22 Mar 2004 13:46:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5ULg-0000Ta-Py for namedroppers-data@psg.com; Mon, 22 Mar 2004 18:40:32 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B5ULd-0000TF-5r for namedroppers@ops.ietf.org; Mon, 22 Mar 2004 18:40:29 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i2MIh5HP003574 for <namedroppers@ops.ietf.org>; Mon, 22 Mar 2004 10:43:05 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id <T687e90f8d8118064e13b0@mailgate1.apple.com> for <namedroppers@ops.ietf.org>; Mon, 22 Mar 2004 10:40:28 -0800 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id i2MIeBON018009 for <namedroppers@ops.ietf.org>; Mon, 22 Mar 2004 18:40:12 GMT Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <Pine.LNX.4.56.0403200335280.8666@internaut.com> References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-741880068; protocol="application/pkcs7-signature" Message-Id: <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Mon, 22 Mar 2004 10:40:10 -0800 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-32-741880068 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Based on prior discussions and reading the draft, I was under the impression that if a DNS query fails (response with answercount of zero or a response with an error of NXDOMAIN), the query would be performed using LLMNR. It seems very plausible that someone might setup their computers to respond to LLMNR queries for names such as josh.llmnr or josh.thisdomainmustfailtoresolve. This would allow someone to locally refer to their computers by name no matter what the local addresses are and whether or not a DNS server is available. This would also be perfectly valid according to the current LLMNR spec. In this valid scenario, if there are multiple subnets on the same local network, LLMNR will fail. -josh On Mar 20, 2004, at 3:47 AM, Bernard Aboba wrote: > [Bernard Aboba] In practice, I don't believe this issue will arise. > Section 1 says: > > "The assumption is that if a network has a gateway, > then the network is able to provide DNS server configuration." > > Therefore in the "overlapping subnet" case LLMNR > assumes that the host has DNS configuration. From early > on, LLMNR has assumed that the gateway supports the > resolution of the names of local hosts using DHCPv4 and > dynamic DNS update. However, this assumption cannot be > made for IPv6 at this point. > > So if we are talking about multiple subnets on a link in > IPv4, then a conventional DNS query will be sent first, > and local names can be resolved by the gateway. If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, > so that TCP-based queries can be sent on the local > link, rather than forwarded by a router. --Apple-Mail-32-741880068 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMyMjE4NDAxMVowIwYJKoZIhvcNAQkEMRYEFDl8 9/kmuygyZVn0ISG4dH3oZKYDMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAKeo F6CpAFWpAvOdpM0OBoVrJenuTybGod5v/4E0F44x70U/JOeZApkZAK1dREIeT1M42J4b9iWk52CX 4mb++kOUH65xD77FH6xWNihVCHOIQF8W8+OHRO7yJSVuD6xYjahCpUVyF9KupoIzvGV1fBwz3Jml DtzmKAISHUTzXsZrLvKtvpUKcsouw3UMuiiE8GVWBsoInmA3w66Wd8EMSFmyJpVlry9lG/9VNemZ 8/+sQrWmxHBlfeweschkXXzXKqnMaliaRurH330kVS3V1lCmD340JsL8xbcpC19nGgQWPxGJlbAM ZYJSAmxRXO/uIlf95HB5A1FPEE16WGQ3Z5QAAAAAAAA= --Apple-Mail-32-741880068-- -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Tue Mar 23 01:15:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22849 for <dnsext-archive@lists.ietf.org>; Tue, 23 Mar 2004 01:15:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B5f8R-000PYA-BN for namedroppers-data@psg.com; Tue, 23 Mar 2004 06:11:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1B5f8N-000PXk-Qh for namedroppers@ops.ietf.org; Tue, 23 Mar 2004 06:11:32 +0000 Received: (qmail 47306 invoked from network); 23 Mar 2004 06:17:14 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 23 Mar 2004 06:17:14 -0000 Message-ID: <405FD5B8.7060909@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Mar 2004 15:14:16 +0900 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Joshua Graessley <jgraessley@apple.com> CC: namedroppers@ops.ietf.org Subject: Re: LLMNR authorized range References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> In-Reply-To: <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Josh; > In this valid > scenario, if there are multiple subnets on the same local network, LLMNR > will fail. With IPv6, there is no reason not to share all the prefixes of a link by all the hosts on the link, which means there is only a single subnet. Masataka Ohta -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 24 03:22:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04277 for <dnsext-archive@lists.ietf.org>; Wed, 24 Mar 2004 03:22:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B63ZU-000Blv-J5 for namedroppers-data@psg.com; Wed, 24 Mar 2004 08:17:08 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B63ZJ-000Bjo-EQ for namedroppers@ops.ietf.org; Wed, 24 Mar 2004 08:16:57 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id E2A434EDD0; Wed, 24 Mar 2004 09:16:56 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 84DAD4E0A6; Wed, 24 Mar 2004 09:16:56 +0100 (CET) Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i2O8Guht027958; Wed, 24 Mar 2004 09:16:56 +0100 Date: Wed, 24 Mar 2004 09:16:56 +0100 From: "Olaf M. Kolkman" <olaf@ripe.net> To: "Thomas Narten" <narten@us.ibm.com>, "Margaret Wasserman" <margaret@thingmagic.com> Cc: namedroppers@ops.ietf.org, jakob@schlyter.se Subject: Advance: draft-ietf-dnsext-nsec-rdata-05.txt Message-Id: <20040324091656.048886e8.olaf@ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.015749 / 0.0 / 0.0 / disabled X-RIPE-Signature: d65dbcaea04193b902f993fc8813be54 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, Margaret, Hereby the advancement questionnaire (www.mip4.org/2004/draft-writeup-items.html) for "DNSSEC NSEC RDATA Format" draft-ietf-dnsext-nsec-rdata-05.txt. The questionaire serves as a request to advance the document to proposed standard. 1. Chairs review. The chair responsible for tracking this document has read it and considers it ready for IESG review. 2. Working Group member review. The proposed format has been discussed on the list as well as during the IETF 58 meeting. The content of the comments received during last call indicate that a number of people have closely reviewed the document. 3. Is more review from a particular perspective needed. In the chairs opinion not. 4. Specific Issues and concerns the AD/IESG should be aware of. The document _only_ changes a format. The security section therefore does not go into the details of NSEC security. Note however that the text describing this format will be directly 'cut-n-pasted' into the dnssec-bis document set. The dnssec-bis intro document set covers the security considerations, e.g. NSEC cain walking, in more detail. 5. How solid is the WG consensus. The format was chosen during IETF58. The document itself got explicit consensus from only a few individuals. On the other hand this is has not been contentious issue. 6. Thread for appeal. None. 7. _all_ ID nits addressed. All are addressed. 8. References There is a normative reference to an I-D that has been advanced. Also not that this document will be merged and obsoleted by the dnssec-bis document set. 9. Writeup. Technical Summary To prevent the introduction of an extension mechanism once DNSSEC has a deployed base this document redefines the wire format of the "Type Bit Map" field in the NSEC resource record RDATA format to cover the full RR type space. The new format of the type bitmap is easy to implement, can cover the full range of type codes, is economical in the common case and has a maximum size of approximately 8.5 kilobytes. Efficient searching of the type bitmap for presence of a type had a lower priority. Working Group Summary The format was chosen from 6 different candidates that were presented to the working group. There is consensus on the chosen representation. Protocol Quality There are 3 independent implementations of this format. 1 implementation provides both a server and a client, 1 implementation only a server and 1 implementation only a client. These interoperate. -- Olaf Kolkman Olafur Gudmundsson -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Wed Mar 24 14:14:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14358 for <dnsext-archive@lists.ietf.org>; Wed, 24 Mar 2004 14:14:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6Dkm-0001OY-FZ for namedroppers-data@psg.com; Wed, 24 Mar 2004 19:09:28 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6Dkc-0001LY-76 for namedroppers@ops.ietf.org; Wed, 24 Mar 2004 19:09:20 +0000 Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 67C5618C9 for <namedroppers@ops.ietf.org>; Wed, 24 Mar 2004 14:08:52 -0500 (EST) Date: Wed, 24 Mar 2004 14:08:52 -0500 From: Rob Austein <sra@isc.org> To: namedroppers@ops.ietf.org Subject: DNSSECbis Q-30: DNAME awareness References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040324190852.67C5618C9@thrintun.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Q-30: Should the DNSSECbis specs require DNAME-awareness? Approximate text to be added if the WG agrees: [To be inserted somewhere in Section 3.x of -protocol] A security-aware name server which synthesizes CNAME RRs from DNAME RRs as described in RFC 2672 SHOULD NOT generate signatures for the synthesized CNAMEs. [To be inserted somewhere in Section 4.x of -protocol] A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs which could have been synthesized from the DNAME RR as described in RFC-2672, at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so. Background: RFC-2672 recommends that name servers synthesize CNAME RRs based on DNAME RRs, for backwards compatability with DNAME-oblivious resolvers. RFC-2672 goes on to suggest that DNSSEC-capable name servers might want to keep the zone key online in order to sign these synthesized CNAME RRs, for the benefit of security-aware DNAME-oblivious resolvers. This has obvious security issues, and also adds some complexity. In fairness, note that when RFC-2672 came out, DNSSEC-classic (RFC 2535) had already shipped, so one could argue that this was the least bad backwards compatability hack available to the author of RFC-2672. So the question here is whether there is any need for DNSSECbis to support security-aware DNAME-oblivious implementations. Specifically, can we eliminate the case of a security-aware DNAME-oblivious resolver expecting name servers to synthesize signed CNAME RRs from signed DNAME RRs? DNSSECbis question Q-27 already covered part of this space, by allowing a security-aware recursive name server to set the AD bit for responses containing synthesized CNAME RRs. Q-27 did not, however address whether name servers should attempt to sign synthesized CNAME records or whether resolvers should expect to receive signatures for synthesized CNAME records. Whether a validating resolver choses to retain synthesized CNAMEs or not appears to be an implementation and local policy choice, since CNAME synthesis itself is only a SHOULD in RFC-2672 and thus not something on which any DNS-using software can depend. Deadline and default: Per instructions from the WG chairs, this question will time out on 4 April 2003 with a default action to accept these changes. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Thu Mar 25 04:04:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09971 for <dnsext-archive@lists.ietf.org>; Thu, 25 Mar 2004 04:04:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6Qfx-000Ji2-EY for namedroppers-data@psg.com; Thu, 25 Mar 2004 08:57:21 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6Qfm-000Jgh-Ua for namedroppers@ops.ietf.org; Thu, 25 Mar 2004 08:57:11 +0000 Received: from forastero.guide.se (unknown [195.100.50.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 8DDBB19640; Thu, 25 Mar 2004 09:57:09 +0100 (CET) Date: Thu, 25 Mar 2004 09:57:08 +0100 (CET) From: Jakob Schlyter <jakob@rfc.se> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard In-Reply-To: <6.0.3.0.2.20040312111536.02678528@localhost> Message-ID: <Pine.OSX.4.58.0403250951140.4054@forastero.dynamic.schlyter.se> References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> <6.0.3.0.2.20040312111536.02678528@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk interested parties should visit http://www.rfc.se/interop3597/ and join the mailing-list at http://www.rfc.se/mailman/listinfo/interop3597. before testing starts, I need help with filling the test zone (published as interop3597.rfc.se) with useful, and wierd, data. please send suggestions me or to the list above. jakob -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 26 11:43:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00655 for <dnsext-archive@lists.ietf.org>; Fri, 26 Mar 2004 11:43:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6uJs-000Fll-H5 for namedroppers-data@psg.com; Fri, 26 Mar 2004 16:36:32 +0000 Received: from [192.149.252.32] (helo=smtp2.arin.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6uJo-000Fky-AC for namedroppers@ops.ietf.org; Fri, 26 Mar 2004 16:36:28 +0000 Received: by smtp2.arin.net (Postfix, from userid 5003) id A7A2C6DC; Fri, 26 Mar 2004 11:36:27 -0500 (EST) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 296EA658; Fri, 26 Mar 2004 11:36:27 -0500 (EST) Received: from [127.0.0.1] (account edlewis HELO [192.136.136.41]) by arin.net (CommuniGate Pro SMTP 4.1.5) with ESMTP id 1430419; Fri, 26 Mar 2004 11:36:27 -0500 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: <a06020406bc8a0bbf6e0f@[192.136.136.41]> In-Reply-To: <20040324190852.67C5618C9@thrintun.hactrn.net> References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> <20040324190852.67C5618C9@thrintun.hactrn.net> Date: Fri, 26 Mar 2004 11:33:53 -0500 To: Rob Austein <sra@isc.org> From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSSECbis Q-30: DNAME awareness Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I like what these words say. At 14:08 -0500 3/24/04, Rob Austein wrote: >Q-30: Should the DNSSECbis specs require DNAME-awareness? > >Approximate text to be added if the WG agrees: > > [To be inserted somewhere in Section 3.x of -protocol] > > A security-aware name server which synthesizes CNAME RRs from DNAME > RRs as described in RFC 2672 SHOULD NOT generate signatures for the > synthesized CNAMEs. > > [To be inserted somewhere in Section 4.x of -protocol] > > A validating security-aware resolver MUST treat the signature of a > valid signed DNAME RR as also covering unsigned CNAME RRs which > could have been synthesized from the DNAME RR as described in > RFC-2672, at least to the extent of not rejecting a response > message solely because it contains such CNAME RRs. The resolver > MAY retain such CNAME RRs in its cache or in the answers it hands > back, but is not required to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. -- 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://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Mar 26 15:53:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14236 for <dnsext-archive@lists.ietf.org>; Fri, 26 Mar 2004 15:53:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1B6yGi-0002RC-BX for namedroppers-data@psg.com; Fri, 26 Mar 2004 20:49:32 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B6yGg-0002Qh-OD for namedroppers@ops.ietf.org; Fri, 26 Mar 2004 20:49:30 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13865; Fri, 26 Mar 2004 15:49:28 -0500 (EST) Message-Id: <200403262049.PAA13865@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-30.txt Date: Fri, 26 Mar 2004 15:49:27 -0500 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --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) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-30.txt Pages : 26 Date : 2004-3-26 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. 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. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. 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-30.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-30.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-30.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: <2004-3-26161128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-30.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-26161128.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: <http://ops.ietf.org/lists/namedroppers/> From emenews@mail.com Mon Mar 29 12:34:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13835 for <dnsext-archive@ietf.org>; Mon, 29 Mar 2004 12:34:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B80en-00068o-00 for dnsext-archive@ietf.org; Mon, 29 Mar 2004 12:34:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B80dt-0005xw-00 for dnsext-archive@ietf.org; Mon, 29 Mar 2004 12:33:46 -0500 Received: from proxy.gascom.ru ([217.17.160.5] helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1B80cw-0005ep-00; Mon, 29 Mar 2004 12:32:48 -0500 From: "Atualidade Brasileira . sua" <emenews@mail.com> To: eap-archive@ietf.org Subject: "Trabalho escravo": novo instrumento da demagogia? . zsx User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: <E1B80cw-0005ep-00@ietf-mx> Date: Mon, 29 Mar 2004 12:32:48 -0500 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=8.8 required=5.0 tests=AWL,HTML_40_50,HTML_FONT_BIG, HTML_MESSAGE,MAILTO_SUBJ_REMOVE,MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 X-Spam-Report: * 1.0 SUBJ_HAS_SPACES Subject contains lots of white space * 0.5 REMOVE_REMOVAL_2WORD BODY: List removal information * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.3 MAILTO_SUBJ_REMOVE BODY: mailto URI includes removal text * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email * 0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 0.0 AWL AWL: Auto-whitelist adjustment <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="http://www.hotmail.com"> <META NAME="Generator" CONTENT="http://www.spamcop.net"> </HEAD> <BODY LINK="#0000ff" VLINK="#800080"> <B><FONT FACE="Garamond" SIZE=2><P ALIGN="CENTER">(ref.: <!-- Please, follow the links: http://www.hotmail.com http://www.spamcop.net mailto:abernardico@yahoo.com.br?subject=Remove andrediniz@nonaarte.com.br andredogon@simbolo.com.br mailto:andredogon@simbolo.coml.sys.intranet?subject=Subscribir braulinojr@bol.com.br mailto:camera3@mail.telepac.pt?subject=IAgree caparroz@wanadoo.es mailto:carlospi@adinet.com.uy?subject=Adquirir DADEAN1@aol.com df01a8c0@xdata1.com.uy mailto:efigge@arnet.com.ar?subject=Unsubscribe elrey@123.com emancipacordoba@hotmail.com mailto:FabianF@exo.com.ar?subject=MyOpinion fuckspam@attbi.com gcv2000@adinet.com.uy gindre@indecs.org.br grupeiro@uol.com.br gsya@arnet.com.ar igge@arnet.com.ar iica@reuna.cl iranzo@fa.upc.es itiro@openlink.c itiro@openlink.com.br jaabril@comcast.net jaabril@mail.comcast.net jbarloccod@medynet.com -->cur) (utilize os links instantâneos para contacto, recebimento de informações, remoção ou subscrição) </B></FONT><FONT FACE="Garamond"><P> </FONT><B><FONT FACE="Garamond" SIZE=5>"Trabalho escravo": instrumento da demagogia contra a propriedade?</P> </B></FONT><I><FONT FACE="Garamond" SIZE=4><P ALIGN="CENTER">A Proposta de Emenda Constitucional (PEC) 438/01 prevê a expropriação sumária de fazendas; amanhã, com a brecha constitucional aberta, chegará a hora da expropriação sumária de indústrias e até mesmo de lares, a partir de qualquer denúncia sobre "trabalho escravo"</P> </I></FONT><FONT FACE="Garamond"><P>Caro amigo</P> <P>* Um novo golpe contra a propriedade privada paira sobre nossas cabeças e poderá ocorrer através de uma reforma à Constituição, com a introdução da ambígua expressão "trabalho escravo".</P> <P>* A Comissão de Constituição e Justiça da Câmara aprovou a admissibilidade da Proposta de Emenda Constitucional (PEC) 438/01, do Senado, que prevê a desapropriação sumária (sem indenização) da terra onde for constatada a prática do chamado "trabalho escravo" (clique aqui para maiores informações: </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:MaisInformaçãoEmendaConstitucional">MaisInformaçãoEmendaConstitucional</A><FONT FACE="Garamond">).</P> <P>* Para acelerar os debates sobre o "trabalho escravo", o presidente da Câmara instalou Comissão Especial, que terá prazo de 40 sessões para votar a matéria antes de seguir para o Plenário. Os trabalhos da Comissão já começaram em março.</P> <P>* A simpática bandeira do combate ao "trabalho escravo" será utilizada demagogicamente para expropriações sumárias de fazendas para fins de Reforma Agrária.</P> <P>* A emenda constitucional poderá criar tal ambigüidade em torno do direito de propriedade, que ficará aberta mais uma fonte de conflitos no meio rural. O MST não espera outra coisa!</P> <P>* Hoje, a proposta é a expropriação sumária de fazendas. Amanhã, já com a brecha constitucional aberta, chegará a hora da expropriação sumária de indústrias e até mesmo de lares, a partir de uma denúncia sobre "trabalho escravo". </P> <P>* Levantar este tema "politicamente incorreto" não é agradável. Mas é o próprio futuro do Brasil que está em jogo.</P> <P>* Caro amigo, coloco-me à sua disposição,sem nenhum ônus de sua parte,um "pacote" de informações para que V.forme uma opinião objetiva a respeito do tema. E, eventualmente, se dirija de maneira respeitosa, mas firme, aos ilustres deputados membros da Comissão que trata do assunto, através de um link que lhe proporciono a seguir (para acessá-lo, basta clicar em: </FONT><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:LinkParaEnviarMensagemADeputados">LinkParaEnviarMensagemADeputados</A><FONT FACE="Garamond">).</P> <P>* Na verdade, o que o Brasil precisa é de uma reforma de suas leis trabalhistas, reforma que venha atender as múltiplas atividades econômicas, sobretudo às do campo, com suas peculiaridades; leis que facilitem a geração de empregos e a legalização de milhões de trabalhadores informais.</P> <P>* Gostaria, se possível, ouvir sugestões, receber ponderações e mesmo críticas de sua parte a respeito deste momentoso assunto. Temo ter interpretado mal informações da imprensa e do âmbito legislativo, áreas nas quais trabalho como jornalista há anos. Estaria sendo exagerado ou pessimista?</P> <P>* Finalmente, declaro que não possuo um palmo de terra e que faço esta divulgação exercendo meu direito e minha obrigação de informar, sem qualquer vantagem pessoal.</P> <P>Mais uma vez, ao seu inteiro dispor para qualquer esclarecimento. </P> <P>Atenciosamente,</P> <P ALIGN="CENTER">Nelson Barretto / Jornalista</P> <P>P.S. </P> <P>* No ano passado, após percorrer 20 mil quilômetros pelo Brasil e visitar 60 "assentamentos" de Reforma Agrária, inclusive aqueles tidos pelo governo como "modelos", constatei o desastre e o fracasso da Reforma Agrária que vem sendo feita. Com o material colhido, publiquei o livro "Reforma Agrária: o mito e a realidade", já com 4 edições. Os fatos ali narrados não foram desmentidos pelo INCRA, nem pelo MST nem ainda pelo ministério da Reforma Agrária. </P> <P>* Como gostaria, desta vez, de ver minhas apreensões dissipadas sobre a reforma constitucional que se prepara! O combate ao "trabalho escravo" é bandeira mais que simpática. Mas, ao meu ver, não nas mãos da demagogia agro-reformista.</P> <P>LINKS DISPONÍVEIS: </P> </FONT><P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:Concordo-VisãoObjetiva">Atualidade:Concordo-VisãoObjetiva</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:EmTermos-VisãoExagerada">Atualidade:EmTermos-VisãoExagerada</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:Discordo-VisãoTendenciosa">Atualidade:Discordo-VisãoTendenciosa</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:DesejoReceberGratuitamenteInformações">Atualidade:DesejoReceberGratuitamenteMaisInformações</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:DesejoContatoTelefonico">Atualidade:DesejoContatoTelefonico</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:LinkParaEnviarMensagemADeputados">LinkParaEnviarMensagemADeputados</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=DesejoReceberLivroBarrettoSobreReformaAgrária">Atualidade:DesejoReceberLivroBarrettoSobreReformaAgrária</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:Mantenha-meInformado">Atualidade:SubscreverAmigos</A></P> <P><A HREF="mailto:atualidadebrasileira@yahoo.com.br?subject=Atualidade:RemoverImediatamente">Atualidade:RemoverImediatamente</A></P> <B><FONT FACE="Garamond" SIZE=2><P ALIGN="CENTER">A retransmissão desta mensagem é de exclusiva responsabilidade de Ferreira-Passos, Atualidade Brasileira (RJ)</P></B></FONT></BODY> </HTML>