From owner-namedroppers@ops.ietf.org Fri Jan 9 16:34: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 QAA18037 for ; Fri, 9 Jan 2004 16:34:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af47p-000Ani-T2 for namedroppers-data@psg.com; Fri, 09 Jan 2004 21:25:01 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af47a-000Amx-Hp for namedroppers@ops.ietf.org; Fri, 09 Jan 2004 21:24:46 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16110; Fri, 9 Jan 2004 16:24:43 -0500 (EST) Message-Id: <200401092124.QAA16110@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-28.txt Date: Fri, 09 Jan 2004 16:24:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 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, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-28.txt Pages : 26 Date : 2004-1-9 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-28.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-28.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-28.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-1-9164403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-28.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-28.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-9164403.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 9 16:59: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 QAA19787 for ; Fri, 9 Jan 2004 16:59:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Af4aU-000HXQ-CM for namedroppers-data@psg.com; Fri, 09 Jan 2004 21:54:38 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Af4aH-000HWm-Ss for namedroppers@ops.ietf.org; Fri, 09 Jan 2004 21:54:25 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Fri, 09 Jan 2004 16:54:24 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: comments on draft-ietf-dnsext-dnssec-intro-08 Date: Fri, 9 Jan 2004 16:54:24 -0500 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401091654.24722.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit These are some relatively minor comments on the intro-08 document. 1 -- Section 6 ends by describing a "security-aware stub resolver" that does its own signature validation. I am wondering if there should there be an explicit term for this? "Validating sub resolver" perhaps? I only bring this up because I know that some folks that I have talked to in the past wish that this sort of animal were the norm, and I know that this sort of concept sometimes comes up when discussion the CD bit. This would be a term to essentially distinguish between a security aware resolver which does recursion (or iterates) and one that does not. 2 -- Section 11, 6th paragraph ends with: While not an attack on the DNS itself, this could allow an attacker to map network hosts or other resources by enumerating the contents of a zone. There are non-DNS protocol means of limiting this attack such as limiting the number of NSEC queries from a single host, use of intrusion detection tools, etc. This second sentence is not, technically, correct. Limiting "NSEC" queries is not nearly good enough. You would have to limit queries for any non-existant RR type. For at least some of the organizations that are concerned about NSEC walking, rate limiting of any sort could be seen as a very bad idea. I have no idea how intrusion detection tools could be used to mitigate NSEC walking, but that could just be my lack of familiarity with such tools. I recommend that this latter sentence be just dropped. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From wptpress@bol.com.br Fri Jan 9 20:14: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 UAA03579 for ; Fri, 9 Jan 2004 20:14:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Af7hX-0002S9-00 for dnsext-archive@ietf.org; Fri, 09 Jan 2004 20:14:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Af7fr-0002Kt-00 for dnsext-archive@ietf.org; Fri, 09 Jan 2004 20:12:24 -0500 Received: from [211.253.127.81] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1Af7f2-00025U-00; Fri, 09 Jan 2004 20:11:34 -0500 From: "Temas Patrulhados" To: disman-archive@ietf.org Subject: Lindenberg e o Clero "sem-microfone" ref.: tws X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 09 Jan 2004 20:11:34 -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=10.1 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,HTML_40_50,HTML_FONT_BIG,HTML_MESSAGE, LINES_OF_YELLING,LINES_OF_YELLING_2,MAILTO_TO_REMOVE, MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MSGID_FROM_MTA_SHORT,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.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED * 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 * 3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.0 AWL AWL: Auto-whitelist adjustment

Ref.: xnc FreeAutomaticTranslator / TraductorGratuito / Retirar / SubscreverGratuitamente

Série Temas "Patrulhados" (2)

Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone

"Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na sua agenda o fim do boicote contra os sacerdotes sem-microfone?"

Adolpho Lindenberg

O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), incitando as invasões de terras promovidas pelo MST, criticando indiscriminadamente a Área de Livre Comércio das Américas (ALCA), as privatizações, as multinacionais (as norte-americanas, em especial), e o plantio dos transgênicos, apresenta um inconveniente sério: tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados.

Movimentos contestatários

É contristador perceber que na vasta rede de movimentos contestatários que está sendo articulada por todo o país, a ala progressista religiosa - fruto das Comunidades de Base e da Comissão Pastoral da Terra (CPT) - se sobressai como o núcleo mais ativo e radical em suas convicções. Para esses movimentos de contestação é de fundamental importância dar a impressão de que expressam a opinião majoritária, ou pelo menos muito expressiva, do Episcopado e no Clero.

Não é verdade, necessariamente.

Uma minoria do Clero fala, a maioria está calada

A realidade profunda é bem outra. A maioria do Episcopado e do Clero, na realidade, não tem voz nem vez na grande mídia. Suas pastorais, sermões e opiniões não chegam ao grande público. Quase ninguém os conhece, só alguns paroquianos e amigos próximos, com quem compartilham confidências. Eles são os prelados e sacerdotes sem-microfone; pertencem à imensa maioria dos excluídos dos grandes meios de difusão. E muitos deles inteligentes, cultos, de expressão fácil, com reflexões que ajudariam muito à autêntica formação da opinião nacional. Até por exigência de equilíbrio na ponderação das opiniões e de equidade em relação a este setor social, eles também precisariam ser ouvidos.

Padres sem-microfone são discriminados

O grande número dos padres sem-microfone, muitas vezes, talvez na maioria esmagadora dos casos, teria reservas sérias com as invasões e depredações das propriedades agrícolas. Mas são discriminados, não são ouvidos pelo público. De nada adiantam suas advertências. Não repercutem. Estão excluídos. Para eles, não funciona a encenação publicitária aparatosa, suas opiniões são ignoradas pela grande imprensa, o que acontece por exemplo no caso de "O Grito dos Excluídos". É que, para azar deles, nem estão entre os promotores da revolução social, nem pertencem aos pequenos grupos dos privilegiados pela mídia.

Excluir a exclusão

É preciso que se inclua entre os formadores de opinião, com acesso à mídia, também os prelados e sacerdotes que hoje estão sem microfone. Por que deixá-los de fora? Por que os grupelhos contestatários, de intenso ativismo no interior da Igreja, e cuja especialidade é reivindicar todo tipo de medidas antiexclusão, não incluem na agenda já tão abrangente do "Grito dos Excluídos" também o fim do boicote contra os sacerdotes sem-microfone? Afinal de contas, não se proclamam os seus participantes em batalha contra as exclusões, pelo fim das discriminações? Ou é que umas exclusões podem existir, e são bem-vindas, e outras não? Se for assim afastam-se do que deseja o povo, pois milhões de brasileiros querem saber o que pensa o Clero sem-microfone.

Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado".

LINKS:

Lindenberg:Concordo (envie seu voto virtual, e, melhor ainda, acrescente seu comentário, caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores / GratuitamenteProximosArtigos / GratuitamenteTodosOsArtigos

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEmPortugal (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora em Portugal; preço: E 19,45)

Lindenberg:DesejoAdquirirLivroNoBrasil (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora no Brasil, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais Correio)

LINK DE REMOÇÃO

ConstruNews:Remover

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 From owner-namedroppers@ops.ietf.org Mon Jan 12 04:18: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 EAA19248 for ; Mon, 12 Jan 2004 04:18:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Afy5H-000HQA-H9 for namedroppers-data@psg.com; Mon, 12 Jan 2004 09:10:07 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Afy4Y-000Gc2-DA for namedroppers@ops.ietf.org; Mon, 12 Jan 2004 09:09:22 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0C96cBX025892 for ; Mon, 12 Jan 2004 04:06:38 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA03ayKY; Mon, 12 Jan 04 04:06:37 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0C983GH002901; Mon, 12 Jan 2004 04:08:04 -0500 (EST) Date: Mon, 12 Jan 2004 04:08:03 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org cc: jakob@schlyter.se Subject: Re: Comments on draft-ietf-dnsext-nsec-rdata-03.txt In-Reply-To: Message-ID: References: <200401050759.i057xSMF006856@birch.ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk abstract: Strike "defines" "cover" is vague unless someone already knows what you're talking about. How about: "allow signing of records with any typecode" or "remove the limitation ..." ot somesuch intro, paragraph 2: "once the first 127 type codes are allocated," isn't quite right, since 2929 specifies a private range that's available for use now, independent of IANA assignment. I think the bigger problem is that the current behavior in the pressence of big types is unspecified -- we don't know how to handle them (as an authoritative server or as a resolver). intro, paragraph 3: s/ This document introduces a new format for the type bit map/ ...type list/ (since it's no longer a bit map, exactly) s/all possible type/all possible types/ replace semi-colons with commas, and add an "and" section 2: Should "authoritative" be used here? Even non-authoritative RRsets are in the NSEC chain (delegations w/o DS records). Yes, the parent is authoritative for their existance, but that's a subtlety that may be lost on some readers. Also, "the owner name of the next authoritative RRset" sounds wrong. It's the next name -- there can be multiple RRsets at a name. section 2.1.2 The term "window blocks" doesn't sound right to me. Can we think of something better? "ignored upon reading" puzzles me. Can that be better specified? section 2.2 raw numbers not allowed? want to impose any ordering constraints here? And I concur with Simon's suggest to mention NXT, especially when citing 2535. The chain of changes just gets too long. I don't see a need to change the security considerations section. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 12 08:00: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 IAA24992 for ; Mon, 12 Jan 2004 08:00:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag1bL-000K35-GY for namedroppers-data@psg.com; Mon, 12 Jan 2004 12:55:27 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag1b6-000Jgp-TW for namedroppers@ops.ietf.org; Mon, 12 Jan 2004 12:55:13 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i0CCt8aQ056428 for ; Mon, 12 Jan 2004 13:55:08 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) with ESMTP id i0CCt7Xp007749 for ; Mon, 12 Jan 2004 13:55:07 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) id i0CCt6Gl007748 for namedroppers@ops.ietf.org; Mon, 12 Jan 2004 13:55:06 +0100 Date: Mon, 12 Jan 2004 13:55:06 +0100 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: Explicit support during WGLC. Message-ID: <20040112125506.GA7476@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <200401081938.i08JcRMF003137@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401081938.i08JcRMF003137@birch.ripe.net> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk For what it is worth: we (the NSD team) were able to gather all necessary information from the 2535bis documents (including NSEC) to implement DNSSEC support in NSD. As NSD is only authoritative we haven't look at the rescursion stuff as thoroughly. regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 12 14:53: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 OAA13553 for ; Mon, 12 Jan 2004 14:53:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ag7zo-0001PI-E1 for namedroppers-data@psg.com; Mon, 12 Jan 2004 19:45:08 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ag7zY-00019e-K9 for namedroppers@ops.ietf.org; Mon, 12 Jan 2004 19:44:52 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i0CJiji06276; Mon, 12 Jan 2004 11:44:45 -0800 From: bill Message-Id: <200401121944.i0CJiji06276@karoshi.com> Subject: Re: DISCOVER - the return To: aboba@internaut.com (Bernard Aboba) Date: Mon, 12 Jan 2004 11:44:45 -0800 (PST) Cc: bmanning@karoshi.com (bill), namedroppers@ops.ietf.org In-Reply-To: from "Bernard Aboba" at Jan 08, 2004 07:53:30 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > LLMNR and mDNS may have evolved from the same root, but have taken > > minor varients in evolution. LLMNR could adopt, with minor tweeks > > many of the original design features of mDNS. > > Is there a way to get a list of the "minor tweeks" that would be required? I expect so, but then one would have to revisit the remit of LLMNR. DISCOVER, in conjunction w/ the TBDS modifications to DNS has zero link-local restrictions. > I'm willing to make the modifications to section 2.1, for example, if this > would allow DISCOVER to run over LLMNR. Right now, for example, -28 > reserves the RD, RA, CD and AD bits (since they're not used > with the QUERY opcode). So DISCOVER could define uses for these bits when > used with that opcode. It could, but I would not wish to derail LLMNR w/ its adoption of a clearly experimental OPCODE. > > the "normative" reference for mDNS was rejected by the IETF but > > is part of the DARPA final report for that effort. mDNS is > > normal DNS with multicast capabilities so there is no unique > > protocol. > > I'm not sure that there is such a thing as "normal DNS with multicast > capabilities." When you get into the details, there are elements of the > DNS header (RCODEs, for example) that just don't make sense when used with > multicast DNS. For example, in LLMNR only responses with RCODE=0 are > allowed. Are non-zero RCODEs in allowed in DISCOVER responses? Yes, they were. > > 3 MZAP [Thaler] > > 4 Multicast Discovery of DNS Services [Manning] > > ----------------------------------------------- > > Are you suggesting that LLMNR should use the relative multicast address > originally allocated to you? > No. You asked what multicast addresses are used in an implementation that supports DISCOVER. I'm not suggesting LLMNR adopt DISCOVER. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 12 17:40: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 RAA26223 for ; Mon, 12 Jan 2004 17:40:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgAe8-0008xf-EH for namedroppers-data@psg.com; Mon, 12 Jan 2004 22:34:56 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgAdu-0008vk-DB for namedroppers@ops.ietf.org; Mon, 12 Jan 2004 22:34:42 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Mon, 12 Jan 2004 17:34:41 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: question about draft-ietf-dnsext-dnssec-records-06 Date: Mon, 12 Jan 2004 17:34:41 -0500 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401121734.41484.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit When carefully reviewing this excellent document, I came across this sentence in section 4.1.1: Owner names of RRsets not authoritative for the given zone (such as glue records) MUST NOT be listed in the Next Domain Name unless at least one authoritative RRset exists at the same owner name. which made me think of this "unless" case. If an authoritive RRset exists at the same owner name as glue, what should the type map look like? Intuitively, it should contain the types of the authoritative RRsets only, but since it isn't specified in the document, I'm only guessing. Just to make sure folks know what I'm talking about, consider this snippet from the "example." zone: foo.example. IN NS ns1.foo.example. foo.example. IN NS foo.example. foo.example. IN A 1.2.3.5 ns1.foo.example. IN A 1.2.3.4 foo.example. IN NSEC foo2.example. (A?) NS RRSIG NSEC foo.example. IN RRSIG NSEC ... which I think is a valid illustration of this case. Whatever the answer is, I think that it should be spelled out in this document. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 13 10:58:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20674 for ; Tue, 13 Jan 2004 10:58:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgQmu-000EyL-7H for namedroppers-data@psg.com; Tue, 13 Jan 2004 15:49:04 +0000 Received: from [65.201.175.62] (helo=cliffie.verisignlabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgQmh-000Erw-I5 for namedroppers@ops.ietf.org; Tue, 13 Jan 2004 15:48:51 +0000 Received: from pinion.admin.cto.netsol.com ([::ffff:172.25.170.10]) (AUTH: LOGIN davidb, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by cliffie.verisignlabs.com with esmtp; Tue, 13 Jan 2004 10:48:50 -0500 From: David Blacka Organization: Verisign, Inc. To: namedroppers@ops.ietf.org Subject: another question about draft-...-records-06 Date: Tue, 13 Jan 2004 10:48:50 -0500 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401131048.50120.davidb@verisignlabs.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I noticed that records-06, section 6.3 "Canonical RR Ordering Within An RRset" says: For purposes of DNS security, RRs with the same owner name, class, and type are sorted by RDATA: first by RDATA length, shortest to longest, then by the canonical form of the RDATA itself in the case of length equality, treating the RDATA portion of the canonical form of each RR as a left justified unsigned octet sequence. The absence of an octet sorts before a zero octet. Which seems to contradict rfc 2535, which says: 8.3 Canonical RR Ordering Within An RRset Within any particular owner name and type, RRs are sorted by RDATA as a left justified unsigned octet sequence where the absence of an octet sorts before the zero octet. When and why did this change? I know that previous interpretations of 2535 excluded ordering the RDATA by length first, because I had code that did this by mistake, and it did not interoperate. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 16:42: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 QAA15485 for ; Wed, 14 Jan 2004 16:42:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Agsed-000BnW-0j for namedroppers-data@psg.com; Wed, 14 Jan 2004 21:34:23 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgseQ-000BkK-Ft for namedroppers@ops.ietf.org; Wed, 14 Jan 2004 21:34:10 +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 i0ELX5gC045063; Wed, 14 Jan 2004 16:33:05 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20040114094546.0275fec0@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 14 Jan 2004 16:33:53 -0500 To: David Blacka , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: question about draft-ietf-dnsext-dnssec-records-06 In-Reply-To: <200401121734.41484.davidb@verisignlabs.com> References: <200401121734.41484.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:34 2004-01-12, David Blacka wrote: >When carefully reviewing this excellent document, I came across this >sentence in section 4.1.1: > > Owner names of RRsets not authoritative for the given zone (such as > glue records) MUST NOT be listed in the Next Domain Name unless at > least one authoritative RRset exists at the same owner name. > >which made me think of this "unless" case. If an authoritive RRset exists >at the same owner name as glue, what should the type map look like? > >Intuitively, it should contain the types of the authoritative RRsets only, >but since it isn't specified in the document, I'm only guessing. > >Just to make sure folks know what I'm talking about, consider this snippet >from the "example." zone: > >foo.example. IN NS ns1.foo.example. >foo.example. IN NS foo.example. >foo.example. IN A 1.2.3.5 >ns1.foo.example. IN A 1.2.3.4 >foo.example. IN NSEC foo2.example. (A?) NS RRSIG NSEC >foo.example. IN RRSIG NSEC ... > >which I think is a valid illustration of this case. Yes this is a good illustration of this case. I can not find any text in any DNS document that outlaws A residing with a NS in parent. (Not sure anyone does this anyway) >Whatever the answer is, I think that it should be spelled out in this >document. It is in a way implied in protocol section 2.2, but it should be spelled out in records. In the case of NS the parent is authoritative for the existence of the name and the type while the child is authoritative for the contents of the record. Thus the NS is included in the NSEC type map but not signed. In the case of NSEC and DS the parent is authoritative for the contents of them and signs them, thus they appear in the NSEC bit map. In the case of glue the parent is not authoritative for any part of the type or content. For this reason (IMHO) the type should not be listed in the NSEC bit map. A different argument is: why should glue that happens to reside at delegation point get preferential treatment over glue that is below a delegation point. With this interpretation of NSEC bitmap at delegations, the contents of a NSEC at delegation points is always NS [DS] RRSIG NSEC, this should be spelled out in the documents. Olafur (himself not as WG-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: From owner-namedroppers@ops.ietf.org Wed Jan 14 20:24: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 UAA25216 for ; Wed, 14 Jan 2004 20:24:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgwAy-0007go-7H for namedroppers-data@psg.com; Thu, 15 Jan 2004 01:20:00 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgwAl-0007g2-GK for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 01:19:47 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 14 Jan 2004 17:22:35 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0F1JiGN024253; Wed, 14 Jan 2004 17:19:44 -0800 (PST) Received: from cisco.com ([161.44.65.133]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFG53939; Wed, 14 Jan 2004 20:19:43 -0500 (EST) Message-ID: <4005EAAF.3060408@cisco.com> Date: Wed, 14 Jan 2004 20:19:43 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olaf Kolkman CC: namedroppers@ops.ietf.org Subject: Re: Reminder WGLC DNSSECvbis and NSEC++ References: <200401050759.i057xSMF006856@birch.ripe.net> In-Reply-To: <200401050759.i057xSMF006856@birch.ripe.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf Kolkman wrote: > References: > draft-ietf-dnsext-nsec-rdata-03.txt I support moving draft-ietf-dnsext-nsec-rdata-03 forward (as appropriate, or killing it because dnssec-records-06 fully incorporates it). I do request consideration of the following 2 minor editorial nits: - Sec. 1: The first paragraph indicates that NSEC RR was descibed in RFC2535. It is actually NXT that is defined there. - Sec. 2.3: In the second paragraph is says, "The A, MX, RRSIG and NSEC mnemonics indicate there are A, MX, RRSIG, NSEC and TYPE1234 RRsets...". This probably should begin "The A, MX, RRSIG, NSEC and TYPE1234 mnemonics..." > draft-ietf-dnsext-dnssec-intro-08 > draft-ietf-dnsext-dnssec-protocol-04 I support moving draft-ietf-dnsext-dnssec-intro-08 and draft-ietf-dnsext-dnssec-protocol-04 forward as written. > draft-ietf-dnsext-dnssec-records-06 I support moving draft-ietf-dnssext-records-06 forward, with the minor comment above for nsec-rdata-03, sec. 2.3 applied to sec. 4.3 -josh -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 20:42: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 UAA25720 for ; Wed, 14 Jan 2004 20:42:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgwSl-0009XP-A5 for namedroppers-data@psg.com; Thu, 15 Jan 2004 01:38:23 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgwSY-0009Vm-VD for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 01:38:11 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0F1ZNRE003367 for ; Wed, 14 Jan 2004 20:35:23 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUdaWKg; Wed, 14 Jan 04 20:35:22 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0F1at7D010514 for ; Wed, 14 Jan 2004 20:36:55 -0500 (EST) Date: Wed, 14 Jan 2004 20:36:55 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Explicit support for nsec-03 In-Reply-To: Message-ID: References: <200401050759.i057xSMF006856@birch.ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This document has nits that need to be fixed before it is progressed (see my earlier message), but it is technically complete. I support its publication, contingent on another editting cycle. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 21:58: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 VAA27752 for ; Wed, 14 Jan 2004 21:58:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Agxat-000Hdg-FV for namedroppers-data@psg.com; Thu, 15 Jan 2004 02:50:51 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Agxag-000Hd1-S9 for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 02:50:38 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0F2louo007100 for ; Wed, 14 Jan 2004 21:47:50 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAGay3n; Wed, 14 Jan 04 21:47:50 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0F2nNNV012451 for ; Wed, 14 Jan 2004 21:49:23 -0500 (EST) Date: Wed, 14 Jan 2004 21:49:23 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: intro-08 WGLC comments In-Reply-To: Message-ID: References: <200401050759.i057xSMF006856@birch.ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk intro-08 is a beautiful and very complete document. The editors have done a marvelous job, and they've been very responsive to previous suggested changes. I applaud them. In addition to the usual minor nits, I see some things that I expect to cause IESG delays, and I do not support the advancement of this document until they are addressed. To be clear, I will support the document during IETF last call (the document is technically sound). I just think it would be prudent for DNSEXT to fix these things before advancing the doc. First, there's an inconsistency in this document re: which direction the authentication happens in (FROM a preconfigured key, as in section 5, or TO a preconfigured key as in section 3.1). It doesn't really matter, but the inconsistency does show up and may confuse people, including the IESG. Section 2, definitions The distinction between "authenticated" and "validated" is subtle and may be inconsistent, which makes these definitions look cavalier. If we can't clean this up, perhaps we need to add a disclaimer about these being "rough" definitions, lest the IESG throw this back. In the zone signing key definition, please repeat the warning re: the ZSK/KSK distinction not mattering for validation. The second paragraph of 3.1 also confuses this a little (more detail sent to editors). Section 3.1 third paragraph The attempt at DS->DNSKEY chaining formalism misses the optional DNSKEY->DNSKEY indirection inside the zone. 11. Security considerations More should be said about DNSSEC's potential for making zones less reachable and for otherwise causing DNS to appear to break. And it should be stressed that DNSSEC does not necessarily help a resolver to find good data (it may, but we haven't developed those technologies yet). In the second paragraph, is "intermediate" really defined elsewhere? It looks to me like it's both undefined and overloaded. Local policy is discussed several times in this document, but with limited examples. I'd like to see more examples (ie. disabling an algorithm and the impacts thereof). Many minor nits have been sent privately to the editors. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 14 22:50: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 WAA29003 for ; Wed, 14 Jan 2004 22:50:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgySx-000Np3-9X for namedroppers-data@psg.com; Thu, 15 Jan 2004 03:46:43 +0000 Received: from [211.30.120.24] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgySk-000NoO-6Z for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 03:46:30 +0000 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.9p2/8.12.9) with ESMTP id i0F3kS15081975 for ; Thu, 15 Jan 2004 14:46:28 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200401150346.i0F3kS15081975@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: WGLC comments Date: Thu, 15 Jan 2004 14:46:28 +1100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Protocol Section 5.2 need a paragraph like. If the resolver authenticates the DS RRset and ALL the DS records contain unsupported algorithms, then there is no supported authentication path leading from the parent to the child. The child zone should be treated as if it was unsigned. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 00:04: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 AAA00750 for ; Thu, 15 Jan 2004 00:04:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AgzcV-0005xT-FG for namedroppers-data@psg.com; Thu, 15 Jan 2004 05:00:39 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AgzcI-0005wY-PH for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 05:00:26 +0000 Received: from ENGILL.ogud.com (ns.md.ogud.com [10.20.30.6] (may be forged)) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i0F4xJgC046311 for ; Wed, 14 Jan 2004 23:59:20 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20040114235522.02a74ad0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 15 Jan 2004 00:00:09 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSEXT in Seoul (not) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk There will not be a DNSEXT meeting at IETF-59. The working group is just finishing up the DNSEXT document set and few other documents, there are no items on the table that warrant a meeting. Still here is the ID draft deadlines: February 9, Monday - 00 Internet Draft Cut-off February 16, Monday - Internet Draft cut-off Once we have cleared the tables of DNSSEC the working group must turn its attention to the large number of RFC that are in Proposed standards state and start the work of revising and advancing them. Olafur & 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: From owner-namedroppers@ops.ietf.org Thu Jan 15 00:50: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 AAA01952 for ; Thu, 15 Jan 2004 00:50:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah0Lg-000ADa-O3 for namedroppers-data@psg.com; Thu, 15 Jan 2004 05:47:20 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah0LU-000ACj-Pl for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 05:47:08 +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 i0F5k1gC046470; Thu, 15 Jan 2004 00:46:02 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20040114222936.024b0ea0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 14 Jan 2004 22:57:58 -0500 To: David Blacka , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: another question about draft-...-records-06 In-Reply-To: <200401131048.50120.davidb@verisignlabs.com> References: <200401131048.50120.davidb@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:48 2004-01-13, David Blacka wrote: >I noticed that records-06, section 6.3 "Canonical RR Ordering Within An >RRset" says: > > For purposes of DNS security, RRs with the same owner name, class, > and type are sorted by RDATA: first by RDATA length, shortest to > longest, then by the canonical form of the RDATA itself in the case > of length equality, treating the RDATA portion of the canonical form > of each RR as a left justified unsigned octet sequence. The absence > of an octet sorts before a zero octet. > >Which seems to contradict rfc 2535, which says: > >8.3 Canonical RR Ordering Within An RRset > > Within any particular owner name and type, RRs are sorted by RDATA as > a left justified unsigned octet sequence where the absence of an > octet sorts before the zero octet. > >When and why did this change? Good catch, dnssec-records-04 is the first version with this wording. the text before that was not clear and this was an attempt to fix that. You are right, this is a protocol change, thus this text needs to be revised to comply to 2535. >I know that previous interpretations of 2535 excluded ordering the RDATA by >length first, because I had code that did this by mistake, and it did not >interoperate. I wonder how many of the implementations had picked up on this detail and coded it ? Olafur Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 02:16: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 CAA15227 for ; Thu, 15 Jan 2004 02:16:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah1eX-000JrN-3m for namedroppers-data@psg.com; Thu, 15 Jan 2004 07:10:53 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Ah1eF-000Jpl-Gr for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 07:10:35 +0000 Received: (qmail 51299 invoked from network); 15 Jan 2004 07:18:02 -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 Jan 2004 07:18:02 -0000 Message-ID: <40063D1F.8000007@necom830.hpcl.titech.ac.jp> Date: Thu, 15 Jan 2004 16:11:27 +0900 From: Masataka Ohta 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: Olaf Kolkman CC: namedroppers@ops.ietf.org Subject: Re: WGLC on DNSSEC bis document set References: <200312180654.hBI6sOdH023644@birch.ripe.net> In-Reply-To: <200312180654.hBI6sOdH023644@birch.ripe.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Olaf Kolkman wrote: > This is a working group last call for the DNSSEC bis specification. Though I still can't see any reason to have DNSSEC, I spent 30 minutes to read: > draft-ietf-dnsext-dnssec-intro-08 and felt alarted that it says: A security-aware resolver should be configured with at least one authentication key or a key's DS RR hash as the starting point from which it will attempt to establish authentication chains. My question is, where is the information on key or hash expiration date stored and how? I spent another 30 minutes to read: > draft-ietf-dnsext-dnssec-records-06 > draft-ietf-dnsext-dnssec-protocol-04 but can't find any information on it yet. First, I thought hash of a resolver should be over key and expiration date, which minimize configuration on resolvers. But I found it not the case. 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: From owner-namedroppers@ops.ietf.org Thu Jan 15 03:14: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 DAA18166 for ; Thu, 15 Jan 2004 03:14:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah2ZS-000Pr7-8G for namedroppers-data@psg.com; Thu, 15 Jan 2004 08:09:42 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah2ZF-000Pq9-Pe for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 08:09:29 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0F86fDX025143 for ; Thu, 15 Jan 2004 03:06:41 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4daOgX; Thu, 15 Jan 04 03:06:40 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0F88Csj022528; Thu, 15 Jan 2004 03:08:12 -0500 (EST) Date: Thu, 15 Jan 2004 03:08:12 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Masataka Ohta cc: namedroppers@ops.ietf.org Subject: expiring preconfigured keys (was: Re: WGLC on DNSSEC bis document set) In-Reply-To: <40063D1F.8000007@necom830.hpcl.titech.ac.jp> Message-ID: References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > My question is, where is the information on key or hash > expiration date stored and how? Some distributors of keys intended for configuration in resolvers may not expect to ever change their keys. Some may also distribute chains of keys, intended to be rolled over at regular intervals. Some may even distribute algorithms that generate the key to be used at a particular time. Perhaps resolvers should include support for such practices, and I invite you to make that case to resolver authors in appropriate forums. I don't see how this is a protocol issue that needs to be addressed in these specifications. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 05:47: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 FAA26391 for ; Thu, 15 Jan 2004 05:47:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah4xQ-000Eax-Jt for namedroppers-data@psg.com; Thu, 15 Jan 2004 10:42:36 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah4wh-000EXk-Bv for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 10:41:51 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i0FAfkaQ078262 for ; Thu, 15 Jan 2004 11:41:46 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) with ESMTP id i0FAfjxx022817 for ; Thu, 15 Jan 2004 11:41:45 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) id i0FAfjJu022816 for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 11:41:45 +0100 Date: Thu, 15 Jan 2004 11:41:45 +0100 From: Miek Gieben To: namedroppers Subject: direct query for NSEC Message-ID: <20040115104145.GA22803@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, When doing some early testing with NSD2 and BIND9.4, we came across the following. Both nameserver were loaded with the example. zone from protocol-04. a.example is delegated in that zonem dig @nsd-server nsec a.example we get a referral to a.example, not the nsec. We feel this is ok. dig @bind-server nsec a.example we get the nsec from the a.example zone. One can argue this is also correct. But what happens when the server is also authoritative the a.example (as a child zone), which nsec do we get? Both? In good old rfc2535 it says: 5.5 Special Considerations at Delegation Points A name (other than root) which is the head of a zone also appears as the leaf in a superzone. If both are secure, there will always be two different NXT RRs with the same name. They can be easily distinguished by their signers, the next domain name fields, the presence of the SOA type bit, etc. Security aware servers should return the correct NXT automatically when required to authenticate the non-existence of a name and both NXTs, if available, on explicit query for type NXT. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ..... deleted the rest of the paragraph .... I'm not really parsing this, but "...and both NXTs, if available, on explicit..." ... so a server authoritative for both example. and a.example should give them both back? I cannot find this in the current protocol draft. The inclusion of NSEC (section 3.3) records only says how to deal with them when including them in a nxdomain (and other) responses. Not what to do when directly queried for NSEC. My feeling is that 2535 makes the nsec record (in this respect) as weird as the DS record. We need to add extra logic to NSD to give back both the NSECs. And this logic is _very_ simular to the DS logic... Is this under specified? Regards, Miek -- GPG fingerprint: miek.nl/about.html -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 06:36: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 GAA28564 for ; Thu, 15 Jan 2004 06:36:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah5il-000JKH-2i for namedroppers-data@psg.com; Thu, 15 Jan 2004 11:31:31 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Ah5iX-000JJS-Q9 for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 11:31:18 +0000 Received: (qmail 52024 invoked from network); 15 Jan 2004 11:38:47 -0000 Received: from h219-110-033-052.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.52) by necom830.hpcl.titech.ac.jp with SMTP; 15 Jan 2004 11:38:47 -0000 Message-ID: <40067A39.8090903@necom830.hpcl.titech.ac.jp> Date: Thu, 15 Jan 2004 20:32:09 +0900 From: Masataka Ohta 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: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: expiring preconfigured keys References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler; >>My question is, where is the information on key or hash >>expiration date stored and how? > Some distributors of keys intended for configuration in resolvers may > not expect to ever change their keys. Some may also distribute chains > of keys, intended to be rolled over at regular intervals. Some may > even distribute algorithms that generate the key to be used at a > particular time. You are arguing that DNSSEC specification is incomplete and not ready for last call evaluation, unless all the operational details are specified, which is a valid point against DNSSEC. > Perhaps resolvers should include support for such practices, and I > invite you to make that case to resolver authors in appropriate > forums. I don't see how this is a protocol issue that needs to be > addressed in these specifications. Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says A security-aware resolver should be configured with at least one authentication key or a key's DS RR hash as the starting point from which it will attempt to specify hash should be that of DS RR? It is necessary to standardize hash information format necessary for resolvers so that zone administrators do not have to provide hash information in 1,000 different ways. 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: From owner-namedroppers@ops.ietf.org Thu Jan 15 08:30: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 IAA04814 for ; Thu, 15 Jan 2004 08:30:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah7V7-0004PS-Aq for namedroppers-data@psg.com; Thu, 15 Jan 2004 13:25:33 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah7Uu-0004NT-JZ for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 13:25:20 +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 i0FDOhjO002859; Thu, 15 Jan 2004 08:24:43 -0500 (EST) Message-ID: <00eb01c3db6a$f039c500$b9370681@barnacle> From: "Scott Rose" To: "Masataka Ohta" Cc: References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <40067A39.8090903@necom830.hpcl.titech.ac.jp> Subject: Re: expiring preconfigured keys Date: Thu, 15 Jan 2004 08:24:43 -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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Masataka Ohta" > Samuel Weiler; > > >>My question is, where is the information on key or hash > >>expiration date stored and how? > > > Some distributors of keys intended for configuration in resolvers may > > not expect to ever change their keys. Some may also distribute chains > > of keys, intended to be rolled over at regular intervals. Some may > > even distribute algorithms that generate the key to be used at a > > particular time. > > You are arguing that DNSSEC specification is incomplete and not > ready for last call evaluation, unless all the operational details > are specified, which is a valid point against DNSSEC. > Not exactly. Trust anchors are pre-configured and loaded at startup. This could be done by any number of means, and some administrators and network operators may have a preference for another, existing method instead of the DNS protocol. > > Perhaps resolvers should include support for such practices, and I > > invite you to make that case to resolver authors in appropriate > > forums. I don't see how this is a protocol issue that needs to be > > addressed in these specifications. > > Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says > > A security-aware > resolver should be configured with at least one authentication key or > a key's DS RR hash as the starting point from which it will attempt > > to specify hash should be that of DS RR? > > It is necessary to standardize hash information format necessary > for resolvers so that zone administrators do not have to provide > hash information in 1,000 different ways. > At the time of writing, it was assumed to be similar to the DS RDATA. However, the DS RR can use different algorithms for creating the DNSKEY hash (SHA1 is the only currently defined one). How the trusted keys are stored is strictly an internal resolver issue, not a protocol issue. Zone administers do not have to provide the hash of a DNSKEY anyway: If the resolver loads with hashes of trusted keys, it can compute those hashes for the keys it recieves to match with the trusted values. The resolver does the work in DNSSEC, not the zone servers. > Masataka Ohta > > Scott > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 11:07: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 LAA13098 for ; Thu, 15 Jan 2004 11:07:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1Ah9vJ-000LYn-T5 for namedroppers-data@psg.com; Thu, 15 Jan 2004 16:00:45 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ah9v6-000LVu-NT for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 16:00:32 +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 i0FG05jO011494 for ; Thu, 15 Jan 2004 11:00:06 -0500 (EST) Message-ID: <01ac01c3db80$a53b4e50$b9370681@barnacle> From: "Scott Rose" To: References: <200401050759.i057xSMF006856@birch.ripe.net> Subject: Re: intro-08 WGLC comments Date: Thu, 15 Jan 2004 11:00:06 -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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Samuel Weiler" > First, there's an inconsistency in this document re: which direction > the authentication happens in (FROM a preconfigured key, as in section > 5, or TO a preconfigured key as in section 3.1). It doesn't really > matter, but the inconsistency does show up and may confuse people, > including the IESG. > > Section 2, definitions > > The distinction between "authenticated" and "validated" is > subtle and may be inconsistent, which makes these definitions > look cavalier. If we can't clean this up, perhaps we need to > add a disclaimer about these being "rough" definitions, lest > the IESG throw this back. > > In the zone signing key definition, please repeat the warning > re: the ZSK/KSK distinction not mattering for validation. The > second paragraph of 3.1 also confuses this a little (more > detail sent to editors). > Probably will need some wording changes. All of us know the material already, so we know what it's saying, even though it is written differently. > Section 3.1 third paragraph > > The attempt at DS->DNSKEY chaining formalism misses the > optional DNSKEY->DNSKEY indirection inside the zone. > > 11. Security considerations > > More should be said about DNSSEC's potential for making zones > less reachable and for otherwise causing DNS to appear to > break. And it should be stressed that DNSSEC does not > necessarily help a resolver to find good data (it may, but we > haven't developed those technologies yet). > > In the second paragraph, is "intermediate" really defined > elsewhere? It looks to me like it's both undefined and > overloaded. > > Local policy is discussed several times in this document, but with > limited examples. I'd like to see more examples (ie. disabling an > algorithm and the impacts thereof). > We might wander dangerously close to specificiations (which was to be avoided in this doc). I think local policy, resolver actions, etc. might lead to a deep rathole. Maybe even a seperate doc on how a resolver might intereact with a secure name system. Scott > Many minor nits have been sent privately to the editors. > > -- Sam > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 13:44: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 NAA19224 for ; Thu, 15 Jan 2004 13:44:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhCOj-000DMW-Va for namedroppers-data@psg.com; Thu, 15 Jan 2004 18:39:17 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhCOX-000DLn-4W for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 18:39:05 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0FIaGxt027963 for ; Thu, 15 Jan 2004 13:36:16 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAALFaqN2; Thu, 15 Jan 04 13:36:15 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0FIblrN017381; Thu, 15 Jan 2004 13:37:48 -0500 (EST) Date: Thu, 15 Jan 2004 13:37:47 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: Masataka Ohta cc: namedroppers@ops.ietf.org Subject: Re: expiring preconfigured keys In-Reply-To: <40067A39.8090903@necom830.hpcl.titech.ac.jp> Message-ID: References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <40067A39.8090903@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 15 Jan 2004, Masataka Ohta wrote: > > Some distributors of keys intended for configuration in resolvers may > > not expect to ever change their keys. Some may also distribute chains > > of keys, intended to be rolled over at regular intervals. Some may > > even distribute algorithms that generate the key to be used at a > > particular time. > > You are arguing that DNSSEC specification is incomplete and not > ready for last call evaluation, unless all the operational details > are specified, which is a valid point against DNSSEC. I'm sorry to hear that I was unclear again. That seems to be common in our conversations (see namedroppers on 13 November 2003.) To the contray, I think trust anchor configuration is a matter of local policy. It's a knob, albeit a more complex one than disabling an untrusted algorithm. Conventions for it will develop, and they could have profound impacts on resolvers' configuration interfaces and the user experience of DNSSEC, but they do not affect the on-the-wire protocol. The DNSSECbis document set is complete without documenting more than the token set of them that it documents now. Furthermore, having the base protocol deployed will help us develop more useful trust anchor configuration schemes. > Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says > > A security-aware > resolver should be configured with at least one authentication key or > a key's DS RR hash as the starting point from which it will attempt > > to specify hash should be that of DS RR? As an example of something that might be reasonable. A gentle nudge in the right direction. That's not a 2119 SHOULD. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 14:03: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 OAA20173 for ; Thu, 15 Jan 2004 14:03:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhCiT-000G8V-7n for namedroppers-data@psg.com; Thu, 15 Jan 2004 18:59:41 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhCiG-000G5h-OL for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 18:59:28 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0FIueWN029146 for ; Thu, 15 Jan 2004 13:56:40 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZsai74; Thu, 15 Jan 04 13:56:39 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0FIwDot018550 for ; Thu, 15 Jan 2004 13:58:13 -0500 (EST) Date: Thu, 15 Jan 2004 13:58:13 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: prohibiting use of expired RRSIGs In-Reply-To: Message-ID: References: <200401050759.i057xSMF006856@birch.ripe.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk From records-06, section 3.1.5, first paragraph: The Signature Expiration and Inception fields specify a validity period for the signature. The RRSIG record MUST NOT be used for authentication prior to the inception date and MUST NOT be used for authentication after the expiration date. To accomodate local policy, I think these should be SHOULD NOTs. I can imagine some resolvers wanting to knowingly use expired RRSIGs. Perhaps the error when a RRSIG has expired but otherwise validates will be more gentle (or more user overridable) than an error when the RRSIG is missing or doesn't validate at all. Perhaps a given zone will be known to have bad RRSIGs, and that could be configured on a per-zone basis. Perhaps the resolver lacks any sense of the current time, and doesn't want to check times at all. Perhaps the resolver knows that its clock is wildly inaccurate and wants to globablly allow for five hours of slop in either direction. Perhaps there will be a default local policy that states: for a given zone, unless you've seen more recent RRSIGs, keep accepting the old ones -- once any newer RRSIG appears, reject the old ones. These are all local policies, the merits of which can be debated (we probably shouldn't do that here and now), but I see no need to prohibit them wholesale. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 15 15:25: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 PAA26791 for ; Thu, 15 Jan 2004 15:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhDsy-000OHk-IA for namedroppers-data@psg.com; Thu, 15 Jan 2004 20:14:36 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AhDsk-000OFr-JE for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 20:14:22 +0000 Received: (qmail 53812 invoked from network); 15 Jan 2004 20:21:59 -0000 Received: from h219-110-033-052.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.52) by necom830.hpcl.titech.ac.jp with SMTP; 15 Jan 2004 20:21:59 -0000 Message-ID: <4006F4D3.9020708@necom830.hpcl.titech.ac.jp> Date: Fri, 16 Jan 2004 05:15:15 +0900 From: Masataka Ohta 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: Samuel Weiler CC: namedroppers@ops.ietf.org Subject: Re: expiring preconfigured keys References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <40067A39.8090903@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler; >>You are arguing that DNSSEC specification is incomplete and not >>ready for last call evaluation, unless all the operational details >>are specified, which is a valid point against DNSSEC. > > > I'm sorry to hear that I was unclear again. That seems to be common > in our conversations (see namedroppers on 13 November 2003.) > > To the contray, I think trust anchor configuration is a matter of > local policy. Trust anchor configuration policy of a resolver is a matter of policy local to the resolver. However, trust anchor configuration procedure of a resolver for a zone involves two administrators that there is no locality. Standardization is inevitable. > It's a knob, albeit a more complex one than disabling > an untrusted algorithm. Conventions for it will develop, and they > could have profound impacts on resolvers' configuration interfaces and > the user experience of DNSSEC, but they do not affect the on-the-wire > protocol. To implement something, it is not enough to specify on-the-wire protocol. It is also necessary to specify what (not necessarily how, which is an operational issue) kind of information is obtained off-the-wire. Resolvers which can not handle key hash expiration is broken, if there are zones with key expiration. Protocol specifications to allow for broken implementations are broken. > The DNSSECbis document set is complete without documenting > more than the token set of them that it documents now. It is incomplete. >>Why, do you think, draft-ietf-dnsext-dnssec-intro-08 says >> >> A security-aware >> resolver should be configured with at least one authentication key or >> a key's DS RR hash as the starting point from which it will attempt >> >>to specify hash should be that of DS RR? > As an example of something that might be reasonable. A gentle nudge > in the right direction. That's not a 2119 SHOULD. It is an incomplete attempt to address the real problem. 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: From owner-namedroppers@ops.ietf.org Thu Jan 15 15:27: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 PAA26845 for ; Thu, 15 Jan 2004 15:27:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhE0o-000P8j-B7 for namedroppers-data@psg.com; Thu, 15 Jan 2004 20:22:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AhE0Z-000P7Y-TL for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 20:22:28 +0000 Received: (qmail 53838 invoked from network); 15 Jan 2004 20:30:05 -0000 Received: from h219-110-033-052.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.52) by necom830.hpcl.titech.ac.jp with SMTP; 15 Jan 2004 20:30:05 -0000 Message-ID: <4006F6B8.3060509@necom830.hpcl.titech.ac.jp> Date: Fri, 16 Jan 2004 05:23:20 +0900 From: Masataka Ohta 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 CC: namedroppers@ops.ietf.org Subject: Re: expiring preconfigured keys References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <40067A39.8090903@necom830.hpcl.titech.ac.jp> <00eb01c3db6a$f039c500$b9370681@barnacle> In-Reply-To: <00eb01c3db6a$f039c500$b9370681@barnacle> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose; >>>>My question is, where is the information on key or hash >>>>expiration date stored and how? >> >>>Some distributors of keys intended for configuration in resolvers may >>>not expect to ever change their keys. Some may also distribute chains >>>of keys, intended to be rolled over at regular intervals. Some may >>>even distribute algorithms that generate the key to be used at a >>>particular time. >> >>You are arguing that DNSSEC specification is incomplete and not >>ready for last call evaluation, unless all the operational details >>are specified, which is a valid point against DNSSEC. >> > > > Not exactly. Trust anchors are pre-configured and loaded at startup. This > could be done by any number of means, and some administrators and network > operators may have a preference for another, existing method instead of the > DNS protocol. Can you define what is a "trust anchor" which never appears in any of the three IDs. Note that I'm not asking how it is distributed and stored. 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: From owner-namedroppers@ops.ietf.org Thu Jan 15 15:40: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 PAA27379 for ; Thu, 15 Jan 2004 15:40:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhEBA-0000IE-CW for namedroppers-data@psg.com; Thu, 15 Jan 2004 20:33:24 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhEAx-0000Hb-Sn for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 20:33:12 +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 i0FKWvjO029501; Thu, 15 Jan 2004 15:32:57 -0500 (EST) Message-ID: <00a101c3dba6$c33aa380$b9370681@barnacle> From: "Scott Rose" To: "Masataka Ohta" Cc: References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <40067A39.8090903@necom830.hpcl.titech.ac.jp> <00eb01c3db6a$f039c500$b9370681@barnacle> <4006F6B8.3060509@necom830.hpcl.titech.ac.jp> Subject: Re: expiring preconfigured keys Date: Thu, 15 Jan 2004 15:32:58 -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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Masataka Ohta" > > > > > > Not exactly. Trust anchors are pre-configured and loaded at startup. This > > could be done by any number of means, and some administrators and network > > operators may have a preference for another, existing method instead of the > > DNS protocol. > > Can you define what is a "trust anchor" which never appears in > any of the three IDs. > > Note that I'm not asking how it is distributed and stored. > Poor word choice in my statement. I used trust anchor to mean a key that is to be trusted and used to form an authentication chain in DNSSEC. An example would be the root "." zone key, but it could be any zone key, or even a hash of a zone key. Scott > 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: From owner-namedroppers@ops.ietf.org Thu Jan 15 15:51: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 PAA27864 for ; Thu, 15 Jan 2004 15:51:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhEKy-0001iY-6f for namedroppers-data@psg.com; Thu, 15 Jan 2004 20:43:32 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AhEKl-0001eu-QQ for namedroppers@ops.ietf.org; Thu, 15 Jan 2004 20:43:20 +0000 Received: (qmail 53914 invoked from network); 15 Jan 2004 20:50:57 -0000 Received: from h219-110-033-052.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.33.52) by necom830.hpcl.titech.ac.jp with SMTP; 15 Jan 2004 20:50:57 -0000 Message-ID: <4006FB9C.8020409@necom830.hpcl.titech.ac.jp> Date: Fri, 16 Jan 2004 05:44:12 +0900 From: Masataka Ohta 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 CC: namedroppers@ops.ietf.org Subject: Re: expiring preconfigured keys References: <200312180654.hBI6sOdH023644@birch.ripe.net> <40063D1F.8000007@necom830.hpcl.titech.ac.jp> <40067A39.8090903@necom830.hpcl.titech.ac.jp> <00eb01c3db6a$f039c500$b9370681@barnacle> <4006F6B8.3060509@necom830.hpcl.titech.ac.jp> <00a101c3dba6$c33aa380$b9370681@barnacle> In-Reply-To: <00a101c3dba6$c33aa380$b9370681@barnacle> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Scott Rose; > I used trust anchor to mean a key that is > to be trusted and used to form an authentication chain in DNSSEC. An > example would be the root "." zone key, but it could be any zone key, or > even a hash of a zone key. Then, it is insufficient information for resolvers. 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: From owner-namedroppers@ops.ietf.org Fri Jan 16 09:02: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 JAA14211 for ; Fri, 16 Jan 2004 09:02:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhUPp-0003sl-7j for namedroppers-data@psg.com; Fri, 16 Jan 2004 13:53:37 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhUPb-0003sV-6y for namedroppers@ops.ietf.org; Fri, 16 Jan 2004 13:53:23 +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 i0GDrGjO028201 for ; Fri, 16 Jan 2004 08:53:16 -0500 (EST) Message-ID: <007a01c3dc38$18b80be0$b9370681@barnacle> From: "Scott Rose" To: References: <200401050759.i057xSMF006856@birch.ripe.net> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 08:53:18 -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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Samuel Weiler" To: Sent: Thursday, January 15, 2004 1:58 PM Subject: prohibiting use of expired RRSIGs > >From records-06, section 3.1.5, first paragraph: > > The Signature Expiration and Inception fields specify a validity > period for the signature. The RRSIG record MUST NOT be used for > authentication prior to the inception date and MUST NOT be used for > authentication after the expiration date. > > To accomodate local policy, I think these should be SHOULD NOTs. > > I can imagine some resolvers wanting to knowingly use expired RRSIGs. > Perhaps the error when a RRSIG has expired but otherwise validates > will be more gentle (or more user overridable) than an error when the > RRSIG is missing or doesn't validate at all. Perhaps a given zone > will be known to have bad RRSIGs, and that could be configured on a > per-zone basis. Perhaps the resolver lacks any sense of the current > time, and doesn't want to check times at all. Perhaps the resolver > knows that its clock is wildly inaccurate and wants to globablly allow > for five hours of slop in either direction. Perhaps there will be a > default local policy that states: for a given zone, unless you've seen > more recent RRSIGs, keep accepting the old ones -- once any newer > RRSIG appears, reject the old ones. > > These are all local policies, the merits of which can be debated (we > probably shouldn't do that here and now), but I see no need to > prohibit them wholesale. > I think there is a danger if the specifications say it is ok to go "off the reservation" and accept certain errors. Unless an application and user is willing to accept risky responses (example: RRSIG verified, but time was off, or RRSIG in an algorithm the resolver cannot understand), it can request that, but it should be able to rely on a some base security checks. Since we are talking resolver local policy, there really is nothing stopping a resolver implementation from offering that service as an option, but not as default, where it takes liberty with application requests, and hands back responses that were "close enough", but maybe not to the application's wishes. I would rather see a base "MUST NOT accept expired SIG" as the default operation, and anything beyond that as an option an app can specify, rather than "SHOULD NOT" and have an application not be sure what the resolver is doing. Scott > -- Sam > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 16 12:23: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 MAA22049 for ; Fri, 16 Jan 2004 12:23:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhXcI-000P11-Q5 for namedroppers-data@psg.com; Fri, 16 Jan 2004 17:18:42 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhXc6-000Ozq-ME for namedroppers@ops.ietf.org; Fri, 16 Jan 2004 17:18:30 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i0GHIS309905; Fri, 16 Jan 2004 09:18:28 -0800 From: bill Message-Id: <200401161718.i0GHIS309905@karoshi.com> Subject: Re: prohibiting use of expired RRSIGs To: scottr@nist.gov (Scott Rose) Date: Fri, 16 Jan 2004 09:18:28 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <007a01c3dc38$18b80be0$b9370681@barnacle> from "Scott Rose" at Jan 16, 2004 08:53: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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > >From records-06, section 3.1.5, first paragraph: > > > > The Signature Expiration and Inception fields specify a validity > > period for the signature. The RRSIG record MUST NOT be used for > > authentication prior to the inception date and MUST NOT be used for > > authentication after the expiration date. > > > > To accomodate local policy, I think these should be SHOULD NOTs. > > > > I can imagine some resolvers wanting to knowingly use expired RRSIGs. > > > > I think there is a danger if the specifications say it is ok to go "off the > reservation" and accept certain errors. Unless an application and user is > willing to accept risky responses (example: RRSIG verified, but time was > off, or RRSIG in an algorithm the resolver cannot understand), it can > request that, but it should be able to rely on a some base security checks. ... > > I would rather see a base "MUST NOT accept expired SIG" as the default > operation, and anything beyond that as an option an app can specify, rather > than "SHOULD NOT" and have an application not be sure what the resolver is > doing. > > Scott > > -- Sam perhaps its me, but some thinking leads me to beleive that we are mixing features/functionality here. What if folks have a "stock" resolver (whatever the heck that is) and a "validator", where the default is that the resolver "throws" data to the validator, which does the checking and then "throws" a response back to the resolver. Much less change on the part of the resolver (can impliment local policy) and then the validator can retain the "MUST NOT accept expired SIG". Or is this just too wierd? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 16 12:36: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 MAA22504 for ; Fri, 16 Jan 2004 12:36:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhXob-00006x-8H for namedroppers-data@psg.com; Fri, 16 Jan 2004 17:31:25 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhXoO-00006J-MZ for namedroppers@ops.ietf.org; Fri, 16 Jan 2004 17:31:12 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id 91B6556824; Fri, 16 Jan 2004 09:31:10 -0800 (PST) Message-Id: <6.0.1.1.2.20040116122716.02c77a08@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Jan 2004 12:31:37 -0500 To: Samuel Weiler , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: prohibiting use of expired RRSIGs In-Reply-To: References: <200401050759.i057xSMF006856@birch.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk MUST be configurable as to whether to accept expired records, SHOULD be configurable to as to the maximum out of date expired records can be to be acceptable. MUST default to not accepting expired records. At 01:58 PM 1/15/2004, Samuel Weiler wrote: > >From records-06, section 3.1.5, first paragraph: > > The Signature Expiration and Inception fields specify a validity > period for the signature. The RRSIG record MUST NOT be used for > authentication prior to the inception date and MUST NOT be used for > authentication after the expiration date. > >To accomodate local policy, I think these should be SHOULD NOTs. > >I can imagine some resolvers wanting to knowingly use expired RRSIGs. >Perhaps the error when a RRSIG has expired but otherwise validates >will be more gentle (or more user overridable) than an error when the >RRSIG is missing or doesn't validate at all. Perhaps a given zone >will be known to have bad RRSIGs, and that could be configured on a >per-zone basis. Perhaps the resolver lacks any sense of the current >time, and doesn't want to check times at all. Perhaps the resolver >knows that its clock is wildly inaccurate and wants to globablly allow >for five hours of slop in either direction. Perhaps there will be a >default local policy that states: for a given zone, unless you've seen >more recent RRSIGs, keep accepting the old ones -- once any newer >RRSIG appears, reject the old ones. > >These are all local policies, the merits of which can be debated (we >probably shouldn't do that here and now), but I see no need to >prohibit them wholesale. > >-- Sam > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 16 12:49: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 MAA23059 for ; Fri, 16 Jan 2004 12:49:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhY1j-0001dY-Bx for namedroppers-data@psg.com; Fri, 16 Jan 2004 17:44:59 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhY18-0001Wx-PN for namedroppers@ops.ietf.org; Fri, 16 Jan 2004 17:44:22 +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 i0GHiJjO010671 for ; Fri, 16 Jan 2004 12:44:19 -0500 (EST) Message-ID: <002401c3dc58$5ee67460$b9370681@barnacle> From: "Scott Rose" To: References: <200401161718.i0GHIS309905@karoshi.com> Subject: Re: prohibiting use of expired RRSIGs Date: Fri, 16 Jan 2004 12:44:20 -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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "bill" > > > > I think there is a danger if the specifications say it is ok to go "off the > > reservation" and accept certain errors. Unless an application and user is > > willing to accept risky responses (example: RRSIG verified, but time was > > off, or RRSIG in an algorithm the resolver cannot understand), it can > > request that, but it should be able to rely on a some base security checks. > .... > > > > I would rather see a base "MUST NOT accept expired SIG" as the default > > operation, and anything beyond that as an option an app can specify, rather > > than "SHOULD NOT" and have an application not be sure what the resolver is > > doing. > > > > Scott > > > -- Sam > > perhaps its me, but some thinking leads me to beleive that > we are mixing features/functionality here. What if folks > have a "stock" resolver (whatever the heck that is) and a > "validator", where the default is that the resolver "throws" > data to the validator, which does the checking and then "throws" > a response back to the resolver. Much less change on the > part of the resolver (can impliment local policy) and then > the validator can retain the "MUST NOT accept expired SIG". > > Or is this just too wierd? > nope, sounds like it could be a common set up. I was probably blurring the lines between resolver and validator too much there. If the resolver throws stuff to the validator, and the validator returns the answer, there would have to be other info there if an error occurred so the resolver can make a decision. There is also the problem of a recursive resolver acting on behalf of a stub. If an expired RRSIG is encountered, what should the recursive resolver pass back to the stub? The stub has not said what kind of response it is willing to accept. Scott > --bill > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 16 13:17: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 NAA23852 for ; Fri, 16 Jan 2004 13:17:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhYSr-0004tY-QS for namedroppers-data@psg.com; Fri, 16 Jan 2004 18:13:01 +0000 Received: from [198.32.6.68] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhYSf-0004t3-Hi for namedroppers@ops.ietf.org; Fri, 16 Jan 2004 18:12:49 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id i0GICml10305; Fri, 16 Jan 2004 10:12:48 -0800 From: bill Message-Id: <200401161812.i0GICml10305@karoshi.com> Subject: Re: prohibiting use of expired RRSIGs To: scottr@nist.gov (Scott Rose) Date: Fri, 16 Jan 2004 10:12:48 -0800 (PST) Cc: namedroppers@ops.ietf.org In-Reply-To: <002401c3dc58$5ee67460$b9370681@barnacle> from "Scott Rose" at Jan 16, 2004 12:44:20 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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > perhaps its me, but some thinking leads me to beleive that > > we are mixing features/functionality here. What if folks > > have a "stock" resolver (whatever the heck that is) and a > > "validator", where the default is that the resolver "throws" > > data to the validator, which does the checking and then "throws" > > a response back to the resolver. Much less change on the > > part of the resolver (can impliment local policy) and then > > the validator can retain the "MUST NOT accept expired SIG". > > > > Or is this just too wierd? > > > > nope, sounds like it could be a common set up. I was probably blurring the > lines between resolver and validator too much there. If the resolver throws > stuff to the validator, and the validator returns the answer, there would > have to be other info there if an error occurred so the resolver can make a > decision. > > There is also the problem of a recursive resolver acting on behalf of a > stub. If an expired RRSIG is encountered, what should the recursive > resolver pass back to the stub? The stub has not said what kind of response > it is willing to accept. presuming a validator "module" - one could conceive that it would plug into the iterative/caching resolver and then the stub would behave the way it does today... > > Scott > > > --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: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 16 14:26: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 OAA25472 for ; Fri, 16 Jan 2004 14:26:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhZUM-000CG0-J1 for namedroppers-data@psg.com; Fri, 16 Jan 2004 19:18:38 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhZU9-000CFA-Pq for namedroppers@ops.ietf.org; Fri, 16 Jan 2004 19:18:25 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0GJFavf005896 for ; Fri, 16 Jan 2004 14:15:36 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAfFa4Gl; Fri, 16 Jan 04 14:15:36 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0GJH9f5007052 for ; Fri, 16 Jan 2004 14:17:09 -0500 (EST) Date: Fri, 16 Jan 2004 14:17:09 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: Re: prohibiting use of expired RRSIGs In-Reply-To: <6.0.1.1.2.20040116122716.02c77a08@localhost> Message-ID: References: <200401050759.i057xSMF006856@birch.ripe.net> <6.0.1.1.2.20040116122716.02c77a08@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Going back to 2119: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. On Fri, 16 Jan 2004, Mike StJohns wrote: > MUST be configurable as to whether to accept expired records, SHOULD be > configurable to as to the maximum out of date expired records can be to be > acceptable. MUST default to not accepting expired records. Configurability is not a MUST. At most it's a SHOULD, and probably a MAY. I'm not even sure about the default... I'm happy with taking the original text, replacing MUST with SHOULD, and moving on. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 16 14:52:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26643 for ; Fri, 16 Jan 2004 14:52:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AhZw7-000Ful-ND for namedroppers-data@psg.com; Fri, 16 Jan 2004 19:47:19 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AhZvu-000Fts-Ic for namedroppers@ops.ietf.org; Fri, 16 Jan 2004 19:47:06 +0000 Received: from STJOHNS-LAPTOP2.nominum.com (shell-ng.nominum.com [81.200.64.181]) by shell-ng.nominum.com (Postfix) with ESMTP id EB13956824; Fri, 16 Jan 2004 11:47:04 -0800 (PST) Message-Id: <6.0.1.1.2.20040116143609.02a21418@localhost> X-Sender: stjohns@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 16 Jan 2004 14:47:31 -0500 To: Samuel Weiler , namedroppers@ops.ietf.org From: Mike StJohns Subject: Re: prohibiting use of expired RRSIGs In-Reply-To: References: <200401050759.i057xSMF006856@birch.ripe.net> <6.0.1.1.2.20040116122716.02c77a08@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk How about MAY be configurable as to whether to accept expired records. If configurable, SHOULD be configurable to as to the maximum out of date expired records can be to be acceptable. And if configurable, MUST default to not accepting expired records. At 02:17 PM 1/16/2004, Samuel Weiler wrote: >Going back to 2119: > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > >On Fri, 16 Jan 2004, Mike StJohns wrote: > > > MUST be configurable as to whether to accept expired records, SHOULD be > > configurable to as to the maximum out of date expired records can be to be > > acceptable. MUST default to not accepting expired records. > >Configurability is not a MUST. At most it's a SHOULD, and probably a >MAY. I'm not even sure about the default... > >I'm happy with taking the original text, replacing MUST with SHOULD, >and moving on. > >-- Sam > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From evknews@mail.com Sat Jan 17 02:31:52 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 CAA29697 for ; Sat, 17 Jan 2004 02:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ahkvv-0002iG-00 for dnsext-archive@ietf.org; Sat, 17 Jan 2004 02:31:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ahkv4-0002dH-00 for dnsext-archive@ietf.org; Sat, 17 Jan 2004 02:30:58 -0500 Received: from [61.154.118.6] (helo=ietf.org) by ietf-mx with smtp (Exim 4.12) id 1Ahktx-0002PO-00; Sat, 17 Jan 2004 02:29:56 -0500 From: "Memorial Cubano:" To: disman-archive@ietf.org Subject: Pedem Missas e orações pelas vítimas do comunismo ref.: bon 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: Date: Sat, 17 Jan 2004 02:29:56 -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=11.2 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,MSGID_FROM_MTA_SHORT, REMOVE_REMOVAL_2WORD,SUBJ_HAS_SPACES,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.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 * 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

Ref.: (tjp) InEnglish / InItaliano / EnCastellano

Memorial cubano: Pedido de Missas e orações pelas vítimas do comunismo

A ajuda urgente que solicitamos é de caráter estritamente espiritual, ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus

Queridos irmãos luso-brasileiros,

* Precisamos de vossa valiosa ajuda para resgatar do esquecimento a mais de 10 mil cubanos que morreram vítimas do regime comunista, sobre os quais se possui informação documentada. Esta ajuda que lhes solicitamos é de caráter estritamente espiritual, inteiramente ao alcance de cada um e, sem dúvida, a mais valiosa aos olhos de Deus!

* Entre os dias 20 e 23 de fevereiro próximo, no Tamiami Park de Miami, Flórida, voluntários de diversos países organizarão o Memorial Cubano, consistente em mais de 10 mil cruzes brancas, cada uma delas tendo inscrito o nome de uma vítima do regime comunista de Cuba. Familiares desterrados que nunca puderam dar o adeus a seus seres queridos assassinados, por não ser-lhes permitido visitar suas tumbas em Cuba, poderão fazê-lo agora.

* No centro da área se localizará uma cruz de madeira gigante, também pintada de branco, denominada "Cruz da vítima desconhecida", que constituirá o reconhecimento a todos os que morreram por causa do regime comunista, porém a respeito dos quais até o momento não se possui informação suficiente.

* De que maneira vocês podem unir-se a esta cruzada de orações e a esta homenagem espiritual? Simplesmente encomendando uma Missa ou serviço religioso, organizando com sua família, comunidade ou colegas de trabalho um momento de oração conjunta, ou rezando privadamente. Solicitamos-lhes que as Missas sejam encomendadas, se for possível, para o domingo 22 de fevereiro. Assim, no mundo inteiro, nesse dia se elevarão preces a Deus pelo eterno descanso dessas almas. Poderão encomendá-las em benefício das "vítimas do genocídio cubano sob o regime comunista de Fidel Castro".

* Muitas destas vítimas foram jovens que enfrentaram o "paredón" de fuzilamento proclamando "Viva Cristo Rei!"

* Confirmem-nos o quanto antes vossa adesão, encomendando Missas, prometendo orações, etc., fazendo clic em:

ConfirmamosMissa/ServicoReligioso e/ou ConfirmamosOraçoesPreces incluindo local, data e, se o desejarem, outros detalhes.

* Irmãos ibero-americanos e homens e mulheres de boa vontade, de outras regiões do mundo, que leiam esta mensagem e a ela adiram: que a Providência os recompense com o cêntuplo já nesta terra!

Com a maior consideração e estima,

Renato Gómez - Coordenador Geral

Comitê Organizador do Memorial Cubano

Tel. (1-786) 621-7505 Miami (FL) www memorialcubano org

PS.:

Em vossas orações e preces incluam também os homens, mulheres e crianças que morreram afogados no estreito da Flórida, tentando alcançar a liberdade. Seus nomes são em sua maioria desconhecidos e fontes autorizadas estimam que o número deles seja de muitas dezenas de milhares de cubanos.

Por fim, rezem pelos presos políticos que agonizam nos cárceres, como o médico Oscar Elias Biscet, pela economista Martha Beatriz Roque e milhares de outros irmãos cubanos detidos DesejoInfoPresosPoliticos. A seis anos da viagem de S.S. João Paulo II a Cuba (21-25 de janeiro de 1998), se continua contrariando o sonho papal de que a ilha-cárcere abra-se ao mundo.

LINKS PRIORITÁRIOS:

ConfirmoMissa/ServiçoReligioso e/ou ConfirmoOraçoesPreces (incluindo nome, cidade e, se desejar, outros detalhes)

MinhaAjuda (narre de que maneira poderá ajudar-nos a difundir esta iniciativa espiritual e humanitária: reenviando esta notícia a seus amigos, levando-a a jornalistas conhecidos, colocando-a no quadro de avisos de seu local de trabalho, etc.; pode incluir também sugestões).

MinhaOpiniao

OUTROS LINKS:

DesejoRecibirLinkMemorialCubano (para receber o link do web site sobre o Memorial Cubano, com nomes de todas as vítimas)

DesejoReceberInfoPresosPoliticos

ProximosEnvios:SoloEnEspañol

NextMails:OnlyInEnglish

Remover

A difusão deste e-mail é de exclusiva responsabilidade da agência humanitária Derechos Sin Fronteras (DSF).

Tradução: Graça Salgueiro

 

 

From owner-namedroppers@ops.ietf.org Tue Jan 20 11: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 LAA08522 for ; Tue, 20 Jan 2004 11:11:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AiyNx-000HvN-GS for namedroppers-data@psg.com; Tue, 20 Jan 2004 16:05:49 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AiyNh-000HuH-6b for namedroppers@ops.ietf.org; Tue, 20 Jan 2004 16:05:33 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0KGJuI09018 for ; Tue, 20 Jan 2004 08:19:56 -0800 Date: Tue, 20 Jan 2004 08:19:56 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed resolution to LLMNR Issue 59: Miscellaneous Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 59 is enclosed below. The proposed fix is as follows:' In Section 2.2, change: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone root." To: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone apex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone apex." In Section 2.2, change: "Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." Add the following paragraph to Section 2.2: "Upon configuring an IP address responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has. However, in general whether RRs are manually or automatically created is an implementation decision." Change Section 2.7 from: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In less dynamic environments, LLMNR traffic can be reduced by setting the TTL to a higher value. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 30 seconds is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc networks), the TTL value may need to be reduced. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." Add the following section: "2.1. LLMNR packet format LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for both queries and responses. LLMNR implementations SHOULD send UDP queries and responses only as large as are known to be permissible without causing fragmentation. When in doubt a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST accept UDP queries and responses as large as permitted by the link MTU. 2.1.1. LLMNR header format LLMNR queries and responses utilize the DNS header format defined in [RFC1035] with exceptions noted below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied from the query to the response and can be used by the sender to match responses to outstanding queries. The ID field in a query SHOULD be set to a pseudo-random value. QR A one bit field that specifies whether this message is an LLMNR query (0), or an LLMNR response (1). OPCODE A four bit field that specifies the kind of query in this message. This value is set by the originator of a query and copied into the response. This specification defines the behavior of standard queries and responses (opcode value of zero). Future specifications may define the use of other opcodes with LLMNR. LLMNR senders and responders MUST support standard queries (opcode value of zero). LLMNR queries with unsupported OPCODE values MUST be silently discarded by responders. TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. The TC bit MUST NOT be set in an LLMNR query and if set is ignored by an LLMNR responder. If the TC bit is set an LLMNR response, then the sender MAY use the response if it contains all necessary information, or the sender MAY discard the response and resend the LLMNR query over TCP using the unicast address of the responder as the destination address. See [RFC2181] and Section 2.4 of this specification for further discussion of the TC bit. Z Reserved for future use. Implementations of this specification MUST set these bits to zero in both queries and responses. If these bits are set in a LLMNR query or response, implementations of this specification MUST ignore them. Since reserved bits could conceivably be used for different purposes than in DNS, implementors are advised not to enable processing of these bits in an LLMNR implementation starting from a DNS code base. RCODE Response code -- this 4 bit field is set as part of LLMNR responses. In an LLMNR query, the RCODE MUST be zero, and is ignored by the responder. The response to a multicast LLMNR query MUST have RCODE set to zero. A sender MUST silently discard an LLMNR response with a non-zero RCODE sent in response to a multicast query. If an LLMNR responder is authoritative for the name in a multicast query, but an error is encountered, the responder SHOULD send an LLMNR response with an RCODE of zero, no RRs in the answer section, and the TC bit set. This will cause the query to be resent using TCP, and allow the inclusion of a non-zero RCODE in the response to the TCP query. Responding with the TC bit set is preferrable to not sending a response, since it enables errors to be diagnosed. Since LLMNR responders only respond to LLMNR queries for names for which they are authoritative, LLMNR responders MUST NOT respond with an RCODE of 3; instead, they should not respond at all. LLMNR implementations MUST support EDNS0 [RFC2671] and extended RCODE values. QDCOUNT An unsigned 16 bit integer specifying the number of entries in the question section. A sender MUST place only one question into the question section of an LLMNR query. LLMNR responders MUST silently discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders MUST silently discard LLMNR responses with QDCOUNT not equal to one. ANCOUNT An unsigned 16 bit integer specifying the number of resource records in the answer section. LLMNR responders MUST silently discard LLMNR queries with ANCOUNT not equal to zero. NSCOUNT An unsigned 16 bit integer specifying the number of name server resource records in the authority records section. Authority record section processing is described in Section 2.9. ARCOUNT An unsigned 16 bit integer specifying the number of resource records in the additional records section. Additional record section processing is described in Section 2.9." Delete the following sentence from Section 2.2: "An LLMNR query is composed in exactly the same manner and with the same packet format as a DNS query. " Delete the following sentence from Section 2.3: "A response to an LLMNR query is composed in exactly the same manner and with the same packet format as a response to a DNS query. " Add the following to the IANA considerations section 6: "This specification creates one new name space: the reserved bits in the LLMNR header. These are allocated by IETF Consensus, in accordance with BCP 26 [RFC2434]." Add the following to the normative reference section: [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2845] Vixie, P., et al., "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001. -------------------------------------------------------------------------- Issue 59: Miscellaneous Issues Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: December 17, 2003 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02305.html Document: LLMNR-27 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The draft could benefit from addition of a section gathering in one place all the requirements relating to the use of the DNS packet format for LLMNR. For example, use of the TC bit is not defined and neither are the AD and CD bits (which I assume are set to zero). In Section 2.2, change: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone root." To: "In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone appex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone appex." In Section 2.2, change: "Responders SHOULD respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." To: "Responders MUST respond to LLMNR queries for names and addresses they are authoritative for. This applies to both forward and reverse lookups." Add the following paragraph to Section 2.2: "Upon configuring an IP address responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR as well; the SOA RR MUST NOT be the only RR that a responder has. However, in general whether RRs are manually or automatically created is an implementation decision." Change Section 2.7 from: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 0 is recommended in highly dynamic environments (such as mobile ad-hoc networks). In less dynamic environments, LLMNR traffic can be reduced by setting the TTL to a higher value. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." To: "The responder should use a pre-configured TTL value in the records returned in the LLMNR query response. A default value of 30 seconds is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc networks), the TTL value may need to be reduced. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 20 11:11: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 LAA08521 for ; Tue, 20 Jan 2004 11:11:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AiyIg-000H3e-Bx for namedroppers-data@psg.com; Tue, 20 Jan 2004 16:00:22 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AiyIS-000H1W-K6 for namedroppers@ops.ietf.org; Tue, 20 Jan 2004 16:00:08 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0KGEVN08669 for ; Tue, 20 Jan 2004 08:14:31 -0800 Date: Tue, 20 Jan 2004 08:14:31 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Proposed Resolution to LLMNR issue 63: Miscellaneous NITs (part 3) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The text of LLMNR Issue 63 is enclosed below. The proposed fix is as follows: Change "appex" to "apex" throughout the document. Add the following definition of "reachable" to Section 1.2: "An address is considered reachable over a link if either an ARP or neighbor discovery cache entry exists for the address on the link." In section 2, change: "Enabling LLMNR for use in situations where a DNS server has been configured will result in a change in default behavior without a simultaneous update to configuration information." To: "Enabling LLMNR for use in situations where a DNS server has been configured will result in a change in default behavior without a simultaneous update to configuration information." In Section 3,.1, change: " The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option for DHCP [RFC2937]." To: " The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option (NSSO) for DHCP [RFC2937], using the LLMNR Enable Option code carried in the NSSO data." In Section 2.3, add: "For example, a host configured to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: host1. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 host1.example.com. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 1.1.1.10.in-addr.arpa. IN PTR host1. IN PTR host1.example.com. 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN PTR host1. IN PTR host1.example.com An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1." and "host1.example.com." records." ------------------------------------------------------------------------ Issue 63: Miscellaneous NITs (Part 3) Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: January 9, 2004 Reference: Document: LLMNR-28 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: s/appex/apex/ ? Should "reachable" or "reachable through the link" be included in the terminology section? Section 2, fourth paragraph: what are "upgraded hosts"? Section 3.1, sixth paragraph: if LLMNR is to be configured in the name resolution mechanism through the DHCP Name Service Search Option (NSSO), there has to be some option concerning LLMNR whose option code can be carried in the NSSO data. The discussion about dynamic RTO computation seems OK. I still think it would be useful to include some text about the use of LLMNR when responders are authoritative for names that have only a single component, for example, when the responders are hosts on a home network where users may enter a name with no domain. Here is some text that might fit into section 2.3: For example, a Windows 2000 host configured through the "System Properties" control panel to have computer name "host1" and to be a member of the "example.com" domain, and with IPv4 address 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the following records: host1. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 host1.example.com. IN A 10.1.1.1 IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 1.1.1.10.in-addr.arpa. IN PTR host1. IN PTR host1.example.com. 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN PTR host1. IN PTR host1.example.com An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1" and "host1.example.com" records. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 20 11:53: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 LAA12106 for ; Tue, 20 Jan 2004 11:53:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aiz3X-000MaA-E6 for namedroppers-data@psg.com; Tue, 20 Jan 2004 16:48:47 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aiz3E-000MXR-CZ for namedroppers@ops.ietf.org; Tue, 20 Jan 2004 16:48:28 +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 i0KGmShM002434; Tue, 20 Jan 2004 11:48:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20040120114718.02724db0@localhost> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Tue, 20 Jan 2004 11:48:00 -0500 To: Bernard Aboba , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: Proposed resolution to LLMNR Issue 59: Miscellaneous Issues In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:19 2004-01-20, Bernard Aboba wrote: >The text of LLMNR Issue 59 is enclosed below. I agree that the changes below address all the issues raised by me on this ticket. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 20 15:52: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 PAA21730 for ; Tue, 20 Jan 2004 15:52:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj2j8-000N5s-Pj for namedroppers-data@psg.com; Tue, 20 Jan 2004 20:43:58 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj2it-000N1e-WD for namedroppers@ops.ietf.org; Tue, 20 Jan 2004 20:43:44 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20524; Tue, 20 Jan 2004 15:43:40 -0500 (EST) Message-Id: <200401202043.PAA20524@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-29.txt Date: Tue, 20 Jan 2004 15:43:40 -0500 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.61 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, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-29.txt Pages : 26 Date : 2004-1-20 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-29.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-29.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-29.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-1-20142545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-29.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-29.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-20142545.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 20 16:11: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 QAA24245 for ; Tue, 20 Jan 2004 16:11:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj33f-0000FY-So for namedroppers-data@psg.com; Tue, 20 Jan 2004 21:05:11 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj33S-0000Df-Ip for namedroppers@ops.ietf.org; Tue, 20 Jan 2004 21:04:58 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i0KL4tA0009793 for ; Tue, 20 Jan 2004 22:04:55 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) with ESMTP id i0KL4r8A026253 for ; Tue, 20 Jan 2004 22:04:53 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) id i0KL4rjG026250 for namedroppers@ops.ietf.org; Tue, 20 Jan 2004 22:04:53 +0100 Date: Tue, 20 Jan 2004 22:04:53 +0100 From: Miek Gieben To: namedroppers Subject: proposed text for 'direct nsec queries' Message-ID: <20040120210453.GA26114@atoom.net> Mail-Followup-To: namedroppers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hello, Following up on some discussions on the (tiny) subject of direct queries for NSEC I propose something like the following text to be included in the drafts. [this mail is sent to provoke some discussion] proposed text for protocol-05 Direct Queries for NSEC Records at Delegation Points When the qtype equals NSEC and the qname equals the delegation point of a zone, a problem can pop up when a server is both authoritative for the parent and child. RFC 2535 said that in this case both NSEC's should be returned. It failed to specify how a resolver should treat these two NSEC's. These two records are identical except in their rdata. The child NSEC has the SOA bit set, while the parent has not. Unlike any other RR these two are not a RRset and a resolver must treat them differently from any other RR type. The current spec (2535bis) is silent on this topic and we want to avoid opening a can of worms when specifying this behavior. The current thinking is that direct NSEC queries are never required for the normal operation of the DNS (ie resolving). Another problem is correlated to caches. Depending on the server behavior a cache would either have a child's NSEC or parental NSEC or both. The client can not specify which NSEC it wants. This is also not specified in 2535. For these reasons direct queries for NSEC can not be relied upon, therefor the reply from the server is not specified in this document. Resolvers cannot depend on the data returned in the answer. grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 20 18:11: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 SAA29834 for ; Tue, 20 Jan 2004 18:11:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj4wH-000DWE-TV for namedroppers-data@psg.com; Tue, 20 Jan 2004 23:05:41 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj4w5-000DUJ-9W for namedroppers@ops.ietf.org; Tue, 20 Jan 2004 23:05:29 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0KNJoA01814 for ; Tue, 20 Jan 2004 15:19:50 -0800 Date: Tue, 20 Jan 2004 15:19:50 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR Change Summary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Since the conclusion of DNSEXT WG last call on the LLMNR specification, a number of new issues were submitted. Issue Status report ------------------- Total new issues: 14 Resolved: 14 Open: 0 Disposition ----------- Rejected: 1 (Technical) Accepted: 13 Editorial: 5 Technical: 8 Submitters: Ralph Droms: 6 Bernard Aboba: 5 Tony Hain: 1 Olafur G.: 1 Michael Patton: 1 A summary of the Issues is included below: # Type Title Submitter --- ---- ----- --------- 50 Technical LLMNR-24 Review Ralph Droms 51 Technical Clarity Issues Tony Hain 52 Editorial LLMNR-25 Review Ralph Droms 53 Editorial Miscellaneous NITs-1 Ralph Droms 54 Editorial Comments on -25 Michael Patton 55 Technical Sender checks Bernard Aboba 56 Technical Miscellaneous NITs-2 Ralph Droms 57 Editorial Organizational improv. Bernard Aboba 58 Technical DNS server usage of LLMNR Bernard Aboba 59 Technical Miscellaneous Issues Olafur Gudmundsson 60 Technical Uniqueness check on linkup Ralph Droms 61 Technical Miscellaneous Clarif. Bernard Aboba 62 Reject RCODEs Bernard Aboba 63 Editorial Miscellaneous NITs-3 Ralph Droms Details on the issues and their resolutions is available here: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The latest copy of the specification with all of the changes applied is available here: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-29.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: From owner-namedroppers@ops.ietf.org Tue Jan 20 19:36: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 TAA03602 for ; Tue, 20 Jan 2004 19:36:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj6Hm-000MqD-S6 for namedroppers-data@psg.com; Wed, 21 Jan 2004 00:31:58 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj6HY-000MoM-N8 for namedroppers@ops.ietf.org; Wed, 21 Jan 2004 00:31:44 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i0L0Vht5001957 for ; Wed, 21 Jan 2004 00:31:43 GMT To: namedroppers Subject: Re: proposed text for 'direct nsec queries' In-Reply-To: Message from Miek Gieben of "Tue, 20 Jan 2004 22:04:53 +0100." <20040120210453.GA26114@atoom.net> Date: Wed, 21 Jan 2004 00:31:43 +0000 Message-ID: <1955.1074645103@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Miek, I have a couple of comments on your proposed text. Since we're supposed to be superseding RFC2535, I think the draft should not refer back to something that's effectively dead. This is even more important when we know a corner case is being left unspecified that was also left unspecified in 2535. If 2535 got this wrong, we should take this opportunity to fix it. As part of the overall DNSSEC tidy-up and rewrite, I think some clarity is needed here on (a) what the server should and shouldn't do; and (b) what a resolver is expected to do with that response. If there's a corner case because a server is authoritative for the parent and child, the draft should eliminate it by clearly documenting what the server and resolver should do and shouldn't do for that case. Or at the very least the draft should say what the preferred behaviour is. [And why.] IMO some clarity is needed here: the draft should say what it means and mean what it says. Your proposed text is too fluffy IMO. It could be misinterpreted. That might lead to inconsistences in implementation because it leaves enough wiggle room for a server to do one thing while a resolver does the other. Some of the language you suggested looks bad. It's inappropriate for a standards-track RFC to use phrases like "a can of worms" or "a problem can pop up". Y'know, like, this doesn't read well, man. Know what I mean, dude? Sure, 2535 is a can of worms. But it's one that should get a bullet in the head, if I can mix metaphors. How about the text below? Explicit Queries for NSEC Records at Delegation Points Special consideration will be needed in the case of queries for an NSEC QTYPE when the QNAME is a delegation point and the server is authoritative for both the parent and child zones. In these circumstances the server will have two NSEC records with different RDATA matching the query. One will be from the parent zone for the delegation and the other will be from the child zone. These two NSEC records MUST NOT be treated as an RRset. The server SHOULD (MUST?) return both NSEC records in response to such queries. When NSEC records exist above and below a zone cut for some QNAME, a resolver making an explicit NSEC query cannot specify which of these two NSEC records it wants. Therefore, a resolver which makes an explicit query for an NSEC qtype MUST (SHOULD?) be prepared to receive a response containing both these NSEC records. It cannot know in advance that the QNAME is a delegation point or if the queried server is authoritative for both the parent and child zones. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 20 20:55: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 UAA06157 for ; Tue, 20 Jan 2004 20:55:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aj7T9-0004D5-FJ for namedroppers-data@psg.com; Wed, 21 Jan 2004 01:47:47 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aj7Sn-00048v-5d for namedroppers@ops.ietf.org; Wed, 21 Jan 2004 01:47:25 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id A6B6514C51 for ; Wed, 21 Jan 2004 01:47:24 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: proposed text for 'direct nsec queries' In-Reply-To: Message from Jim Reid of "Wed, 21 Jan 2004 00:31:43 GMT." <1955.1074645103@gromit.rfc1035.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 21 Jan 2004 01:47:24 +0000 Message-Id: <20040121014724.A6B6514C51@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk jim reid wrote: > How about the text below? > > Explicit Queries for NSEC Records at Delegation Points > > Special consideration will be needed in the case of queries for an > NSEC QTYPE when the QNAME is a delegation point and the server is > authoritative for both the parent and child zones. In these > circumstances the server will have two NSEC records with different > RDATA matching the query. One will be from the parent zone for the > delegation and the other will be from the child zone. These two NSEC > records MUST NOT be treated as an RRset. The server SHOULD (MUST?) > return both NSEC records in response to such queries. When NSEC > records exist above and below a zone cut for some QNAME, a resolver > making an explicit NSEC query cannot specify which of these two NSEC > records it wants. Therefore, a resolver which makes an explicit query > for an NSEC qtype MUST (SHOULD?) be prepared to receive a response > containing both these NSEC records. It cannot know in advance that the > QNAME is a delegation point or if the queried server is authoritative > for both the parent and child zones. miek's proposed text was better. (note that miek said it was only draft discussion quality, so it was unfair of jim to question its informality.) there are too many corner cases to cover if we want to define "proper" behaviour for queries at delegation points. for example, what if the reason were that the server had recursion enabled and had thusly cached the above-the-cut NSEC RR? for this reason, a proposal limited to servers who are authoritative for both the parent and child is not useful. miek's proposal is in my opinion the correct one in this circumstance. since there is no protocol necessity for above-the-cut NSEC queries, it is reasonable to specifically undefine them. some servers may decide to answer with delegation responses when queried for anything "at" a delegation point (other than the DS RRset, which may be required due to the grandparent problem). some servers may decide to issue SERVFAIL when queried for NSEC "at" a delegation point. if we place a requirement on it then we have to explain our reasoning and enumerate the cases where our requirement applies. if we just say it's undefined, then we're done. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 21 08:19: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 IAA19347 for ; Wed, 21 Jan 2004 08:19:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjI5v-0008xN-Ko for namedroppers-data@psg.com; Wed, 21 Jan 2004 13:08:31 +0000 Received: from [195.54.233.67] (helo=gromit.rfc1035.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjI5i-0008wi-9K for namedroppers@ops.ietf.org; Wed, 21 Jan 2004 13:08:18 +0000 Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.67]) by gromit.rfc1035.com (8.12.10/8.12.10) with ESMTP id i0LD87t5002459; Wed, 21 Jan 2004 13:08:16 GMT To: Paul Vixie cc: namedroppers Subject: Re: proposed text for 'direct nsec queries' In-Reply-To: Message from Paul Vixie of "Wed, 21 Jan 2004 01:47:24 GMT." <20040121014724.A6B6514C51@sa.vix.com> Date: Wed, 21 Jan 2004 13:08:07 +0000 Message-ID: <2458.1074690487@gromit.rfc1035.com> From: Jim Reid X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Paul" == Paul Vixie writes: Paul> miek's proposed text was better. (note that miek said it Paul> was only draft discussion quality, so it was unfair of jim Paul> to question its informality.) Maybe so. But that discussion would/should lead to agreed text for the draft that goes to last call. More formal language would be needed eventually. That process might as well start as the proposed text is discussed and refined. Paul> there are too many corner cases to cover if we want to Paul> define "proper" behaviour for queries at delegation points. Sigh. I fear there may well be too many corner cases. But IMO that isn't justification for not documenting them. Paul> some servers may decide to issue SERVFAIL when queried for Paul> NSEC "at" a delegation point. This worries me. Something smells very bad -- more than DNSSEC usually smells bad -- if the spec leaves something so wide open that different implementations could return responses as far apart as NOERROR and SERVFAIL for the same query, all other things being equal. Paul> if we place a requirement on it then we Paul> have to explain our reasoning and enumerate the cases where Paul> our requirement applies. if we just say it's undefined, Paul> then we're done. But we'll have done a sloppy job and could well be revisiting the problem in 5-10 year's time. By which time everyone will have forgotten what those cases and requirements were. [And then they'll pop up wackamole-style again, just as they've been doing for the last umpteen years of DNSSEC development.] If the corner cases are known about now, they should at the very least be enumerated and documented. So if the spec is going to say something is undefined, it should say why the behaviour is undefined. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 21 08:39: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 IAA20213 for ; Wed, 21 Jan 2004 08:39:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjIWI-000BHk-IH for namedroppers-data@psg.com; Wed, 21 Jan 2004 13:35:46 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjIW5-000BGl-Vq for namedroppers@ops.ietf.org; Wed, 21 Jan 2004 13:35:34 +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 i0LDYujO023516; Wed, 21 Jan 2004 08:34:56 -0500 (EST) Message-ID: <00f901c3e023$5e9f9620$b9370681@barnacle> From: "Scott Rose" To: Cc: , References: Subject: Re: DNSKEYset in -protocol Section A example Date: Wed, 21 Jan 2004 08:35:00 -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.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You are correct, but I think we may be adding more complexity for very little efficiency. Most DNS admins are not security gurus, so presenting a list of conditionals to go through to determine how many RRSIGs are needed at the keyset would be confusing. If all the other RRsets are signed by both DNSKEYs, why not the DNSKEY RRset? While there is some efficiency, dropping one RRSIG from the zone file (and DNSKEY responses) doesn't gain enough to add more complexity to the signing rules IMHO. However, since this would be a spec change, I cc'd namedroppers. Scott ----- Original Message ----- From: "Sam Weiler" To: Cc: Sent: Wednesday, January 21, 2004 4:24 AM Subject: DNSKEYset in -protocol Section A example > Kind Editors, > > It should only be necessary to sign a DNSKEYset with the DNSKEY(s) > that are intended to be used as SEPs unless there are multiple > algorithms in the DNSKEYset, in which case there must be at least one > RRSIG made by each algorithm. Is there any specific guidance anywhere > about the first part of that requirement? Section 2.2 doesn't address > it specifically. > > Perhaps this could be combined with the one-key-per-zone discussion > and SEP clarifications (see my earlier comments on -protocol section > 2.1). > > I noticed this because the signed zone in -protocol appendix A has its > apex DNSKEYset signed by both of the DNSKEYs. That's not necessarily > wrong, but the text should point out that it isn't necessary. > > -- Sam > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 21 08:51: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 IAA20736 for ; Wed, 21 Jan 2004 08:51:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjIho-000CZp-Pv for namedroppers-data@psg.com; Wed, 21 Jan 2004 13:47:40 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjIhc-000CZ8-30 for namedroppers@ops.ietf.org; Wed, 21 Jan 2004 13:47:28 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i0LDlLA0015095; Wed, 21 Jan 2004 14:47:22 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) with ESMTP id i0LDlIZu005838; Wed, 21 Jan 2004 14:47:18 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.10/8.12.10/Debian-6) id i0LDlIsp005837; Wed, 21 Jan 2004 14:47:18 +0100 Date: Wed, 21 Jan 2004 14:47:18 +0100 From: Miek Gieben To: Paul Vixie Cc: namedroppers Subject: Re: proposed text for 'direct nsec queries' Message-ID: <20040121134718.GA5732@atoom.net> Mail-Followup-To: Paul Vixie , namedroppers References: <1955.1074645103@gromit.rfc1035.com> <20040121014724.A6B6514C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040121014724.A6B6514C51@sa.vix.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 21 Jan, @02:47, Paul wrote in "Re: proposed text for 'direct ..."] > jim reid wrote: > > > How about the text below? > > > > Explicit Queries for NSEC Records at Delegation Points > > > > for an NSEC qtype MUST (SHOULD?) be prepared to receive a response > > containing both these NSEC records. It cannot know in advance that the > > QNAME is a delegation point or if the queried server is authoritative > > for both the parent and child zones. > > miek's proposed text was better. (note that miek said it was only draft > discussion quality, so it was unfair of jim to question its informality.) it was indeed alpha quality :-) The reason to define explicit server behavior would be: "give back what you've got" - property of DNS. But this leads to weird corner cases that also need to be documented, which could lead to even more corner cases. We don't want to go there for these weirdo nsec queries. Therefor I think it is best to define it to 'undefined'. Direct queries for nsec are not part of the normal resolving process. If a resolver _needs_ an nsec it will get the nsec in the answer (as part of a nxdomain respons, for instance). > miek's proposal is in my opinion the correct one in this circumstance. > since there is no protocol necessity for above-the-cut NSEC queries, it > is reasonable to specifically undefine them. some servers may decide > to answer with delegation responses when queried for anything "at" a > delegation point (other than the DS RRset, which may be required due to > the grandparent problem). some servers may decide to issue SERVFAIL or a 'REFUSED'. The only thing resolvers need to know is that nsec queries are special and that answers to those queries can not relied up on. And that nsec's are always alone in a RRset. regards, Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 21 12:59: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 MAA01911 for ; Wed, 21 Jan 2004 12:59:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjMSr-0007tT-SH for namedroppers-data@psg.com; Wed, 21 Jan 2004 17:48:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjMRq-0007mx-45 for namedroppers@ops.ietf.org; Wed, 21 Jan 2004 17:47:26 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 35E1814BBE for ; Wed, 21 Jan 2004 17:47:25 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: proposed text for 'direct nsec queries' In-Reply-To: Message from Jim Reid of "Wed, 21 Jan 2004 13:08:07 GMT." <2458.1074690487@gromit.rfc1035.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 21 Jan 2004 17:47:25 +0000 Message-Id: <20040121174725.35E1814BBE@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul> there are too many corner cases to cover if we want to > Paul> define "proper" behaviour for queries at delegation points. > > Sigh. I fear there may well be too many corner cases. But IMO that > isn't justification for not documenting them. it can be, though, if the corner case you didn't cover ends up being the one that matters to somebody. if you deliberately undefine it, then noone will (sanely) depend on implementation-specific behaviour. > Paul> some servers may decide to issue SERVFAIL when queried for > Paul> NSEC "at" a delegation point. > > This worries me. Something smells very bad -- more than DNSSEC usually > smells bad -- if the spec leaves something so wide open that different > implementations could return responses as far apart as NOERROR and > SERVFAIL for the same query, all other things being equal. it's not the only thing that's deliberately left undefined. if you send a query that makes no sense you will get an answer that makes no sense. consider the "upward referral" problem, where an authority-only server receives a query for a zone it doesn't carry. correct answers range from SERVFAIL to a list of root name servers (which an authority only server might not even have). sometimes the best thing to do is specify the part you care about and explicitly note the unspecificity of the parts you don't care about. asking for NSEC RR's qualifies squarely in this category, and we are indebted to miek for pointing this out. > ... So if the spec is going to say something is undefined, it should > say why the behaviour is undefined. i believe that miek's proposed text does that. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 22 02:37: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 CAA12276 for ; Thu, 22 Jan 2004 02:37:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjZKL-000MEA-NA for namedroppers-data@psg.com; Thu, 22 Jan 2004 07:32:33 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjZK8-000M9H-9c for namedroppers@ops.ietf.org; Thu, 22 Jan 2004 07:32:20 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B9ED996; Thu, 22 Jan 2004 16:32:17 +0900 (JST) References: <200312180654.hBI6sOdH023644@birch.ripe.net> Cc: dnssec-editors@east.isi.edu In-Reply-To: Your message of "Thu, 18 Dec 2003 07:54:24 +0100" <200312180654.hBI6sOdH023644@birch.ripe.net> Subject: Re: WGLC on DNSSEC bis document set To: namedroppers@ops.ietf.org X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Thu, 22 Jan 2004 16:32:17 +0900 Message-Id: <20040122073217.B9ED996@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > draft-ietf-dnsext-dnssec-intro-08 > draft-ietf-dnsext-dnssec-records-06 sorry that i did not meet the last-call deadline. will try to go throgh draft-ietf-dnsext-dnssec-protocoo-04 soon. itojun intro-08 3. or 4. you may want to enumerate what "most of the threats" are solved, or not solved - dnsext-dns-threats have the following sections (dnsext-dns-threats section 3 does not apply here as section 3 analyzes old-DNSSEC), and it is not easy to relate topics in intro-08 to each item. 2. Known Threats 2.1. Packet Interceptionu 2.2. ID Guessing and Query Prediction 2.3. Name Gamesco' 2.4. Betrayal By Trusted Serversu 2.5. Denial of Servicenda! 2.6. Authenticated Denial of Domain Names records-06 1.3.1 i think it fine to move DSA to OPTIONAL. records-06 2, 3, 4 "The xxxx RR is class independent" - which class should I use then? (I assume it to be "IN" but there's no guidance) records-06 2.1.1 by "Bit X" do you mean 2^X ("bit 0" is LSB), or 2^(16-X) ("bit 0" is MSB)? there's no definition given. maybe it is better to put these bits into diagram (2.1). records-06 2.2 description on Flag field seems too restrictive; isn't there any chance that Flag field be 1? i think it better to state "The Flag field MUST be represented as an unsigned decimal integer" (e.g. no example values). records-06 3.1.5 description of signature expiration/inception field is a bit confusing. for instance, when expiration is smaller than inception (like expiration = 1 and inception = 2^32 - 1), expiration field is not the number of seconds since 1970/1/1, but 2^32 more. what happens when 2^32 seconds have passed? (year 2106) maybe it's better to have these fields 64bit, or have scaling parameter like TCP window scaling option? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 22 11:32: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 LAA27447 for ; Thu, 22 Jan 2004 11:32:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ajhdv-0003OX-1M for namedroppers-data@psg.com; Thu, 22 Jan 2004 16:25:19 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajhdg-0003Mt-2W for namedroppers@ops.ietf.org; Thu, 22 Jan 2004 16:25:04 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i0MGPBV8003620 for ; Thu, 22 Jan 2004 11:25:11 -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 i0MGPBCt003619 for namedroppers@ops.ietf.org; Thu, 22 Jan 2004 11:25:11 -0500 (EST) Received: from [129.188.136.7] (helo=motgate7.mot.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajgvq-000P1A-Dt for namedroppers@ops.ietf.org; Thu, 22 Jan 2004 15:39:46 +0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id i0MFbOnD029674 for ; Thu, 22 Jan 2004 08:37:25 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i0MFbRWO001770 for ; Thu, 22 Jan 2004 09:37:28 -0600 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 22 Jan 2004 10:39:41 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF2381037F33DC@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: namedroppers@ops.ietf.org Cc: dnssec-editors@east.isi.edu Subject: RE: WGLC on DNSSEC bis document set Date: Thu, 22 Jan 2004 10:39:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I think it is clear if you actually go look at the serial number arithmetic RFC; however it would probably be helpful to change Signature Expiration and Inception field values are in POSIX.1 time format: a 32-bit unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. to Signature Expiration and Inception field values are POSIX.1 time format modulo 2**32: the least significant 32-bits of the number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. Since I believe that signature validity periods will rarely be even as long as one year, there is no need to waste bits by expanding these fields to 64 bits or to lose the one second resolution by scaling them. This is an instance where "serial number arithmetic" with a resolution of one second works well. Thanks, Donald -----Original Message----- From: owner-dnssec-editors@east.isi.edu [mailto:owner-dnssec-editors@east.isi.edu] On Behalf Of itojun@iijlab.net Sent: Thursday, January 22, 2004 2:32 AM To: namedroppers@ops.ietf.org Cc: dnssec-editors@east.isi.edu Subject: Re: WGLC on DNSSEC bis document set records-06 3.1.5 description of signature expiration/inception field is a bit confusing. for instance, when expiration is smaller than inception (like expiration = 1 and inception = 2^32 - 1), expiration field is not the number of seconds since 1970/1/1, but 2^32 more. what happens when 2^32 seconds have passed? (year 2106) maybe it's better to have these fields 64bit, or have scaling parameter like TCP window scaling option? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 22 21:12:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24743 for ; Thu, 22 Jan 2004 21:12:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjqgS-000FAE-Iy for namedroppers-data@psg.com; Fri, 23 Jan 2004 02:04:32 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ajqg4-000F8v-GI for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 02:04:08 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 40DE089; Fri, 23 Jan 2004 11:04:05 +0900 (JST) To: Donald.Eastlake@motorola.com Cc: namedroppers@ops.ietf.org, dnssec-editors@east.isi.edu Subject: RE: WGLC on DNSSEC bis document set In-Reply-To: Your message of "Thu, 22 Jan 2004 10:39:41 -0500" <62173B970AE0A044AED8723C3BCF2381037F33DC@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF2381037F33DC@ma19exm01.e6.bcs.mot.com> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 From: itojun@iijlab.net Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040123020405.40DE089@coconut.itojun.org> Date: Fri, 23 Jan 2004 11:04:05 +0900 (JST) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I think it is clear if you actually go look at the serial number arithmetic RFC; > however it would probably be helpful to change > > Signature Expiration and Inception field values are in POSIX.1 time > format: a 32-bit unsigned number of seconds elapsed since 1 January > 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. > > to > > Signature Expiration and Inception field values are POSIX.1 time > format modulo 2**32: the least significant 32-bits of the number of > seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap > seconds, in network byte order. > > Since I believe that signature validity periods will rarely be even as > long as one year, there is no need to waste bits by expanding these > fields to 64 bits or to lose the one second resolution by scaling them. > This is an instance where "serial number arithmetic" with a resolution > of one second works well. based on what i get from protocol-04 page 28, expiration/inception field will be compared to wall clock of resolver, therefore DNSSEC baesd on the current packet format will not work after year 2106. so i think it necessary to address "after year 2106" issue by some way. there are multiple possibilities: - expand the field to 64bits - scaling (trade lifetime with resolution) - anything else? itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 23 06:21: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 GAA24630 for ; Fri, 23 Jan 2004 06:21:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AjzJ9-000LJz-9F for namedroppers-data@psg.com; Fri, 23 Jan 2004 11:17:03 +0000 Received: from [193.0.2.44] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AjzIw-000LI6-Ld for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 11:16:50 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id AA1491D7841 for ; Fri, 23 Jan 2004 12:16:49 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Conclusion WGLC NSEC++ Date: Fri, 23 Jan 2004 12:16:49 +0100 X-Mailer: Apple Mail (2.609) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear colleagues, This a conclusion of the WGLC on draft-ietf-dnsext-nsec-rdata-03.txt as issued 22nd of December 2003. (http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02322.html) The last call did raise a number of editorial issues but there where no comments on the technical specifications. The specification of the representation of the available type codes in the NSEC RDATA will be incorporated into the DNSSECbis document set. The document editor will incorporate the editorial comments and publish that document for review. If during a period of 2 weeks after publication of the new version of the I-D no new editorial comments are received the document will be forwarded to the IESG. --Olaf Kolkman DNSEXT 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: From owner-namedroppers@ops.ietf.org Fri Jan 23 07:28: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 HAA26903 for ; Fri, 23 Jan 2004 07:28:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak0MG-0000ar-38 for namedroppers-data@psg.com; Fri, 23 Jan 2004 12:24:20 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak0M3-0000aU-RC for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 12:24:08 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0NBEbMV011110 for ; Fri, 23 Jan 2004 06:14:38 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAALjaORv; Fri, 23 Jan 04 06:14:26 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0NBFcvR023300 for ; Fri, 23 Jan 2004 06:16:03 -0500 (EST) Date: Fri, 23 Jan 2004 12:15:38 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers Subject: TMM (too many mnemonics) In-Reply-To: <20040121174725.35E1814BBE@sa.vix.com> Message-ID: References: <20040121174725.35E1814BBE@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk RFC2535 allows numbers or mnemonics for the flags and protocol fields in the KEY RR presentation format, but -records drops that for DNSKEY and requires numbers. Was that intentional? -records also allows algorithm mnemonics in the DS presentation format, but RFC3658 only allows numbers (for both the algorithm and digest type fields). Again, was that intentional? To summarize: Field Allowed presentation formats Different? -records RFC2535 RFC3658 (DNS)KEY algorithm either either (DNS)KEY flags number either X (DNS)KEY protocol number either X DS algorithm either number X DS digest number number SIG algorithm either either -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 23 08:02: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 IAA28954 for ; Fri, 23 Jan 2004 08:02:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak0vJ-00047K-Sv for namedroppers-data@psg.com; Fri, 23 Jan 2004 13:00:33 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak0v3-000455-Lz for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 13:00:17 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0NCvPlM017202 for ; Fri, 23 Jan 2004 07:57:25 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAABWaiMH; Fri, 23 Jan 04 07:57:24 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0NCx3TA027011 for ; Fri, 23 Jan 2004 07:59:03 -0500 (EST) Date: Fri, 23 Jan 2004 13:59:03 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers@ops.ietf.org Subject: RE: WGLC on DNSSEC bis document set In-Reply-To: <20040123020405.40DE089@coconut.itojun.org> Message-ID: References: <62173B970AE0A044AED8723C3BCF2381037F33DC@ma19exm01.e6.bcs.mot.com> <20040123020405.40DE089@coconut.itojun.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Most of the items I found during my review of the DNSSECbis documents were either omissions or editorial in nature. I've included a summary below. I don't think any of these are major technical issues -- most are matters which are well understood but incorrectly or inadequately documented. This message is intended mostly as a reference list. I suggest that we start separate threads for each issue that needs discussion (such as the mnemonics message I just end). For several of these items, more extensive discussion has been sent to the editors' list and many more minor nits have been sent to the editors. In -protocol, the DS-13 resolver-side grandparent problem fixes are missing. Section 3.1.4.1 tells servers authoritative for both a zone and its grandparent how to answer a DS query (with NODATA), and section 4.2 tells resolvers to ask the parent zone for the DS, but it doesn't tell resolvers how to find the parent zone. RFC3658 section 2.1.2.2 has the needed closest encloser logic. -protocol needs to discuss the safety property and the resolver-side mandatory algorithm rules (per Mark Andrews' message). I'll post more about this in a separate thread. The docs need to do a better job explaining the DNSKEY->DNSKEY indirection. Intro's diagram (DNSKEY->[DS->DNSKEY]*->RRset) misses it entirely, as pointed out earlier. Intro and/or protocol need to explicitly say that having only a single DNSKEY in a zone works, and there are times when the mention of SEP/ZSK/KSK is confusing and perhaps misleading. As my comments on -intro noted, there are some very messy editorial changes that I think would be wise to complete before advancing that document. David Blacka found a problem with the canonical ordering section in -records (good eye, David!) In -records section 4, just as in the NSEC doc, "authoritative" is not locally defined and may confuse readers. -protocol section 2.2 does the job admirably. I suggest a direct reference from records section 4 to protocol section 2.2. -protocol section 3.2.2 implies that the default is to ignore the CD bit setting, which has the potential to deny data to clients that specifically want unvalidated data. The default should be to honor it (and copy it to outgoing queries). We can allow resolvers to un-set the bit (with a MAY), but need to add lots of Security Considerations text to explain how this might deny service to unsuspecting clients. Furthermore, it should be clarified that a resolver MAY choose to set CD even though the incoming query didn't set it (ie. if the resolver is planning to do validation itself). (Credit to Mark Andrews for this last observation.) -protocol sections 3.2.2 and 4.2 (and perhaps others) say one MUST do something unless local policy is not to. If it's reasonable for local policy to override something, a 2119 MUST doesn't make much sense. (Noticed by workshop participants.) I posted a specific MUST/SHOULD concern to the list re: out-of-date RRSIGs. I previously observed that intro's security considerations doesn't say enough about how DNSSEC can make the DNS more fragile. protocol-05's security considerations actually does that pretty well. I'd like to see more Security Considerations text across the board, but this concern has been addressed. And I just sent a note about mnemonics. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 23 08:10: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 IAA29177 for ; Fri, 23 Jan 2004 08:10:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak12l-0004dP-LK for namedroppers-data@psg.com; Fri, 23 Jan 2004 13:08:15 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak12Z-0004cl-Dc for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 13:08:03 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0ND5A4A017773 for ; Fri, 23 Jan 2004 08:05:10 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAtEayTI; Fri, 23 Jan 04 08:05:10 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0ND6m34027425; Fri, 23 Jan 2004 08:06:48 -0500 (EST) Date: Fri, 23 Jan 2004 14:06:48 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: Mike StJohns cc: namedroppers@ops.ietf.org Subject: Re: prohibiting use of expired RRSIGs In-Reply-To: <6.0.1.1.2.20040116143609.02a21418@localhost> Message-ID: References: <200401050759.i057xSMF006856@birch.ripe.net> <6.0.1.1.2.20040116122716.02c77a08@localhost> <6.0.1.1.2.20040116143609.02a21418@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > MAY be configurable as to whether to accept expired records. If > configurable, SHOULD be > configurable to as to the maximum out of date expired records can be to be > acceptable. And if configurable, MUST default to not accepting expired > records. Much better, but this loses the main sentiment of the original, namely that one MUST NOT or SHOULD NOT use out-of-date (expired or not yet active) RRSIGs. The text above would allow a non-configurable resolver to accept out-of-date records. I have a broader proposal, which I'm about to post. -- Sam -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 23 08:46: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 IAA00321 for ; Fri, 23 Jan 2004 08:46:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak1a3-0007WQ-N2 for namedroppers-data@psg.com; Fri, 23 Jan 2004 13:42:39 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak1Zr-0007Ti-9g for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 13:42:27 +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 i0NDg5jO017952; Fri, 23 Jan 2004 08:42:05 -0500 (EST) Message-ID: <00da01c3e1b6$b17099f0$b9370681@barnacle> From: "Scott Rose" To: "Samuel Weiler" , "namedroppers" References: <20040121174725.35E1814BBE@sa.vix.com> Subject: Re: TMM (too many mnemonics) Date: Fri, 23 Jan 2004 08:42:06 -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.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I do not seem to recall any discussion on the list about dropping the mnemonic option in the presentation format. Someone please correct me if I am wrong. Is there an objection to allowing the algorithm mnemonic in the presentation formats of the DS/RRSIG and DNSKEY RRs? Since there is only one protocol value now (3), I feel the mnemonics for that field could be safely dropped. Scott ----- Original Message ----- From: "Samuel Weiler" To: "namedroppers" Sent: Friday, January 23, 2004 6:15 AM Subject: TMM (too many mnemonics) > RFC2535 allows numbers or mnemonics for the flags and protocol fields > in the KEY RR presentation format, but -records drops that for DNSKEY > and requires numbers. Was that intentional? > > -records also allows algorithm mnemonics in the DS presentation > format, but RFC3658 only allows numbers (for both the algorithm and > digest type fields). Again, was that intentional? > > To summarize: > > Field Allowed presentation formats Different? > -records RFC2535 RFC3658 > (DNS)KEY algorithm either either > (DNS)KEY flags number either X > (DNS)KEY protocol number either X > DS algorithm either number X > DS digest number number > SIG algorithm either either > > -- Sam > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 23 10:53: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 KAA06477 for ; Fri, 23 Jan 2004 10:53:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak3ZP-000JfM-Bp for namedroppers-data@psg.com; Fri, 23 Jan 2004 15:50:07 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak3ZC-000Jd4-A0 for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 15:49:54 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i0NFnrV8014980 for ; Fri, 23 Jan 2004 10:49:53 -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 i0NFnr8G014979 for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 10:49:53 -0500 (EST) Received: from [204.152.187.5] (helo=farside.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak3Kz-000ISz-TI for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 15:35:13 +0000 Received: by farside.isc.org (Postfix, from userid 10265) id AD252A82B; Fri, 23 Jan 2004 15:35:13 +0000 (UTC) Date: Fri, 23 Jan 2004 15:35:13 +0000 From: Suzanne Woolf To: namedroppers@ops.ietf.org Subject: DNSSECbis last call workshop -- summary Message-ID: <20040123153513.GB67664@farside.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 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. ] Greetings, As noted to the list, a "DNSSECbis last call" workshop was sponsored this week in Amsterdam by NLnet Labs, ISC, and RIPE NCC. Activities included testing of DNSSEC features in two independent authoritative server implementations and detailed analysis and discussion of the current DNSSEC protocol draft (draft-ietf-dnsext-dnssec-protocol-04.txt). * The operational tests conducted in the workshop found that the core DNSSEC features have been implemented and function as expected. Basic functional tests raised no new corner cases or other protocol issues for either implementation used. * A number of editorial issues with the documents were identified. Those that qualify as "nits" are being sent directly to the DNSSECbis-editors, several of whom were present at the workshop. * Some more extensive editorial work was also identified. This is primarily in the areas of more detailed justifications of MUSTs and SHOULDs, missing or incomplete definitions, and other clarifications in the specification for the benefit of implementors. These were not protocol changes or significant areas for new protocol specification. Individual participants will raise these concerns on namedroppers. * A couple of issues were identified that are substantive enough to need working group consensus for changes to the documents. These will be brought to the working group in the near future, in separate messages as coordinated by the chair. In summary, however, the issues identified were weaknesses in the documents, not significant problems with the specification. The workshop result was that the protocol is functionally complete. At risk of speaking for others, it seems that when the documents are revised to address the concerns raised, participants will be ready to support advancing them to the IESG. Suzanne Workshop participants, alphabetically: Jaap Akkerhuis, Mark Andrews, Roy Arends, David Blacka, Cagri Coltekin, Joao Damas, Miek Gieben, Johan Ihren, Olaf Kolkman, Matt Larson, David Lawrence, Ed Lewis, Ted Lindgreen, Bill Manning, Daniel Massey, Erik Rozendaal, Jakob Schlyter, Sam Weiler and Suzanne Woolf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 23 11:19: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 LAA09408 for ; Fri, 23 Jan 2004 11:19:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak3ye-000Lrp-5V for namedroppers-data@psg.com; Fri, 23 Jan 2004 16:16:12 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak3yJ-000LqP-Ny for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 16:15:51 +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 i0NGFiV9015142; Fri, 23 Jan 2004 11:15:44 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20040123110508.0261f5a0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 23 Jan 2004 11:15:23 -0500 To: Suzanne Woolf , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: Re: DNSSECbis last call workshop -- summary In-Reply-To: <20040123153513.GB67664@farside.isc.org> References: <20040123153513.GB67664@farside.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:35 2004-01-23, Suzanne Woolf wrote: > [ 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. ] > > >Greetings, > >As noted to the list, a "DNSSECbis last call" workshop was sponsored >this week in Amsterdam by NLnet Labs, ISC, and RIPE NCC. Activities >included testing of DNSSEC features in two independent authoritative >server implementations and detailed analysis and discussion of the >current DNSSEC protocol draft >(draft-ietf-dnsext-dnssec-protocol-04.txt). >In summary, however, the issues identified were weaknesses in the >documents, not significant problems with the specification. The >workshop result was that the protocol is functionally complete. At >risk of speaking for others, it seems that when the documents are >revised to address the concerns raised, participants will be ready to >support advancing them to the IESG. > On behalf of the working group, I would like to thank RIPE NCC for hosting this workshop and all the participants for their valuable contributions of time and effort. The outcome of this workshop is a proof that we are finally close to having good DNSSECbis documents as well as two working DNSSEC implementations. Many of the nits raised in the WS and on the mailing lists, have already been addressed in the working versions of the documents. DNSSECbis WGLC formally ends today but keep the comments coming. Olafur DNSEXT 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: From owner-namedroppers@ops.ietf.org Fri Jan 23 12:05: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 MAA11533 for ; Fri, 23 Jan 2004 12:05:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak4g2-000P8m-IW for namedroppers-data@psg.com; Fri, 23 Jan 2004 17:01:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak4fq-000P8B-Jp for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 17:00:50 +0000 Received: from ENGILL.ogud.com (ns.md.ogud.com [10.20.30.6] (may be forged)) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i0NH0nV9015290 for ; Fri, 23 Jan 2004 12:00:49 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <6.0.1.1.2.20040123115338.0261fec0@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 23 Jan 2004 12:00:26 -0500 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: LLMNR is done (RE: LLMNR Change Summary) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The editor of LLMNR has posted a summary of all changes made since the WGLC started. All issues have been addressed. If no issues are raised with the current version, the chairs will advance the document to the IESG next Friday Jan 30'th 2004. Message from editor: http://psg.com/lists/namedroppers/namedroppers.2004/msg00054.html >Details on the issues and their resolutions is available here: > >http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html > >The latest copy of the specification with all of the changes applied is >available here: > >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-29.txt Olafur & 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: From owner-namedroppers@ops.ietf.org Fri Jan 23 12:07: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 MAA11708 for ; Fri, 23 Jan 2004 12:07:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ak4iw-000PL3-Ku for namedroppers-data@psg.com; Fri, 23 Jan 2004 17:04:02 +0000 Received: from [66.92.146.160] (helo=ogud.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak4ii-000PJz-HY for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 17:03:48 +0000 Received: from hlid.md.ogud.com (localhost [127.0.0.1]) by ogud.com (8.12.8p2/8.12.8) with ESMTP id i0NH3lV8015317 for ; Fri, 23 Jan 2004 12:03:47 -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 i0NH3ldE015316 for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 12:03:47 -0500 (EST) Received: from [129.188.136.101] (helo=ftpbox.mot.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Ak4CI-000MwW-7b for namedroppers@ops.ietf.org; Fri, 23 Jan 2004 16:30:18 +0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i0NGUFmq008263 for ; Fri, 23 Jan 2004 09:30:16 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i0NGTh7L005519 for ; Fri, 23 Jan 2004 10:29:44 -0600 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 23 Jan 2004 11:30:12 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF2381037F33ED@ma19exm01.e6.bcs.mot.com> From: Eastlake III Donald-LDE008 To: "'itojun@iijlab.net'" Cc: namedroppers@ops.ietf.org, dnssec-editors@east.isi.edu Subject: RE: WGLC on DNSSEC bis document set Date: Fri, 23 Jan 2004 11:30:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 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. ] Where protocol-04 says o The resolver's notion of the current time MUST be less than or equal to the time listed in the RRSIG RR's Expiration field; o The resolver's notion of the current time MUST be greater than or equal to the time listed in the RRSIG RR's Inception field; perhaps "using serial number arithmetic" should be inserted into each of these two points for clarity. This solves the problem you see. Donald -----Original Message----- From: itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: Thursday, January 22, 2004 9:04 PM To: Eastlake III Donald-LDE008 Cc: namedroppers@ops.ietf.org; dnssec-editors@east.isi.edu Subject: RE: WGLC on DNSSEC bis document set > I think it is clear if you actually go look at the serial number arithmetic RFC; > however it would probably be helpful to change > > Signature Expiration and Inception field values are in POSIX.1 time > format: a 32-bit unsigned number of seconds elapsed since 1 January > 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. > > to > > Signature Expiration and Inception field values are POSIX.1 time > format modulo 2**32: the least significant 32-bits of the number of > seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap > seconds, in network byte order. > > Since I believe that signature validity periods will rarely be even as > long as one year, there is no need to waste bits by expanding these > fields to 64 bits or to lose the one second resolution by scaling them. > This is an instance where "serial number arithmetic" with a resolution > of one second works well. based on what i get from protocol-04 page 28, expiration/inception field will be compared to wall clock of resolver, therefore DNSSEC baesd on the current packet format will not work after year 2106. so i think it necessary to address "after year 2106" issue by some way. there are multiple possibilities: - expand the field to 64bits - scaling (trade lifetime with resolution) - anything else? itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Jan 23 19:47: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 TAA05341 for ; Fri, 23 Jan 2004 19:47:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkBtU-0009wT-Mv for namedroppers-data@psg.com; Sat, 24 Jan 2004 00:43:24 +0000 Received: from [81.200.64.181] (helo=shell-ng.nominum.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkBtI-0009vs-8J for namedroppers@ops.ietf.org; Sat, 24 Jan 2004 00:43:12 +0000 Received: by shell-ng.nominum.com (Postfix, from userid 10014) id 489325683D; Fri, 23 Jan 2004 16:43:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by shell-ng.nominum.com (Postfix) with ESMTP id 45FA456824; Fri, 23 Jan 2004 16:43:11 -0800 (PST) Date: Fri, 23 Jan 2004 16:43:11 -0800 (PST) From: Brian Wellington To: Scott Rose Cc: namedroppers Subject: Re: TMM (too many mnemonics) In-Reply-To: <00da01c3e1b6$b17099f0$b9370681@barnacle> Message-ID: <20040123164050.T54457@shell-ng.nominum.com> References: <20040121174725.35E1814BBE@sa.vix.com> <00da01c3e1b6$b17099f0$b9370681@barnacle> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 23 Jan 2004, Scott Rose wrote: > I do not seem to recall any discussion on the list about dropping the > mnemonic option in the presentation format. Someone please correct me if I > am wrong. Is there an objection to allowing the algorithm mnemonic in the > presentation formats of the DS/RRSIG and DNSKEY RRs? > > Since there is only one protocol value now (3), I feel the mnemonics for > that field could be safely dropped. This sounds like an argument for dropping the field, not dropping support for mnemonics. If there's only one value, it shouldn't exist at all. Having a field whose only legal value is '3' is confusing. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jan 25 17:36: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 RAA20000 for ; Sun, 25 Jan 2004 17:36:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akskx-0006w9-8C for namedroppers-data@psg.com; Sun, 25 Jan 2004 22:29:27 +0000 Received: from [192.94.214.100] (helo=nutshell.tislabs.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Akskk-0006vO-DD for namedroppers@ops.ietf.org; Sun, 25 Jan 2004 22:29:14 +0000 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i0PMQKxV004291 for ; Sun, 25 Jan 2004 17:26:20 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVnaqyi; Sun, 25 Jan 04 17:26:20 -0500 Received: from localhost (weiler@localhost) by filbert.tislabs.com (8.12.9/8.12.9) with ESMTP id i0PMS02P017685 for ; Sun, 25 Jan 2004 17:28:00 -0500 (EST) Date: Sun, 25 Jan 2004 23:28:00 +0100 (CET) From: Samuel Weiler X-X-Sender: weiler@filbert To: namedroppers Subject: Re: TMM (too many mnemonics) In-Reply-To: Message-ID: References: <20040121174725.35E1814BBE@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk After thinking about this more, I like the choices made by -records now and, even though they are changes, I suggest we adopt them. The DNSKEY flags mnemonic scheme is acrane. The BIND signing tools don't generate DNSKEYs with flags or protocol mnemonics, and I have yet to hear any of us whine. I suggest that we drop those. For the algorithm field, I'd like for DS, RRSIG, and DNSKEY to be consistent. Having spent some time arguing about algorithm mnemonics for the TCR document, I have a bit of a personal attachment to them, and I'd like to see them stay. If someone would be so kind as to dig through the DS discussion from ages past and see why mnemonics were dropped, that might be useful to us now. --- Sam > RFC2535 allows numbers or mnemonics for the flags and protocol fields > in the KEY RR presentation format, but -records drops that for DNSKEY > and requires numbers. Was that intentional? > > -records also allows algorithm mnemonics in the DS presentation > format, but RFC3658 only allows numbers (for both the algorithm and > digest type fields). Again, was that intentional? > > To summarize: > > Field Allowed presentation formats Different? > -records RFC2535 RFC3658 > (DNS)KEY algorithm either either > (DNS)KEY flags number either X > (DNS)KEY protocol number either X > DS algorithm either number X > DS digest number number > SIG algorithm either either -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jan 25 20:37: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 UAA29206 for ; Sun, 25 Jan 2004 20:37:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Akvcs-000LSm-6q for namedroppers-data@psg.com; Mon, 26 Jan 2004 01:33:18 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AkvcW-000LPu-MJ for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 01:32:56 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5DE7A1476B for ; Mon, 26 Jan 2004 01:32:56 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers Subject: Re: TMM (too many mnemonics) In-Reply-To: Message from Samuel Weiler of "Sun, 25 Jan 2004 23:28:00 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 26 Jan 2004 01:32:56 +0000 Message-Id: <20040126013256.5DE7A1476B@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > After thinking about this more, I like the choices made by -records > now and, even though they are changes, I suggest we adopt them. as long as this doesn't set a precedent whereby all small changes which are improvements are also accepted (which is infinite regress for dnssec) i agree. > The DNSKEY flags mnemonic scheme is acrane. The BIND signing tools > don't generate DNSKEYs with flags or protocol mnemonics, and I have > yet to hear any of us whine. I suggest that we drop those. for the record, if bind ends up being wrong, we would fix it immediately. what i mean is, the above indicates an oversight, not intention, by isc. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Jan 25 20:52: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 UAA29623 for ; Sun, 25 Jan 2004 20:52:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AkvsH-000MeW-NI for namedroppers-data@psg.com; Mon, 26 Jan 2004 01:49:13 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1Akvs3-000McH-FJ for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 01:48:59 +0000 Received: (qmail 98871 invoked from network); 26 Jan 2004 01:59:44 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2004 01:59:44 -0000 Message-ID: <4014724F.7080906@necom830.hpcl.titech.ac.jp> Date: Mon, 26 Jan 2004 10:50:07 +0900 From: Masataka Ohta 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: Samuel Weiler CC: Mike StJohns , namedroppers@ops.ietf.org Subject: Re: prohibiting use of expired RRSIGs References: <200401050759.i057xSMF006856@birch.ripe.net> <6.0.1.1.2.20040116122716.02c77a08@localhost> <6.0.1.1.2.20040116143609.02a21418@localhost> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Samuel Weiler; >>MAY be configurable as to whether to accept expired records. If >>configurable, SHOULD be >>configurable to as to the maximum out of date expired records can be to be >>acceptable. And if configurable, MUST default to not accepting expired >>records. > > > Much better, but this loses the main sentiment of the original, > namely that one MUST NOT or SHOULD NOT use out-of-date (expired or > not yet active) RRSIGs. The text above would allow a non-configurable > resolver to accept out-of-date records. Allowing an insecure option is not appropriate. If a protocol is allowed to be operated with less security, most people will do so and still believes they have advertised (full) security. It seems to me that the problem is that people recognizes it essentially impossible to deploy DNSSEC. As a result, requirements in protocol specification is reduced to make DNSSEC not really secure. But, it does not really address the problem and only to make the result useless. 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: From owner-namedroppers@ops.ietf.org Mon Jan 26 01:49:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09107 for ; Mon, 26 Jan 2004 01:49:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al0Tg-0003k1-FW for namedroppers-data@psg.com; Mon, 26 Jan 2004 06:44:08 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al0TU-0003jE-1F for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 06:43:56 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 6252AB4; Mon, 26 Jan 2004 15:43:54 +0900 (JST) To: ogud@ogud.com Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR is done (RE: LLMNR Change Summary) In-Reply-To: Your message of "Fri, 23 Jan 2004 12:00:26 -0500" <6.0.1.1.2.20040123115338.0261fec0@localhost> References: <6.0.1.1.2.20040123115338.0261fec0@localhost> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040126064354.6252AB4@coconut.itojun.org> Date: Mon, 26 Jan 2004 15:43:54 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The editor of LLMNR has posted a summary of all changes made since > the WGLC started. All issues have been addressed. > If no issues are raised with the current version, the chairs will advance > the document to the IESG next Friday Jan 30'th 2004. > > Message from editor: > http://psg.com/lists/namedroppers/namedroppers.2004/msg00054.html maybe a stupid question (sorry) - has the interop issue with Apple Rendezvous implementaiton resolved? if not, i don't think the protocol useful. of course both Apple side as well as LLMNR side should make effort to make it interoperable (Apple cannot just force LLMNR be compatible with Rendezvous), in my opinion. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 26 04:09: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 EAA25373 for ; Mon, 26 Jan 2004 04:09:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al2gN-000Ik5-5P for namedroppers-data@psg.com; Mon, 26 Jan 2004 09:05:23 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al2g9-000Ih5-Kf for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 09:05:09 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 0A3994E117; Mon, 26 Jan 2004 10:05:09 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A64D14EC47 for ; Mon, 26 Jan 2004 10:05:08 +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 i0Q9580G010027 for ; Mon, 26 Jan 2004 10:05:08 +0100 Date: Mon, 26 Jan 2004 10:05:08 +0100 From: "Olaf M. Kolkman" To: namedroppers@ops.ietf.org Subject: Conclusion on WGLC DNSSECbis document set. Message-Id: <20040126100508.0dcc64c6.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.119813 X-RIPE-Signature: a04ff09fd9a8f0b1ce8261ce7e7edc37 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear colleagues, This is a conclusion of the WGLC on draft-ietf-dnsext-dnssec-intro-08, draft-ietf-dnsext-dnssec-records-06 and draft-ietf-dnsext-dnssec-protocol-04 as issued Mon, 22 Dec 2003 [1]. The executive summary: The protocol is ready, the documents are not. As mentioned in postings to the list during WGLC and in the report on the work-shop last week in Amsterdam [2], there are a number of editorial nits and issues identified that will need some work by the editors and the working group. Most of them can be identified as unexplained (and or unneeded) MUSTs, SHOULDs or MAYs. Sometimes definitions where not clear. All in all, some of the implicit details will need to be made a little more explicit. How to go forward. The coming days I will try to put new issues (those that are more than just editorial nits) to the list in the forms of questions, this may include issues recently discussed on the list. The questions come with 'default' resolutions. Please raise your voice if the proposed resolutions lead to inconsistencies with other part of the specs, are an example of bad engineering or just plainly wrong. On silence we assume you can live with the proposal and the editors will do further word crafting to merge the resolutions in the specs. Since I would like the editors to try and roll the document set before the final submission cut-off (February 16, 09:00 ET) there will be a week for discussing the issues. The documents will be available for review for some time and we hope to be able to forward the next revision to the IESG around IETF59. -- Olaf Kolkman DNSEXT Co-Chair. [1] WGLC issued in http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02307.html and extended in http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00005.html [2] Workshop report: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00069.html ---------------------------------| 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: From owner-namedroppers@ops.ietf.org Mon Jan 26 09:55: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 JAA07572 for ; Mon, 26 Jan 2004 09:55:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al81v-000Obn-SM for namedroppers-data@psg.com; Mon, 26 Jan 2004 14:47:59 +0000 Received: from [129.6.16.92] (helo=postmark.nist.gov) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al81j-000ObK-Je for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 14:47:47 +0000 Received: from lapdancer (asynce016.nist.gov [129.6.31.16]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id i0QElWjO003936; Mon, 26 Jan 2004 09:47:33 -0500 (EST) Message-ID: <001c01c3fc77$9b88fde0$101f0681@lapdancer> From: "Scott Rose" To: "Samuel Weiler" , "namedroppers" References: <20040121174725.35E1814BBE@sa.vix.com> Subject: Re: TMM (too many mnemonics) Date: Thu, 26 Feb 2004 09:48:32 -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.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_96_XX autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit My guess is the mnemonics were dropped without thinking. No one really uses them, since tools are used to generated, parse, and sign the DNSSEC RRs. No one thought about using mnemonics when numbers worked for machines. Scott ----- Original Message ----- From: "Samuel Weiler" > > For the algorithm field, I'd like for DS, RRSIG, and DNSKEY to be > consistent. Having spent some time arguing about algorithm mnemonics > for the TCR document, I have a bit of a personal attachment to them, > and I'd like to see them stay. If someone would be so kind as to dig > through the DS discussion from ages past and see why mnemonics were > dropped, that might be useful to us now. > > --- Sam > > > RFC2535 allows numbers or mnemonics for the flags and protocol fields > > in the KEY RR presentation format, but -records drops that for DNSKEY > > and requires numbers. Was that intentional? > > > > -records also allows algorithm mnemonics in the DS presentation > > format, but RFC3658 only allows numbers (for both the algorithm and > > digest type fields). Again, was that intentional? > > > > To summarize: > > > > Field Allowed presentation formats Different? > > -records RFC2535 RFC3658 > > (DNS)KEY algorithm either either > > (DNS)KEY flags number either X > > (DNS)KEY protocol number either X > > DS algorithm either number X > > DS digest number number > > SIG algorithm either either > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 26 10:26: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 KAA09548 for ; Mon, 26 Jan 2004 10:26:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al8Zz-0002dO-5J for namedroppers-data@psg.com; Mon, 26 Jan 2004 15:23:11 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al8Zj-0002bN-B5 for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 15:22:55 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 1949414C4F for ; Mon, 26 Jan 2004 15:22:55 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done (RE: LLMNR Change Summary) In-Reply-To: Message from itojun@itojun.org (Jun-ichiro itojun Hagino) of "Mon, 26 Jan 2004 15:43:54 +0900." <20040126064354.6252AB4@coconut.itojun.org> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 26 Jan 2004 15:22:55 +0000 Message-Id: <20040126152255.1949414C4F@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > maybe a stupid question (sorry) - has the interop issue with Apple > Rendezvous implementaiton resolved? if not, i don't think the > protocol useful. of course both Apple side as well as LLMNR side > should make effort to make it interoperable (Apple cannot just force > LLMNR be compatible with Rendezvous), in my opinion. seconded. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 26 11:43: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 LAA12346 for ; Mon, 26 Jan 2004 11:43:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al9mG-000B5q-VM for namedroppers-data@psg.com; Mon, 26 Jan 2004 16:39:56 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al9m4-000B45-Hy for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 16:39:44 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0QGrXY22010 for ; Mon, 26 Jan 2004 08:53:33 -0800 Date: Mon, 26 Jan 2004 08:53:33 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > maybe a stupid question (sorry) - has the interop issue with Apple > Rendezvous implementaiton resolved? if not, i don't think the > protocol useful. of course both Apple side as well as LLMNR side > should make effort to make it interoperable (Apple cannot just > force LLMNR be compatible with Rendezvous), in my opinion. On August 29, 2003 Olaf Kolkman posted the following message to the DNSEXT WG mailing list summarizing the situation: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html In this message, he made the request that *all* changes required to achieve interoperability be provided. No answer was received. Subsequently, I went back over the Rendezvous documents to look at the differences. These go well beyond the TTL and multicast address choices. mDNS and LLMNR have taken different approaches on more than half a dozen different points, many going back to the earliest drafts. The differences are more than cosmetic because the protocols began from different assumptions and problem statements, and evolved in separate ways from the beginning. At this point, the protocols only share some similarities in the use of the DNS packet format, and even here the differences are substantial. To sum up the situation, on October 6, 2003, Olafur posted the following reply: http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01872.html Known differences between Rendezvous and LLMNR ---------------------------------------------- a. Rendezvous uses multicast responses. LLMNR uses unicast. b. Rendezvous allows proxying; LLMNR does not. c. Rendezvous uses the header bits differently, including AA, TC, RD, RA, AD, CD d. Rendezvous and LLMNR uses different retransmission strategies and timers. e. Rendezvous uses ".local" extension, LLMNR does not. f. Rendezvous requires TTL=255; LLMNR uses TTL=1. g. LLMNR supports unicast queries; Rendezvous does not. h. LLMNR and Rendezvous use different multicast addresses and ports. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 26 11:44: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 LAA12545 for ; Mon, 26 Jan 2004 11:44:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Al9kt-000Ata-0W for namedroppers-data@psg.com; Mon, 26 Jan 2004 16:38:31 +0000 Received: from [149.8.64.10] (helo=mclmx.mail.saic.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Al9kg-000Asr-Kf for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 16:38:18 +0000 Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 11:38:02 -0500 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by mcl-its-ieg01.mail.saic.com (SAVSMTP 3.1.2.35) with SMTP id M2004012611380204145 for ; Mon, 26 Jan 2004 11:38:02 -0500 Received: by mcl-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jan 2004 11:38:02 -0500 Message-Id: <4E25ECBBC03F874CBAD03399254ADFDE104E51@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: namedroppers@ops.ietf.org Subject: RE: prohibiting use of expired RRSIGs Date: Mon, 26 Jan 2004 11:36:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Various people had written: > >>MAY be configurable as to whether to accept expired records. If > >>configurable, SHOULD be > >>configurable to as to the maximum out of date expired > records can be to be > >>acceptable. And if configurable, MUST default to not > accepting expired > >>records. > > > > > > Much better, but this loses the main sentiment of the original, > > namely that one MUST NOT or SHOULD NOT use out-of-date (expired or > > not yet active) RRSIGs. The text above would allow a > > non-configurable resolver to accept out-of-date records. > > Allowing an insecure option is not appropriate. > > If a protocol is allowed to be operated with less security, most > people will do so and still believes they have advertised (full) > security. Ohta-san: During the transition from DNS-today to DNS-with-signed-zones, many compromises need to be made that allow for configurability without denying DNS to users. The challenge is doing that in a way that does not lead to long-term security issues with DNSSEC. However, in this case Mike StJohns correctly stated an issue with the language. If Sam revises his language appropriately then that would lead to a workable solution that does not detract from security. Are you sure that you're actually reading the e-mails, rather than just responding to a perceived opportunity to denigrate DNSSEC? > It seems to me that the problem is that people recognizes it > essentially impossible to deploy DNSSEC. It seems to me that it is not "essentially impossible to deploy DNSSEC". It seems to me that there will be some effort required, and I'm not sure that we have all the answers yet--but saying "it's too hard" isn't the best solution to most problems in my personal experience. Do you believe that the postulated threats against DNS (which DNSSEC was designed to address) are not realistic? If so, then that would be an...interesting...opinion to me. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 26 16:59: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 QAA21388 for ; Mon, 26 Jan 2004 16:59:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlEd1-000LPE-HP for namedroppers-data@psg.com; Mon, 26 Jan 2004 21:50:43 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlEcZ-000LMv-3M for namedroppers@ops.ietf.org; Mon, 26 Jan 2004 21:50:15 +0000 Received: (qmail 3428 invoked from network); 26 Jan 2004 22:01:15 -0000 Received: from h219-110-032-093.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.93) by necom830.hpcl.titech.ac.jp with SMTP; 26 Jan 2004 22:01:15 -0000 Message-ID: <40158BDB.6050804@necom830.hpcl.titech.ac.jp> Date: Tue, 27 Jan 2004 06:51:23 +0900 From: Masataka Ohta 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: "Loomis, Rip" CC: namedroppers@ops.ietf.org Subject: Re: prohibiting use of expired RRSIGs References: <4E25ECBBC03F874CBAD03399254ADFDE104E51@US-Columbia-CIST.mail.saic.com> In-Reply-To: <4E25ECBBC03F874CBAD03399254ADFDE104E51@US-Columbia-CIST.mail.saic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rip; > Various people had written: > >>>>MAY be configurable as to whether to accept expired records. If configurable, SHOULD be >>>>configurable to as to the maximum out of date expired records can be to be >>>>acceptable. And if configurable, MUST default to not accepting expired >>>>records. > During the transition from DNS-today to DNS-with-signed-zones, many > compromises need to be made that allow for configurability without > denying DNS to users. The challenge is doing that in a way that > does not lead to long-term security issues with DNSSEC. OK. > However, > in this case Mike StJohns correctly stated an issue with the language. The statement above says nothing about "long-term". Regardless of whatever is the default, configuration to accept expired records will be used widely forever. That DNSSEC needs a lot of configuration means that, during the configuration, administrators are tempted to change some of the default to reduce the rest of the configuration effort. > Are you sure that you're actually reading the e-mails, rather than > just responding to a perceived opportunity to denigrate DNSSEC? You don't read the e-mails literally and assuming impractical assumptions. >>It seems to me that the problem is that people recognizes it >>essentially impossible to deploy DNSSEC. > > > It seems to me that it is not "essentially impossible to deploy > DNSSEC". It seems to me that there will be some effort required, > and I'm not sure that we have all the answers yet--but saying > "it's too hard" isn't the best solution to most problems in my > personal experience. Introducing options means you recognize "it's too hard". > Do you believe that the postulated threats against DNS (which > DNSSEC was designed to address) are not realistic? If so, then > that would be an...interesting...opinion to me. Just before the previous meeting, I posted a solution for small message ID space, though I don't expect you read it. Othere threats are as realistic as DNSSEC zones with compromized keys or DNSSEC resolvers with faked root public keys (or their signatures). 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: From owner-namedroppers@ops.ietf.org Mon Jan 26 20:42:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01332 for ; Mon, 26 Jan 2004 20:42:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlI6t-000MTd-JM for namedroppers-data@psg.com; Tue, 27 Jan 2004 01:33:47 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlI6f-000MSY-H8 for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 01:33:33 +0000 Received: by sa.vix.com (Postfix, from userid 716) id 4107D14C56; Tue, 27 Jan 2004 01:33:33 +0000 (GMT) To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done References: From: Paul Vixie Date: 27 Jan 2004 01:33:33 +0000 In-Reply-To: Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Bernard Aboba writes: > ... > To sum up the situation, on October 6, 2003, Olafur posted the following > reply: > http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01872.html can llmnr and rendezvous be issued in tandem, with applicability statements? -- Paul Vixie -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Jan 26 23:10: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 XAA05585 for ; Mon, 26 Jan 2004 23:10:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlKT4-000Hrd-Ng for namedroppers-data@psg.com; Tue, 27 Jan 2004 04:04:50 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlKSq-000Ho6-VS for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 04:04:36 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id i0R44acb020970 for ; Mon, 26 Jan 2004 20:04:36 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Mon, 26 Jan 2004 20:04:36 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by relay2.apple.com (8.12.10/8.12.9) with SMTP id i0R44aPx022075 for ; Tue, 27 Jan 2004 04:04:36 GMT Message-Id: <200401270404.i0R44aPx022075@relay2.apple.com> Subject: Re: LLMNR is done Date: Mon, 26 Jan 2004 20:04:36 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >On August 29, 2003 Olaf Kolkman posted the following message to the >DNSEXT WG mailing list summarizing the situation: > >http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html > >In this message, he made the request that *all* changes required >to achieve interoperability be provided. No answer was received. Unfortunately, *everything* seems subject to intense debate, even what the list of things to debate is. Before embarking on that debate, I asked if the working group had any interest in working for interoperability with the installed base. No answer was received. >Known differences between Rendezvous and LLMNR I think there are some misperceptions here; I should correct them. >a. Rendezvous uses multicast responses. LLMNR uses unicast. Rendezvous uses both unicast and multicast responses, depending on what is most efficient. If only one client is likely to want a particular response, then unicast is used. If multiple clients are likely to want the response, then multicast is used. >b. Rendezvous allows proxying; LLMNR does not. Sleep proxy servers for power management are an important part of meeting Energy Star and Blue Angel energy consumption requirements. As the limits get tighter and tighter each year, it is going to become increasingly hard to sell products that don't have this kind of intelligent power management. >c. Rendezvous uses the header bits differently, including AA, TC, RD, >RA, AD, CD Can you elaborate? I'm not aware of any substantive differences. >d. Rendezvous and LLMNR uses different retransmission strategies and >timers. Surely these are trivial differences that could be easily agreed. >e. Rendezvous uses ".local" extension, LLMNR does not. This is a red herring. The dot-local debate exists at a layer above Rendezvous/LLMNR. Apple (and others) use dot-local to trigger an explicit multicast query; other names may be looked up according via unicast or multicast depending on situation, just as with LLMNR. >f. Rendezvous requires TTL=255; LLMNR uses TTL=1. The TTL check is, as you know, to guarantee that packets really originated on the local link (*especially* unicast replies). I'm told that in the latest Windows XP Service Pack lots of services have been locked down the local link by default for "security", so I would have thought that having the ability to do the same for LLMNR would have met with Microsoft's approval in the current climate. Note that setting the TTL to 255 allows the receiver to check the TTL; it doesn't *require* the receiver to check if it doesn't want to. >g. LLMNR supports unicast queries; Rendezvous does not. Incorrect. Rendezvous supports unicast queries as well as multicast, and always has. >h. LLMNR and Rendezvous use different multicast addresses and ports. This is the ultimate red herring. They only use different multicast addresses and ports because of perceived differences (a)-(g). So, as I have said before, the only real show-stopping incompatibility I see is the decision on the TTL. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 05:00: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 FAA27400 for ; Tue, 27 Jan 2004 05:00:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlPv9-000BBF-VH for namedroppers-data@psg.com; Tue, 27 Jan 2004 09:54:11 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlPux-000BA3-DV for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 09:53:59 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id B06C1D0; Tue, 27 Jan 2004 18:53:58 +0900 (JST) To: cheshire@apple.com Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR is done In-Reply-To: Your message of "Mon, 26 Jan 2004 20:04:36 -0800" <200401270404.i0R44aPx022075@relay2.apple.com> References: <200401270404.i0R44aPx022075@relay2.apple.com> X-Mailer: Cue version 0.6 (031125-1130/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20040127095358.B06C1D0@coconut.itojun.org> Date: Tue, 27 Jan 2004 18:53:58 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >On August 29, 2003 Olaf Kolkman posted the following message to the > >DNSEXT WG mailing list summarizing the situation: > > > >http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html > > > >In this message, he made the request that *all* changes required > >to achieve interoperability be provided. No answer was received. > > Unfortunately, *everything* seems subject to intense debate, even what > the list of things to debate is. Before embarking on that debate, I asked > if the working group had any interest in working for interoperability > with the installed base. No answer was received. i guess i missed your message - yes, i'd love to see Rendezvous and LLMNR be interoperate (or converge into a single protocol). itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 05:18: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 FAA27870 for ; Tue, 27 Jan 2004 05:18:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlQCk-000Dl8-Qh for namedroppers-data@psg.com; Tue, 27 Jan 2004 10:12:22 +0000 Received: from [203.51.31.28] (helo=cuneata.net) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlQCA-000Dh7-AP for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 10:11:46 +0000 Received: (qmail 19037 invoked from network); 27 Jan 2004 18:14:59 -0000 Received: from pc-00216.cuneata.net (HELO rachel) (192.168.0.216) by squirt.cuneata.net (192.168.0.1) with ESMTP; 27 Jan 2004 18:14:59 -0000 From: Brad Hards To: Stuart Cheshire Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 21:06:51 +1100 User-Agent: KMail/1.5.94 Cc: namedroppers@ops.ietf.org References: <200401270404.i0R44aPx022075@relay2.apple.com> In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200401272106.51872.bhards@bigpond.net.au> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) 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.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 27 Jan 2004 15:04 pm, Stuart Cheshire wrote: > Unfortunately, *everything* seems subject to intense debate, even what > the list of things to debate is. Before embarking on that debate, I asked > if the working group had any interest in working for interoperability > with the installed base. No answer was received. I have interest in interoperability with MacOS and Windows boxes. Unix=20 variants in embedded applications, and Unix variant boxes as clients in mix= ed=20 environments require it. > >Known differences between Rendezvous and LLMNR > > I think there are some misperceptions here; I should correct them. > > >a. Rendezvous uses multicast responses. LLMNR uses unicast. > > Rendezvous uses both unicast and multicast responses, depending on what > is most efficient. If only one client is likely to want a particular > response, then unicast is used. If multiple clients are likely to want > the response, then multicast is used. I don't see this as a fundamental issue. Worst case is we require both=20 multicast and unicast responses, but agreement on which is better in some=20 common cases shouldn't be that hard. > >b. Rendezvous allows proxying; LLMNR does not. > > Sleep proxy servers for power management are an important part of meeting > Energy Star and Blue Angel energy consumption requirements. As the limits > get tighter and tighter each year, it is going to become increasingly > hard to sell products that don't have this kind of intelligent power > management. Again, not fundamental. Add proxying as a MAY, and explain to implementers = the=20 tradeoff. > >c. Rendezvous uses the header bits differently, including AA, TC, RD, > >RA, AD, CD > > Can you elaborate? I'm not aware of any substantive differences. Pass for now. > >d. Rendezvous and LLMNR uses different retransmission strategies and > >timers. > > Surely these are trivial differences that could be easily agreed. Without looking at the detail, I'd have to agree. > >e. Rendezvous uses ".local" extension, LLMNR does not. > > This is a red herring. The dot-local debate exists at a layer above > Rendezvous/LLMNR. Apple (and others) use dot-local to trigger an explicit > multicast query; other names may be looked up according via unicast or > multicast depending on situation, just as with LLMNR. I see .local as a useful scoping approach. Easy to explain to part-time=20 sysadmins too. > >f. Rendezvous requires TTL=3D255; LLMNR uses TTL=3D1. > > The TTL check is, as you know, to guarantee that packets really > originated on the local link (*especially* unicast replies). I'm told > that in the latest Windows XP Service Pack lots of services have been > locked down the local link by default for "security", so I would have > thought that having the ability to do the same for LLMNR would have met > with Microsoft's approval in the current climate. Note that setting the > TTL to 255 allows the receiver to check the TTL; it doesn't *require* the > receiver to check if it doesn't want to. This has been done a time or two (perhaps more). There is no obviously best= =20 way. In this case, we might as well choose the path of least gratuitous=20 breakage. =20 > >g. LLMNR supports unicast queries; Rendezvous does not. > > Incorrect. Rendezvous supports unicast queries as well as multicast, and > always has. We probably should support both.=20 > >h. LLMNR and Rendezvous use different multicast addresses and ports. > > This is the ultimate red herring. They only use different multicast > addresses and ports because of perceived differences (a)-(g). I see it as "self fulfilling requirement". Either we agree a compatible=20 protocol, or we support running both on different mc addresses and ports=20 (optionally with a shared cache). Brad =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFjg7GwwszQ/PZzgRAtNRAJ4iLjOsGi95fppbxwB2dscBQGQSKQCcD+F7 EtZtNjXxToZELkN6ssvI3Aw=3D =3D2HJL =2D----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 05:28: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 FAA28219 for ; Tue, 27 Jan 2004 05:28:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlQOe-000FIN-7T for namedroppers-data@psg.com; Tue, 27 Jan 2004 10:24:40 +0000 Received: from [203.51.31.28] (helo=cuneata.net) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlQOQ-000FDk-H3 for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 10:24:26 +0000 Received: (qmail 19047 invoked from network); 27 Jan 2004 18:27:47 -0000 Received: from pc-00216.cuneata.net (HELO rachel) (192.168.0.216) by squirt.cuneata.net (192.168.0.1) with ESMTP; 27 Jan 2004 18:27:47 -0000 From: Brad Hards To: =?iso-8859-1?q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= Subject: Re: LLMNR is done (RE: LLMNR Change Summary) Date: Tue, 27 Jan 2004 21:19:40 +1100 User-Agent: KMail/1.5.94 Cc: namedroppers@ops.ietf.org References: <6.0.1.1.2.20040123115338.0261fec0@localhost> In-Reply-To: <6.0.1.1.2.20040123115338.0261fec0@localhost> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200401272119.40182.bhards@bigpond.net.au> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS,UPPERCASE_25_50 autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 24 Jan 2004 04:00 am, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > The editor of LLMNR has posted a summary of all changes made since > the WGLC started. All issues have been addressed. > If no issues are raised with the current version, the chairs will advance > the document to the IESG next Friday Jan 30'th 2004. Per the other voices - please don't do this until we have sorted out the=20 interop issues with the MDNS part of Rendezvous. Brad =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFjs8GwwszQ/PZzgRAlYaAJ9UdBXHpUc16mzVMR5oiCn964gHaQCgh2RJ QnfC2Df7AfjduRTtVRcirRU=3D =3DGp7n =2D----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 11:42: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 LAA12532 for ; Tue, 27 Jan 2004 11:42:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlW7d-000Bm5-Mk for namedroppers-data@psg.com; Tue, 27 Jan 2004 16:31:29 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlW7O-000Bk8-NF for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 16:31:14 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id 14D8A4E1F7; Tue, 27 Jan 2004 17:31:14 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id BEB074E0A0 for ; Tue, 27 Jan 2004 17:31:13 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i0RGVC0G022859 for ; Tue, 27 Jan 2004 17:31:12 +0100 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i0RGVCwV019326 for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 17:31:12 +0100 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlVP2-0005l5-Jg for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 15:45:24 +0000 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 9D0541B2F18; Tue, 27 Jan 2004 09:36:42 -0600 (CST) In-Reply-To: <200401272106.51872.bhards@bigpond.net.au> References: <200401270404.i0R44aPx022075@relay2.apple.com> <200401272106.51872.bhards@bigpond.net.au> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Stuart Cheshire , namedroppers@ops.ietf.org From: Ted Lemon Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 09:45:21 -0600 To: Brad Hards X-Mailer: Apple Mail (2.609) X-RIPE-Spam-Status: N 0.498672 X-RIPE-Signature: 0fcf913bc8c036a1e559239a0b8cabb0 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't have anything substantive to add except that I would really, really like to see Rendezvous be able to interoperate with LLMNR. I use Rendezvous a _lot_, it makes a big difference in the usability of my network, and the one big remaining hole right now is that it doesn't work with Windows. :'( I think that resolving the TTL issue in favor of the way Rendezvous does it is a good solution - there are pros and cons to both ways of doing TTL, and in fact it was as a result of debate about this issue with regard to LLMNR that Rendezvous switched to this scheme originally. I've weighed in on this several times in the past - the only reason I've stopped saying anything about it is because I've given up hope in the process - it's seemed recently that there was no interest at all in making LLMNR and Rendezvous interoperate. It sounds like this is not actually the case, and that a lot of other folks have been silent as well, perhaps for the same 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: From owner-namedroppers@ops.ietf.org Tue Jan 27 11:42:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12551 for ; Tue, 27 Jan 2004 11:42:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlW8X-000BvA-3f for namedroppers-data@psg.com; Tue, 27 Jan 2004 16:32:25 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlW7o-000Bnb-Ad for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 16:31:40 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id A72074E4F1; Tue, 27 Jan 2004 17:31:39 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 656654E1F1 for ; Tue, 27 Jan 2004 17:31:39 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i0RGVd0G023106 for ; Tue, 27 Jan 2004 17:31:39 +0100 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i0RGVdnL019338 for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 17:31:39 +0100 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlVQ5-0005w3-Jt for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 15:46:29 +0000 Received: from [10.0.1.2] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 24A021B5D7C; Tue, 27 Jan 2004 09:37:48 -0600 (CST) In-Reply-To: <200401272119.40182.bhards@bigpond.net.au> References: <6.0.1.1.2.20040123115338.0261fec0@localhost> <200401272119.40182.bhards@bigpond.net.au> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= , namedroppers@ops.ietf.org From: Ted Lemon Subject: Re: LLMNR is done (RE: LLMNR Change Summary) Date: Tue, 27 Jan 2004 09:46:25 -0600 To: Brad Hards X-Mailer: Apple Mail (2.609) X-RIPE-Spam-Status: N 0.488638 X-RIPE-Signature: b5ee9d8ca5300aa70644ff1e7dc6bf29 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jan 27, 2004, at 4:19 AM, Brad Hards wrote: >> If no issues are raised with the current version, the chairs will >> advance >> the document to the IESG next Friday Jan 30'th 2004. > Per the other voices - please don't do this until we have sorted out > the > interop issues with the MDNS part of Rendezvous. Right, please let's give this one more chance. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 12:53: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 MAA16342 for ; Tue, 27 Jan 2004 12:53:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlXAp-000Jzc-Cz for namedroppers-data@psg.com; Tue, 27 Jan 2004 17:38:51 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlXAc-000Jy7-IX for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 17:38:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 51E6D14C60 for ; Tue, 27 Jan 2004 17:38:38 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done In-Reply-To: Message from Ted Lemon of "Tue, 27 Jan 2004 09:45:21 CST." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 27 Jan 2004 17:38:38 +0000 Message-Id: <20040127173838.51E6D14C60@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I've weighed in on this several times in the past - the only reason > I've stopped saying anything about it is because I've given up hope in > the process - it's seemed recently that there was no interest at all > in making LLMNR and Rendezvous interoperate. It sounds like this is > not actually the case, and that a lot of other folks have been silent > as well, perhaps for the same reason. :'/ i think aboba's assessment may be accurate, which is that these are different protocols with different applicability statements. if that's true then simply advancing both of them, each with an applicability statement that makes clear why it exists and what its purpose and scope is, is a reasonable approach. for example, i saw a demo where a mac found a desktop printer without either one of them having an ip address, and a mac found an mp3 jukebox without either one of them having an ip address. the chooser/browser widget just came up and showed what it found. is this sufficiently different from llmnr's target and purpose that we can reasonably say that both protocols can be advanced, and both will be in the field, and they are not competing approaches to the same problem space? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 13:40: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 NAA17550 for ; Tue, 27 Jan 2004 13:40:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlXzX-0000Mi-04 for namedroppers-data@psg.com; Tue, 27 Jan 2004 18:31:15 +0000 Received: from [192.18.98.31] (helo=brmea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlXzK-0000LY-Fh for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 18:31:02 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0RIV1bm014982 for ; Tue, 27 Jan 2004 11:31:02 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HS500AWAVFP6R@edgemail1.Central.Sun.COM> for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 11:31:01 -0700 (MST) Received: from sun.com ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HS50043BVFG8J@mail.sun.net> for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 11:30:59 -0700 (MST) Date: Tue, 27 Jan 2004 10:31:51 -0800 From: Alain Durand Subject: Re: LLMNR is done To: Paul Vixie , namedroppers@ops.ietf.org Message-id: <4016AE97.2050606@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <20040127173838.51E6D14C60@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I really have a hard time with the idea that LLMNR & Rendez-vous address different needs. There is so much overlap that, in a normal worl, convergence would be the most sensible avenue. If we, as a collection of vocal individuals, cannot put ego aside and can't converge, please, at least, let's make those two interoperable. - Alain. Paul Vixie wrote: >>I've weighed in on this several times in the past - the only reason >>I've stopped saying anything about it is because I've given up hope in >>the process - it's seemed recently that there was no interest at all >>in making LLMNR and Rendezvous interoperate. It sounds like this is >>not actually the case, and that a lot of other folks have been silent >>as well, perhaps for the same reason. :'/ >> >> > >i think aboba's assessment may be accurate, which is that these are >different protocols with different applicability statements. if that's >true then simply advancing both of them, each with an applicability >statement that makes clear why it exists and what its purpose and scope >is, is a reasonable approach. > >for example, i saw a demo where a mac found a desktop printer without >either one of them having an ip address, and a mac found an mp3 jukebox >without either one of them having an ip address. the chooser/browser >widget just came up and showed what it found. is this sufficiently >different from llmnr's target and purpose that we can reasonably say >that both protocols can be advanced, and both will be in the field, and >they are not competing approaches to the same problem space? > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 13:58: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 NAA18293 for ; Tue, 27 Jan 2004 13:58:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlYHD-0003Kj-W8 for namedroppers-data@psg.com; Tue, 27 Jan 2004 18:49:31 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlYGy-0003Gv-KN for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 18:49:16 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 62EE314C5B for ; Tue, 27 Jan 2004 18:49:16 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done In-Reply-To: Message from Alain Durand of "Tue, 27 Jan 2004 10:31:51 PST." <4016AE97.2050606@sun.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 27 Jan 2004 18:49:16 +0000 Message-Id: <20040127184916.62EE314C5B@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I really have a hard time with the idea that LLMNR & Rendez-vous address > different needs. nevertheless i think the llmnr authors might in fact intend it for a different use, in which case we could expect to see microsoft and apple each implement both rendezvous and llmnr, which would lead to... > There is so much overlap that, in a normal worl, convergence would be > the most sensible avenue. ...convergence. in which case, as long as ietf advances them in tandem, and with well written applicability statements to motivate implementors to put both of them in (where appropriate), then... > If we, as a collection of vocal individuals, cannot put ego aside and > can't converge, please, at least, let's make those two interoperable. ...we will have done the job we agreed to do when attending ietf functions. if on the other hand alain (quoted above) is correct and these protocols address identical needs or significantly overlapping needs, then it would be irresponsible of us to advance both drafts, or to advance only one. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 14:13:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18801 for ; Tue, 27 Jan 2004 14:13:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlYWJ-0005u6-Hi for namedroppers-data@psg.com; Tue, 27 Jan 2004 19:05:07 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlYW7-0005s6-9D for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 19:04:55 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 27 Jan 2004 11:07:15 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0RJ4l5q006116 for ; Tue, 27 Jan 2004 11:04:53 -0800 (PST) Received: from rdroms-w2k01.cisco.com (sjc-vpn3-611.cisco.com [10.21.66.99]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFO56978; Tue, 27 Jan 2004 14:01:10 -0500 (EST) Message-Id: <4.3.2.7.2.20040127134826.00b93400@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Jan 2004 14:01:05 -0500 To: namedroppers@ops.ietf.org From: Ralph Droms Subject: Re: LLMNR is done In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Following up on Bernard's assessment of the relationship between LLMNR and Rendezvous: At 08:53 AM 1/26/2004 -0800, Bernard Aboba wrote: >[...] The >differences are more than cosmetic because the protocols began from >different assumptions and problem statements, and evolved in separate >ways from the beginning. At this point, the protocols only share some >similarities in the use of the DNS packet format, and even here the >differences are substantial. My understanding is that LLMNR is designed: * to avoid interference with and pollution of DNS information * to transition gracefully to DNS * to avoid generating bogus .local queries * to avoid redfining key IP concepts like TTL * to use TTL correctly so that LLMNR traffic is confined to a link, rather than redefining TTL to provide security (whch it doesn't provide, anyway) I'm working here from observation, not from any requirements explicitly set out in or the dnsext WG charter... - Ralph -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 14: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 OAA18884 for ; Tue, 27 Jan 2004 14:15:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlYUl-0005g3-76 for namedroppers-data@psg.com; Tue, 27 Jan 2004 19:03:31 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlYUZ-0005ev-9U for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 19:03:19 +0000 Received: from jschnizl-w2k.cisco.com (sjc-vpn2-300.cisco.com [10.21.113.44]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0RJ3G5l001328; Tue, 27 Jan 2004 11:03:16 -0800 (PST) Message-Id: <4.3.2.7.2.20040127140033.05acccc8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Jan 2004 14:02:44 -0500 To: Paul Vixie From: John Schnizlein Subject: Re: LLMNR is done Cc: namedroppers@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Where is Rendezvous under consideration in the IETF? I would be glad to see an informational RFC specifying Rendezvous. I never saw it named explicitly in the Zero-Conf charter. At 08:33 PM 1/26/2004, Paul Vixie wrote: >can llmnr and rendezvous be issued in tandem, with applicability statements? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 14:29: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 OAA19178 for ; Tue, 27 Jan 2004 14:29:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlYl1-0007rb-J0 for namedroppers-data@psg.com; Tue, 27 Jan 2004 19:20:19 +0000 Received: from [64.104.129.9] (helo=ind-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlYkW-0007lr-Q7 for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 19:19:49 +0000 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 28 Jan 2004 06:21:13 +0530 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by india-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0RJIeME021340; Tue, 27 Jan 2004 11:19:40 -0800 (PST) Received: from rdroms-w2k01.cisco.com (sjc-vpn3-611.cisco.com [10.21.66.99]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AFO59120; Tue, 27 Jan 2004 14:18:03 -0500 (EST) Message-Id: <4.3.2.7.2.20040127141608.00b8c048@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Jan 2004 14:18:01 -0500 To: Paul Vixie From: Ralph Droms Subject: Re: LLMNR is done Cc: namedroppers@ops.ietf.org In-Reply-To: <20040127173838.51E6D14C60@sa.vix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul - can you explain what you mean by "without either one of them having an ip address". If I take that statement literally, I wonder why the IETF would be interested in a protocol that doesn't use IP? - Ralph At 05:38 PM 1/27/2004 +0000, Paul Vixie wrote: >for example, i saw a demo where a mac found a desktop printer without >either one of them having an ip address, and a mac found an mp3 jukebox >without either one of them having an ip address. the chooser/browser >widget just came up and showed what it found. is this sufficiently >different from llmnr's target and purpose that we can reasonably say >that both protocols can be advanced, and both will be in the field, and >they are not competing approaches to the same problem space? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 14:33: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 OAA19329 for ; Tue, 27 Jan 2004 14:33:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlYqz-0008ij-Rs for namedroppers-data@psg.com; Tue, 27 Jan 2004 19:26:29 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlYqf-0008gx-2m for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 19:26:09 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id B2E2814C56; Tue, 27 Jan 2004 19:26:08 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: Ralph Droms Cc: namedroppers@ops.ietf.org Subject: Re: LLMNR is done In-Reply-To: Message from Ralph Droms of "Tue, 27 Jan 2004 14:18:01 EST." <4.3.2.7.2.20040127141608.00b8c048@flask.cisco.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 27 Jan 2004 19:26:08 +0000 Message-Id: <20040127192608.B2E2814C56@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Paul - can you explain what you mean by "without either one of them having > an ip address". If I take that statement literally, I wonder why the IETF > would be interested in a protocol that doesn't use IP? > > - Ralph i misspoke. there was no dhcp server, no dhs server, no server of any kind. of course there were ip addresses, but they were self assigned and invisible to the user. to get a non-rendezvous laptop to see a non-rendezvous desktop printer, i'd have had to set, or at least know, one or both ip addresses. and there would not have been a way to get it to show up in the chooser/browser tool. what this really comes down to is applicability. yesterday here, aboba said that rendezvous and llmnr were different protocols intended for different uses. if the community agrees, then both docs should be advanced, with clear applicability statements. if the community doesn't agree, then a new/merged specification should be developed and advanced, with a notation that apple's existing protocol is to enjoy no special advantage, regardless of the size of their installed base. re: > At 05:38 PM 1/27/2004 +0000, Paul Vixie wrote: > > >for example, i saw a demo where a mac found a desktop printer without > >either one of them having an ip address, and a mac found an mp3 jukebox > >without either one of them having an ip address. the chooser/browser > >widget just came up and showed what it found. is this sufficiently > >different from llmnr's target and purpose that we can reasonably say > >that both protocols can be advanced, and both will be in the field, and > >they are not competing approaches to the same problem space? > > > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 14:41: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 OAA19821 for ; Tue, 27 Jan 2004 14:41:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlYz4-0009qv-PV for namedroppers-data@psg.com; Tue, 27 Jan 2004 19:34:50 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlYys-0009pM-OM for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 19:34:38 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 5B39B14BBE for ; Tue, 27 Jan 2004 19:34:38 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done In-Reply-To: Message from John Schnizlein of "Tue, 27 Jan 2004 14:02:44 EST." <4.3.2.7.2.20040127140033.05acccc8@wells.cisco.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Tue, 27 Jan 2004 19:34:38 +0000 Message-Id: <20040127193438.5B39B14BBE@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Where is Rendezvous under consideration in the IETF? http://www.zeroconf.org/Rendezvous/ http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt > I would be glad to see an informational RFC specifying Rendezvous. i think that would be a cop-out. if dns-sd ("apple's rendezvous") and llmnr have the same target audience, then the existence of both protocols is an indication of chaos or irresponsibility (depending on how far it goes before it's stopped). if they have different target audiences, then both should be advanced, on the standards track, with clear applicability statements to tell implementors which one they need, or why they need both. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 16:28: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 QAA25257 for ; Tue, 27 Jan 2004 16:28:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alaa0-000MLd-8p for namedroppers-data@psg.com; Tue, 27 Jan 2004 21:17:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlaZf-000MJ1-LH for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 21:16:43 +0000 Received: (qmail 12901 invoked from network); 27 Jan 2004 21:28:01 -0000 Received: from h219-110-032-187.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.187) by necom830.hpcl.titech.ac.jp with SMTP; 27 Jan 2004 21:28:01 -0000 Message-ID: <4016D586.40305@necom830.hpcl.titech.ac.jp> Date: Wed, 28 Jan 2004 06:17:58 +0900 From: Masataka Ohta 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 CC: namedroppers@ops.ietf.org Subject: Re: LLMNR is done References: <20040127173838.51E6D14C60@sa.vix.com> In-Reply-To: <20040127173838.51E6D14C60@sa.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul; > i think aboba's assessment may be accurate, which is that these are > different protocols with different applicability statements. if that's > true then simply advancing both of them, each with an applicability > statement that makes clear why it exists and what its purpose and scope > is, is a reasonable approach. As both of them are designed for closed home network with dumb administration (which means it is crazy to make TTL of multicast larger than 1, even more crazy than that of DHCPv6) and neither of them are useful for hosts connected to the public internet, we, Internet ETF, should not mind so much how they evolve or ruin, as long as it is made clear that they are not useful to the Internet and should not be used on hosts connected to the Internet. 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: From owner-namedroppers@ops.ietf.org Tue Jan 27 17:55:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28213 for ; Tue, 27 Jan 2004 17:55:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Albw7-00045J-Op for namedroppers-data@psg.com; Tue, 27 Jan 2004 22:43:59 +0000 Received: from [192.188.192.2] (helo=imail.akc.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Albvv-00043s-D8 for namedroppers@ops.ietf.org; Tue, 27 Jan 2004 22:43:47 +0000 Received: from upstairs [64.253.39.242] by imail.akc.com with ESMTP (SMTPD32-8.02) id AB50C67011A; Tue, 27 Jan 2004 17:50:56 -0500 Message-ID: <1a7f01c3e527$022e9b80$6401a8c0@akc.com> From: "Al Costanzo" To: "Paul Vixie" Cc: References: <4.3.2.7.2.20040127141608.00b8c048@flask.cisco.com> Subject: Re: LLMNR is done Date: Tue, 27 Jan 2004 17:43:39 -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.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,DNS_FROM_RFCI_DSN autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Are you speaking about an old protocol (non-routable) that does not need IP because it just finds MAC addresses on small nets? (kinda sorta like one of the options HP has/had for thier network printers?) -Al ----- Original Message ----- From: "Ralph Droms" To: "Paul Vixie" Cc: Sent: Tuesday, January 27, 2004 2:18 PM Subject: Re: LLMNR is done > Paul - can you explain what you mean by "without either one of them having > an ip address". If I take that statement literally, I wonder why the IETF > would be interested in a protocol that doesn't use IP? > > - Ralph > > At 05:38 PM 1/27/2004 +0000, Paul Vixie wrote: > > >for example, i saw a demo where a mac found a desktop printer without > >either one of them having an ip address, and a mac found an mp3 jukebox > >without either one of them having an ip address. the chooser/browser > >widget just came up and showed what it found. is this sufficiently > >different from llmnr's target and purpose that we can reasonably say > >that both protocols can be advanced, and both will be in the field, and > >they are not competing approaches to the same problem space? > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Jan 27 19:25: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 TAA04525 for ; Tue, 27 Jan 2004 19:25:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AldQo-000EYp-36 for namedroppers-data@psg.com; Wed, 28 Jan 2004 00:19:46 +0000 Received: from [202.12.73.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AldQY-000EWw-5j for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 00:19:30 +0000 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i0R7oGY05589; Tue, 27 Jan 2004 14:50:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id i0R7lTv22361; Tue, 27 Jan 2004 14:47:29 +0700 (ICT) From: Robert Elz To: Stuart Cheshire cc: namedroppers@ops.ietf.org Subject: Re: LLMNR is done In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> References: <200401270404.i0R44aPx022075@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Jan 2004 14:47:28 +0700 Message-ID: <16743.1075189648@munnari.OZ.AU> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 26 Jan 2004 20:04:36 -0800 From: Stuart Cheshire Message-ID: <200401270404.i0R44aPx022075@relay2.apple.com> | So, as I have said before, the only real show-stopping incompatibility I | see is the decision on the TTL. Perhaps a possible compromise. (In other contexts I have argued against any TTL rules at all - that wasn't in the context of a particular application, I see no problem with telling applications what TTL is appropriate for them to use). As I understand it, the argument for TTL=1 is that it restricts packets to the local net, they won't accidentally go further than that. The argument for TTL=255 is that it allows hosts to verify that packets originated from the local net, and didn't come from off net. The verification (it seems to me) is only really important for answers. That is, it is entirely reasonable for a host to care whether the answer it received came from a local responder, and not someone-off net doing bad (or just stupid) things. On the other hand, someone being asked a query should not care too much where the query came from - if it is doing things sensibly, it will only be sending its answer to its local net anyway, if the query came from further away, no reply will be received - so by verifying the query came from the local net, all that really can be achieved is to save a little work (perhaps a useful gain, but hardly a requirement). Packets going off net when they serve no useful purpose is a minor annoyance when they're unicast, but it is something that really wants to be avoided with multicast. So, I think setting TTL==1 on multicast packets is definitely right. Even for multicast replies, that's likely the best thing to do. For unicast packets, I'd think TTL==255 is OK - unicast LLMR packets are likely to be replies, where verifying that the packet came from the local net is more important. Preventing unicast packets "escaping" is a pretty meaningless thing to do (or even hope to do) - if LL addresses are involved, they won't escape anyway, otherwise an occasional packet may go somewhere it isn't wanted - I don't see that as an important enough issue to argue about. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 03:09: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 DAA18627 for ; Wed, 28 Jan 2004 03:09:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlkfQ-000A1K-Kj for namedroppers-data@psg.com; Wed, 28 Jan 2004 08:03:20 +0000 Received: from [203.51.31.28] (helo=cuneata.net) by psg.com with smtp (Exim 4.24; FreeBSD) id 1AlkfD-000A0a-50 for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 08:03:07 +0000 Received: (qmail 19218 invoked from network); 28 Jan 2004 16:06:23 -0000 Received: from pc-00216.cuneata.net (HELO rachel) (192.168.0.216) by squirt.cuneata.net (192.168.0.1) with ESMTP; 28 Jan 2004 16:06:23 -0000 From: Brad Hards To: Paul Vixie Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 18:58:15 +1100 User-Agent: KMail/1.5.94 Cc: namedroppers@ops.ietf.org References: <20040127193438.5B39B14BBE@sa.vix.com> In-Reply-To: <20040127193438.5B39B14BBE@sa.vix.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200401281858.15892.bhards@bigpond.net.au> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) 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.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 28 Jan 2004 06:34 am, Paul Vixie wrote: > > Where is Rendezvous under consideration in the IETF? > > http://www.zeroconf.org/Rendezvous/ > http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt > > > I would be glad to see an informational RFC specifying Rendezvous. > > i think that would be a cop-out. if dns-sd ("apple's rendezvous") and The bit of Rendezvous you want is MDNS. DNS-SD is a peer to protocols like = SLP=20 (which could do name<->address conversion, but isn't really intended for=20 that. > llmnr have the same target audience, then the existence of both protocols > is an indication of chaos or irresponsibility (depending on how far it > goes before it's stopped). if they have different target audiences, then > both should be advanced, on the standards track, with clear applicability > statements to tell implementors which one they need, or why they need bot= h. These look pretty similar to me: Abstract 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. Abstract As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up host names and similar DNS resource record data types, in the absence of a conventional managed DNS server, is becoming essential. I don't think those could be considered to be addresses distinct audiences.= =20 Where is the difference? Brad =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAF2uXGwwszQ/PZzgRAqqFAKCoT82Ks563m4J1pLhhqjt7akd5VACgiheQ 7b0gsBs3p+4PoJ3BHSFDSgI=3D =3Dxpf6 =2D----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 03:33:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20725 for ; Wed, 28 Jan 2004 03:33:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1All49-000CLx-4O for namedroppers-data@psg.com; Wed, 28 Jan 2004 08:28:53 +0000 Received: from [196.4.160.222] (helo=mercury.is.co.za) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1All3v-000CK1-P2 for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 08:28:40 +0000 Received: from hypatia.dns.net (c18-rba-79.dial-up.net [196.39.9.79]) by mercury.is.co.za (Postfix) with ESMTP id 7DD52B95D8; Wed, 28 Jan 2004 10:28:28 +0200 (SAST) Received: (from andras@localhost) by hypatia.dns.net (8.11.3/8.11.3) id i0S83Qj03448; Wed, 28 Jan 2004 10:03:26 +0200 Date: Wed, 28 Jan 2004 10:03:26 +0200 From: Andras Salamon To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done Message-ID: <20040128080326.GA3345@dns.net> References: <200401270404.i0R44aPx022075@relay2.apple.com> <16743.1075189648@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16743.1075189648@munnari.OZ.AU> User-Agent: Mutt/1.5.5.1i X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Jan 27, 2004 at 02:47:28PM +0700, Robert Elz wrote: > As I understand it, the argument for TTL=1 is that it restricts packets > to the local net, they won't accidentally go further than that. > > The argument for TTL=255 is that it allows hosts to verify that packets > originated from the local net, and didn't come from off net. How about requiring queries to use TTL=255, to ensure only members of the local network can generate queries, and requiring answers to use TTL=1, which stops responses leaving the local network? This would stop denial of service attacks caused by injection of queries into the local network, and would damp any DoS attempts originated on the local network before they left. It also strongly ties the protocol to local networks, satisfying at least one member of the working group. Of course, this would have the side effect of breaking both LLMNR and Rendezvous. -- 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: From owner-namedroppers@ops.ietf.org Wed Jan 28 05:45: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 FAA24634 for ; Wed, 28 Jan 2004 05:45:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aln87-0001XH-FJ for namedroppers-data@psg.com; Wed, 28 Jan 2004 10:41:07 +0000 Received: from [195.47.254.20] (helo=mail.rfc.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Aln7v-0001W8-9u for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 10:40:55 +0000 Received: from criollo.schlyter.se (criollo.schlyter.se [195.47.254.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rfc.se (Postfix) with ESMTP id 4317919617 for ; Wed, 28 Jan 2004 11:40:54 +0100 (CET) Date: Wed, 28 Jan 2004 11:40:53 +0100 (CET) From: Jakob Schlyter To: IETF DNSEXT WG Subject: Re: LLMNR is done In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> Message-ID: References: <200401270404.i0R44aPx022075@relay2.apple.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 26 Jan 2004, Stuart Cheshire wrote: > So, as I have said before, the only real show-stopping incompatibility I > see is the decision on the TTL. I'd like to second this and I really hope the chairs will allow the WG to work this out before advancing the docs. rendezvous has been proven to work well in the real world (i.e. outside the ietf) and I cannot see why not to follow the path it has taken. if we, as the WG, cannot resolve this issue, we have failed. 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: From owner-namedroppers@ops.ietf.org Wed Jan 28 06:38: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 GAA26487 for ; Wed, 28 Jan 2004 06:38:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alnx5-0008MN-Q0 for namedroppers-data@psg.com; Wed, 28 Jan 2004 11:33:47 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alnws-0008K2-TJ for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 11:33:34 +0000 Received: from jschnizl-w2k.cisco.com (sjc-vpn2-300.cisco.com [10.21.113.44]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id i0SBXWnH008409 for ; Wed, 28 Jan 2004 03:33:32 -0800 (PST) Message-Id: <4.3.2.7.2.20040127115618.02350130@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Jan 2004 06:33:30 -0500 To: From: John Schnizlein Subject: Re: LLMNR is done In-Reply-To: <200401270404.i0R44aPx022075@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk It is worth noting that this 11th hour attempt to reverse the TTL=1 decision in this WG is much like the 11th hour (after the chair announced ROUGH consensus) change in the Zero-Conf WG. There also, the old history of earlier consideration of TTL=1 was presented as justification for the reversal to support TTL=255. The change of the meaning of this field in the IP header is unnecessary and risky. That it hasn't caused trouble yet is insufficient justification. In the Zero-Conf WG, my concern that the reversal made its specification at odds with the consensus reached in DNS-ext was ignored. Returning to the original rough consensus in Zero-Conf would restore compatibility between these WGs. Why all this new reference to Rendezvous? Note that it was not mentioned in the Zero-Conf charter at all. Zero-Conf progressed as if independent of a single vendor's implementation until near the end. John At 10:45 AM 1/27/2004, Ted Lemon wrote: >I don't have anything substantive to add except that I would really, really like to see Rendezvous be able to interoperate with LLMNR. I use Rendezvous a _lot_, it makes a big difference in the usability of my network, and the one big remaining hole right now is that it doesn't work with Windows. :'( > >I think that resolving the TTL issue in favor of the way Rendezvous does it is a good solution - there are pros and cons to both ways of doing TTL, and in fact it was as a result of debate about this issue with regard to LLMNR that Rendezvous switched to this scheme originally. > >I've weighed in on this several times in the past - the only reason I've stopped saying anything about it is because I've given up hope in the process - it's seemed recently that there was no interest at all in making LLMNR and Rendezvous interoperate. It sounds like this is not actually the case, and that a lot of other folks have been silent as well, perhaps for the same reason. :'/ At 11:04 PM 1/26/2004, Stuart Cheshire wrote: >... > >Unfortunately, *everything* seems subject to intense debate, even what >the list of things to debate is. Before embarking on that debate, I asked >if the working group had any interest in working for interoperability >with the installed base. No answer was received. > >>Known differences between Rendezvous and LLMNR > >I think there are some misperceptions here; I should correct them. > >... >>f. Rendezvous requires TTL=255; LLMNR uses TTL=1. > >The TTL check is, as you know, to guarantee that packets really >originated on the local link (*especially* unicast replies). I'm told >that in the latest Windows XP Service Pack lots of services have been >locked down the local link by default for "security", so I would have >thought that having the ability to do the same for LLMNR would have met >with Microsoft's approval in the current climate. Note that setting the >TTL to 255 allows the receiver to check the TTL; it doesn't *require* the >receiver to check if it doesn't want to. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 08:23: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 IAA29918 for ; Wed, 28 Jan 2004 08:23:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlpcR-000MPd-6e for namedroppers-data@psg.com; Wed, 28 Jan 2004 13:20:35 +0000 Received: from [193.0.9.220] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlpcE-000MNk-N8 for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 13:20:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 1A1A71E58D2 for ; Wed, 28 Jan 2004 14:20:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Wed, 28 Jan 2004 14:20:22 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is related to the thread starting at: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00053.html The document currently requires a security aware resolver to query for security related RRs needed to complete a validation. Given that both parent and child have NSEC and RRSIG records for a delegation, the logic for fetching those records is likely to be very complicated, much as is the logic for fetching a DS record when the grandparent situation exists. Since the authoritative server special processing rules are supposed to deliver all records needed for validation, it is safe to weaken this requirement. (One must also note that the requirement (RFC2535 5.5) to serve the NSEC from both the parent and the child if both are available will lead to inconsistencies between answer from different authoritative servers and answers from recursive nameservers. Therefore and because of the argument about the special processing rules above the requirement is consciously not copied into the DNSSECbis specs and left unspecified). The proposed text therefore is: security aware resolvers MAY query for missing security RRs; implementations that choose to do so must be aware of the fact that the answers received may not be sufficient to perform validation. --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: From owner-namedroppers@ops.ietf.org Wed Jan 28 08:24: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 IAA29941 for ; Wed, 28 Jan 2004 08:24:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alpa4-000M8i-DP for namedroppers-data@psg.com; Wed, 28 Jan 2004 13:18:08 +0000 Received: from [193.0.9.220] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlpZg-000M2i-IM for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 13:17:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id EFC931E58B4 for ; Wed, 28 Jan 2004 14:17:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <5BC0D19E-5194-11D8-AF3C-000393DA2D46@ripe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: New DNSSEC Questions Date: Wed, 28 Jan 2004 14:17:44 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Colleagues, As a result of the last call we have a number of questions that we would like to get WG feedback on. The questions come with 'default' answers. The dnssec-editors will merge those into the document set if there is no comments received. Some of these questions have been discussed on the list previously, please regard the proposed answers as a proposal for a consensus in those cases. Since we would like to get a new, and final, version of the docs by mid February I would like to ask the WG to respond within before the end of next week. (Feb 6, 2004). These will be posted topic by topic. Please respond to them in thread. These questions will follow shortly: Q-23 Direct NSEC queries; specs for resolvers and servers. Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Q-25 Under specification of NSEC TTL. Q-26 Appearance of DS RRs. Q-27 Setting AD for DNAME synthesis of CNAME --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: From owner-namedroppers@ops.ietf.org Wed Jan 28 08:24: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 IAA29959 for ; Wed, 28 Jan 2004 08:24:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlpdC-000MXX-D2 for namedroppers-data@psg.com; Wed, 28 Jan 2004 13:21:22 +0000 Received: from [193.0.9.220] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alpd0-000MVp-IM for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 13:21:10 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 685ED1E58E5 for ; Wed, 28 Jan 2004 14:21:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Q-24 DNSKEY with flag 7=0 not to be used with DNSSEC. Date: Wed, 28 Jan 2004 14:21:11 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The behavior for the flag bit (bit7) in the DNSKEY RR set to 0 is not specified. We propose the following text to be added to section 2.1: DNSKEY RRs MUST NOT be used for DNSSEC validation if bit 7 of the flag field is set to 0. --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: From owner-namedroppers@ops.ietf.org Wed Jan 28 08:26: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 IAA00024 for ; Wed, 28 Jan 2004 08:26:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alpep-000MlH-4v for namedroppers-data@psg.com; Wed, 28 Jan 2004 13:23:03 +0000 Received: from [193.0.9.220] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alped-000MjR-8j for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 13:22:51 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 27A601E58F8 for ; Wed, 28 Jan 2004 14:22:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <12F5C8A6-5195-11D8-AF3C-000393DA2D46@ripe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Q-26 Appearance of DS RRs. Date: Wed, 28 Jan 2004 14:22:51 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since this is on the boundary between editorial and protocol you should see this more as a notification than a question. DS RR MUST NOT appear at non-delegation point has changed. The new text says DS MUST NOT appear at apex (this is needed). silent on DS appearing elsewhere. The reason for this change is that although it seems rather senseless to have a DS anywhere else than with a delegation there seems no reason to forbid the existence elsewhere --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: From owner-namedroppers@ops.ietf.org Wed Jan 28 08:26: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 IAA00042 for ; Wed, 28 Jan 2004 08:26:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alpdx-000Mdr-Bh for namedroppers-data@psg.com; Wed, 28 Jan 2004 13:22:09 +0000 Received: from [193.0.9.220] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alpdl-000Mbv-Em for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 13:21:57 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 287ED1E58ED for ; Wed, 28 Jan 2004 14:21:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Q-25 Under specification of NSEC TTL. Date: Wed, 28 Jan 2004 14:21:57 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The document does not specify the setting of the TTL on NSEC RRs. We propose the following text to be added to 2.3 proto: In the spirit of [RFC negative cache] the TTL of the NSEC RRset SHOULD match the TTL of the zone SOA minimum field. --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: From owner-namedroppers@ops.ietf.org Wed Jan 28 08:28: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 IAA00153 for ; Wed, 28 Jan 2004 08:28:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Alpgb-000N5G-R8 for namedroppers-data@psg.com; Wed, 28 Jan 2004 13:24:53 +0000 Received: from [193.0.9.220] (helo=ernie.secret-wg.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlpgO-000N1H-LV for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 13:24:40 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by ernie.secret-wg.org (Postfix) with ESMTP id 61B761E590F for ; Wed, 28 Jan 2004 14:24:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <5214FE3C-5195-11D8-AF3C-000393DA2D46@ripe.net> Content-Type: text/plain; charset=US-ASCII; format=flowed To: namedroppers@ops.ietf.org From: Olaf Kolkman Subject: Q-27 Setting AD for DNAME synthesis of CNAME Date: Wed, 28 Jan 2004 14:24:37 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is a question regarding the interaction between the rules governing the setting of an AD bit in a reply message and the inclusion of a DNAME RR in an answer. In addition to more rules, an AD bit is to be set (to 1) only if the server has cryptographicly verified each of the RRsets in the answer section of the message. According to the rules governing the inclusion a DNAME RR in an answer section, a synthesized CNAME RR is also included to assist older implementations that might not understand the DNAME RR. The question is whether it is appropriate to set the AD bit when a signed, checked, DNAME RR set is in an answer, followed by its synthesized, unsigned CNAME RR? On the one hand, the CNAME RR is unsigned and hence unchecked, suggesting the answer is no. On the other hand, the CNAME RR is verifiably generated via an algorithm from a signed and checked DNAME RR, hence the AD bit can still be set in the answer (barring other reasons to not set the AD bit). The suggested answer is that setting the AD bit is appropriate with the DNAME RR warrants it, regardless of there being the synthesized CNAME RR. If a client is unable to understand DNAME RR, the client is also assumed to not be able to understand the AD bit. If a client does understand the DNAME RR, it can ignore the presence of the CNAME RR, so the lack of a signature covering the CNAME is immaterial. --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: From owner-namedroppers@ops.ietf.org Wed Jan 28 08:59: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 IAA01139 for ; Wed, 28 Jan 2004 08:59:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlqA7-0003tg-Uy for namedroppers-data@psg.com; Wed, 28 Jan 2004 13:55:23 +0000 Received: from [211.30.120.24] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alq9u-0003kh-QV for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 13:55:11 +0000 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 i0SDt9cc088162; Thu, 29 Jan 2004 00:55:09 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200401281355.i0SDt9cc088162@drugs.dv.isc.org> To: Olaf Kolkman Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: Q-27 Setting AD for DNAME synthesis of CNAME In-reply-to: Your message of "Wed, 28 Jan 2004 14:24:37 BST." <5214FE3C-5195-11D8-AF3C-000393DA2D46@ripe.net> Date: Thu, 29 Jan 2004 00:55:09 +1100 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_DYNABLOCK,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This is a question regarding the interaction between the rules > governing the setting of an AD bit in a reply message and the > inclusion of a DNAME RR in an answer. In addition to more rules, an > AD bit is to be set (to 1) only if the server has cryptographicly > verified each of the RRsets in the answer section of the message. > According to the rules governing the inclusion a DNAME RR in an answer > section, a synthesized CNAME RR is also included to assist older > implementations that might not understand the DNAME RR. > > The question is whether it is appropriate to set the AD bit when a > signed, checked, DNAME RR set is in an answer, followed by its > synthesized, unsigned CNAME RR? On the one hand, the CNAME RR is > unsigned and hence unchecked, suggesting the answer is no. On the > other hand, the CNAME RR is verifiably generated via an algorithm from > a signed and checked DNAME RR, hence the AD bit can still be set in > the answer (barring other reasons to not set the AD bit). > > The suggested answer is that setting the AD bit is appropriate with > the DNAME RR warrants it, regardless of there being the synthesized > CNAME RR. If a client is unable to understand DNAME RR, the client is > also assumed to not be able to understand the AD bit. If a client > does understand the DNAME RR, it can ignore the presence of the CNAME > RR, so the lack of a signature covering the CNAME is immaterial. > > > --Olaf This also needs to extended to other synthesised records. If a zone is marked as secure (permitted by RFC 3655) then wildcard answers also set AD. The wording needs to be in terms of synthesised from secure rather than DNAME. DNAME -> CNAME is a example of when you apply the rule. This will future proof the spec. > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 09:39: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 JAA02113 for ; Wed, 28 Jan 2004 09:39:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlqkX-00095j-Oa for namedroppers-data@psg.com; Wed, 28 Jan 2004 14:33:01 +0000 Received: from [211.30.120.24] (helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Alqk5-00091Q-Lq for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 14:32:33 +0000 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 i0SEWWcd088389 for ; Thu, 29 Jan 2004 01:32:32 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200401281432.i0SEWWcd088389@drugs.dv.isc.org> To: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: returning AD through intermediate servers Date: Thu, 29 Jan 2004 01:32:32 +1100 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,NO_REAL_NAME, RCVD_IN_DYNABLOCK,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Client <-> server <-> validating server <-> world We need to permit AD being returned from the validating server to get to the client iff "server <-> validating server" is secure and there is a existing trust relationship between the two servers. While this is a logical consequence of the rest of the draft it may not be obvious that it needs to be done. 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: From owner-namedroppers@ops.ietf.org Wed Jan 28 11:31:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08101 for ; Wed, 28 Jan 2004 11:31:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlsRH-000Pb4-10 for namedroppers-data@psg.com; Wed, 28 Jan 2004 16:21:15 +0000 Received: from [193.0.0.199] (helo=postman.ripe.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlsR4-000PaJ-IQ for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 16:21:02 +0000 Received: by postman.ripe.net (Postfix, from userid 8) id F0A404E64D; Wed, 28 Jan 2004 17:21:01 +0100 (CET) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A176A4E37A for ; Wed, 28 Jan 2004 17:21:01 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i0SGL00G018311 for ; Wed, 28 Jan 2004 17:21:00 +0100 Received: (from olaf@localhost) by cow.ripe.net (8.12.10/8.12.6) id i0SGL0ib022925 for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 17:21:00 +0100 Received: from [204.152.186.142] (helo=toccata.fugue.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlrbC-000Fw8-Sg for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 15:27:26 +0000 Received: from [10.0.0.12] (cs241750-189.austin.rr.com [24.175.0.189]) by toccata.fugue.com (Postfix) with ESMTP id 3C7E61B5BB9; Wed, 28 Jan 2004 09:18:33 -0600 (CST) In-Reply-To: <4.3.2.7.2.20040127115618.02350130@wells.cisco.com> References: <4.3.2.7.2.20040127115618.02350130@wells.cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78D054ED-51A6-11D8-9E6D-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: From: Ted Lemon Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 09:27:24 -0600 To: John Schnizlein X-Mailer: Apple Mail (2.609) X-RIPE-Spam-Status: N 0.499981 X-RIPE-Signature: 3335e135e5f1ee93ada9e5afee088b8d X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Jan 28, 2004, at 5:33 AM, John Schnizlein wrote: > It is worth noting that this 11th hour attempt to reverse the TTL=1 > decision in this WG is much like the 11th hour (after the chair > announced ROUGH consensus) change in the Zero-Conf WG. John, this isn't an 11th-hour attempt. We've been arguing about this for several years now, without reaching consensus. If you had the impression that there was consensus, it's only because the people who do not participate in the "consensus" have been quiet for a while because we have little hope that saying anything will be productive. > There also, > the old history of earlier consideration of TTL=1 was presented > as justification for the reversal to support TTL=255. The change > of the meaning of this field in the IP header is unnecessary and > risky. That it hasn't caused trouble yet is insufficient justification. Yes, you and several other people have repeatedly made this assertion. So because of this, we will have two non-interoperating protocols that do the same thing. That's a real world problem that can be demonstrated on networks today. How do I know? Because it's already caused trouble for me personally and for people for whom I provide network support - people who are not John Schnizlein or Ted Lemon and cannot debug these problems without our help. This interoperability problem is a direct result of what appears to be a completely theoretical argument. > Why all this new reference to Rendezvous? Note that it was not > mentioned in the Zero-Conf charter at all. Zero-Conf progressed > as if independent of a single vendor's implementation until near > the end. Rendezvous happened, as far as I can tell, because the Zeroconf working group failed. By which I mean that although there was strong agreement among proponents of zeroconf about what to do, there was strong resistance to the idea of the IETF pushing any kind of zeroconf, and this prevented the working group from succeeding. We have some drafts in/near last call now, but it's a Pyrrhic victory - I'd rather implement Rendezvous than zeroconf. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 15:41: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 PAA27171 for ; Wed, 28 Jan 2004 15:41:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlwMh-000BH5-N9 for namedroppers-data@psg.com; Wed, 28 Jan 2004 20:32:47 +0000 Received: from [204.152.187.1] (helo=sa.vix.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlwMT-000BG1-DA for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 20:32:33 +0000 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 08EE614C52 for ; Wed, 28 Jan 2004 20:32:33 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. In-Reply-To: Message from Olaf Kolkman of "Wed, 28 Jan 2004 14:20:22 +0100." X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Jan 2004 20:32:33 +0000 Message-Id: <20040128203233.08EE614C52@sa.vix.com> X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The proposed text therefore is: security aware resolvers MAY query for > missing security RRs; implementations that choose to do so must be > aware of the fact that the answers received may not be sufficient to > perform validation. this gives no guideance to server implementors, and is therefore inadequate. how about adding this text: security aware responders who receive queries for security 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 in other words, driving home the point that requestor implementors ought not depend on the results of queries for security RRs is only part of the story; the document should also clearly state that there is no standard behaviour for responders, and place a self-consistency requirement there instead. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 16:05: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 QAA28571 for ; Wed, 28 Jan 2004 16:05:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlwfW-000ER6-WB for namedroppers-data@psg.com; Wed, 28 Jan 2004 20:52:14 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlwfI-000EKZ-SS for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 20:52:01 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0SL5bn21143 for ; Wed, 28 Jan 2004 13:05:38 -0800 Date: Wed, 28 Jan 2004 13:05:37 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk LLMNR was designed to handle situations in which hosts are highly mobile, and to be extensible to use in larger scopes, if the initial deployments prove successful. These situations do not lend themselves to multicast responses. For a highly mobile situation, with a DNS TTL close to zero, multicast responses are not useful to any host other than the one sending the original query, yet they need to be processed by all hosts for marginal benefit. Multicast responses also do not scale beyond link-local scope to situations where hundreds or even thousands of hosts could be listening across a site. Given the design goals of LLMNR, multicast queries were precluded early on. While the content of queries might indeed be a higher layer issue, it is very relevant to the interoperability question. A host sending a query for a ".local" name will not receive a response unless the target also is configured with a ".local" name. So in practice, converging LLMNR and Rendezvous yields no useful benefits unless the hosts also adopt the Rendezvous namespace model. The problem with that model is that it requires users to either type the ".local" extension, or for ".local" to be put into the searchlist. The former is a problem for users used to a flat namespace (e.g. http://foo, which can be resolved via RFC 1001-1002, NetBIOS over TCP/IP). The latter results in lots of bogus ".local" queries. In terms of proxying and power management, name conflict detection can be run when systems power up again, and since name conflicts are relatively unlikely, there is no need in LLMNR to deploy proxies for this purpose, particularly in mobile environments where they are likely to be serving up out of date information. In any case, since proxies depend on multicast responses, once those are eliminated to improve scaling, they can't be used anyway. In terms of differing uses of the header bits, and other sections of the DNS packet, almost every bit and field is used differently in LLMNR and Rendezvous. LLMNR does not allow multiple questions in a query, since these are known to cause confusion. Therefore there is no need to use the TC bit in a query, as Rendezvous does. Since LLMNR is not a service discovery protocol, there is no need to implement known answer suppression. Since in LLMNR there are no proxies or non-authoritative answers, there is no need to use the RA or AA bits either. LLMNR specifies more strict handling of SOA and NS RRs in order to handle the different delegation model of a peer-to-peer name resolution protocol. The CD or AD bits do not apply to a peer-to-peer name resolution protocol where there is no implicit trust, so LLMNR does not use them. In order to be compatible with DNSSEC, LLMNR requires support for EDNS0, which has its own way of handling MTU issues. In LLMNR automatically sending a packet of link MTU size would not be wise because of the need to allow extension to larger scopes going forward. So LLMNR and Rendezvous don't even handle MTU issues the same way. Rather than disallowing all non-zero RCODEs, LLMNR allows error messages to be used in response to unicast queries, in order to permit problem diagnosis and enable use of DNSSEC & TSIG. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 17:33: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 RAA03998 for ; Wed, 28 Jan 2004 17:33:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlyAW-000POD-5g for namedroppers-data@psg.com; Wed, 28 Jan 2004 22:28:20 +0000 Received: from [17.254.13.22] (helo=mail-out3.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlyAI-000PKx-Ht for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 22:28:06 +0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id i0SMS6nM014155 for ; Wed, 28 Jan 2004 14:28:06 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Wed, 28 Jan 2004 14:28:06 -0800 Received: from [17.202.40.111] (graejo.apple.com [17.202.40.111]) by relay2.apple.com (8.12.10/8.12.9) with ESMTP id i0SMRpPx015158 for ; Wed, 28 Jan 2004 22:27:51 GMT Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: References: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-21-384909771; protocol="application/pkcs7-signature" Message-Id: <36F3B35E-51E1-11D8-92CC-000A95B9474C@apple.com> From: Joshua Graessley Subject: Re: LLMNR is done Date: Wed, 28 Jan 2004 14:27:53 -0800 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-21-384909771 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jan 28, 2004, at 1:05 PM, Bernard Aboba wrote: > Multicast responses also do not scale beyond link-local scope to > situations where hundreds or even thousands of hosts could be listening > across a site. Given the design goals of LLMNR, multicast queries were > precluded early on. I'm confused. LLMNR is only useful when there is no configured DNS, otherwise all queries go to unicast DNS and only fall back to LLMNR if the unicast DNS query fails (which one can not rely on). What sort of scenario are you likely to run in to where there would be no unicast DNS but there are routers configured to handle multicast? Where is this mentioned as a design goal? It seems like LLMNR has a subset of the mDNS functionality. LLMNR focuses on solving the problem of resolving DNS entries when there is no DNS server. mDNS attempts to solve the problem of resolving DNS names when there is no DNS as well as resolving names even when there is a configured DNS server. In a number of situations, people may end up on the same network where names for the addresses they receive are arbitrary or nonexistent. A common example would be two people meeting in an airport and joining the same wireless network at the airport. If they had private addresses, there would be no point in using dynamic DNS to register their address. LLMNR wouldn't work. -josh --Apple-Mail-21-384909771 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDEyODIyMjc1NFowIwYJKoZIhvcNAQkEMRYEFK8P XeBNc3hrYKY8/sl9R75UFt86MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBABvy pd50zXHL+u+Us3jP4xUZVj5wnxg/yDZaxZCQoz6KgWwc+Ruc3pFzLd3xtkagRSeCYrdoXnX38k/A 5TgSkeY4cjtamTQFR0rYZNHGGFIEjLshOndUJBygWdbgE2jucRqBYWNF5cmzgbkIgJGERYpYuVlJ iKviqYeCwrXz9X0jAN8OiwnCcgos+ynfYFkcHnCpR/Be+sI7JIxY/C3Cj0tJAkXQgh7OXFi50D/u afPHk3MSxhXJSVaa31u26d2ydeZTXPBEM4y2yb+gdvl2lfMFWDY7FGsEZoAwTksBLGWI9iITcTf0 trp8CDwbhk775dt55q/nD7ownhvZE1WvOXwAAAAAAAA= --Apple-Mail-21-384909771-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Jan 28 18:36: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 SAA07594 for ; Wed, 28 Jan 2004 18:36:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AlzAO-0006Xk-0i for namedroppers-data@psg.com; Wed, 28 Jan 2004 23:32:16 +0000 Received: from [66.167.171.107] (helo=internaut.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AlzAA-0006Wl-Ue for namedroppers@ops.ietf.org; Wed, 28 Jan 2004 23:32:03 +0000 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i0SNjdZ30693 for ; Wed, 28 Jan 2004 15:45:39 -0800 Date: Wed, 28 Jan 2004 15:45:39 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: Re: LLMNR is done Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >I'm confused. LLMNR is only useful when there is no configured DNS, LLMNR can be used where there is a configured DNS server as well, but where the DNS server doesn't answer, or responds with RCODE=3 or RCODE=0 and no answers in the answer section. See Section 2 for details. Also note that LLMNR prefers unicast queries for PTR RRs, and does not use multicast responses, to avoid unnecessary multicast traffic that would become a problem if the scope were expanded beyond link local. See Section 2.4. >What sort of scenario are you likely to run in to where there would be no >unicast DNS but there are routers configured to handle multicast? Where >is this mentioned as a design goal? If the user has a router at home that includes support for DHCPv4 only and no support for IPV6 DNS configuration or resolution of AAAA queries, then LLMNR can be used to resolve names of IPv6-only hosts on the local network. See Section 3.1. >It seems like LLMNR has a subset of the mDNS functionality. mDNS is focussed on discovery of stationary services. LLMNR is about name resolution in environments which may be highly mobile. They are different problems and different design choices were made to address them. >LLMNR focuses on solving the problem of resolving DNS entries when there >is no DNS server. mDNS attempts to solve the problem of resolving DNS >names when there is no DNS as well as resolving names even when there is >a configured DNS server. LLMNR handles both situations. LLMNR can be used to resolve any name. See Section 2. >If they had private addresses, there would be no point in using dynamic DNS to register their address. >LLMNR wouldn't work. LLMNR can resolve a name with any kind of address. LLMNR doesn't rely on dynamic DNS or support dynamic DNS update op codes. See Section 2.1. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 29 04:13: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 EAA09138 for ; Thu, 29 Jan 2004 04:13:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Am894-000Ovw-Eq for namedroppers-data@psg.com; Thu, 29 Jan 2004 09:07:30 +0000 Received: from [213.154.224.1] (helo=open.nlnetlabs.nl) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1Am88j-000Ou9-Cq for namedroppers@ops.ietf.org; Thu, 29 Jan 2004 09:07:09 +0000 Received: from elektron.atoom.net (f52166.upc-f.chello.nl [80.56.52.166]) by open.nlnetlabs.nl (8.12.10/8.12.8) with ESMTP id i0T973oM053535 for ; Thu, 29 Jan 2004 10:07:03 +0100 (CET) (envelope-from miekg@atoom.net) Received: from elektron.atoom.net (localhost [127.0.0.1]) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) with ESMTP id i0T972UG026118 for ; Thu, 29 Jan 2004 10:07:02 +0100 Received: (from miekg@localhost) by elektron.atoom.net (8.12.11.Beta0/8.12.11.Beta0/Debian-1) id i0T972C0026117 for namedroppers@ops.ietf.org; Thu, 29 Jan 2004 10:07:02 +0100 Date: Thu, 29 Jan 2004 10:07:02 +0100 From: Miek Gieben To: namedroppers@ops.ietf.org Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Message-ID: <20040129090702.GB26037@atoom.net> Mail-Followup-To: namedroppers@ops.ietf.org References: <20040128203233.08EE614C52@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040128203233.08EE614C52@sa.vix.com> User-Agent: Vim/Mutt/Linux X-Home: www.miek.nl X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [On 28 Jan, @21:32, Paul wrote in "Re: Q-23 Direct NSEC queries; ..."] > > The proposed text therefore is: security aware resolvers MAY query for > > missing security RRs; implementations that choose to do so must be > > aware of the fact that the answers received may not be sufficient to > > perform validation. > > this gives no guideance to server implementors, and is therefore inadequate. > > how about adding this text: > > security aware responders who receive queries for security 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 > > in other words, driving home the point that requestor implementors ought not I like this text more than the one provided by Olaf, grtz Miek -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 29 10:41: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 KAA25512 for ; Thu, 29 Jan 2004 10:41:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmEC5-000NHB-JC for namedroppers-data@psg.com; Thu, 29 Jan 2004 15:35:01 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmEBr-000NDW-Kt for namedroppers@ops.ietf.org; Thu, 29 Jan 2004 15:34:47 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24733; Thu, 29 Jan 2004 10:34:43 -0500 (EST) Message-Id: <200401291534.KAA24733@ietf.org> From: The IESG To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org, Olafur Gudmundsson , Olaf Kolkman Subject: WG Action: RECHARTER: DNS Extensions (dnsext) Date: Thu, 29 Jan 2004 10:34:43 -0500 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,OPT_IN_CAPS autolearn=no version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The charter of the DNS Extensions (dnsext) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. DNS Extensions (dnsext) ----------------------- Current Status: Active Working Group Chair(s): Olafur Gudmundsson Olaf Kolkman Internet Area Director(s): Thomas Narten Margaret Wasserman Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update and notify documents to Draft standard and on the rewrite of the DNSSEC proposed standard. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. The DNSEXT Working Group actually uses an additional mailing list for discussion of DNS Security related issues. This list is open to all: Discussion: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list The RFC2535bis document set is edited by a team that can be reached through dnssec-editors@east.isi.edu. This team is chartered with making editorial changes only, with all substantative changes discussed on the WG list. Only the document editors and working group chairs are on this list, an archive of the mailing list is available at: Archive: http://www.east.isi.edu/projects/DNSSEC Specific work items are: o Protocol clarifications and corrections for DNSSEC, initially these clarifications will be done as separate RFCs that will later be folded into a document that we refer to as the RFC 2535bis document standard. These include changes that simplify the operation of DNSSEC. o Generate new specification documents of DNSSEC (the RFC 2535bis document set) that includes all changes to RFC2535. This includes the following RFCs 2931, 3007, 3008, 3090 and 3226 and a number of Internet Drafts including DS, AD-is-secure, Key Signing Flag, NSEC RDATA etc. Advance this document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. + Case insensitivity rules clarification. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2672 (DNAME) to Draft Standard, or revision. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3645 GSS/TSIG to Draft Standard + RFC3??? AXFR clarify to Draft Standard. o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Goals and Milestones: Jan 04 Forward NSEC rdata to IESG for Proposed Standard Feb 04 Forward RFC2535-bis to IESG for proposed standard. Feb 04 Forward Case Insensitive to IESG for Proposed Standard Feb 04 Forward LLMNR to IESG for Proposed Standard. Mar 04 Forward Wildcard clarification to IESG for proposed standard Mar 04 Submit KEY algorithm documents RFC253[69]bis and RFC3110 to IESG for proposed standard. Apr 04 Update boilerplate text on OPT-IN Apr 04 Submit to IESG RFC2845 (TSIG)to Draft standard. Mar 04 Start of process of reviewing the following RFCs and to move them to Draft Standard status. May 04 RFC1982 (Serial Number Arithmetic) May 04 RFC2782 (SRV RR) to Draft Standard May 04 RFC2538 (CERT RR) to Draft Standard. Jun 04 RFC1995 (IXFR) to Draft standard Jun 04 RFC1996 (Notify) to Draft Standard. Jun 04 RFC2136 (Dynamic Update) to Draft Standard. Jul 04 RFC3007 (Secure Update) to Draft Standard. Jul 04 Submit to IESG RFC2930 (TKEY) to Draft standard. Jul 04 RFC2672 (DNAME) to Draft Standard or revision. Sep 04 RFC2181 (Clarify) to Draft Standard. Sep 04 RFC2671 (EDNS0) to Draft Standard. Sep 04 RFC2308 (Neg Caching) to Draft Standard. Nov 04 RFC3090 (DNSSEC zones tatus) to Draft Standard. Nov 04 FRC2539 (DH Key RR) to Draft Standard. Nov 04 RFC3226 (Message Size) to Draft Standard. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Jan 29 17:57: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 RAA26170 for ; Thu, 29 Jan 2004 17:57:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AmKzu-000H29-6o for namedroppers-data@psg.com; Thu, 29 Jan 2004 22:50:54 +0000 Received: from [17.254.13.23] (helo=mail-out4.apple.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AmKzh-000H0z-Ou for namedroppers@ops.ietf.org; Thu, 29 Jan 2004 22:50:41 +0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id i0TMofcb026285 for ; Thu, 29 Jan 2004 14:50:41 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 29 Jan 2004 14:50:41 -0800 Received: from [10.0.1.24] (2x101.filemaker.com [17.184.101.2] (may be forged)) by relay1.apple.com (8.12.10/8.12.9) with ESMTP id i0TMof9x022749 for ; Thu, 29 Jan 2004 22:50:41 GMT Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: References: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-472678492; protocol="application/pkcs7-signature" Message-Id: <912FB2F7-52AD-11D8-B03A-000A95B9474C@apple.com> From: Joshua Graessley Subject: Re: LLMNR is done Date: Thu, 29 Jan 2004 14:50:42 -0800 To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --Apple-Mail-4-472678492 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Jan 28, 2004, at 3:45 PM, Bernard Aboba wrote: >> I'm confused. LLMNR is only useful when there is no configured DNS, > > LLMNR can be used where there is a configured DNS server as well, but > where the DNS server doesn't answer, or responds with RCODE=3 or > RCODE=0 > and no answers in the answer section. See Section 2 for details. Counting on DNS to return RCODE=3 or RCODE=0 with no answers is error prone. Unless you or someone you know is responsible for a domain, you can't guarantee that a query will fail. If you use an unqualified name, the resolver may attempt to append a search domain first, which may result in a successful unicast DNS query for a name you were not expecting. Maybe I'm missing something obvious? Otherwise, it seems that LLMNR is unreliable (nearly useless) when there is a configured DNS server. -josh --Apple-Mail-4-472678492 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDEyOTIyNTA0MlowIwYJKoZIhvcNAQkEMRYEFGIW bh2hQGh9sELJ9hxAC2HV1Q16MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAEWA l1ypzWcynd8/9CiboerBOghm3SVqOW+JDVUdJfT4moxVy+cAITp/k00jEqoI+H3g7978TI235YI6 heffeImZdgKguVINbTZKS72dXJ5MXKVeYTa7te7ycfhVZpg2yola0Mqp67v3hdSIHEI0zaPgPJRm PmsX7Q6pNtIyltyrItYtSOd4RJ/p3/+/VYlMEaQuGX2TPNvORzeG3EcIM1T1dgqAaMnyrASnTitm rbqStr5H0R6wbsrM5N+hvLsjE0lmUqsdQ6LrYuxl6fYRCvQn/InNcSDIiqU9XnHDyfBlyLmkMcsc PzzdRYn27UtMt97t4bL4g1XseZlDngy3+rgAAAAAAAA= --Apple-Mail-4-472678492-- -- 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: