Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 02 Mar 2004 00:24:45 -0500 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> <20040226144216.GA7166@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba <aboba@internaut.com>, huitema@microsoft.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 02 06:35:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040226144216.GA7166@dns.net> (Andras Salamon's message of "Thu, 26 Feb 2004 16:42:16 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: >> If there is to be a "compromise" I believe that it should be >> to set TTL=255 on responses and (optionally) check on the sender, while >> *always* setting TTL=1 on queries. > > Sounds reasonable to me. But now you're open to smurf attacks, where I send a LLMNR request to a responder, setting YOUR ip address as the source, and setting the TTL to make sure the packet arrives "properly". Or do we just not care about this? I can make sure you send the packet, and with TTL=255 the response will always make it back to the "sender" (which is YOUR ip address in this case). So, what is the threat(s) we're trying to solve? In particular, what threat does TTL=255 on responses actually solve? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: draft-ietf-dnsext-nsec-rdata-04 Date: Wed, 3 Mar 2004 20:08:54 +0900 (KST) Lines: 15 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 03 12:20:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Precedence: bulk Status: O I've just submitted an updated version of this draft to the drafts editor. For those who want to read it now, you can find a copy (and a diff against -03) at the following location: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.txt http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.wdiff jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: comment on NSEC RDATA format draft -04 Date: Thu, 4 Mar 2004 08:37:31 -0500 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 04 15:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The text states that there are no special TTL requirements for the NSEC RR. However, in the new DNSSECbis specs, we have the following suggestion for TTL values (records draft-07): The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308]. Minor difference since the above is a suggestion, and there are no real special requirements for the TTL. I think the NSEC data draft should include the above for consistancy. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:03:22 +0100 Lines: 143 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 15:15:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Hello, being new to rfc2782, I have a number of questions. I would be grateful for any enlightenment anyone could provide. Regards Barry Desborough Barry.Desborough@wanadoo.fr SRV RR FORMAT >From rfc2782 page 2 "The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target" But rfc1035 page 29 describes the generic RR header as being NAME TYPE CLASS TTL RDLENGTH RDATA According to 1035, and assuming that 'SRV' refers to TYPE, (not specified in 2782), it seems that the SRV RR should be _Service._Proto.Name SRV Class TTL RDLENGTH Priority Weight Port Target where _Service._Proto.Name corresponds to NAME SRV is the TYPE (33) Class, TTL and RDLENGTH are 1035 standard and Priority Weight, Port and Target correspond to RDATA Q1) Which rfc is correct? Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? Could not the contents of Target have been be reported in the NAME field and the Target field be dispensed with? TARGET SELECTION >From page 3 of rfc2782 " ............................................ The following algorithm SHOULD be used to order the SRV RRs of the same priority: To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority." Let's say we have only two targets of the same priority, with weights 1 and 2. If the weights are ordered 1 then 2, then we have Wt Sum ----------- 1 1 2 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 1 1 2 2 2nd contact 2 2 1 1 This gives each target equal probability of being contacted first. If the weights are ordered 2 then 1, then we have Wt Sum ----------- 2 2 1 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 2 2 2 1 2nd contact 1 1 1 2 The weight 2 target is contacted first with a probability of 3/4. Overall the probabilities for 1st contact are 3/8 and 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ _order_is_randomly_chosen_, but this is not specified. According to my reckoning, consistent, correct results are obtained if the random number is chosen to be between _ONE_ and the sum computed. Q3) Does anyone agree or disagree with this? If what is meant by 1st contact is the 1st successful attempt to find a Target, from whereupon this target's service is always used until it's TTL expiry or failure, then load sharing is only effected by different clients choosing different 1st contacts. On the other hand, if it means that a client which is a frequent, heavy user of a service client works down a sequence of targets to select which one provides the service next, all targets are selected with equal frequency. It seems to me that there is an assumption here that target contact selection from any particular client is very infrequent, and that load sharing occurs by virtue of different clients making 1st contact to different targets. In a system who's application makes frequent heavy of a service, service selection should be purely probabilistic based on the relative weights of the highest priority records available. Q4) Can anyone clarify this matter? Q5) Does anyone have any DNS SRV sniffer trace they could send directly to me to throw more light on the message format? (Please mail the group to say you have responded to this one, to save me being flooded!) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: bill <bmanning@karoshi.com> Subject: Re: comment on NSEC RDATA format draft -04 Date: Sat, 6 Mar 2004 06:57:33 -0800 (PST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:03:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: scottr@nist.gov (Scott Rose) In-Reply-To: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> from "Scott Rose" at Mar 04, 2004 08:37:31 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The > text states that there are no special TTL requirements for the NSEC RR. > However, in the new DNSSECbis specs, we have the following suggestion for > TTL values (records draft-07): > > The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL > field. This is in the spirit of negative caching [RFC2308]. > > Minor difference since the above is a suggestion, and there are no real > special requirements for the TTL. I think the NSEC data draft should > include the above for consistancy. > > Scott ack. this is a reasonable thing to do. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 10:31:55 -0500 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:41:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Barry Desborough <Barry.Desborough@wanadoo.fr> In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > From page 3 of rfc2782 > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive) > Random number case 0 1 2 3 > 1st contact 1 1 2 2 > 2nd contact 2 2 1 1 You appear to be computing a random integer, rather than a random real number, as was intended. If you choose a random real number, you'll get the appropriate distribution (a server with weight 2 is chosen twice as often with a server of weight 1). I would have much preferred a statement which used random integers (which is something you can actually do on a computer), but the working group was having a little trouble coming up with an algorithm statement that actually worked, so we decided to go with one which we strongly believed was correct even if it wasn't very clear and which didn't translate easily into code. It's particularly galling to me that we didn't even state explicitly what kind of number is to be chosen (integer, rational, computable, real, complex...), and then we threw in this parenthetical note "(inclusive)" which actually has no effect on the outcome if real numbers are being chosen. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. Neither of these choices seems appropriate. The TTL only applies to the DNS data itself, not the processing of it, so it would be wrong to choose a server once and then stick with it until the TTL expires. It would also be wrong to walk the list of choices when making multiple successful contacts; the idea is to walk the list when making a single contact until you are successful, then throw the list away. The next time you make a contact, you should start all over again and choose a new contact order randomly according to the weights. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 19:08:47 +0200 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:19:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 03:03:22PM +0100, Barry Desborough wrote: > Here is the format of the SRV RR, whose DNS type code is 33: > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > NAME TYPE CLASS TTL RDLENGTH RDATA RFC1035 deals with the on-the-wire encoding, while the SRV text above seems to be related to the usual BIND-style zone file format. The examples in RFC 2782 bear this out. However, re-reading RFC 2782 and RFC 2052, I could not determine a definitive on-the-wire encoding of SRV records -- this seems to be undefined. Presumably, implementors have just looked at how BIND returns SRV records and gone with that. > According to 1035, and assuming that 'SRV' refers to TYPE, > (not specified in 2782), The section "Usage rules" mentions QTYPE=SRV, and there is further text the SRV RR, whose DNS type code is 33 and The IANA has assigned RR type value 33 to the SRV RR which seems to tie SRV to TYPE, although perhaps not very directly. > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? I tried to find an online deployment of SRV records to feed to tcpdump, but the closest I came was an SOA record for _tcp.microsoft.com (one of the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no appear to have _tcp subdomains. Does anyone actually have a deployment of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? I also tried to find the IANA assignments for the Service tags, as referred to in RFC 2782, and couldn't locate any. Have any actually been standardized? If so, a pointer would be appreciated! -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 12:29:42 -0500 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:40:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? We appear to have: _sip._tcp.mit.edu _sip._udp.mit.edu _sip._tcp.sipxchange.mit.edu _sip._udp.sipxchange.mit.edu _kerberos._udp.athena.mit.edu _kerberos-master._udp.athena.mit.edu _kerberos-adm._tcp.athena.mit.edu -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:37:28 +0000 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <Barry.Desborough@wanadoo.fr> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:46:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from "Barry Desborough" <Barry.Desborough@wanadoo.fr> of "Sat, 06 Mar 2004 15:03:22 +0100." <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > From rfc2782 page 2 > > "The format of the SRV RR > > Here is the format of the SRV RR, whose DNS type code is 33: > > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > > NAME TYPE CLASS TTL RDLENGTH RDATA > ... > Q1) Which rfc is correct? both. rdlength is a protocol element describing rdata. the <rdlength,rdata> tuple is used to represent the rr data, which in this case is itself a tuple: <Priority,Weight,Port,Target>. in "dns master file" format as entered into zone files and as displayed by utilities such as "dig", rdlength is used to encode and decode the rr data but is never specified or displayed directly. > Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? > Could not the contents of Target have been be reported in the NAME field > and the Target field be dispensed with? because the names of the servers capable of responding to requests may not have names equal or similar to the name of the service. this is analagous to MX records, where the target name can be a service provider even though the query name is that of a customer. > ... > Overall the probabilities for 1st contact are 3/8 and > 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ > _order_is_randomly_chosen_, but this is not specified. > > According to my reckoning, consistent, correct results are > obtained if the random number is chosen to be between > _ONE_ and the sum computed. > > Q3) Does anyone agree or disagree with this? it seems reasonable to me, but i didn't write that part of the rfc and i'm not sure i ever understood it. greg hudson's answer was that the numbers had to be real not integer, and this may indeed be the case. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. > > It seems to me that there is an assumption here that target contact > selection from any particular client is very infrequent, and that > load sharing occurs by virtue of different clients making 1st contact > to different targets. no, actually we contemplated a web-like service where an object and all of the sub-objects (such as images) mentioned in that object should ideally be fetched from the same server, in case that server was capable of opportunistic pipelining or prefetching. > In a system who's application makes frequent heavy of a service, > service selection should be purely probabilistic based on the relative > weights of the highest priority records available. > > Q4) Can anyone clarify this matter? we contemplated making "sticky-ness" or "re-use" a protocol element but we felt that the SRV algorythm was already beyond its complexity horizon. the right thing to do now is: remove that part of the spec and designate re-use as "requestor-specific local policy". > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? (Please > mail the group to say you have responded to this one, to save me being > flooded!) ;; QUESTION SECTION: ;_kerberos._udp.vix.com. IN SRV ;; ANSWER SECTION: _kerberos._udp.vix.com. 3600 IN SRV 0 1 88 kerberos-0.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-1.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-2.vix.com. ;; AUTHORITY SECTION: vix.com. 3178 IN NS ns.lah1.vix.com. vix.com. 3178 IN NS ns.sql1.vix.com. vix.com. 3178 IN NS ns-ext.isc.org. ;; ADDITIONAL SECTION: ns.lah1.vix.com. 2429 IN A 204.152.188.234 ns.lah1.vix.com. 2429 IN AAAA 2001:4f8:2::9 ns.sql1.vix.com. 2429 IN A 204.152.184.135 ns.sql1.vix.com. 2429 IN AAAA 2001:4f8:3::9 ns-ext.isc.org. 3055 IN A 204.152.184.64 ns-ext.isc.org. 3057 IN AAAA 2001:4f8:0:2::13 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:48:11 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:53:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 06 Mar 2004 19:08:47 +0200." <20040306170847.GB24117@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > ... > RFC1035 deals with the on-the-wire encoding, while the SRV text > above seems to be related to the usual BIND-style zone file format. > The examples in RFC 2782 bear this out. However, re-reading RFC 2782 > and RFC 2052, I could not determine a definitive on-the-wire encoding > of SRV records -- this seems to be undefined. Presumably, implementors > have just looked at how BIND returns SRV records and gone with that. note that if BIND is shown to be wrong, we (isc) will of course fix it. > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? vix.com has no SRV-discovered services that use tcp as their transport. (presumably if we were a macintosh shop or a windows shop, we would?) _kerberos._udp.vix.com/IN/SRV has some data for you, though. > I also tried to find the IANA assignments for the Service tags, as > referred to in RFC 2782, and couldn't locate any. Have any actually > been standardized? If so, a pointer would be appreciated! here's the problem. SRV is experimental. 2052 was "snuck through" the ietf process when iesg's attention was focused elsewhere, and they got Really Angry about it when they found out. i've apologized, since mostly i was acting in ignorance and without malice, but it hasn't helped. so, in spite of the significant deployment of SRV in the community (like with the service discovery protocols currently shipped by microsoft and apple), SRV remains experimental. and as long as it's only experimental, iana's charter does not cover it. what we need to do is in two stages. first, iesg has to tell me how i can mend relations and achieve some kind of pardon for past SRV-related misdeeds. (perhaps a public apologia at an iesg plenary would suffice?) second, iana should create a registry of service identifiers, by importing the BSD file "/etc/services" and then periodically amending it for new standards -- and new standards should allocate a service name not just a default port number. i don't know how to do either of those things but that's the list, anyway. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jarle Greipsland <jarle@uninett.no> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 20:01:52 +0100 (CET) Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:07:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV > outside pseudo-DNS dynamic zones tied to DHCP servers? _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV -jarle -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 14:08:35 -0500 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:14:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 13:48, Paul Vixie wrote: > here's the problem. SRV is experimental. 2052 was "snuck through" the > ietf process when iesg's attention was focused elsewhere, and they got > Really Angry about it when they found out. Your history seems to be omitting the part where we got RFC 2782 published as a proposed standard (with you as one of the authors). That one certainly wasn't snuck through the IESG; we got significant feedback about the static weighting system, among other things. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 19:49:01 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <ghudson@MIT.EDU> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:56:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU> of "Sat, 06 Mar 2004 14:08:35 EST." <1078600115.9992.140.camel@error-messages.mit.edu> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > here's the problem. SRV is experimental. 2052 was "snuck through" the > > ietf process when iesg's attention was focused elsewhere, and they got > > Really Angry about it when they found out. > > Your history seems to be omitting the part where we got RFC 2782 > published as a proposed standard (with you as one of the authors). That > one certainly wasn't snuck through the IESG; we got significant feedback > about the static weighting system, among other things. indeed. i was thinking only of 2052 in my recounting. in that case there's nothing stopping someone from writing an rfc to immortalize /etc/services and making that file an iana database. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: David Shaw <dshaw@jabberwocky.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:13:42 -0500 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 21:20:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <20040306170847.GB24117@dns.net> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 07:08:47PM +0200, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV outside > pseudo-DNS dynamic zones tied to DHCP servers? _hkp._tcp.pgp.net to help find PGP keyservers. David -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sun, 7 Mar 2004 18:24:27 +0200 (EET) Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 03:29:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Hi, [[ note: I'm not subscribed... ]] I took a quick look at the DNSSEC intro document; it was in a very good shape. Two major comments: 1) the document requires the use of EDNS0. However, current EDNS0 implementations typically advertise the larger sizes than they can handle at the IP layer, causing fragmentation. You can argue that this is OK as long as the result of NOT fragmenting would end up with a worse result than as you would be without it (e.g., requiring falling back to TCP, or whatever). With DNSSEC, I'm not sure that this holds anymore. It seems to me that the best behaviour would be to avoid IP fragmentation by having correct implementations of EDNS0, and if some data must be left out, that it would be fetched separately, over second, third, ..., nth query over UDP. Shouldn't that be possible and reasonable? 2) Security considerations lists a number of threats, but does not discuss whether they have been fixed or mitigated at all (e.g., relating to dynamic updates and signing). It might not hurt to be a bit more explicit on this. Similarly, maybe some of this text could be included in the DNS security analysis document as well... editorial --------- page 4, chapter 2, replace "RRsets forms" with "RRsets forming" -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 03:09:22 +0000 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 04:15:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Sun, 07 Mar 2004 18:24:27 +0200." <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). most of <http://research.compaq.com/wrl/techreports/abstracts/87.3.html>'s concerns about fragmentation have been addressed, and the ones which still apply are relevant to small-mtu connections ("don't do that") and to high performance/demand mobygram applications (nfs, tcp). for dns, it's okay. > With DNSSEC, I'm not sure that this holds anymore. It seems to me > that the best behaviour would be to avoid IP fragmentation by having > correct implementations of EDNS0, and if some data must be left out, > that it would be fetched separately, over second, third, ..., nth > query over UDP. Shouldn't that be possible and reasonable? no, that really would force tcp, which really would be worse than ip-frag. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 13:47:21 +0900 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 05:55:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O Paul; > no, that really would force tcp, which really would be worse than ip-frag. If message size is 1400B or so, it is definitely so. If message size is 4200B or so, it can still be a valid argument. However, if message size is 64000B, TCP is far better than IP-frag. I understand the problem is not of DNSSEC but of EDNS0. But with the current EDNS0 specification lacking rational upper limit on message size, it will be safe if DNSSEC says: messages over UDP MUST NOT be larger than 4000 Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 05:02:50 +0000 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 06:08:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 13:47:21 +0900." <404BFAD9.80109@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > no, that really would force tcp, which really would be worse than ip-frag. > > If message size is 1400B or so, it is definitely so. > > If message size is 4200B or so, it can still be a valid argument. > > However, if message size is 64000B, TCP is far better than IP-frag. yes, that's true. the crossover is probably closer to 4*PMTU. > I understand the problem is not of DNSSEC but of EDNS0. > > But with the current EDNS0 specification lacking rational upper > limit on message size, it will be safe if DNSSEC says: > > messages over UDP MUST NOT be larger than 4000 it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E is for Estimated) but this isn't the time or place to make that change. so perhaps an advisory statement like "Note: advertising a buffer size larger than EPMTU could lead to unfortunate overaggressive IP fragmentation" would be enough to tell the dnssec implementor crowd -- who is likely to be the first real stress-testers of EDNS0's buffer size extension -- what they need to know, without actually amending the EDNS0 specification by side effect. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 14:58:13 +0900 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:02:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >> messages over UDP MUST NOT be larger than 4000 > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. I meant DNSSEC entities MUST NOT send messages larger than 4000 over UDP Can it be within the scope of DNSSEC? > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E > is for Estimated) but this isn't the time or place to make that change. If EDNS0 is to be changed (in the future, of course), reference to PMTUD should be clarified (removed entirely), because EDNS0 seemingly assumes fragmentation is always enabled, which means there is no room for PMTUD, which means, with IPv6, packets must be fragmented at the source. Or, if you think some form of PMTUD should be performed, it should be documented (though I think PMTUD practically impossible). > so perhaps an advisory statement like "Note: advertising a buffer size larger > than EPMTU could lead to unfortunate overaggressive IP fragmentation" would > be enough to tell the dnssec implementor crowd -- who is likely to be the > first real stress-testers of EDNS0's buffer size extension -- what they need > to know, without actually amending the EDNS0 specification by side effect. :-) Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:26:31 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:33:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Mon, 08 Mar 2004 07:37:47 +0200." <Pine.LNX.4.44.0403080733160.16733-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... would force tcp, which really would be worse than ip-frag. > > Seems like a flaw in DNS spec -- too coarse granularity: > 1) "everything fits in one UDP datagram", or > 2) "just use TCP". > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > datagram of specific size, query again, but only the missing data this > time". sense, yes, but the atomicity requirements are hard to adjust in that light. for example, if what you're trying to send is a referral, and the query and authority sections are all that fits, and you decide to just send that much and let the initiator re-query for the parts that would have been in the additional-data section, then it might end up being the case that they can never query for it. consider an authority section whose names are all under the referral cut. in earlier work once proposed as part of EDNS0 and then reintroduced as EDNS1, the idea came up to indicate in a response that there were multiple messages in the answer. we called it MD ("more data"). ultimately this turned out to be a lot more complicated than it sounded, and it's since been abandoned. i dearly wish that EDNS0 had made TTCP its prerequisite. ("ah, hindsight.") > Not sure if that would make sense but instead of forcing everything in > one, probably fragmented message, it would seem to encourage "proper" > operation with big DNS replies. in general, if you think the response might be larger than 3*EPMTU, use tcp, and that will amortize the complexity nicely. note that PMTUD hasn't been a raging success, and that EPMTU is probably 1500 octets most of the time, and that's where masataka's "4000" number comes from. > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. yes but on such a host, the EDNS0 initiator would presumably be able to discover this limitation and advertise a 1500-octet buffer. that's what the EDNS0 spec says it should do, at any rate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:29:28 +0000 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:34:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 14:58:13 +0900." <404C0B75.3000303@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > of scope. > > I meant > > DNSSEC entities MUST NOT send messages larger than 4000 > over UDP > > Can it be within the scope of DNSSEC? then it would be within scope for this docset, but extremely controversial since it places a requirement more stringent than EDNS0. far better to make it advisory and avoid the fight. > > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU > > (where E is for Estimated) but this isn't the time or place to make > > that change. > > If EDNS0 is to be changed (in the future, of course), reference to > PMTUD should be clarified (removed entirely), because EDNS0 seemingly > assumes fragmentation is always enabled, which means there is no room > for PMTUD, which means, with IPv6, packets must be fragmented at the > source. > > Or, if you think some form of PMTUD should be performed, it should be > documented (though I think PMTUD practically impossible). i think that you're right and that all hope of PMTUD should be abandoned in the next update of EDNS, which at this point would be EDNS1 rather than a reissue of EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 10:11:02 +0100 Organization: NIC France Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <20040306.200152.46801952.jarle@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 10:22:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jarle Greipsland <jarle@uninett.no> Content-Disposition: inline In-Reply-To: <20040306.200152.46801952.jarle@uninett.no> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.25-1-k7 i686 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 08:01:52PM +0100, Jarle Greipsland <jarle@uninett.no> wrote a message of 16 lines which said: > _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV Which is documented in: http://mailbox.univie.ac.at/~gw/draft-sanz-whois-srv-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 11:10:08 +0100 Lines: 196 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <1078587114.9992.126.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C404FD.EAE798E0" Cc: "Attila" <Attila.Sipos@VegaStream.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 11:32:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Greg Hudson" <ghudson@MIT.EDU> 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 Precedence: bulk Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your help, Greg. There's a note below about selection using random integers. ----- Original Message -----=20 From: "Greg Hudson" <ghudson@MIT.EDU> To: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Cc: <namedroppers@ops.ietf.org> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: DNS SRV Clarification sought > On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > > From page 3 of rfc2782 > > Compute the sum of the weights of those RRs, and with each = RR > > associate the running sum in the selected order. Then choose = a > > uniform random number between 0 and the sum computed > > (inclusive) > > > Random number case 0 1 2 3 > > 1st contact 1 1 2 2 > > 2nd contact 2 2 1 1 > > You appear to be computing a random integer, rather than a random real > number, as was intended. If you choose a random real number, you'll = get > the appropriate distribution (a server with weight 2 is chosen twice = as > often with a server of weight 1). > > I would have much preferred a statement which used random integers > (which is something you can actually do on a computer), but the = working > group was having a little trouble coming up with an algorithm = statement > that actually worked, so we decided to go with one which we strongly > believed was correct even if it wasn't very clear and which didn't > translate easily into code. Demonstration of selection using random integers. (Hope the fixed font is preserved and there's no line folding) Item Cumulative (weight) sum ---- -----=20 a a b a+b c a+b+c . . . . n a+b+c+...+n i.e.(sum(a...n)) Choosing a random integer between 1 and sum(a...n) inclusive and = selecting the first item greater than or equal to the random integer, we have - Random integer range 1...a a+1...a+b a+b+1...a+b+c Random integer frequency a (a+b)-(a+1)+1=3Db = (a+b+c)-(a+b+1)+1=3Dc Probability a/sum(a...n) b/sum(a...n) c/sum(a...n) For any item say, i, h being the previous item, Random integer range sum(a...h)+1...sum(a...i) Random integer frequency sum(a...i)-(sum(a...h)+1)+1=3Di Probability i/sum(a...n) Barry Desborough ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV>Thanks for your help, = Greg. There's a note=20 below about selection using random integers. ----- Original = Message -----=20 From: "Greg Hudson" <<A = href=3D"mailto:ghudson@MIT.EDU"><FONT=20 face=3DArial size=3D2>ghudson@MIT.EDU</A>> To:=20 "Barry Desborough" <<A = href=3D"mailto:Barry.Desborough@wanadoo.fr"><FONT=20 face=3DArial size=3D2>Barry.Desborough@wanadoo.fr</A>> Cc: <<A = href=3D"mailto:namedroppers@ops.ietf.org"><FONT=20 face=3DArial size=3D2>namedroppers@ops.ietf.org</A>> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: = DNS SRV=20 Clarification sought > On Sat, 2004-03-06 at 09:03, Barry=20 Desborough wrote: > > From page 3 of rfc2782 >=20 > Compute the sum of = the=20 weights of those RRs, and with each RR >=20 > associate the = running sum=20 in the selected order. Then choose a >=20 > uniform random = number=20 between 0 and the sum computed >=20 > = (inclusive) > >=20 > Random number case 0 1 2 3 > > 1st=20 contact = =20 1 1 2 2 > > 2nd=20 contact = =20 2 2 1 1 > > You appear to be computing a random integer, = rather than=20 a random real > number, as was intended. If you choose a = random real=20 number, you'll get > the appropriate distribution (a server with = weight 2=20 is chosen twice as > often with a server of weight = 1). > > I=20 would have much preferred a statement which used random integers > = (which=20 is something you can actually do on a computer), but the working > = group=20 was having a little trouble coming up with an algorithm = statement > that=20 actually worked, so we decided to go with one which we strongly > = believed=20 was correct even if it wasn't very clear and which didn't > = translate=20 easily into code. Demonstration of = selection=20 using random integers. (Hope the fixed font is preserved and there's = no line=20 folding) Item =20 Cumulative</DIV> <DIV>(weight) =20 sum ---- -----=20 a =20 a b =20 a+b c =20 a+b+c . =20 . . =20 . n a+b+c+...+n = i.e.(sum(a...n)) Choosing a random integer between 1 and = sum(a...n)=20 inclusive and selecting the first item greater than or equal to the = random=20 integer, we have -</DIV> <DIV> Random integer=20 range =20 1...a =20 a+1...a+b = a+b+1...a+b+c Random=20 integer frequency =20 a =20 (a+b)-(a+1)+1=3Db =20 (a+b+c)-(a+b+1)+1=3Dc Probability &= nbsp; =20 a/sum(a...n) b/sum(a...n) = c/sum(a...n) For any=20 item say, i, h being the previous item,</DIV> <DIV> Random integer=20 range sum(a...h)+1...sum(a...i) Random = integer=20 frequency =20 sum(a...i)-(sum(a...h)+1)+1=3Di Probability &nb= sp; =20 i/sum(a...n) Barry Desborough </DIV></BODY></HTML> ------=_NextPart_000_0007_01C404FD.EAE798E0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:59:49 -0500 Organization: NIST Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Pekka Savola" <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 16:39:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O ----- Original Message ----- From: "Paul Vixie" <paul@vix.com> > > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > > of scope. > > > > I meant > > > > DNSSEC entities MUST NOT send messages larger than 4000 > > over UDP > > > > Can it be within the scope of DNSSEC? > > then it would be within scope for this docset, but extremely controversial > since it places a requirement more stringent than EDNS0. far better to make > it advisory and avoid the fight. > It would also be an arbitrary limit based on current underlying network layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or EDNS0. It would best not be made a strict constraint that might be made obsolete by non-DNS factors. I agree with Paul in that it would be better to be an advisory statement, but not necessary to the specification. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 19:10:10 +1100 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 09:41:34 +0200." <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > What's your issue here? > > > > IPv4 has reassembly buffer size limits. > > IPv6 has reassembly buffer size limits. > > > > In either case you don't advertise a EDNS UDP buffer bigger > > than this limit. > > It would be nice if EDNS0 implementations conformed to these buffer > sizes then. On what platforms do the existing implementation not take these into account. Note most *nix platforms support 4k UDP datagrams already. > Currently it seems they have zero relation to MTU or PMTU, or buffer > sizes. There doesn't have to be a *explict* relationship to these. The current recommendations already take these into account. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 07:37:47 +0200 (EET) Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > With DNSSEC, I'm not sure that this holds anymore. It seems to me > > that the best behaviour would be to avoid IP fragmentation by having > > correct implementations of EDNS0, and if some data must be left out, > > that it would be fetched separately, over second, third, ..., nth > > query over UDP. Shouldn't that be possible and reasonable? > > no, that really would force tcp, which really would be worse than ip-frag. Seems like a flaw in DNS spec -- too coarse granularity: 1) "everything fits in one UDP datagram", or 2) "just use TCP". Would it make sense to add 1.5) there, "if it doesn't fit to a UDP datagram of specific size, query again, but only the missing data this time". Not sure if that would make sense but instead of forcing everything in one, probably fragmented message, it would seem to encourage "proper" operation with big DNS replies. Btw: note that IPv6 implementations aren't even required to defragment a datagram which is larger than 1500 bytes once assembled.. so we're in a bit murky waters here. I'd certainly want to try to avoid packet sizes >= ~1500. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:41:34 +0200 (EET) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200403080658.i286wXcq013551@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080658.i286wXcq013551@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > What's your issue here? > > IPv4 has reassembly buffer size limits. > IPv6 has reassembly buffer size limits. > > In either case you don't advertise a EDNS UDP buffer bigger > than this limit. It would be nice if EDNS0 implementations conformed to these buffer sizes then. Currently it seems they have zero relation to MTU or PMTU, or buffer sizes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 17:58:33 +1100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:05:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 06:26:31 -0000." <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. What's your issue here? IPv4 has reassembly buffer size limits. IPv6 has reassembly buffer size limits. In either case you don't advertise a EDNS UDP buffer bigger than this limit. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 10:08:33 -0600 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:18:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> Precedence: bulk Status: O On 3/6/2004 12:48 PM, Paul Vixie wrote: > iana should create a registry of service identifiers, by importing the > BSD file "/etc/services" and then periodically amending it for new > standards Is that really feasible? Service definitions may require weighting values and client-selection algorithms to be useful, all of which requires some level of agreement among implementors. If we start with a list of defaults and then update the list on-the-fly, how does the client know which version of the list entry is in use for those SRV RRs that they encounter? The nice thing about the current model is that an entry in the list connotes agreement among implementors, or at least carries a footnote. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 17:25:32 +0100 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <404C9A81.2040708@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:34:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 10:08:33 CST." <404C9A81.2040708@ehsco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <26114.1078763131.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Eric A. Hall wrote: > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards which would be different from <http://www.iana.org/assignments/port-numbers>? > Is that really feasible? Service definitions may require weighting values What weighting values are you talking about? Those in the SRV RR are not supposed to carry any additional meaning. RFC 2782 is pretty clear about the service names to be used: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. [...] Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. STD 2 is obsoleted by RFC 3232, again pointing to the URL above (although rather indirectly). What may be missing is a list of services without portnumber. In the whois case mentioned earlier inthis thread (which, btw uses "nicname" instead of the more prominent "whois" because of the "Service" requirement cited above) one would sometimes like to further differentiate the service without really using a different protocol, e.g. _ripe_whois.tcp... -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:21:20 +0200 (EET) Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <200403080810.i288AAcq036874@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:24:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080810.i288AAcq036874@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > > It would be nice if EDNS0 implementations conformed to these buffer > > sizes then. > > On what platforms do the existing implementation not take > these into account. Note most *nix platforms support 4k > UDP datagrams already. I don't know, maybe some embedded systems have restrictions. In any case 4000 byte UDP buffers does not equal being able to defragment datagrams worth of 4000 bytes total, right? > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > sizes. > > There doesn't have to be a *explict* relationship to these. > The current recommendations already take these into account. Well, about all the implementations I've seen set the EDNS0 irrespective of the MTU or PMTU configured on the system, which might make sense. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET) Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:25:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > > ... would force tcp, which really would be worse than ip-frag. > > > > Seems like a flaw in DNS spec -- too coarse granularity: > > 1) "everything fits in one UDP datagram", or > > 2) "just use TCP". > > > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > > datagram of specific size, query again, but only the missing data this > > time". > > sense, yes, but the atomicity requirements are hard to adjust in that light. Precisely -- but IMHO we need to figure out whether such atomicity requirements exist. They very certainly exist with 512 byte limit and DNSSEC. But do they exist e.g., with 1400 bytes? I'm a bit doubtful.. but I'd be interested in hearing what might be a "typical case", a "bad case", and "worst case". (We'll never be able to handle the last one, of course.) > > Not sure if that would make sense but instead of forcing everything in > > one, probably fragmented message, it would seem to encourage "proper" > > operation with big DNS replies. > > in general, if you think the response might be larger than 3*EPMTU, use tcp, > and that will amortize the complexity nicely. note that PMTUD hasn't been a > raging success, and that EPMTU is probably 1500 octets most of the time, and > that's where masataka's "4000" number comes from. Yep, EPMTU is 1500 bytes or a bit less -- but isn't that sufficient for about all intents and purposes? > > Btw: note that IPv6 implementations aren't even required to defragment > > a datagram which is larger than 1500 bytes once assembled.. so we're > > in a bit murky waters here. I'd certainly want to try to avoid packet > > sizes >= ~1500. > > yes but on such a host, the EDNS0 initiator would presumably be able to > discover this limitation and advertise a 1500-octet buffer. that's what > the EDNS0 spec says it should do, at any rate. Should, yes :). Does, no. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 12:03:05 -0600 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:10:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O On 3/8/2004 10:25 AM, Peter Koch wrote: > Eric A. Hall wrote: >> Is that really feasible? Service definitions may require weighting >> values > > What weighting values are you talking about? Those in the SRV RR are > not supposed to carry any additional meaning. The 'priority' field is different from the 'weight' field. RFC2782 says the following about the weight: | In the absence of a protocol whose specification calls for the | use of other weighting information, a client arranges the SRV | RRs of the same Priority in the order in which target hosts, | specified by the SRV RRs, will be contacted. > RFC 2782 is pretty clear about the service names to be used: Well, that's not the whole ball of wax. Service names can vary for reasosn other than protocol (http != www). Service names are relative labels which do not describe behavioral rules which may be associated with the service in general (algorithm may require SRV for in-addr space, or domain-wide space, or host-specific maps). Etc. Really, it seems to me that it's best to leave the list of well-known definitions for those SRV mappings and algorithms which are actually defined by the affected community. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: <fenner@research.att.com> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 03:47:36 +0900 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:54:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: pk@TechFak.Uni-Bielefeld.DE Versions: dmail (solaris) 2.5a/makemail 2.9d Precedence: bulk Status: O >> > iana should create a registry of service identifiers, by importing the >> > BSD file "/etc/services" and then periodically amending it for new >> > standards > >which would be different from ><http://www.iana.org/assignments/port-numbers>? Actually, I always thought that RFC 2782's [STD 2] reference was to the "PROTOCOL AND SERVICE NAMES" section, aka <http://www.iana.org/assignments/service-names>, and people who looked for the names in port-numbers were confused by the lack of strong binding to the reference (since there's no strong requirement for a port number assignment, just a name). Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 20:32:14 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 20:39:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 09 Mar 2004 03:47:36 +0900." <200403081847.i28IlbS24713@windsor.research.att.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <27142.1078774333.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Bill Fenner wrote: > was to the "PROTOCOL AND SERVICE NAMES" section, aka > <http://www.iana.org/assignments/service-names>, and people who looked this teaches us that the registry name will need to be specified explicitly, especially since URL references to the IANA registries are (were when I tried) only allowed to point to http://www.iana.org/numbers.html. > for the names in port-numbers were confused by the lack of strong binding Thanks, and increase the number of confused :-) > to the reference (since there's no strong requirement for a port number > assignment, just a name). The document you mention references WKS RRs, and since SRV is an orthogonal, though not totally unrelated, concept, it may be useful to use the same registry. However, since WKS uses port numbers (in a bit string) on-the-wire, I'm not too sure I understand the reasoning behind a registry dealing with names *only*. What's more important is some kind of link to the spec describing a) the protocol and b) use of SRV RRs in connection with that protocol. Elevation of 2782 will give us an opportunity to clarify this. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 05:41:18 +1100 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 21:19:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 18:21:20 +0200." <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > > It would be nice if EDNS0 implementations conformed to these buffer > > > sizes then. > > > > On what platforms do the existing implementation not take > > these into account. Note most *nix platforms support 4k > > UDP datagrams already. > > I don't know, maybe some embedded systems have restrictions. Well if you are writing a resolver for such a system you take its IP stack limitations into consideration. There are lots of additional considerations when writing for small memory platforms. Nobody is saying you *MUST* use certain size, just that they are recommended. Named has a switch to set the advertised size to 512. > In any case 4000 byte UDP buffers does not equal being able to > defragment datagrams worth of 4000 bytes total, right? > > > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > > sizes. > > > > There doesn't have to be a *explict* relationship to these. > > The current recommendations already take these into account. > > Well, about all the implementations I've seen set the EDNS0 > irrespective of the MTU or PMTU configured on the system, which might > make sense. With the current Internet the min(MTU,PMTU) will usually be 1500, ethernet/ppp default. Rarely will it be below 1200, slip default. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 13:17:05 -0800 Lines: 76 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 22:23:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Eric A. Hall'" <ehall@ehsco.com>, Paul Vixie <paul@vix.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O Registies are over-rated. Look at the number of programs there are on windows that have their own file format. Important name collisions are pretty rare considering that it is essentially a 3 character identifier. All that matters here is that the identifier be unique and plentiful enough that they do not run out. If you try to impose any requirement that is more stringent than first come first served we end up back with the X-Header problem. We could adopt the hash-cash scheme that Microsoft is pushing for anti-spam as a way of rationing code points in tables. All code points are first come first served. To get the code point 'SPAM' in table 'SRV' you have to provide a string s such that SHA1(s) - SHA1('SPAM+SRV') <> 0 AND |SHA1(s) - SHA1('SPAM+SRV')| < 2^(160-n) I.e. the strings must not be the same and the first n bits must match. The value of n would increase as the code points in the registry were exhausted. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eric A. Hall > Sent: Monday, March 08, 2004 11:09 AM > To: Paul Vixie > Cc: namedroppers@ops.ietf.org > Subject: Re: DNS SRV Clarification sought > > > > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by > importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards > > Is that really feasible? Service definitions may require > weighting values > and client-selection algorithms to be useful, all of which > requires some > level of agreement among implementors. > > If we start with a list of defaults and then update the list > on-the-fly, > how does the client know which version of the list entry is in use for > those SRV RRs that they encounter? > > The nice thing about the current model is that an entry in the list > connotes agreement among implementors, or at least carries a footnote. > > -- > Eric A. Hall > http://www.ehsco.com/ > Internet Core Protocols > http://www.oreilly.com/catalog/coreprot/ > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:02:38 +0900 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> <000301c40521$f3ba77c0$1a1f0681@lapdancer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:08:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Scott Rose <scottr@nist.gov> In-Reply-To: <000301c40521$f3ba77c0$1a1f0681@lapdancer> Precedence: bulk Status: O Scott Rose; > It would also be an arbitrary limit based on current underlying network > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > EDNS0. 512 byte limit is a bound not by DNS but by the current underlying network and transport layers. So? > but not necessary to the specification. It is necessary that DNS message size has a limit in the specification. Masataka Ohta PS The proper limit bound by minimum reassembly buffer size, maximum IP header length and UDP header length is 508. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:46:37 +0900 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:51:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > Why are we arguing about the minimums that have to be > supported by the architecure? Because the minimums of the infrastructure are maximums of DNS. > For example, named has a upper bound on the size of the > EDNS/UDP response it will send. And, it should be specified. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 09:38:11 +0900 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 02:44:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > EDNS and DNS are *different* protocols which share a port and > message format. RFC2671 This document describes backward compatible mechanisms for allowing the protocol to *GROW*. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 09:13:19 +0100 Organization: RIPE NCC Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <1078594181.9992.134.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 09:26:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Greg Hudson <ghudson@MIT.EDU> In-Reply-To: <1078594181.9992.134.camel@error-messages.mit.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.473609 / 0.0 / 0.0 X-RIPE-Signature: 86a7b34adf4294872cd6cf962183ce6b Precedence: bulk Status: O On Sat, 06 Mar 2004 12:29:42 -0500 Greg Hudson <ghudson@MIT.EDU> wrote: > On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > > I tried to find an online deployment of SRV records to feed to tcpdump, > > but the closest I came was an SOA record for _tcp.microsoft.com (one of > > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > > appear to have _tcp subdomains. Does anyone actually have a deployment > > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? > > We appear to have: > > _sip._tcp.mit.edu > _sip._udp.mit.edu > _sip._tcp.sipxchange.mit.edu > _sip._udp.sipxchange.mit.edu Where the use of SRV for SIP is documented in RFC3263 -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 11:23:43 +1100 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:46:37 +0900." <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Mark Andrews; > > > Why are we arguing about the minimums that have to be > > supported by the architecure? > > Because the minimums of the infrastructure are maximums of DNS. We are talking about EDNS. Nobody is thinking about changing the DNS UDP message size. The DNS is constained in this way, EDNS is not. EDNS and DNS are *different* protocols which share a port and message format. EDNS has a UDP request size limit of 512 bytes (inherited from DNS) unless you have reason to believe a larger request can be handled. e.g. you have just made a request and have been told that a bigger request can be handled. EDNS has a *negotiated* response size limit. This is IP stack dependent and will usually be *bigger* than the infrastructure minimums. It can also be smaller the the infrastructure minimums. e.g. you have a IPv6 firewall which is rejecting DNS packets > 512 bytes so you set the EDNS UDP size advertised to 512. The advertised EDNS UDP size is less than the minimum supported by the IPv6. DNS has a UDP request and response size limit of 512 bytes. > > For example, named has a upper bound on the size of the > > EDNS/UDP response it will send. > > And, it should be specified. Why. This is a *implemtation* limit not a *protocol* limit. RFC 2671 already has guidance for seting this limit. > > Masataka Ohta > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 10:35:24 +1100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:02:38 +0900." <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Scott Rose; > > > It would also be an arbitrary limit based on current underlying network > > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > > EDNS0. > > 512 byte limit is a bound not by DNS but by the current underlying > network and transport layers. > > So? > > > but not necessary to the specification. > > It is necessary that DNS message size has a limit in the specification. > > Masataka Ohta > > PS > > The proper limit bound by minimum reassembly buffer size, maximum > IP header length and UDP header length is 508. Why are we arguing about the minimums that have to be supported by the architecure? EDNS is about letting the the other end knowing what you are *capable of handling*. There is *nothing* in to stop a site sending *smaller* EDNS/UDP message than the receiving site is capable of handling. If the client says it can accept a 4k response but you know that your firewall is broken (e.g. drops DNS packets > 512) you are quite entitled to only send a 512 byte EDNS/UDP responses. Set TC as appropriate. For example, named has a upper bound on the size of the EDNS/UDP response it will send. You can advertise a 64k UDP buffer all you want but you will not get more that 4k EDNS/UDP response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 9 Mar 2004 17:04:26 +0100 Organization: RIPE NCC Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 17:12:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> In-Reply-To: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.456200 / 0.0 / 0.0 X-RIPE-Signature: 61983aa15b37f75c7f5207c40c99cbab Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). It seems there _could_ be consensus for an advisory note targeted at implementors, if only there were such a note. Can somebody please come up with text that can be put into the document set so we can focus on getting that correct and the editors can cut-n-paste. Let us not try to fix EDNS0, that is not in scope. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Wed, 10 Mar 2004 17:58:37 +0100 Organization: RIPE NCC Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <20040128203233.08EE614C52@sa.vix.com> <6.0.3.0.2.20040212231103.02da4b80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 18:11:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040212231103.02da4b80@localhost> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000719 / 0.0 / 0.0 X-RIPE-Signature: 022e6963a054024de5098a486a89bbd4 Precedence: bulk Status: O > While attempting to summarize what the consensus of the working group > is on this editors question and trying to interpret this block of text. > Does self-consistently apply to a name or the holy Q-trinity? Having reread the threat I think that the answer to Olafurs question was in the proposed text (only for the _security_ RRs so only for specific holy Q-trinities :-) ). I propose the editors use Paul's initial text with the clarification that this only applies to those _security_ RRs that can exist above and below a delegation point. e.g. like: security aware responders who receive queries security RRs (NSEC or RRSIG RRs) which match the content of more than one zone, for example above and below a delegation point, are encouraged to behave self-consistently, which could mean: always return an error; always return above-delegation records; always return below-delegation records; always return no records; always return both above- and below-delegation records; or always something else entirely. We'll consider this question resolved if no further comments are received before the end of the week. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-04.txt Date: Wed, 10 Mar 2004 15:40:37 -0500 Lines: 86 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 21:48:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-04.txt Pages : 9 Date : 2004-3-10 This document redefines the wire format of the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:34:09 -0500 Lines: 50 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 16:43:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org Precedence: bulk Status: O The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf >Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >From: Derek Atkins <derek@ihtfp.com> >Date: Tue, 24 Feb 2004 22:14:43 -0500 > >It sounds like you want two things here, but it also sounds like all >of them need to happen in the responder. The attacker could >theoretically send packets of any type, with any TTL. So you can't >trust anything you receive from the network. To this affect, I think: > >1) We want the responder to try to determine that a request came from > the local network. The best way to do this is for the responder to > check that TTL=255 to make sure. If a TTL is less than 255 then it > originiated off-net and can be dropped. > >2) We want the responder to make sure response packets don't go > off-net. In other words, we want the responder to respond with > TTL=1, to make sure it can't smurf. > >So, to this affect: > >a) an LLMNR requestor should send requests with TTL=255 >b) an LLMNR responder should verify requests have TTL=255 -- if it is not > 255 then it should drop the packet. >c) an LLMNR responder should respond with TTL=1 >d) I dont' think an LLMNR requestor needs to check the response TTL. > >The only issue this doesn't directly solve is a requester being >spoofed by an off-net attacker, but said attacker would need >to guess the transaction id of the request in order to send a >valid response, which is just as likely in LLMNR as it is in >standard DNS, so it can probably be ignored. > >So, other than this issue, does this solve the issue? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:52:56 -0800 Lines: 161 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--207754511; protocol="application/pkcs7-signature" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 20:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-8--207754511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have an issue with this. Using a TTL of 255 to verify that requests originate from the local=20 link is not very important. It may be useful to use a unicast query to=20= specific address from off of the local link to ask for records such as=20= HINFO. In the case of multicast, unless something is seriously broken a=20= link-local multicast packet is not going to be forwarded. Setting the TTL to 1 also unnecessarily prohibits unicast=20 request/responses from off of the local link. I would consider it more=20= useful to verify that a response to a link-local multicast came from=20 the local link. To those who are concerned that setting the TTL to 255 on a response=20 would enable another smurf attack, I would encourage them to try=20 pinging the all hosts multicast address. Most hosts will respond to=20 such a ping. This has not lead to any serious problems. The solution to=20= the smurf attack was to drop the subnet broadcast packets in routers=20 (don't forward them). A link local multicast packet will not be=20 forwarded. The defense against the smurf style attack is already=20 implemented. Hosts still respond to pings with subnet broadcasts but=20 routers never forward such packets, so this is only a local=20 vulnerability. If someone is local they could just as easily spoof the=20= source address of their packets as any of the other devices on the=20 local network. If the whole point of changing the TTL is to achieve interoperability=20 with Rendezvous, then the proposal below fails. -josh On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > > The chairs are looking for closure and rough consensus on this only > remaining issue for LLMNR. > The solution below seems like a good solid compromise. > Is there any technical reason why this should not be adopted, please > state so before March 24'th. > > Olafur & Olaf > > >> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >> From: Derek Atkins <derek@ihtfp.com> >> Date: Tue, 24 Feb 2004 22:14:43 -0500 >> >> It sounds like you want two things here, but it also sounds like all >> of them need to happen in the responder. The attacker could >> theoretically send packets of any type, with any TTL. So you can't >> trust anything you receive from the network. To this affect, I = think: >> >> 1) We want the responder to try to determine that a request came from >> the local network. The best way to do this is for the responder = to >> check that TTL=3D255 to make sure. If a TTL is less than 255 then = it >> originiated off-net and can be dropped. >> >> 2) We want the responder to make sure response packets don't go >> off-net. In other words, we want the responder to respond with >> TTL=3D1, to make sure it can't smurf. >> >> So, to this affect: >> >> a) an LLMNR requestor should send requests with TTL=3D255 >> b) an LLMNR responder should verify requests have TTL=3D255 -- if it = is=20 >> not >> 255 then it should drop the packet. >> c) an LLMNR responder should respond with TTL=3D1 >> d) I dont' think an LLMNR requestor needs to check the response TTL. >> >> The only issue this doesn't directly solve is a requester being >> spoofed by an off-net attacker, but said attacker would need >> to guess the transaction id of the request in order to send a >> valid response, which is just as likely in LLMNR as it is in >> standard DNS, so it can probably be ignored. >> >> So, other than this issue, does this solve the issue? > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org = with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> --Apple-Mail-8--207754511 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxMTE4NTI1N1owIwYJKoZIhvcNAQkEMRYEFP0O Ia3W8w/x+47YEoXcV/9pDyndMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAApn zOCUjtzfx/HePoVrW9B92akgPc+74/dwmULkkUhYbv/Iw+gASUnplhFK3mz62o1NZYRGb4RuHmjx ar1KWlU8rIl3QoCNBqY8q3QISGI2oApMtnVXMf0abz/IST8hTndYl02br+7iXmDdyNuUrYQmjRyt QYIV3JUzV7Q8UOBiRwPRYuSeiDvJEsCd1h5IMExVNZOBjD69fu3oMK5bVq3gHNPQyKl59BSFkJlE 3w89yzOFPI67eeDhzDVEraXIW8w04oNM6AkzxjJwNugRReSSZAe635ZDBiMFzowtQf7pdNqpSN7c Jr0s0lkNZg2K8rc+5ALBd7MpnTMj44AxUt4AAAAAAAA= --Apple-Mail-8--207754511-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Fri, 12 Mar 2004 11:37:19 -0500 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 17:49:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040228124513.02f35bc8@localhost> References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Precedence: bulk Status: O At 13:00 2004-02-28, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >This RFC was published about 6 months ago so it is now a candidate to >advance through he standards track. >In order to do that we need > evidence of implementation, > interoperabilty test and report. Jakob Schlyter <jakob@rfc.se> has stepped up and will coordinate the interoperabilty testing and write the report. (Thanks Jakob) He needs help from vendors in identifying support, please contact him to participate in the testing. Jakob and I will be contacting some vendors privately asking explicit questions of support and if they want to participate. Even though IETF rules say only two implementation are needed for the interoperabilty test, the chairs would like to include as many as possible. One important reason is the impact RFC3597 support has on the introduction of new RR types. The interoperabilty testing will address all types of DNS functional units: - Authorative servers (primary and secondary) - Recursive Resolvers (including Caches) - Stub Resolvers - Diagnostic tools The standard IETF interoperabilty rules will apply - List of implementations tested will be provided - Any problem identified will be examined to see if the source of the problem is the documentation - There will be NO public disclosure of what implementations had problems only a list of the problems. The goal here is twofold, advance a better document, allow vendors to address any problems identified sooner than later. Olafur (co-chair). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Fri, 12 Mar 2004 15:28:27 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 21:40:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 12 Mar 2004 16:56:27 -0500 Lines: 138 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 23:08:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> (Joshua Graessley's message of "Thu, 11 Mar 2004 10:52:56 -0800") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Hi, Joshua Graessley <jgraessley@apple.com> writes: > Using a TTL of 255 to verify that requests originate from the local > link is not very important. It may be useful to use a unicast query to > specific address from off of the local link to ask for records such as > HINFO. In the case of multicast, unless something is seriously broken > a link-local multicast packet is not going to be forwarded. It's exactly the fact that it's useful in a unicast query that we should do it. You are correct, multicast doesn't care, so we should use the TTL value that gives us the most bang for the buck. What does it hurt us to use TTL=3D255 and verifying it? In neither case does it hurt us. Yes, requests could leave the network, but the responder would drop them (as it should -- it's not link-local!) > Setting the TTL to 1 also unnecessarily prohibits unicast > request/responses from off of the local link. I would consider it more > useful to verify that a response to a link-local multicast came from > the local link. Indeed, this prohibition is EXACTLY WHAT WE WANT! It's not unnecessary. It's a requirement! > To those who are concerned that setting the TTL to 255 on a response > would enable another smurf attack, I would encourage them to try > pinging the all hosts multicast address. Most hosts will respond to > such a ping. Just because a problem exists in another protocol and isn't majorly exploited now does not mean that we should make the same mistake. People HAVE used DNS as a smurf/explosion attack. Pings aren't interesting -- the response is no larger than the request. DNS is VERY interesting, because I could potentially get a LARGE response for a small request. Therefore, we should protect against it. > This has not lead to any serious problems. The solution > to the smurf attack was to drop the subnet broadcast packets in > routers (don't forward them). A link local multicast packet will not > be forwarded. The defense against the smurf style attack is already > implemented. Hosts still respond to pings with subnet broadcasts but > routers never forward such packets, so this is only a local > vulnerability. If someone is local they could just as easily spoof the > source address of their packets as any of the other devices on the > local network. This type of defence does not protect against unicast LLMNR requests. Sure, a properly configured multicast router can stop the multicase requests, but it wont stop the unicast packets. That's yet another reason we should use TTL=3D1 on responses, to make sure unicast messages can't smurf. > If the whole point of changing the TTL is to achieve interoperability > with Rendezvous, then the proposal below fails. No, the whole point of this proposal is to get us out of the deadlock that we've been in by showing how we can use TTLs to get the most bang for the buck. I've listed all the threats that I think we're worried about and I've shown how the largest set of threats can be mitigated by the combined 255/1 TTL. If we can get Apple to move along with us and interoperate, great. But this proposal is not "let's make this look like Rendevous". > -josh So, Olaf and Olafur, I obviously have no technical reason why this should not be adopted ;) -derek > On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > >> >> The chairs are looking for closure and rough consensus on this only >> remaining issue for LLMNR. >> The solution below seems like a good solid compromise. >> Is there any technical reason why this should not be adopted, please >> state so before March 24'th. >> >> Olafur & Olaf >> >> >>> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >>> From: Derek Atkins <derek@ihtfp.com> >>> Date: Tue, 24 Feb 2004 22:14:43 -0500 >>> >>> It sounds like you want two things here, but it also sounds like all >>> of them need to happen in the responder. The attacker could >>> theoretically send packets of any type, with any TTL. So you can't >>> trust anything you receive from the network. To this affect, I think: >>> >>> 1) We want the responder to try to determine that a request came from >>> the local network. The best way to do this is for the responder to >>> check that TTL=3D255 to make sure. If a TTL is less than 255 then it >>> originiated off-net and can be dropped. >>> >>> 2) We want the responder to make sure response packets don't go >>> off-net. In other words, we want the responder to respond with >>> TTL=3D1, to make sure it can't smurf. >>> >>> So, to this affect: >>> >>> a) an LLMNR requestor should send requests with TTL=3D255 >>> b) an LLMNR responder should verify requests have TTL=3D255 -- if it >>> is not >>> 255 then it should drop the packet. >>> c) an LLMNR responder should respond with TTL=3D1 >>> d) I dont' think an LLMNR requestor needs to check the response TTL. >>> >>> The only issue this doesn't directly solve is a requester being >>> spoofed by an off-net attacker, but said attacker would need >>> to guess the transaction id of the request in order to send a >>> valid response, which is just as likely in LLMNR as it is in >>> standard DNS, so it can probably be ignored. >>> >>> So, other than this issue, does this solve the issue? >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: <http://ops.ietf.org/lists/namedroppers/> --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:27:07 +0900 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:35:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >>>no, that really would force tcp, which really would be worse than ip-frag. >> >>If message size is 1400B or so, it is definitely so. >> >>If message size is 4200B or so, it can still be a valid argument. >> >>However, if message size is 64000B, TCP is far better than IP-frag. > yes, that's true. the crossover is probably closer to 4*PMTU. Given 1280B of IPv6 minimum MTU, shouldn't message size limitation be somewhere around 3600 or 4800, but not 4000? Masagtaka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:48:52 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> <4052474B.9010306@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:56:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <4052474B.9010306@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O I wrote: >>yes, that's true. the crossover is probably closer to 4*PMTU. > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? My guess is that current specification of 4000B expects 3 frags over IPv4 that it should be 3600B for IPv6. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 09:35:59 +0900 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 01:53:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Precedence: bulk Status: O From: Derek Atkins <derek@ihtfp.com> >> 1) We want the responder to try to determine that a request came from >> the local network. No, we don't. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 00:58:15 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 02:06:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Sat, 13 Mar 2004 08:27:07 +0900." <4052474B.9010306@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > yes, that's true. the crossover is probably closer to 4*PMTU. > > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? i think it's all very approximate and 4000 is a very fine and round number. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 15:09:22 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 14:28:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Mon, Mar 08, 2004 at 08:32:14PM +0100, Peter Koch wrote: > Bill Fenner wrote: > > was to the "PROTOCOL AND SERVICE NAMES" section, aka > > <http://www.iana.org/assignments/service-names>, and people who looked > > this teaches us that the registry name will need to be specified explicitly, > especially since URL references to the IANA registries are (were when I tried) > only allowed to point to http://www.iana.org/numbers.html. RFC 3232 makes reference to http://www.iana.org/ which in turn makes a reference to http://www.iana.org/numbers.html but then the trail gets cold. There are several potential documents that could be relevant, for instance either http://www.iana.org/assignments/port-numbers (this is the classic /etc/services document we have all been using as a reference, but isn't obviously tied in to DNS) or http://www.iana.org/assignments/service-names (which could be relevant since it is explicitly associated with WKS records). > Elevation of 2782 will give us an opportunity to clarify this. I would like to document the "correct" usage of SRV records at DNSRD, so I agree that the next version of 2782 should explicitly refer to the correct registry document. Now, which one is it? port-numbers or service-names? -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 17:15:25 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 18:27:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 13 Mar 2004 15:09:22 +0200." <20040313130922.GA23428@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > Elevation of 2782 will give us an opportunity to clarify this. > > I would like to document the "correct" usage of SRV records at DNSRD, > so I agree that the next version of 2782 should explicitly refer to the > correct registry document. > > Now, which one is it? port-numbers or service-names? there isn't one. and unless one of you writes an internet-draft which asks iana to import /etc/services and then maintain the master copy of it, then 2782bis will not have anything to point at. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 12:02:40 -0800 Lines: 61 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 21:13:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQIfkyla6nOGvrbT9eb4zFEHTUH4QAtGG7A To: "Derek Atkins" <derek@ihtfp.com>, "Joshua Graessley" <jgraessley@apple.com> X-OriginalArrivalTime: 13 Mar 2004 20:02:38.0054 (UTC) FILETIME=[223D4060:01C40936] Precedence: bulk Status: O Could we agree in any case that the TTL discussion does not apply when = we use TCP?=20 As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=3D255, as = per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of = address ranges is sufficient to guarantee on-link status. Setting = TTL=3D1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of = packet to the local link. On-link attackers can spoof the source = address; off-link attackers generally cannot send multicast packets to = the destination. Checking the TTL provides no protection against on-link = attackers (they can set whatever TTL value is expected). Checking that = the source address belongs to an "on-link" prefix prevents the "smurf = attack to an off-link target". Setting the TTL=3D1 in multicast queries = prevent the side effects of a rare bug in routers, but this bug may not = be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, = including for off-link attackers. Checking TTL=3D255 protects against = spoofing by off-link sources. Checking that the source address belongs = to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the = transaction identifier, which in practice requires an "on-link" = attacker; TTL games do not protect against on-link attackers. Setting = the TTL to 1 protects against unwitting participation in a DOS-attack to = an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some = network topologies that support multicast but require packets to go = through a router -- some wireless networks and some ad hoc networks can = have that property. In practice, checking TTL=3D255 is only useful in UDP unicast queries, = where it provides a slight incremental benefit over a simple check of = the source address prefix. Setting the TTL to 1 provides a limited = benefit in TCP operation, multicast queries and unicast responses, but = contradicts the requirement of TTL=3D255 for IPv6 link-local addresses. = Setting to either value will create operational problems in some future = scenarios. The simplest solution is probably to remove all mentions of TTL checks = from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an = authorized range; 2) The TTL field should be set by the stack to whatever default value is = adequate for the interface and the source address (e.g., TTL=3D255 for = IPv6 link-local addresses.) -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:29:16 +0200 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Derek Atkins <derek@ihtfp.com>, Joshua Graessley <jgraessley@apple.com>, =?ISO-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 23:39:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Christian Huitema <huitema@windows.microsoft.com> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Christian, > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <mika.liljeberg@welho.com> X-From: owner-namedroppers@ops.ietf.org Sun Mar 14 01:32:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Mika Liljeberg <mika.liljeberg@welho.com> of "Sun, 14 Mar 2004 00:29:16 +0200." <1079216956.1930.16.camel@hades> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. "i'll by THAT for a dollar." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 15 Mar 2004 14:08:17 +0900 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040313005815.D96AA14D81@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 06:15:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040313005815.D96AA14D81@sa.vix.com> Precedence: bulk Status: O Paul; >>>yes, that's true. the crossover is probably closer to 4*PMTU. >> >>Given 1280B of IPv6 minimum MTU, shouldn't message size limitation >>be somewhere around 3600 or 4800, but not 4000? > > > i think it's all very approximate and 4000 is a very fine and round number. It could have been so, if PMTUD were usable, which would have resulted in PMTU of 1450~1500. Without PMTUD, however, assumed MTU MUST be 1280, for which very approximate and round should be 3500 or 3600. Or, are there any cryptographic reason that the size is 4000? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 18:52:17 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <20040313171525.8D6F418F48@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:02:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Sat, 13 Mar 2004 17:15:25 GMT." <20040313171525.8D6F418F48@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <25301.1079373136.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Paul Vixie wrote: > > Now, which one is it? port-numbers or service-names? > > there isn't one. and unless one of you writes an internet-draft which > asks iana to import /etc/services and then maintain the master copy of I'm sorry but I do not see any difference between /etc/services and the "port-numbers" registry except for the non-existence of aliases in the latter. What do you miss? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Mon, 15 Mar 2004 10:30:45 -0800 Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <1079216956.1930.16.camel@hades> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-136514579; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:40:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <1079216956.1930.16.camel@hades> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-3-136514579 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Works for me. -josh On Mar 13, 2004, at 2:29 PM, Mika Liljeberg wrote: > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. > > MikaL --Apple-Mail-3-136514579 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNTE4MzA0NlowIwYJKoZIhvcNAQkEMRYEFHrU VLPbNQNtvNopd+r+aqYgPGgTMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAMVP pq29OvSY+jKZQaZQC/DwN6GQ+O7rFsR4Q6EoohlgH38fYMCZ7OwTlKafoMP+kn1kxJK4Cqd8WdQ+ 2PR8K0aTIU9m8SO16+Ou3ddFmgxrB/TpyT75BdB6YsWxdiHMWRrPMXa3udJ4caBrASZ1218a6eM3 fFglGZT8BHoL1bd5ylnjlHbJ5zYOHU9xLliKjacwEwlBV1srKbny1YcRaclaTLPL8rMcwuOggyc9 k3V3G2EgekhjO43lrHH39vU58HqG4fiNUzpsefi9W9KgxyHZntipn2oLO/EUZ1cwsLtZytZLlU0z UHt8+32mJpkXneCh3hLwIAz8cbPUGd4Y53EAAAAAAAA= --Apple-Mail-3-136514579-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 20:00:49 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <pk@TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:13:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Peter Koch <pk@TechFak.Uni-Bielefeld.DE> of "Mon, 15 Mar 2004 18:52:17 +0100." <200403151752.i2FHqHk25304@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > I'm sorry but I do not see any difference between /etc/services and > the "port-numbers" registry except for the non-existence of aliases in the > latter. What do you miss? ftp://ftp.iana.org/assignments/port-numbers' "keyword" field (which wasn't there a few years ago when i last looked at this file) seems like the right answer. however, a purely SRV-discovered service might not _have_ a default port number, in which case ftp://ftp.iana.org/assignments/service-names would be the better choice for an SRV's owner name. and, it would be good to know that iana's policy is to keep synchronization between port-numbers keywords, and service-names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 12:42:37 -0800 Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:54:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O however, a purely SRV-discovered service might not > _have_ a default > port number, in which case > ftp://ftp.iana.org/assignments/service-names would > be the better choice for an SRV's owner name. It seems to me that a good long term objective here would be to stop issuing port numbers completely. The logical extension of SRV is that you look up the service in DNS and get back a report of the name of the server that supports the service, the port address to use plus any parameters that describe the use of the port (I support SSL security with profile X). This is where the Internet will be in a few years time. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Mon, 15 Mar 2004 16:52:00 -0500 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 23:02:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Just a notification from your friendly neighborhood DNSSECbis document editors, to avoid suprising anyone. Miek Gieben and Jelte Jansen pointed out what we are certain is an editorial goof in way we specified calculation of the RRSIG signature value. The current drafts (both -protocol and -records) say that the signature is calculated over RR(i) = name | class | type | OrigTTL | RDATA length | RDATA As Miek and Jelte pointed out to us, the class and type fields here are reversed from the normal RFC 1035 ordering for a wire-encoded RR (not to be confused with the RFC 1035 text format, which has the class, type, and TTL fields in reverse order to avoid parse ambiguities). To the best of our knowledge: a) RFC 2535 did not explictly specify the order, but the algorithm has generally been understood as signing the wire representation; b) There has been no WG action since RFC 2535 that would change this; and c) All current implementations of which we're aware use the wire ordering, not what the DNSSECbis specs currently say. So this seems to have just been an editorial goof, we've fixed it in the editors' working sources, and the fix will be in the next revisions of the drafts we post. If anyone has a problem with this change, please send mail to the editors, the WG chairs, or to namedroppers, as appropriate. Thanks to Miek and Jelte for catching this! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Tue, 16 Mar 2004 09:36:19 +0100 Organization: RIPE NCC Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040315215200.D2A7318E0@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 16 09:44:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org> In-Reply-To: <20040315215200.D2A7318E0@thrintun.hactrn.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.082025 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8ddd797dfea932e40d44a26c70d1f113 Precedence: bulk Status: O Miek, Jelte, Good Catch!! Rob wrote: > a) RFC 2535 did not explictly specify the order, but the algorithm has > generally been understood as signing the wire representation; It is somewhat hidden through a refference from section 4.1.8 (Signature field): " RR(s) is the RRset of the RR(s)(...) in canonical form and order as defined in Section 8. " RFC 2535 section 8.1 applies: For purposes of DNSsecurity, the canonical form for an RR is the wire format of the RR (...) -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST) Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 02:18:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O > Ok, although I would rather suggest: > 1) Nodes should very that the source address of queries belong to an > authorized range; I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. > 2) Use TTL=1 with TCP. This makes sense. > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. This only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 21:54:41 -0800 Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:03:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQLvatlaIXizGLoR++uJyP8Awx4HgAJaJwg To: "Bernard Aboba" <aboba@internaut.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 17 Mar 2004 05:52:47.0441 (UTC) FILETIME=[131E2C10:01C40BE4] Precedence: bulk Status: O > > Ok, although I would rather suggest: >=20 > > 1) Nodes should very that the source address of queries belong to an > > authorized range; >=20 > I'm not sure how to define an "authorized range". A host may not know all > the prefixes present on a given link. In IPv6 at least, the host is suppose to learn the list of on-link prefixes from the RA. But you are right, there are many ways to get this test half-right and cause major operation pain.=20 > > 2) Use TTL=3D1 with TCP. >=20 > This makes sense. >=20 > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. >=20 > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. >=20 > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=3D1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Getting rid of unicast UDP query would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=3D1 also guarantees an on-link peering.=20 The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Wed, 17 Mar 2004 08:07:22 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:11:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Bernard Aboba <aboba@internaut.com> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O On Wed, 2004-03-17 at 03:17, Bernard Aboba wrote: > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. > > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. Well, section 2.4 already says: "Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries." > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Using different TTLs for different messages is awkward from the implementation standpoint. It would be simplest just to require that all requests and responses must be sent to the local link. E.g. use the SO_DONTROUTE socket option. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 06:06:21 -0800 (PST) Lines: 318 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 15:08:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O The text of LLMNR Issue 64 is enclosed below. The proposed resolution is as follows: In Section 2.4, change: "Unicast LLMNR queries SHOULD be sent using TCP." To: "Unicast LLMNR queries MUST be sent using TCP." Change: "Unicast UDP queries MAY be responded to with a UDP response containing an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP." To: "Unicast UDP queries MUST be silently discarded." Change: "If an ICMP "Time Exceeded" message is received in response to a unicast UDP query, or if TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). The UDP sender receiving an ICMP "Time Exceeded" message SHOULD verify that the ICMP error payload contains a valid LLMNR query packet, which matches a query that is currently in progress, so as to guard against a potential Denial of Service (DoS) attack. If a match cannot be made, then the sender relies on the retransmission and timeout behavior described in Section 2.7." To: "If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section)." In Section 2.5, change: "In composing LLMNR queries, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). Even when LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Therefore setting the IPv6 Hop Limit or IPv4 TTL field to one provides an additional precaution against leakage of LLMNR queries. In composing a response to an LLMNR query, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). This is done so as to prevent the use of LLMNR for denial of service attacks across the Internet. Section 2.4 discusses use of TCP for LLMNR queries and responses. The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder." To: "Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. For UDP queries and responses the Hop Limit field in the IPv6 header, and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Rendezvous." In Section 5.1, change: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on both queries and responses. A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can be used to launch denial of service attacks. For example, were the TTL of an LLMNR Response to be set to a value larger than one (1), an attacker could send a large volume of queries from a spoofed source address, causing an off-link target to be deluged with responses. Utilizing a TTL of one (1) in LLMNR responses ensures that they will not be forwarded off-link. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender." To: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing UDP queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on TCP queries and responses. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. When LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may enable denial of service attacks across the Internet. However, since LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal." An edited version of the specification incorporating these changes is available at: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-30.txt -------------------------------------------------------------------- Issue 64: TTL Revisited Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: March 15, 2004 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00299.html Document: LLMNR-29 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Derek Atkins <derek@ihtfp.com> Date: Tue, 24 Feb 2004 22:14:43 -0500 It sounds like you want two things here, but it also sounds like all of them need to happen in the responder. The attacker could theoretically send packets of any type, with any TTL. So you can't trust anything you receive from the network. To this affect, I think: 1) We want the responder to try to determine that a request came from the local network. The best way to do this is for the responder to check that TTL=255 to make sure. If a TTL is less than 255 then it originiated off-net and can be dropped. 2) We want the responder to make sure response packets don't go off-net. In other words, we want the responder to respond with TTL=1, to make sure it can't smurf. So, to this affect: a) an LLMNR requestor should send requests with TTL=255 b) an LLMNR responder should verify requests have TTL=255 -- if it is not 255 then it should drop the packet. c) an LLMNR responder should respond with TTL=1 d) I dont' think an LLMNR requestor needs to check the response TTL. The only issue this doesn't directly solve is a requester being spoofed by an off-net attacker, but said attacker would need to guess the transaction id of the request in order to send a valid response, which is just as likely in LLMNR as it is in standard DNS, so it can probably be ignored. So, other than this issue, does this solve the issue? [Christian Huitema] Could we agree in any case that the TTL discussion does not apply when we use TCP? As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=255, as per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of address ranges is sufficient to guarantee on-link status. Setting TTL=1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of packet to the local link. On-link attackers can spoof the source address; off-link attackers generally cannot send multicast packets to the destination. Checking the TTL provides no protection against on-link attackers (they can set whatever TTL value is expected). Checking that the source address belongs to an "on-link" prefix prevents the "smurf attack to an off-link target". Setting the TTL=1 in multicast queries prevent the side effects of a rare bug in routers, but this bug may not be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, including for off-link attackers. Checking TTL=255 protects against spoofing by off-link sources. Checking that the source address belongs to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the transaction identifier, which in practice requires an "on-link" attacker; TTL games do not protect against on-link attackers. Setting the TTL to 1 protects against unwitting participation in a DOS-attack to an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some network topologies that support multicast but require packets to go through a router -- some wireless networks and some ad hoc networks can have that property. In practice, checking TTL=255 is only useful in UDP unicast queries, where it provides a slight incremental benefit over a simple check of the source address prefix. Setting the TTL to 1 provides a limited benefit in TCP operation, multicast queries and unicast responses, but contradicts the requirement of TTL=255 for IPv6 link-local addresses. Setting to either value will create operational problems in some future scenarios. The simplest solution is probably to remove all mentions of TTL checks from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an authorized range; 2) The TTL field should be set by the stack to whatever default value is adequate for the interface and the source address (e.g., TTL=255 for IPv6 link-local addresses.) [Mika Liljeberg] > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. [Bernard Aboba] I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. TTL=255 on UDP request & responses only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. [Christian Huitema] Getting rid of unicast UDP queries would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=1 also guarantees an on-link peering. The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 17 Mar 2004 11:06:54 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 17:14:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: LLMNR authorized range Date: Wed, 17 Mar 2004 10:19:12 -0800 Lines: 86 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-308620971; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 19:27:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-13-308620971 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 16, 2004, at 5:17 PM, Bernard Aboba wrote: >> Ok, although I would rather suggest: > >> 1) Nodes should very that the source address of queries belong to an >> authorized range; > > I'm not sure how to define an "authorized range". A host may not know > all > the prefixes present on a given link. The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. -josh --Apple-Mail-13-308620971 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzE4MTkxMlowIwYJKoZIhvcNAQkEMRYEFPiN 3vLihLmc6g/UXYaume3X1TIJMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBABID 5kspYzWbi7lBMu8pVrGyZZ2/vNLa7cP+3xgscFyqNHBTYzii2NsnmUe97xQWPBtDJ5PpW1GhanVz DK9XwDPbaTHBBWKmVA5LeHqVhsqzOsYRkRWPU8YmVAnPJbPMH5OvADep2yuoAQvDfkybYIEryOMR o2jfRj8mIXTpwxqKf9hG3OwGleTrEg8bzvOCgGruFIAxm+BiMx2ayDeIYvqfXVy8XU2zTWQUKB+w pyFhIkyJkTbX324Y2wlMAlGlv1zB4KsTqJH62Rb+PsXifl2sW+gD6RMn/XwqJgrteyarMyWMZ+D+ 6IDc848v8NteNdCjpEUrprCGxZqx8KB5QSkAAAAAAAA= --Apple-Mail-13-308620971-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:20:56 +0200 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 20:29:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Josh, On Wed, 2004-03-17 at 20:19, Joshua Graessley wrote: > The current solution of using TCP with a TTL of 1 makes the "authorized > range" pretty simple to understand. Addresses in the authorized range > are those that the host knows about. This highlights a problem with the > current LLMNR draft. If there are two subnets overlaid on a local > network and the hosts are unaware of the opposite subnet, LLMNR will > make it impossible to resolve names of some devices on the same link > just because they exist on a different subnet. As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:25:29 -0500 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 21:33:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O At 13:19 2004-03-17, Joshua Graessley wrote: >The current solution of using TCP with a TTL of 1 makes the "authorized >range" pretty simple to understand. Addresses in the authorized range are >those that the host knows about. This highlights a problem with the >current LLMNR draft. If there are two subnets overlaid on a local network >and the hosts are unaware of the opposite subnet, LLMNR will make it >impossible to resolve names of some devices on the same link just because >they exist on a different subnet. Good point, so what TLL <= N works for you ? N = 5 sounds good to me. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <ogud@ogud.com> X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 22:29:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> of "Wed, 17 Mar 2004 15:25:29 EST." <6.0.3.0.2.20040317152010.02b37e88@localhost> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... If there are two subnets overlaid on a local network and the > > hosts are unaware of the opposite subnet, LLMNR will make it > > impossible to resolve names of some devices on the same link just > > because they exist on a different subnet. that sounds like the right thing, since if they're on different subnets then they will not be able to communicate even though those subnets are in the same broadcast domain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 14:13:00 -0800 Lines: 95 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-322649650; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 23:29:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040317212210.05A5514C51@sa.vix.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-18-322649650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed My friends has a problem with his cable modem provider. He has paid extra to get extra addresses. The addresses are handed out using DHCP. The addresses are not always on the same subnet. I see no reason why LLMNR shouldn't work for him. I may soon have a similar situation at home. I've got sDSL for a small server I run. I'm thinking about getting a cable modem connection so I can get stuff quicker. When I have that setup at home, I'll have two or more subnets running on the local network. All of the devices can communicate using their IPv4 addresses (albeit inefficiently). LLMNR should work in this situation but due to the TTL stuff it may not work. I think there is a simple solution for IPv6. Always use the IPv6 link-local addresses. The only solution that would work 100% of the time for IPv4 would be to use the same link-local multicast to send the response. -josh On Mar 17, 2004, at 1:22 PM, Paul Vixie wrote: >>> ... If there are two subnets overlaid on a local network and the >>> hosts are unaware of the opposite subnet, LLMNR will make it >>> impossible to resolve names of some devices on the same link just >>> because they exist on a different subnet. > > that sounds like the right thing, since if they're on different subnets > then they will not be able to communicate even though those subnets are > in the same broadcast domain. --Apple-Mail-18-322649650 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzIyMTMwMVowIwYJKoZIhvcNAQkEMRYEFGC0 xVKoZ+1an/5iMlJX/1xQw6DpMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAHdE tCTuzek3bgT7uCX+FEcQUYwwsv0Dnpcc8LKbMC7ZUwR6N7Am77lCNPIvw/wZfwm+87pxoori9Cl/ JSVyvPiUgiB/yfipwfUJPdoQIbrD8IbcsleoWSP95c+SAX4Odw1utoo9zbg4ig4sO/xtwQtV2JaA xNfDAhhiuk4+5+GtXf5/fJKEZd+gYa831X6fPBDr+rbVEZYnKO4I89iVrGW4XQ66d61LJ26XIs2/ NNsXHQbq/u9+8p0XUNTauhGPjJH9XVDk9mDt0o23xmbwfPzavUtoDBnvSEt6yASMfaZxUMTPdCD/ F30cuturShwPFbcGw4wSZ0fZmIQOFcG0GRUAAAAAAAA= --Apple-Mail-18-322649650-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 23:23:34 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <jgraessley@apple.com> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 00:31:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Joshua Graessley <jgraessley@apple.com> of "Wed, 17 Mar 2004 14:13:00 PST." <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > My friends has a problem with his cable modem provider. He has paid extra > to get extra addresses. The addresses are handed out using DHCP. The > addresses are not always on the same subnet. I see no reason why LLMNR > shouldn't work for him. i guess if your router is sitting on both subnets and you're willing to go through a router to talk to other hosts in the same broadcast domain, you're right there's no reason LLMNR wouldn't work. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 13:56:57 -0600 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403170606040.10517@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403170606040.10517@internaut.com> To: Bernard Aboba <aboba@internaut.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 8:06 AM, Bernard Aboba wrote: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header MAY be set to any value. However, > it is RECOMMENDED that the value 255 be used for compatibility with > Apple Rendezvous." Why not change it to: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header SHOULD be set to 255. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 17:02:06 -0600 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. It shouldn't work for him because his network is misconfigured. It's not the job of the IETF to arrange for it to be the case that any random configuration error still results in desired behavior, for any arbitrary value of "desired." If you want this to work, you need to go check out the IPv4ll protocol and make sure that it does the right thing in this case. And your friend needs to use IPv4ll. Rendezvous works correctly in this case, doesn't it? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:21:31 -0600 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:07:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 12:19 PM, Joshua Graessley wrote: > If there are two subnets overlaid on a local network and the hosts are > unaware of the opposite subnet, LLMNR will make it impossible to > resolve names of some devices on the same link just because they exist > on a different subnet. I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 20:02:00 -0800 Lines: 26 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 05:11:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution to LLMNR Issue 64: TTL Revisited thread-index: AcQMfLkklVWmcimJRgOk4T8n5ZiKvQAIL36g To: "Ted Lemon" <mellon@fugue.com>, "Bernard Aboba" <aboba@internaut.com> X-OriginalArrivalTime: 18 Mar 2004 04:02:14.0194 (UTC) FILETIME=[CBCEC120:01C40C9D] Precedence: bulk Status: O > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header MAY be set to any value. However, > > it is RECOMMENDED that the value 255 be used for compatibility with > > Apple Rendezvous." >=20 > Why not change it to: >=20 > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header SHOULD be set to 255. Because this is a trade-off. The proper design is to use a TTL=3D1. The only reason to use the 255 value, which has a larger exposure to DOS exploitation, is compatibility with rendezvous. The text that Bernard proposes is a fine compromise. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 23:18:46 -0600 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 06:24:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> To: "Christian Huitema" <huitema@windows.microsoft.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 17, 2004, at 10:02 PM, Christian Huitema wrote: > Because this is a trade-off. The proper design is to use a TTL=1. The > only reason to use the 255 value, which has a larger exposure to DOS > exploitation, is compatibility with rendezvous. The text that Bernard > proposes is a fine compromise. The text I proposed and the text it replaces have exactly the same effect. The difference is that one of them places blame (I think inappropriately, although I think also unintentionally), and the other does not. I can't think of any technical reason to prefer the old text over the new. Can you state such a reason? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: EDNS0 (RFC-2671) questions Date: Thu, 18 Mar 2004 15:25:36 +0200 Lines: 31 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 14:34:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O 1) assuming I send query, which includes the OPT RR (to increase the packet length). If I receive a reply with TC=1 (truncation) and don't find OPT RR in the reply, then I assume the RCODE is the non-extended one? [Just verifying, that I can trust all implementations do it right: if they build an answer and run out of space before inserting the OPT RR, they also fall back to old plain RCODE?] This extended-RCODE makes it somewhat akward, to find RCODE, you have to traverse through all data in Question, Answer and Authority sections, then look OPT RR from Additional section. Doable, but still icky, just to get few extra bits of RCODE that are rarely used. Would have been easier if there was single RCODE value in fixed header to indicate that extended RCODE is in use. 2) Can UDP payload size be < 512? I didn't see any mention of it. Maybe I missed it. I think RFC should state that attempting to use less than 512 is not allowed (and will be ignored). [If < 512 is accepted, there might be some DOS potential in it also] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: correction to RRSIG presentation format in DNSSECbis -records draft Date: Thu, 18 Mar 2004 10:53:08 -0500 Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:04:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-NIST-MailScanner-Information: Please contact the ISP for more information X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Status: O Recently pointed out by Miek and Erik Rozendaal in the Resource Records draft of the DNSSECbis spec is the discrepancy between the ASCII presentation formats of the RRSIG and NSEC RRs. In the text, the RRSIG Type Covered field is supposed to be represented as a RR type mnemonic or an unsigned integer. This goes against the convention in RFC 3597 which states that unknown RR types should be represented as "TYPE<number>" where <number> is the typecode. The text for the representation of the NSEC RR type bitmap already states this (as it was written after RFC3597). The text for the RRSIG representation was changed to be consistent with RFC 3597 and the NSEC text. Section 3.2 paragraph 2 will now read: The Type Covered field is represented as a RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597] (section 5) MUST be used. Thanks, Scott DNSSECbis editors -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 18:14:36 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:19:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 03:21:31PM -0600, Ted Lemon wrote: > A host that you > can't talk to without going through a router isn't "local." Why not? Which part of the Internet-Draft does this violate? >From ...-29.txt: For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. The network overlay scenario is clearly "on link" according to the above definition. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 16:54:57 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 05:02:06PM -0600, Ted Lemon wrote: > On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > >My friends has a problem with his cable modem provider. He has paid > >extra to get extra addresses. The addresses are handed out using DHCP. > >The addresses are not always on the same subnet. I see no reason why > >LLMNR shouldn't work for him. > > It shouldn't work for him because his network is misconfigured. It's > not the job of the IETF to arrange for it to be the case that any > random configuration error still results in desired behavior, for any > arbitrary value of "desired." Exactly how is overlaying two IP network ranges onto one L2 infrastructure misconfigured? -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 17:32:58 +0200 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> Content-Disposition: inline In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. This hits at the crux of what "Link-Local" means in the acronym LLMNR. The above scenario (if indeed regarded as acceptable practice) will be regarded by most people as "local". During the original drafting of the document, did the authors have a specific definition of "link-local" in mind? As I recall, the original spec came out of Stuart Cheshire's work on replacing AppleTalk's naming service; this became Rendezvous and branched off into LLMNR. If this is the case, then the "local" definition was pretty broad, and would probably cover the overlaid network scenario. Also, in the above scenario, forcing TTL=1 will cause the router to drop the packet before it is forwarded back onto the "other" part of the local network. Making TTL=5 (or any other number greater than 1 but less than the worst-case diameter of the Internet) seems to be an ugly solution, and also gets away from the "link-local" part of LLMNR -- why not just call it "restricted scope MNR" then? Or why not just drop the TTL restriction altogether and just allow general MNR? I repeat -- TTL checks are a kludge, and do not capture the idea of "local" networks. There are local networks for which TTL must be greater than 1 to capture locality (eg. multiple IP ranges overlaid on the same L2 medium as above), and there are distinctly non-local networks (eg. LANs bridged through long thin pipes) for which any multicast can cause great harm -- even with TTL=1. In a message to this forum from Bernard Aboba in October 2003: As a result, the ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local specification so as to "do no harm". The current specification no longer mandates a test for a TTL value, and prefers a routable address when available. It is perhaps not as "useful" as the early versions -- but it also does not break the basic interoperability of TCP/IP. I've probably taken the above slightly out of context, but perhaps we should go back to the original multicast slant of LLMNR and drop UDP unicast, as suggested by Bernard in another message. For multicast, the TTL is irrelevant unless we are trying to compensate for potential router bugs. On the other hand, for TCP queries, the TTL should not be restricted. Then, interoperability with an existing protocol seems to be a worthwhile goal, as long as it is not bought at a terrible price. (Why was UDP unicast functionality introduced, anyway?) At the end of the day, I just want to see some finality with LLMNR, whatever it is! Either it is going to be useless and Rendezvous will win out in the marketplace, or it will be useful and over time it may grow to take over from Rendezvous. But right now LLMNR is by definition useless, since it hasn't been finalised. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040318153258.GF9994@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jgraessley@apple.com (Joshua Graessley), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:57:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net (Andras Salamon) In-Reply-To: <20040318153258.GF9994@dns.net> from "Andras Salamon" at Mar 18, 2004 05:32:58 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > > My friends has a problem with his cable modem provider. He has paid > > extra to get extra addresses. The addresses are handed out using DHCP. > > The addresses are not always on the same subnet. I see no reason why > > LLMNR shouldn't work for him. > > This hits at the crux of what "Link-Local" means in the acronym LLMNR. link-local is an unfortunate terminological choice. it might be useful to consider "single broadcast domain", which pretty much eliminates the overlay scenario. > As I recall, the original spec came out of Stuart Cheshire's > work on replacing AppleTalk's naming service; this became Rendezvous and > branched off into LLMNR. If this is the case, then the "local" definition > was pretty broad, and would probably cover the overlaid network scenario. Hum... there were a series of efforts that hit confluence and then diverged... the TBDS research, what became Rendezvous and what might become LLMNR... all are varients that use DNS or DNSlike stuff. > -- Andras Salamon andras@dns.net --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:36:42 -0600 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> <20040318145457.GE9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:51:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318145457.GE9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 8:54 AM, Andras Salamon wrote: > Exactly how is overlaying two IP network ranges onto one L2 > infrastructure > misconfigured? It is misconfigured in the sense that it does not do what the customer expects. The customer expects that the two devices he or she has connected to the network will be able to communicate with each other without relying on the service provider. This is unfortunately not true - they will not be able to communicate other than over the service provider's link, unless they implement Rendezvous (I do not believe that the current IPv4ll draft, for example, will allow them to communicate independent of the ISP). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:47:39 -0600 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <20040318153258.GF9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:59:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318153258.GF9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 9:32 AM, Andras Salamon wrote: > During the original drafting of > the document, did the authors have a specific definition of > "link-local" > in mind? Yes. However, the current document bears only a passing resemblance to what the authors had in mind. The original intention was that the two devices we're discussing would both have IPv4ll addresses, and that MDNS, as it was then called, would uses these addresses, not the globally-routable addresses. Both the IPv4ll spec and the MDNS spec have been changed dramatically since then. IPv4ll no longer works the way it did, and LLMNR doesn't either. At this point, I have to say that it is my sincere hope that neither IPv4ll nor LLMNR make it to standard as they are currently constituted. But if they do make it to standard, my next hope is that they do not fail to interoperate with Rendezvous. If they do not interoperate reliably with Rendezvous, then the only purpose they will serve is to make sure that no reliable mechanism exists whereby two arbitrary hosts can automatically communicate with each other on the local link in the event that the DHCP server is not configured to enable this communication - by having two incompatible mechanisms that do roughly the same thing, we eliminate the possibility of dependable interoperability. I sympathize deeply with your motivation to make LLMNR work correctly in the scenario we're talking about in the absence of any competing protocol, but that is not the domain in which we are operating. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 22:41:55 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 07:41:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O >LLMNR will make it impossible to resolve names of some devices on the >same link just because they exist on a different subnet. No. All but PTR RR queries will be sent to the link-scope multicast address, so they will be resolved without a problem. >As far as I can see, that is only a problem with PTR queries, which >often fail anyway. Yes. Only PTR queries are sent via TCP. Given that other queries will work and applications need to be prepared for PTR RR queries to fail anyway, you'll only see somewhat degraded performance. On the other hand, there is a performance improvement for other cases, since TTL=1 causes unresolvable PTR RR queries to fail quickly, rather than having to wait for LLMNR_TIMEOUT. So this is really just an optimization issue and I'm not clear that optimizing for an uncommon case (e.g. TTL=5) makes sense. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Fri, 19 Mar 2004 10:16:42 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> <20040318161436.GA10775@dns.net> <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 09:48:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Thu, Mar 18, 2004 at 12:34:32PM -0600, Ted Lemon wrote: > On Mar 18, 2004, at 10:14 AM, Andras Salamon wrote: > >The network overlay scenario is clearly "on link" according to the > >above definition. > > Sure, and you could argue that the definition you've quoted is correct > and that mine is wrong. I'm not especially interested in arguing about whose definition is right or wrong. However, the current LLMNR Internet-Draft defines its scope to include the scenario of address ranges overlaid onto the same L2 infrastructure (maybe I'm wrong here, but no-one has yet objected). Hence, either we need to change the wording of the I-D, or we need to accept the wording and its consequences. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 03:47:00 -0800 (PST) Lines: 47 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 12:51:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [Joshua Graessley] said: The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. [Ted Lemon] replied: I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? [Mika Liljeberg] said: As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? [Bernard Aboba] In practice, I don't believe this issue will arise. Section 1 says: "The assumption is that if a network has a gateway, then the network is able to provide DNS server configuration." Therefore in the "overlapping subnet" case LLMNR assumes that the host has DNS configuration. From early on, LLMNR has assumed that the gateway supports the resolution of the names of local hosts using DHCPv4 and dynamic DNS update. However, this assumption cannot be made for IPv6 at this point. So if we are talking about multiple subnets on a link in IPv4, then a conventional DNS query will be sent first, and local names can be resolved by the gateway. If we are talking about IPV6, then Router Advertisement enables the host to become aware of the multiple subnets, so that TCP-based queries can be sent on the local link, rather than forwarded by a router. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 14:23:14 +0200 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 13:31:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: aboba@internaut.com In-reply-to: <Pine.LNX.4.56.0403200335280.8666@internaut.com> (message from Bernard Aboba on Sat, 20 Mar 2004 03:47:00 -0800 (PST)) Precedence: bulk Status: O > From: Bernard Aboba <aboba@internaut.com> > > ... If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, Terminology confusion? What subnets are in RA? RA can have multiple prefixes to be used on the link (if L=1), but they are not subnets. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR authorized range Date: Sat, 20 Mar 2004 10:48:18 -0800 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 19:58:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR authorized range thread-index: AcQOdygluZmu2G4uTO+NBskGu1hyLwANJJKA To: "Markku Savela" <msa@burp.tkv.asdf.org>, <aboba@internaut.com> X-OriginalArrivalTime: 20 Mar 2004 18:48:03.0805 (UTC) FILETIME=[E04548D0:01C40EAB] Precedence: bulk Status: O > > From: Bernard Aboba <aboba@internaut.com> > > > > ... If we are > > talking about IPV6, then Router Advertisement enables > > the host to become aware of the multiple subnets, >=20 > Terminology confusion? What subnets are in RA? RA can have multiple > prefixes to be used on the link (if L=3D1), but they are not subnets. Uh? There is no official definition of subnet, but the generally agreed definition is "the set of addresses that shares a specified prefix". -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 12:12:48 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: msa@burp.tkv.asdf.org (Markku Savela), aboba@internaut.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 21:21:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: huitema@windows.microsoft.com (Christian Huitema) In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> from "Christian Huitema" at Mar 20, 2004 10:48:18 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > > From: Bernard Aboba <aboba@internaut.com> > > > > > > ... If we are > > > talking about IPV6, then Router Advertisement enables > > > the host to become aware of the multiple subnets, > > > > Terminology confusion? What subnets are in RA? RA can have multiple > > prefixes to be used on the link (if L=1), but they are not subnets. > > Uh? There is no official definition of subnet, but the generally agreed > definition is "the set of addresses that shares a specified prefix". That is not generally agreed on in most circles I run in. The working definition here is: "a single broadcast domain" e.g. more layer two'ish. > -- Christian Huitema --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 16:18:45 -0500 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 22:26:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200403202012.i2KKCn418994@karoshi.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > > > Uh? There is no official definition of subnet, but the generally agreed > > definition is "the set of addresses that shares a specified prefix". > > That is not generally agreed on in most circles I run in. > The working definition here is: "a single broadcast domain" > e.g. more layer two'ish. I think you're both right, but Christian's righter. IP "subnets" (the term's a bit dated given CIDR, but comes from the old subnetting extension to the original class A/B/C extension to the original original IPv4 address architecture's static 255.0.0.0 network mask) are an IP (layer 3) concept referring to a set of IP addresses sharing a particular prefix. The fact that IP subnets usually (but not always) map 1-to-1 with link-layer broadcast domains has led to sloppy terminology even in the IP world, and there are certainly other uses of the term "subnet" which mean something entirely different (eg, at one point I think the entire ARPANET was referred to as a "subnet" of the ARPANET/MILNET system, and some link layer specs do use the term "subnet" to mean link layer broadcast domain, as Bill suggests). So for precision you have to state the context (including layer) in which you're using the term, but since this is the IETF, and around here we mostly talk about IP, any use of the term "subnet" in IETF documents should generally be presumed to be talking about IP addresses with a shared prefix unless stated or proven otherwise. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Sun, 21 Mar 2004 08:07:45 +0900 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20040320211845.29FEB18F8@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Mar 21 00:15:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Rob Austein <sra@isc.org> In-Reply-To: <20040320211845.29FEB18F8@thrintun.hactrn.net> Precedence: bulk Status: O Rob Austein; > At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > >>>Uh? There is no official definition of subnet, but the generally agreed >>>definition is "the set of addresses that shares a specified prefix". >> >> That is not generally agreed on in most circles I run in. >> The working definition here is: "a single broadcast domain" >> e.g. more layer two'ish. > > > I think you're both right, but Christian's righter. No, Christian is not. According to the CATENET model of the Internet, the Internet is composed from local networks (of RFC791). local network = subnet = link = broadcast domain The proper way to assign a local network multiple addresses is to let all the hosts (of RFC791) in the local network share multiple prefixes of equal length using identiral host parts (intra-subnet) addresses, which still means local network = subnet = link = broadcast domain Confusions caused by any other configuration are the problems of the configuration. The configuration is responsible to make the model visible from other protocols local network = subnet = link = broadcast domain > any use of the term "subnet" in IETF > documents should generally be presumed to be talking about IP > addresses with a shared prefix unless stated or proven otherwise. It's "shared prefixes", not "a shared prefix". Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Mon, 22 Mar 2004 10:40:10 -0800 Lines: 104 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-741880068; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 22 19:53:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403200335280.8666@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-32-741880068 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Based on prior discussions and reading the draft, I was under the impression that if a DNS query fails (response with answercount of zero or a response with an error of NXDOMAIN), the query would be performed using LLMNR. It seems very plausible that someone might setup their computers to respond to LLMNR queries for names such as josh.llmnr or josh.thisdomainmustfailtoresolve. This would allow someone to locally refer to their computers by name no matter what the local addresses are and whether or not a DNS server is available. This would also be perfectly valid according to the current LLMNR spec. In this valid scenario, if there are multiple subnets on the same local network, LLMNR will fail. -josh On Mar 20, 2004, at 3:47 AM, Bernard Aboba wrote: > [Bernard Aboba] In practice, I don't believe this issue will arise. > Section 1 says: > > "The assumption is that if a network has a gateway, > then the network is able to provide DNS server configuration." > > Therefore in the "overlapping subnet" case LLMNR > assumes that the host has DNS configuration. From early > on, LLMNR has assumed that the gateway supports the > resolution of the names of local hosts using DHCPv4 and > dynamic DNS update. However, this assumption cannot be > made for IPv6 at this point. > > So if we are talking about multiple subnets on a link in > IPv4, then a conventional DNS query will be sent first, > and local names can be resolved by the gateway. If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, > so that TCP-based queries can be sent on the local > link, rather than forwarded by a router. --Apple-Mail-32-741880068 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMyMjE4NDAxMVowIwYJKoZIhvcNAQkEMRYEFDl8 9/kmuygyZVn0ISG4dH3oZKYDMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAKeo F6CpAFWpAvOdpM0OBoVrJenuTybGod5v/4E0F44x70U/JOeZApkZAK1dREIeT1M42J4b9iWk52CX 4mb++kOUH65xD77FH6xWNihVCHOIQF8W8+OHRO7yJSVuD6xYjahCpUVyF9KupoIzvGV1fBwz3Jml DtzmKAISHUTzXsZrLvKtvpUKcsouw3UMuiiE8GVWBsoInmA3w66Wd8EMSFmyJpVlry9lG/9VNemZ 8/+sQrWmxHBlfeweschkXXzXKqnMaliaRurH330kVS3V1lCmD340JsL8xbcpC19nGgQWPxGJlbAM ZYJSAmxRXO/uIlf95HB5A1FPEE16WGQ3Z5QAAAAAAAA= --Apple-Mail-32-741880068-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Tue, 23 Mar 2004 15:14:16 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 23 07:20:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O Josh; > In this valid > scenario, if there are multiple subnets on the same local network, LLMNR > will fail. With IPv6, there is no reason not to share all the prefixes of a link by all the hosts on the link, which means there is only a single subnet. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Advance: draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 24 Mar 2004 09:16:56 +0100 Organization: RIPE NCC Lines: 98 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, jakob@schlyter.se X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 09:28:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Thomas Narten" <narten@us.ibm.com>, "Margaret Wasserman" <margaret@thingmagic.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.015749 / 0.0 / 0.0 / disabled X-RIPE-Signature: d65dbcaea04193b902f993fc8813be54 Precedence: bulk Status: O Thomas, Margaret, Hereby the advancement questionnaire (www.mip4.org/2004/draft-writeup-items.html) for "DNSSEC NSEC RDATA Format" draft-ietf-dnsext-nsec-rdata-05.txt. The questionaire serves as a request to advance the document to proposed standard. 1. Chairs review. The chair responsible for tracking this document has read it and considers it ready for IESG review. 2. Working Group member review. The proposed format has been discussed on the list as well as during the IETF 58 meeting. The content of the comments received during last call indicate that a number of people have closely reviewed the document. 3. Is more review from a particular perspective needed. In the chairs opinion not. 4. Specific Issues and concerns the AD/IESG should be aware of. The document _only_ changes a format. The security section therefore does not go into the details of NSEC security. Note however that the text describing this format will be directly 'cut-n-pasted' into the dnssec-bis document set. The dnssec-bis intro document set covers the security considerations, e.g. NSEC cain walking, in more detail. 5. How solid is the WG consensus. The format was chosen during IETF58. The document itself got explicit consensus from only a few individuals. On the other hand this is has not been contentious issue. 6. Thread for appeal. None. 7. _all_ ID nits addressed. All are addressed. 8. References There is a normative reference to an I-D that has been advanced. Also not that this document will be merged and obsoleted by the dnssec-bis document set. 9. Writeup. Technical Summary To prevent the introduction of an extension mechanism once DNSSEC has a deployed base this document redefines the wire format of the "Type Bit Map" field in the NSEC resource record RDATA format to cover the full RR type space. The new format of the type bitmap is easy to implement, can cover the full range of type codes, is economical in the common case and has a maximum size of approximately 8.5 kilobytes. Efficient searching of the type bitmap for presence of a type had a lower priority. Working Group Summary The format was chosen from 6 different candidates that were presented to the working group. There is consensus on the chosen representation. Protocol Quality There are 3 independent implementations of this format. 1 implementation provides both a server and a client, 1 implementation only a server and 1 implementation only a client. These interoperate. -- Olaf Kolkman Olafur Gudmundsson -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis Q-30: DNAME awareness Date: Wed, 24 Mar 2004 14:08:52 -0500 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 20:23:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Q-30: Should the DNSSECbis specs require DNAME-awareness? Approximate text to be added if the WG agrees: [To be inserted somewhere in Section 3.x of -protocol] A security-aware name server which synthesizes CNAME RRs from DNAME RRs as described in RFC 2672 SHOULD NOT generate signatures for the synthesized CNAMEs. [To be inserted somewhere in Section 4.x of -protocol] A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs which could have been synthesized from the DNAME RR as described in RFC-2672, at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so. Background: RFC-2672 recommends that name servers synthesize CNAME RRs based on DNAME RRs, for backwards compatability with DNAME-oblivious resolvers. RFC-2672 goes on to suggest that DNSSEC-capable name servers might want to keep the zone key online in order to sign these synthesized CNAME RRs, for the benefit of security-aware DNAME-oblivious resolvers. This has obvious security issues, and also adds some complexity. In fairness, note that when RFC-2672 came out, DNSSEC-classic (RFC 2535) had already shipped, so one could argue that this was the least bad backwards compatability hack available to the author of RFC-2672. So the question here is whether there is any need for DNSSECbis to support security-aware DNAME-oblivious implementations. Specifically, can we eliminate the case of a security-aware DNAME-oblivious resolver expecting name servers to synthesize signed CNAME RRs from signed DNAME RRs? DNSSECbis question Q-27 already covered part of this space, by allowing a security-aware recursive name server to set the AD bit for responses containing synthesized CNAME RRs. Q-27 did not, however address whether name servers should attempt to sign synthesized CNAME records or whether resolvers should expect to receive signatures for synthesized CNAME records. Whether a validating resolver choses to retain synthesized CNAMEs or not appears to be an implementation and local policy choice, since CNAME synthesis itself is only a SHOULD in RFC-2672 and thus not something on which any DNS-using software can depend. Deadline and default: Per instructions from the WG chairs, this question will time out on 4 April 2003 with a default action to accept these changes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Thu, 25 Mar 2004 09:57:08 +0100 (CET) Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> <6.0.3.0.2.20040312111536.02678528@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Mar 25 10:11:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040312111536.02678528@localhost> Precedence: bulk Status: O interested parties should visit http://www.rfc.se/interop3597/ and join the mailing-list at http://www.rfc.se/mailman/listinfo/interop3597. before testing starts, I need help with filling the test zone (published as interop3597.rfc.se) with useful, and wierd, data. please send suggestions me or to the list above. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSSECbis Q-30: DNAME awareness Date: Fri, 26 Mar 2004 11:33:53 -0500 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> <20040324190852.67C5618C9@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 17:51:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040324190852.67C5618C9@thrintun.hactrn.net> To: Rob Austein <sra@isc.org> Precedence: bulk Status: O I like what these words say. At 14:08 -0500 3/24/04, Rob Austein wrote: >Q-30: Should the DNSSECbis specs require DNAME-awareness? > >Approximate text to be added if the WG agrees: > > [To be inserted somewhere in Section 3.x of -protocol] > > A security-aware name server which synthesizes CNAME RRs from DNAME > RRs as described in RFC 2672 SHOULD NOT generate signatures for the > synthesized CNAMEs. > > [To be inserted somewhere in Section 4.x of -protocol] > > A validating security-aware resolver MUST treat the signature of a > valid signed DNAME RR as also covering unsigned CNAME RRs which > could have been synthesized from the DNAME RR as described in > RFC-2672, at least to the extent of not rejecting a response > message solely because it contains such CNAME RRs. The resolver > MAY retain such CNAME RRs in its cache or in the answers it hands > back, but is not required to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-30.txt Date: Fri, 26 Mar 2004 15:49:27 -0500 Lines: 96 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 22:06:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-30.txt Pages : 26 Date : 2004-3-26 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-30.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-30.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-30.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: DNSEXT list policy Date: Mon, 1 Mar 2004 08:35:01 +0100 Lines: 190 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 01 08:48:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.500000 / 0.0 / 0.0 X-RIPE-Signature: 32d842149ec8e2859401da1280faf172 Precedence: bulk Status: O - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See <http://www.ietf.org/html.charters/dnsext-charter.html> for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at <http://www.ietf.org/html.charters/dnsop-charter.html>. Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format <NAME> ISSUE: <title> Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 02 Mar 2004 00:24:45 -0500 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> <20040226144216.GA7166@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba <aboba@internaut.com>, huitema@microsoft.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 02 06:35:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040226144216.GA7166@dns.net> (Andras Salamon's message of "Thu, 26 Feb 2004 16:42:16 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: >> If there is to be a "compromise" I believe that it should be >> to set TTL=255 on responses and (optionally) check on the sender, while >> *always* setting TTL=1 on queries. > > Sounds reasonable to me. But now you're open to smurf attacks, where I send a LLMNR request to a responder, setting YOUR ip address as the source, and setting the TTL to make sure the packet arrives "properly". Or do we just not care about this? I can make sure you send the packet, and with TTL=255 the response will always make it back to the "sender" (which is YOUR ip address in this case). So, what is the threat(s) we're trying to solve? In particular, what threat does TTL=255 on responses actually solve? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: draft-ietf-dnsext-nsec-rdata-04 Date: Wed, 3 Mar 2004 20:08:54 +0900 (KST) Lines: 15 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 03 12:20:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Precedence: bulk Status: O I've just submitted an updated version of this draft to the drafts editor. For those who want to read it now, you can find a copy (and a diff against -03) at the following location: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.txt http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.wdiff jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: comment on NSEC RDATA format draft -04 Date: Thu, 4 Mar 2004 08:37:31 -0500 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 04 15:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The text states that there are no special TTL requirements for the NSEC RR. However, in the new DNSSECbis specs, we have the following suggestion for TTL values (records draft-07): The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308]. Minor difference since the above is a suggestion, and there are no real special requirements for the TTL. I think the NSEC data draft should include the above for consistancy. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:03:22 +0100 Lines: 143 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 15:15:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Hello, being new to rfc2782, I have a number of questions. I would be grateful for any enlightenment anyone could provide. Regards Barry Desborough Barry.Desborough@wanadoo.fr SRV RR FORMAT >From rfc2782 page 2 "The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target" But rfc1035 page 29 describes the generic RR header as being NAME TYPE CLASS TTL RDLENGTH RDATA According to 1035, and assuming that 'SRV' refers to TYPE, (not specified in 2782), it seems that the SRV RR should be _Service._Proto.Name SRV Class TTL RDLENGTH Priority Weight Port Target where _Service._Proto.Name corresponds to NAME SRV is the TYPE (33) Class, TTL and RDLENGTH are 1035 standard and Priority Weight, Port and Target correspond to RDATA Q1) Which rfc is correct? Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? Could not the contents of Target have been be reported in the NAME field and the Target field be dispensed with? TARGET SELECTION >From page 3 of rfc2782 " ............................................ The following algorithm SHOULD be used to order the SRV RRs of the same priority: To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority." Let's say we have only two targets of the same priority, with weights 1 and 2. If the weights are ordered 1 then 2, then we have Wt Sum ----------- 1 1 2 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 1 1 2 2 2nd contact 2 2 1 1 This gives each target equal probability of being contacted first. If the weights are ordered 2 then 1, then we have Wt Sum ----------- 2 2 1 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 2 2 2 1 2nd contact 1 1 1 2 The weight 2 target is contacted first with a probability of 3/4. Overall the probabilities for 1st contact are 3/8 and 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ _order_is_randomly_chosen_, but this is not specified. According to my reckoning, consistent, correct results are obtained if the random number is chosen to be between _ONE_ and the sum computed. Q3) Does anyone agree or disagree with this? If what is meant by 1st contact is the 1st successful attempt to find a Target, from whereupon this target's service is always used until it's TTL expiry or failure, then load sharing is only effected by different clients choosing different 1st contacts. On the other hand, if it means that a client which is a frequent, heavy user of a service client works down a sequence of targets to select which one provides the service next, all targets are selected with equal frequency. It seems to me that there is an assumption here that target contact selection from any particular client is very infrequent, and that load sharing occurs by virtue of different clients making 1st contact to different targets. In a system who's application makes frequent heavy of a service, service selection should be purely probabilistic based on the relative weights of the highest priority records available. Q4) Can anyone clarify this matter? Q5) Does anyone have any DNS SRV sniffer trace they could send directly to me to throw more light on the message format? (Please mail the group to say you have responded to this one, to save me being flooded!) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: bill <bmanning@karoshi.com> Subject: Re: comment on NSEC RDATA format draft -04 Date: Sat, 6 Mar 2004 06:57:33 -0800 (PST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:03:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: scottr@nist.gov (Scott Rose) In-Reply-To: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> from "Scott Rose" at Mar 04, 2004 08:37:31 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The > text states that there are no special TTL requirements for the NSEC RR. > However, in the new DNSSECbis specs, we have the following suggestion for > TTL values (records draft-07): > > The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL > field. This is in the spirit of negative caching [RFC2308]. > > Minor difference since the above is a suggestion, and there are no real > special requirements for the TTL. I think the NSEC data draft should > include the above for consistancy. > > Scott ack. this is a reasonable thing to do. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 10:31:55 -0500 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:41:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Barry Desborough <Barry.Desborough@wanadoo.fr> In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > From page 3 of rfc2782 > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive) > Random number case 0 1 2 3 > 1st contact 1 1 2 2 > 2nd contact 2 2 1 1 You appear to be computing a random integer, rather than a random real number, as was intended. If you choose a random real number, you'll get the appropriate distribution (a server with weight 2 is chosen twice as often with a server of weight 1). I would have much preferred a statement which used random integers (which is something you can actually do on a computer), but the working group was having a little trouble coming up with an algorithm statement that actually worked, so we decided to go with one which we strongly believed was correct even if it wasn't very clear and which didn't translate easily into code. It's particularly galling to me that we didn't even state explicitly what kind of number is to be chosen (integer, rational, computable, real, complex...), and then we threw in this parenthetical note "(inclusive)" which actually has no effect on the outcome if real numbers are being chosen. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. Neither of these choices seems appropriate. The TTL only applies to the DNS data itself, not the processing of it, so it would be wrong to choose a server once and then stick with it until the TTL expires. It would also be wrong to walk the list of choices when making multiple successful contacts; the idea is to walk the list when making a single contact until you are successful, then throw the list away. The next time you make a contact, you should start all over again and choose a new contact order randomly according to the weights. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 19:08:47 +0200 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:19:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 03:03:22PM +0100, Barry Desborough wrote: > Here is the format of the SRV RR, whose DNS type code is 33: > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > NAME TYPE CLASS TTL RDLENGTH RDATA RFC1035 deals with the on-the-wire encoding, while the SRV text above seems to be related to the usual BIND-style zone file format. The examples in RFC 2782 bear this out. However, re-reading RFC 2782 and RFC 2052, I could not determine a definitive on-the-wire encoding of SRV records -- this seems to be undefined. Presumably, implementors have just looked at how BIND returns SRV records and gone with that. > According to 1035, and assuming that 'SRV' refers to TYPE, > (not specified in 2782), The section "Usage rules" mentions QTYPE=SRV, and there is further text the SRV RR, whose DNS type code is 33 and The IANA has assigned RR type value 33 to the SRV RR which seems to tie SRV to TYPE, although perhaps not very directly. > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? I tried to find an online deployment of SRV records to feed to tcpdump, but the closest I came was an SOA record for _tcp.microsoft.com (one of the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no appear to have _tcp subdomains. Does anyone actually have a deployment of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? I also tried to find the IANA assignments for the Service tags, as referred to in RFC 2782, and couldn't locate any. Have any actually been standardized? If so, a pointer would be appreciated! -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 12:29:42 -0500 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:40:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? We appear to have: _sip._tcp.mit.edu _sip._udp.mit.edu _sip._tcp.sipxchange.mit.edu _sip._udp.sipxchange.mit.edu _kerberos._udp.athena.mit.edu _kerberos-master._udp.athena.mit.edu _kerberos-adm._tcp.athena.mit.edu -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:37:28 +0000 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <Barry.Desborough@wanadoo.fr> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:46:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from "Barry Desborough" <Barry.Desborough@wanadoo.fr> of "Sat, 06 Mar 2004 15:03:22 +0100." <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > From rfc2782 page 2 > > "The format of the SRV RR > > Here is the format of the SRV RR, whose DNS type code is 33: > > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > > NAME TYPE CLASS TTL RDLENGTH RDATA > ... > Q1) Which rfc is correct? both. rdlength is a protocol element describing rdata. the <rdlength,rdata> tuple is used to represent the rr data, which in this case is itself a tuple: <Priority,Weight,Port,Target>. in "dns master file" format as entered into zone files and as displayed by utilities such as "dig", rdlength is used to encode and decode the rr data but is never specified or displayed directly. > Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? > Could not the contents of Target have been be reported in the NAME field > and the Target field be dispensed with? because the names of the servers capable of responding to requests may not have names equal or similar to the name of the service. this is analagous to MX records, where the target name can be a service provider even though the query name is that of a customer. > ... > Overall the probabilities for 1st contact are 3/8 and > 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ > _order_is_randomly_chosen_, but this is not specified. > > According to my reckoning, consistent, correct results are > obtained if the random number is chosen to be between > _ONE_ and the sum computed. > > Q3) Does anyone agree or disagree with this? it seems reasonable to me, but i didn't write that part of the rfc and i'm not sure i ever understood it. greg hudson's answer was that the numbers had to be real not integer, and this may indeed be the case. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. > > It seems to me that there is an assumption here that target contact > selection from any particular client is very infrequent, and that > load sharing occurs by virtue of different clients making 1st contact > to different targets. no, actually we contemplated a web-like service where an object and all of the sub-objects (such as images) mentioned in that object should ideally be fetched from the same server, in case that server was capable of opportunistic pipelining or prefetching. > In a system who's application makes frequent heavy of a service, > service selection should be purely probabilistic based on the relative > weights of the highest priority records available. > > Q4) Can anyone clarify this matter? we contemplated making "sticky-ness" or "re-use" a protocol element but we felt that the SRV algorythm was already beyond its complexity horizon. the right thing to do now is: remove that part of the spec and designate re-use as "requestor-specific local policy". > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? (Please > mail the group to say you have responded to this one, to save me being > flooded!) ;; QUESTION SECTION: ;_kerberos._udp.vix.com. IN SRV ;; ANSWER SECTION: _kerberos._udp.vix.com. 3600 IN SRV 0 1 88 kerberos-0.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-1.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-2.vix.com. ;; AUTHORITY SECTION: vix.com. 3178 IN NS ns.lah1.vix.com. vix.com. 3178 IN NS ns.sql1.vix.com. vix.com. 3178 IN NS ns-ext.isc.org. ;; ADDITIONAL SECTION: ns.lah1.vix.com. 2429 IN A 204.152.188.234 ns.lah1.vix.com. 2429 IN AAAA 2001:4f8:2::9 ns.sql1.vix.com. 2429 IN A 204.152.184.135 ns.sql1.vix.com. 2429 IN AAAA 2001:4f8:3::9 ns-ext.isc.org. 3055 IN A 204.152.184.64 ns-ext.isc.org. 3057 IN AAAA 2001:4f8:0:2::13 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:48:11 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:53:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 06 Mar 2004 19:08:47 +0200." <20040306170847.GB24117@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > ... > RFC1035 deals with the on-the-wire encoding, while the SRV text > above seems to be related to the usual BIND-style zone file format. > The examples in RFC 2782 bear this out. However, re-reading RFC 2782 > and RFC 2052, I could not determine a definitive on-the-wire encoding > of SRV records -- this seems to be undefined. Presumably, implementors > have just looked at how BIND returns SRV records and gone with that. note that if BIND is shown to be wrong, we (isc) will of course fix it. > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? vix.com has no SRV-discovered services that use tcp as their transport. (presumably if we were a macintosh shop or a windows shop, we would?) _kerberos._udp.vix.com/IN/SRV has some data for you, though. > I also tried to find the IANA assignments for the Service tags, as > referred to in RFC 2782, and couldn't locate any. Have any actually > been standardized? If so, a pointer would be appreciated! here's the problem. SRV is experimental. 2052 was "snuck through" the ietf process when iesg's attention was focused elsewhere, and they got Really Angry about it when they found out. i've apologized, since mostly i was acting in ignorance and without malice, but it hasn't helped. so, in spite of the significant deployment of SRV in the community (like with the service discovery protocols currently shipped by microsoft and apple), SRV remains experimental. and as long as it's only experimental, iana's charter does not cover it. what we need to do is in two stages. first, iesg has to tell me how i can mend relations and achieve some kind of pardon for past SRV-related misdeeds. (perhaps a public apologia at an iesg plenary would suffice?) second, iana should create a registry of service identifiers, by importing the BSD file "/etc/services" and then periodically amending it for new standards -- and new standards should allocate a service name not just a default port number. i don't know how to do either of those things but that's the list, anyway. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jarle Greipsland <jarle@uninett.no> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 20:01:52 +0100 (CET) Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:07:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV > outside pseudo-DNS dynamic zones tied to DHCP servers? _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV -jarle -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 14:08:35 -0500 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:14:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 13:48, Paul Vixie wrote: > here's the problem. SRV is experimental. 2052 was "snuck through" the > ietf process when iesg's attention was focused elsewhere, and they got > Really Angry about it when they found out. Your history seems to be omitting the part where we got RFC 2782 published as a proposed standard (with you as one of the authors). That one certainly wasn't snuck through the IESG; we got significant feedback about the static weighting system, among other things. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 19:49:01 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <ghudson@MIT.EDU> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:56:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU> of "Sat, 06 Mar 2004 14:08:35 EST." <1078600115.9992.140.camel@error-messages.mit.edu> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > here's the problem. SRV is experimental. 2052 was "snuck through" the > > ietf process when iesg's attention was focused elsewhere, and they got > > Really Angry about it when they found out. > > Your history seems to be omitting the part where we got RFC 2782 > published as a proposed standard (with you as one of the authors). That > one certainly wasn't snuck through the IESG; we got significant feedback > about the static weighting system, among other things. indeed. i was thinking only of 2052 in my recounting. in that case there's nothing stopping someone from writing an rfc to immortalize /etc/services and making that file an iana database. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: David Shaw <dshaw@jabberwocky.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:13:42 -0500 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 21:20:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <20040306170847.GB24117@dns.net> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 07:08:47PM +0200, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV outside > pseudo-DNS dynamic zones tied to DHCP servers? _hkp._tcp.pgp.net to help find PGP keyservers. David -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sun, 7 Mar 2004 18:24:27 +0200 (EET) Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 03:29:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Hi, [[ note: I'm not subscribed... ]] I took a quick look at the DNSSEC intro document; it was in a very good shape. Two major comments: 1) the document requires the use of EDNS0. However, current EDNS0 implementations typically advertise the larger sizes than they can handle at the IP layer, causing fragmentation. You can argue that this is OK as long as the result of NOT fragmenting would end up with a worse result than as you would be without it (e.g., requiring falling back to TCP, or whatever). With DNSSEC, I'm not sure that this holds anymore. It seems to me that the best behaviour would be to avoid IP fragmentation by having correct implementations of EDNS0, and if some data must be left out, that it would be fetched separately, over second, third, ..., nth query over UDP. Shouldn't that be possible and reasonable? 2) Security considerations lists a number of threats, but does not discuss whether they have been fixed or mitigated at all (e.g., relating to dynamic updates and signing). It might not hurt to be a bit more explicit on this. Similarly, maybe some of this text could be included in the DNS security analysis document as well... editorial --------- page 4, chapter 2, replace "RRsets forms" with "RRsets forming" -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 03:09:22 +0000 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 04:15:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Sun, 07 Mar 2004 18:24:27 +0200." <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). most of <http://research.compaq.com/wrl/techreports/abstracts/87.3.html>'s concerns about fragmentation have been addressed, and the ones which still apply are relevant to small-mtu connections ("don't do that") and to high performance/demand mobygram applications (nfs, tcp). for dns, it's okay. > With DNSSEC, I'm not sure that this holds anymore. It seems to me > that the best behaviour would be to avoid IP fragmentation by having > correct implementations of EDNS0, and if some data must be left out, > that it would be fetched separately, over second, third, ..., nth > query over UDP. Shouldn't that be possible and reasonable? no, that really would force tcp, which really would be worse than ip-frag. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 13:47:21 +0900 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 05:55:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O Paul; > no, that really would force tcp, which really would be worse than ip-frag. If message size is 1400B or so, it is definitely so. If message size is 4200B or so, it can still be a valid argument. However, if message size is 64000B, TCP is far better than IP-frag. I understand the problem is not of DNSSEC but of EDNS0. But with the current EDNS0 specification lacking rational upper limit on message size, it will be safe if DNSSEC says: messages over UDP MUST NOT be larger than 4000 Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 05:02:50 +0000 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 06:08:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 13:47:21 +0900." <404BFAD9.80109@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > no, that really would force tcp, which really would be worse than ip-frag. > > If message size is 1400B or so, it is definitely so. > > If message size is 4200B or so, it can still be a valid argument. > > However, if message size is 64000B, TCP is far better than IP-frag. yes, that's true. the crossover is probably closer to 4*PMTU. > I understand the problem is not of DNSSEC but of EDNS0. > > But with the current EDNS0 specification lacking rational upper > limit on message size, it will be safe if DNSSEC says: > > messages over UDP MUST NOT be larger than 4000 it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E is for Estimated) but this isn't the time or place to make that change. so perhaps an advisory statement like "Note: advertising a buffer size larger than EPMTU could lead to unfortunate overaggressive IP fragmentation" would be enough to tell the dnssec implementor crowd -- who is likely to be the first real stress-testers of EDNS0's buffer size extension -- what they need to know, without actually amending the EDNS0 specification by side effect. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 14:58:13 +0900 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:02:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >> messages over UDP MUST NOT be larger than 4000 > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. I meant DNSSEC entities MUST NOT send messages larger than 4000 over UDP Can it be within the scope of DNSSEC? > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E > is for Estimated) but this isn't the time or place to make that change. If EDNS0 is to be changed (in the future, of course), reference to PMTUD should be clarified (removed entirely), because EDNS0 seemingly assumes fragmentation is always enabled, which means there is no room for PMTUD, which means, with IPv6, packets must be fragmented at the source. Or, if you think some form of PMTUD should be performed, it should be documented (though I think PMTUD practically impossible). > so perhaps an advisory statement like "Note: advertising a buffer size larger > than EPMTU could lead to unfortunate overaggressive IP fragmentation" would > be enough to tell the dnssec implementor crowd -- who is likely to be the > first real stress-testers of EDNS0's buffer size extension -- what they need > to know, without actually amending the EDNS0 specification by side effect. :-) Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:26:31 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:33:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Mon, 08 Mar 2004 07:37:47 +0200." <Pine.LNX.4.44.0403080733160.16733-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... would force tcp, which really would be worse than ip-frag. > > Seems like a flaw in DNS spec -- too coarse granularity: > 1) "everything fits in one UDP datagram", or > 2) "just use TCP". > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > datagram of specific size, query again, but only the missing data this > time". sense, yes, but the atomicity requirements are hard to adjust in that light. for example, if what you're trying to send is a referral, and the query and authority sections are all that fits, and you decide to just send that much and let the initiator re-query for the parts that would have been in the additional-data section, then it might end up being the case that they can never query for it. consider an authority section whose names are all under the referral cut. in earlier work once proposed as part of EDNS0 and then reintroduced as EDNS1, the idea came up to indicate in a response that there were multiple messages in the answer. we called it MD ("more data"). ultimately this turned out to be a lot more complicated than it sounded, and it's since been abandoned. i dearly wish that EDNS0 had made TTCP its prerequisite. ("ah, hindsight.") > Not sure if that would make sense but instead of forcing everything in > one, probably fragmented message, it would seem to encourage "proper" > operation with big DNS replies. in general, if you think the response might be larger than 3*EPMTU, use tcp, and that will amortize the complexity nicely. note that PMTUD hasn't been a raging success, and that EPMTU is probably 1500 octets most of the time, and that's where masataka's "4000" number comes from. > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. yes but on such a host, the EDNS0 initiator would presumably be able to discover this limitation and advertise a 1500-octet buffer. that's what the EDNS0 spec says it should do, at any rate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:29:28 +0000 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:34:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 14:58:13 +0900." <404C0B75.3000303@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > of scope. > > I meant > > DNSSEC entities MUST NOT send messages larger than 4000 > over UDP > > Can it be within the scope of DNSSEC? then it would be within scope for this docset, but extremely controversial since it places a requirement more stringent than EDNS0. far better to make it advisory and avoid the fight. > > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU > > (where E is for Estimated) but this isn't the time or place to make > > that change. > > If EDNS0 is to be changed (in the future, of course), reference to > PMTUD should be clarified (removed entirely), because EDNS0 seemingly > assumes fragmentation is always enabled, which means there is no room > for PMTUD, which means, with IPv6, packets must be fragmented at the > source. > > Or, if you think some form of PMTUD should be performed, it should be > documented (though I think PMTUD practically impossible). i think that you're right and that all hope of PMTUD should be abandoned in the next update of EDNS, which at this point would be EDNS1 rather than a reissue of EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 10:11:02 +0100 Organization: NIC France Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <20040306.200152.46801952.jarle@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 10:22:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jarle Greipsland <jarle@uninett.no> Content-Disposition: inline In-Reply-To: <20040306.200152.46801952.jarle@uninett.no> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.25-1-k7 i686 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 08:01:52PM +0100, Jarle Greipsland <jarle@uninett.no> wrote a message of 16 lines which said: > _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV Which is documented in: http://mailbox.univie.ac.at/~gw/draft-sanz-whois-srv-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 11:10:08 +0100 Lines: 196 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <1078587114.9992.126.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C404FD.EAE798E0" Cc: "Attila" <Attila.Sipos@VegaStream.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 11:32:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Greg Hudson" <ghudson@MIT.EDU> 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 Precedence: bulk Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your help, Greg. There's a note below about selection using random integers. ----- Original Message -----=20 From: "Greg Hudson" <ghudson@MIT.EDU> To: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Cc: <namedroppers@ops.ietf.org> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: DNS SRV Clarification sought > On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > > From page 3 of rfc2782 > > Compute the sum of the weights of those RRs, and with each = RR > > associate the running sum in the selected order. Then choose = a > > uniform random number between 0 and the sum computed > > (inclusive) > > > Random number case 0 1 2 3 > > 1st contact 1 1 2 2 > > 2nd contact 2 2 1 1 > > You appear to be computing a random integer, rather than a random real > number, as was intended. If you choose a random real number, you'll = get > the appropriate distribution (a server with weight 2 is chosen twice = as > often with a server of weight 1). > > I would have much preferred a statement which used random integers > (which is something you can actually do on a computer), but the = working > group was having a little trouble coming up with an algorithm = statement > that actually worked, so we decided to go with one which we strongly > believed was correct even if it wasn't very clear and which didn't > translate easily into code. Demonstration of selection using random integers. (Hope the fixed font is preserved and there's no line folding) Item Cumulative (weight) sum ---- -----=20 a a b a+b c a+b+c . . . . n a+b+c+...+n i.e.(sum(a...n)) Choosing a random integer between 1 and sum(a...n) inclusive and = selecting the first item greater than or equal to the random integer, we have - Random integer range 1...a a+1...a+b a+b+1...a+b+c Random integer frequency a (a+b)-(a+1)+1=3Db = (a+b+c)-(a+b+1)+1=3Dc Probability a/sum(a...n) b/sum(a...n) c/sum(a...n) For any item say, i, h being the previous item, Random integer range sum(a...h)+1...sum(a...i) Random integer frequency sum(a...i)-(sum(a...h)+1)+1=3Di Probability i/sum(a...n) Barry Desborough ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV>Thanks for your help, = Greg. There's a note=20 below about selection using random integers. ----- Original = Message -----=20 From: "Greg Hudson" <<A = href=3D"mailto:ghudson@MIT.EDU"><FONT=20 face=3DArial size=3D2>ghudson@MIT.EDU</A>> To:=20 "Barry Desborough" <<A = href=3D"mailto:Barry.Desborough@wanadoo.fr"><FONT=20 face=3DArial size=3D2>Barry.Desborough@wanadoo.fr</A>> Cc: <<A = href=3D"mailto:namedroppers@ops.ietf.org"><FONT=20 face=3DArial size=3D2>namedroppers@ops.ietf.org</A>> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: = DNS SRV=20 Clarification sought > On Sat, 2004-03-06 at 09:03, Barry=20 Desborough wrote: > > From page 3 of rfc2782 >=20 > Compute the sum of = the=20 weights of those RRs, and with each RR >=20 > associate the = running sum=20 in the selected order. Then choose a >=20 > uniform random = number=20 between 0 and the sum computed >=20 > = (inclusive) > >=20 > Random number case 0 1 2 3 > > 1st=20 contact = =20 1 1 2 2 > > 2nd=20 contact = =20 2 2 1 1 > > You appear to be computing a random integer, = rather than=20 a random real > number, as was intended. If you choose a = random real=20 number, you'll get > the appropriate distribution (a server with = weight 2=20 is chosen twice as > often with a server of weight = 1). > > I=20 would have much preferred a statement which used random integers > = (which=20 is something you can actually do on a computer), but the working > = group=20 was having a little trouble coming up with an algorithm = statement > that=20 actually worked, so we decided to go with one which we strongly > = believed=20 was correct even if it wasn't very clear and which didn't > = translate=20 easily into code. Demonstration of = selection=20 using random integers. (Hope the fixed font is preserved and there's = no line=20 folding) Item =20 Cumulative</DIV> <DIV>(weight) =20 sum ---- -----=20 a =20 a b =20 a+b c =20 a+b+c . =20 . . =20 . n a+b+c+...+n = i.e.(sum(a...n)) Choosing a random integer between 1 and = sum(a...n)=20 inclusive and selecting the first item greater than or equal to the = random=20 integer, we have -</DIV> <DIV> Random integer=20 range =20 1...a =20 a+1...a+b = a+b+1...a+b+c Random=20 integer frequency =20 a =20 (a+b)-(a+1)+1=3Db =20 (a+b+c)-(a+b+1)+1=3Dc Probability &= nbsp; =20 a/sum(a...n) b/sum(a...n) = c/sum(a...n) For any=20 item say, i, h being the previous item,</DIV> <DIV> Random integer=20 range sum(a...h)+1...sum(a...i) Random = integer=20 frequency =20 sum(a...i)-(sum(a...h)+1)+1=3Di Probability &nb= sp; =20 i/sum(a...n) Barry Desborough </DIV></BODY></HTML> ------=_NextPart_000_0007_01C404FD.EAE798E0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:59:49 -0500 Organization: NIST Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Pekka Savola" <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 16:39:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O ----- Original Message ----- From: "Paul Vixie" <paul@vix.com> > > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > > of scope. > > > > I meant > > > > DNSSEC entities MUST NOT send messages larger than 4000 > > over UDP > > > > Can it be within the scope of DNSSEC? > > then it would be within scope for this docset, but extremely controversial > since it places a requirement more stringent than EDNS0. far better to make > it advisory and avoid the fight. > It would also be an arbitrary limit based on current underlying network layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or EDNS0. It would best not be made a strict constraint that might be made obsolete by non-DNS factors. I agree with Paul in that it would be better to be an advisory statement, but not necessary to the specification. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 19:10:10 +1100 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 09:41:34 +0200." <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > What's your issue here? > > > > IPv4 has reassembly buffer size limits. > > IPv6 has reassembly buffer size limits. > > > > In either case you don't advertise a EDNS UDP buffer bigger > > than this limit. > > It would be nice if EDNS0 implementations conformed to these buffer > sizes then. On what platforms do the existing implementation not take these into account. Note most *nix platforms support 4k UDP datagrams already. > Currently it seems they have zero relation to MTU or PMTU, or buffer > sizes. There doesn't have to be a *explict* relationship to these. The current recommendations already take these into account. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 07:37:47 +0200 (EET) Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > With DNSSEC, I'm not sure that this holds anymore. It seems to me > > that the best behaviour would be to avoid IP fragmentation by having > > correct implementations of EDNS0, and if some data must be left out, > > that it would be fetched separately, over second, third, ..., nth > > query over UDP. Shouldn't that be possible and reasonable? > > no, that really would force tcp, which really would be worse than ip-frag. Seems like a flaw in DNS spec -- too coarse granularity: 1) "everything fits in one UDP datagram", or 2) "just use TCP". Would it make sense to add 1.5) there, "if it doesn't fit to a UDP datagram of specific size, query again, but only the missing data this time". Not sure if that would make sense but instead of forcing everything in one, probably fragmented message, it would seem to encourage "proper" operation with big DNS replies. Btw: note that IPv6 implementations aren't even required to defragment a datagram which is larger than 1500 bytes once assembled.. so we're in a bit murky waters here. I'd certainly want to try to avoid packet sizes >= ~1500. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:41:34 +0200 (EET) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200403080658.i286wXcq013551@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080658.i286wXcq013551@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > What's your issue here? > > IPv4 has reassembly buffer size limits. > IPv6 has reassembly buffer size limits. > > In either case you don't advertise a EDNS UDP buffer bigger > than this limit. It would be nice if EDNS0 implementations conformed to these buffer sizes then. Currently it seems they have zero relation to MTU or PMTU, or buffer sizes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 17:58:33 +1100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:05:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 06:26:31 -0000." <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. What's your issue here? IPv4 has reassembly buffer size limits. IPv6 has reassembly buffer size limits. In either case you don't advertise a EDNS UDP buffer bigger than this limit. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 10:08:33 -0600 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:18:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> Precedence: bulk Status: O On 3/6/2004 12:48 PM, Paul Vixie wrote: > iana should create a registry of service identifiers, by importing the > BSD file "/etc/services" and then periodically amending it for new > standards Is that really feasible? Service definitions may require weighting values and client-selection algorithms to be useful, all of which requires some level of agreement among implementors. If we start with a list of defaults and then update the list on-the-fly, how does the client know which version of the list entry is in use for those SRV RRs that they encounter? The nice thing about the current model is that an entry in the list connotes agreement among implementors, or at least carries a footnote. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 17:25:32 +0100 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <404C9A81.2040708@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:34:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 10:08:33 CST." <404C9A81.2040708@ehsco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <26114.1078763131.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Eric A. Hall wrote: > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards which would be different from <http://www.iana.org/assignments/port-numbers>? > Is that really feasible? Service definitions may require weighting values What weighting values are you talking about? Those in the SRV RR are not supposed to carry any additional meaning. RFC 2782 is pretty clear about the service names to be used: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. [...] Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. STD 2 is obsoleted by RFC 3232, again pointing to the URL above (although rather indirectly). What may be missing is a list of services without portnumber. In the whois case mentioned earlier inthis thread (which, btw uses "nicname" instead of the more prominent "whois" because of the "Service" requirement cited above) one would sometimes like to further differentiate the service without really using a different protocol, e.g. _ripe_whois.tcp... -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:21:20 +0200 (EET) Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <200403080810.i288AAcq036874@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:24:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080810.i288AAcq036874@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > > It would be nice if EDNS0 implementations conformed to these buffer > > sizes then. > > On what platforms do the existing implementation not take > these into account. Note most *nix platforms support 4k > UDP datagrams already. I don't know, maybe some embedded systems have restrictions. In any case 4000 byte UDP buffers does not equal being able to defragment datagrams worth of 4000 bytes total, right? > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > sizes. > > There doesn't have to be a *explict* relationship to these. > The current recommendations already take these into account. Well, about all the implementations I've seen set the EDNS0 irrespective of the MTU or PMTU configured on the system, which might make sense. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET) Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:25:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > > ... would force tcp, which really would be worse than ip-frag. > > > > Seems like a flaw in DNS spec -- too coarse granularity: > > 1) "everything fits in one UDP datagram", or > > 2) "just use TCP". > > > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > > datagram of specific size, query again, but only the missing data this > > time". > > sense, yes, but the atomicity requirements are hard to adjust in that light. Precisely -- but IMHO we need to figure out whether such atomicity requirements exist. They very certainly exist with 512 byte limit and DNSSEC. But do they exist e.g., with 1400 bytes? I'm a bit doubtful.. but I'd be interested in hearing what might be a "typical case", a "bad case", and "worst case". (We'll never be able to handle the last one, of course.) > > Not sure if that would make sense but instead of forcing everything in > > one, probably fragmented message, it would seem to encourage "proper" > > operation with big DNS replies. > > in general, if you think the response might be larger than 3*EPMTU, use tcp, > and that will amortize the complexity nicely. note that PMTUD hasn't been a > raging success, and that EPMTU is probably 1500 octets most of the time, and > that's where masataka's "4000" number comes from. Yep, EPMTU is 1500 bytes or a bit less -- but isn't that sufficient for about all intents and purposes? > > Btw: note that IPv6 implementations aren't even required to defragment > > a datagram which is larger than 1500 bytes once assembled.. so we're > > in a bit murky waters here. I'd certainly want to try to avoid packet > > sizes >= ~1500. > > yes but on such a host, the EDNS0 initiator would presumably be able to > discover this limitation and advertise a 1500-octet buffer. that's what > the EDNS0 spec says it should do, at any rate. Should, yes :). Does, no. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 12:03:05 -0600 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:10:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O On 3/8/2004 10:25 AM, Peter Koch wrote: > Eric A. Hall wrote: >> Is that really feasible? Service definitions may require weighting >> values > > What weighting values are you talking about? Those in the SRV RR are > not supposed to carry any additional meaning. The 'priority' field is different from the 'weight' field. RFC2782 says the following about the weight: | In the absence of a protocol whose specification calls for the | use of other weighting information, a client arranges the SRV | RRs of the same Priority in the order in which target hosts, | specified by the SRV RRs, will be contacted. > RFC 2782 is pretty clear about the service names to be used: Well, that's not the whole ball of wax. Service names can vary for reasosn other than protocol (http != www). Service names are relative labels which do not describe behavioral rules which may be associated with the service in general (algorithm may require SRV for in-addr space, or domain-wide space, or host-specific maps). Etc. Really, it seems to me that it's best to leave the list of well-known definitions for those SRV mappings and algorithms which are actually defined by the affected community. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: <fenner@research.att.com> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 03:47:36 +0900 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:54:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: pk@TechFak.Uni-Bielefeld.DE Versions: dmail (solaris) 2.5a/makemail 2.9d Precedence: bulk Status: O >> > iana should create a registry of service identifiers, by importing the >> > BSD file "/etc/services" and then periodically amending it for new >> > standards > >which would be different from ><http://www.iana.org/assignments/port-numbers>? Actually, I always thought that RFC 2782's [STD 2] reference was to the "PROTOCOL AND SERVICE NAMES" section, aka <http://www.iana.org/assignments/service-names>, and people who looked for the names in port-numbers were confused by the lack of strong binding to the reference (since there's no strong requirement for a port number assignment, just a name). Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 20:32:14 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 20:39:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 09 Mar 2004 03:47:36 +0900." <200403081847.i28IlbS24713@windsor.research.att.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <27142.1078774333.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Bill Fenner wrote: > was to the "PROTOCOL AND SERVICE NAMES" section, aka > <http://www.iana.org/assignments/service-names>, and people who looked this teaches us that the registry name will need to be specified explicitly, especially since URL references to the IANA registries are (were when I tried) only allowed to point to http://www.iana.org/numbers.html. > for the names in port-numbers were confused by the lack of strong binding Thanks, and increase the number of confused :-) > to the reference (since there's no strong requirement for a port number > assignment, just a name). The document you mention references WKS RRs, and since SRV is an orthogonal, though not totally unrelated, concept, it may be useful to use the same registry. However, since WKS uses port numbers (in a bit string) on-the-wire, I'm not too sure I understand the reasoning behind a registry dealing with names *only*. What's more important is some kind of link to the spec describing a) the protocol and b) use of SRV RRs in connection with that protocol. Elevation of 2782 will give us an opportunity to clarify this. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 05:41:18 +1100 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 21:19:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 18:21:20 +0200." <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > > It would be nice if EDNS0 implementations conformed to these buffer > > > sizes then. > > > > On what platforms do the existing implementation not take > > these into account. Note most *nix platforms support 4k > > UDP datagrams already. > > I don't know, maybe some embedded systems have restrictions. Well if you are writing a resolver for such a system you take its IP stack limitations into consideration. There are lots of additional considerations when writing for small memory platforms. Nobody is saying you *MUST* use certain size, just that they are recommended. Named has a switch to set the advertised size to 512. > In any case 4000 byte UDP buffers does not equal being able to > defragment datagrams worth of 4000 bytes total, right? > > > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > > sizes. > > > > There doesn't have to be a *explict* relationship to these. > > The current recommendations already take these into account. > > Well, about all the implementations I've seen set the EDNS0 > irrespective of the MTU or PMTU configured on the system, which might > make sense. With the current Internet the min(MTU,PMTU) will usually be 1500, ethernet/ppp default. Rarely will it be below 1200, slip default. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 13:17:05 -0800 Lines: 76 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 22:23:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Eric A. Hall'" <ehall@ehsco.com>, Paul Vixie <paul@vix.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O Registies are over-rated. Look at the number of programs there are on windows that have their own file format. Important name collisions are pretty rare considering that it is essentially a 3 character identifier. All that matters here is that the identifier be unique and plentiful enough that they do not run out. If you try to impose any requirement that is more stringent than first come first served we end up back with the X-Header problem. We could adopt the hash-cash scheme that Microsoft is pushing for anti-spam as a way of rationing code points in tables. All code points are first come first served. To get the code point 'SPAM' in table 'SRV' you have to provide a string s such that SHA1(s) - SHA1('SPAM+SRV') <> 0 AND |SHA1(s) - SHA1('SPAM+SRV')| < 2^(160-n) I.e. the strings must not be the same and the first n bits must match. The value of n would increase as the code points in the registry were exhausted. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eric A. Hall > Sent: Monday, March 08, 2004 11:09 AM > To: Paul Vixie > Cc: namedroppers@ops.ietf.org > Subject: Re: DNS SRV Clarification sought > > > > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by > importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards > > Is that really feasible? Service definitions may require > weighting values > and client-selection algorithms to be useful, all of which > requires some > level of agreement among implementors. > > If we start with a list of defaults and then update the list > on-the-fly, > how does the client know which version of the list entry is in use for > those SRV RRs that they encounter? > > The nice thing about the current model is that an entry in the list > connotes agreement among implementors, or at least carries a footnote. > > -- > Eric A. Hall > http://www.ehsco.com/ > Internet Core Protocols > http://www.oreilly.com/catalog/coreprot/ > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:02:38 +0900 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> <000301c40521$f3ba77c0$1a1f0681@lapdancer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:08:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Scott Rose <scottr@nist.gov> In-Reply-To: <000301c40521$f3ba77c0$1a1f0681@lapdancer> Precedence: bulk Status: O Scott Rose; > It would also be an arbitrary limit based on current underlying network > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > EDNS0. 512 byte limit is a bound not by DNS but by the current underlying network and transport layers. So? > but not necessary to the specification. It is necessary that DNS message size has a limit in the specification. Masataka Ohta PS The proper limit bound by minimum reassembly buffer size, maximum IP header length and UDP header length is 508. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:46:37 +0900 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:51:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > Why are we arguing about the minimums that have to be > supported by the architecure? Because the minimums of the infrastructure are maximums of DNS. > For example, named has a upper bound on the size of the > EDNS/UDP response it will send. And, it should be specified. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 09:38:11 +0900 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 02:44:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > EDNS and DNS are *different* protocols which share a port and > message format. RFC2671 This document describes backward compatible mechanisms for allowing the protocol to *GROW*. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 09:13:19 +0100 Organization: RIPE NCC Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <1078594181.9992.134.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 09:26:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Greg Hudson <ghudson@MIT.EDU> In-Reply-To: <1078594181.9992.134.camel@error-messages.mit.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.473609 / 0.0 / 0.0 X-RIPE-Signature: 86a7b34adf4294872cd6cf962183ce6b Precedence: bulk Status: O On Sat, 06 Mar 2004 12:29:42 -0500 Greg Hudson <ghudson@MIT.EDU> wrote: > On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > > I tried to find an online deployment of SRV records to feed to tcpdump, > > but the closest I came was an SOA record for _tcp.microsoft.com (one of > > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > > appear to have _tcp subdomains. Does anyone actually have a deployment > > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? > > We appear to have: > > _sip._tcp.mit.edu > _sip._udp.mit.edu > _sip._tcp.sipxchange.mit.edu > _sip._udp.sipxchange.mit.edu Where the use of SRV for SIP is documented in RFC3263 -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 11:23:43 +1100 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:46:37 +0900." <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Mark Andrews; > > > Why are we arguing about the minimums that have to be > > supported by the architecure? > > Because the minimums of the infrastructure are maximums of DNS. We are talking about EDNS. Nobody is thinking about changing the DNS UDP message size. The DNS is constained in this way, EDNS is not. EDNS and DNS are *different* protocols which share a port and message format. EDNS has a UDP request size limit of 512 bytes (inherited from DNS) unless you have reason to believe a larger request can be handled. e.g. you have just made a request and have been told that a bigger request can be handled. EDNS has a *negotiated* response size limit. This is IP stack dependent and will usually be *bigger* than the infrastructure minimums. It can also be smaller the the infrastructure minimums. e.g. you have a IPv6 firewall which is rejecting DNS packets > 512 bytes so you set the EDNS UDP size advertised to 512. The advertised EDNS UDP size is less than the minimum supported by the IPv6. DNS has a UDP request and response size limit of 512 bytes. > > For example, named has a upper bound on the size of the > > EDNS/UDP response it will send. > > And, it should be specified. Why. This is a *implemtation* limit not a *protocol* limit. RFC 2671 already has guidance for seting this limit. > > Masataka Ohta > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 10:35:24 +1100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:02:38 +0900." <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Scott Rose; > > > It would also be an arbitrary limit based on current underlying network > > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > > EDNS0. > > 512 byte limit is a bound not by DNS but by the current underlying > network and transport layers. > > So? > > > but not necessary to the specification. > > It is necessary that DNS message size has a limit in the specification. > > Masataka Ohta > > PS > > The proper limit bound by minimum reassembly buffer size, maximum > IP header length and UDP header length is 508. Why are we arguing about the minimums that have to be supported by the architecure? EDNS is about letting the the other end knowing what you are *capable of handling*. There is *nothing* in to stop a site sending *smaller* EDNS/UDP message than the receiving site is capable of handling. If the client says it can accept a 4k response but you know that your firewall is broken (e.g. drops DNS packets > 512) you are quite entitled to only send a 512 byte EDNS/UDP responses. Set TC as appropriate. For example, named has a upper bound on the size of the EDNS/UDP response it will send. You can advertise a 64k UDP buffer all you want but you will not get more that 4k EDNS/UDP response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 9 Mar 2004 17:04:26 +0100 Organization: RIPE NCC Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 17:12:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> In-Reply-To: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.456200 / 0.0 / 0.0 X-RIPE-Signature: 61983aa15b37f75c7f5207c40c99cbab Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). It seems there _could_ be consensus for an advisory note targeted at implementors, if only there were such a note. Can somebody please come up with text that can be put into the document set so we can focus on getting that correct and the editors can cut-n-paste. Let us not try to fix EDNS0, that is not in scope. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Wed, 10 Mar 2004 17:58:37 +0100 Organization: RIPE NCC Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <20040128203233.08EE614C52@sa.vix.com> <6.0.3.0.2.20040212231103.02da4b80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 18:11:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040212231103.02da4b80@localhost> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000719 / 0.0 / 0.0 X-RIPE-Signature: 022e6963a054024de5098a486a89bbd4 Precedence: bulk Status: O > While attempting to summarize what the consensus of the working group > is on this editors question and trying to interpret this block of text. > Does self-consistently apply to a name or the holy Q-trinity? Having reread the threat I think that the answer to Olafurs question was in the proposed text (only for the _security_ RRs so only for specific holy Q-trinities :-) ). I propose the editors use Paul's initial text with the clarification that this only applies to those _security_ RRs that can exist above and below a delegation point. e.g. like: security aware responders who receive queries security RRs (NSEC or RRSIG RRs) which match the content of more than one zone, for example above and below a delegation point, are encouraged to behave self-consistently, which could mean: always return an error; always return above-delegation records; always return below-delegation records; always return no records; always return both above- and below-delegation records; or always something else entirely. We'll consider this question resolved if no further comments are received before the end of the week. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-04.txt Date: Wed, 10 Mar 2004 15:40:37 -0500 Lines: 86 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 21:48:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-04.txt Pages : 9 Date : 2004-3-10 This document redefines the wire format of the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:34:09 -0500 Lines: 50 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 16:43:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org Precedence: bulk Status: O The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf >Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >From: Derek Atkins <derek@ihtfp.com> >Date: Tue, 24 Feb 2004 22:14:43 -0500 > >It sounds like you want two things here, but it also sounds like all >of them need to happen in the responder. The attacker could >theoretically send packets of any type, with any TTL. So you can't >trust anything you receive from the network. To this affect, I think: > >1) We want the responder to try to determine that a request came from > the local network. The best way to do this is for the responder to > check that TTL=255 to make sure. If a TTL is less than 255 then it > originiated off-net and can be dropped. > >2) We want the responder to make sure response packets don't go > off-net. In other words, we want the responder to respond with > TTL=1, to make sure it can't smurf. > >So, to this affect: > >a) an LLMNR requestor should send requests with TTL=255 >b) an LLMNR responder should verify requests have TTL=255 -- if it is not > 255 then it should drop the packet. >c) an LLMNR responder should respond with TTL=1 >d) I dont' think an LLMNR requestor needs to check the response TTL. > >The only issue this doesn't directly solve is a requester being >spoofed by an off-net attacker, but said attacker would need >to guess the transaction id of the request in order to send a >valid response, which is just as likely in LLMNR as it is in >standard DNS, so it can probably be ignored. > >So, other than this issue, does this solve the issue? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:52:56 -0800 Lines: 161 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--207754511; protocol="application/pkcs7-signature" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 20:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-8--207754511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have an issue with this. Using a TTL of 255 to verify that requests originate from the local=20 link is not very important. It may be useful to use a unicast query to=20= specific address from off of the local link to ask for records such as=20= HINFO. In the case of multicast, unless something is seriously broken a=20= link-local multicast packet is not going to be forwarded. Setting the TTL to 1 also unnecessarily prohibits unicast=20 request/responses from off of the local link. I would consider it more=20= useful to verify that a response to a link-local multicast came from=20 the local link. To those who are concerned that setting the TTL to 255 on a response=20 would enable another smurf attack, I would encourage them to try=20 pinging the all hosts multicast address. Most hosts will respond to=20 such a ping. This has not lead to any serious problems. The solution to=20= the smurf attack was to drop the subnet broadcast packets in routers=20 (don't forward them). A link local multicast packet will not be=20 forwarded. The defense against the smurf style attack is already=20 implemented. Hosts still respond to pings with subnet broadcasts but=20 routers never forward such packets, so this is only a local=20 vulnerability. If someone is local they could just as easily spoof the=20= source address of their packets as any of the other devices on the=20 local network. If the whole point of changing the TTL is to achieve interoperability=20 with Rendezvous, then the proposal below fails. -josh On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > > The chairs are looking for closure and rough consensus on this only > remaining issue for LLMNR. > The solution below seems like a good solid compromise. > Is there any technical reason why this should not be adopted, please > state so before March 24'th. > > Olafur & Olaf > > >> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >> From: Derek Atkins <derek@ihtfp.com> >> Date: Tue, 24 Feb 2004 22:14:43 -0500 >> >> It sounds like you want two things here, but it also sounds like all >> of them need to happen in the responder. The attacker could >> theoretically send packets of any type, with any TTL. So you can't >> trust anything you receive from the network. To this affect, I = think: >> >> 1) We want the responder to try to determine that a request came from >> the local network. The best way to do this is for the responder = to >> check that TTL=3D255 to make sure. If a TTL is less than 255 then = it >> originiated off-net and can be dropped. >> >> 2) We want the responder to make sure response packets don't go >> off-net. In other words, we want the responder to respond with >> TTL=3D1, to make sure it can't smurf. >> >> So, to this affect: >> >> a) an LLMNR requestor should send requests with TTL=3D255 >> b) an LLMNR responder should verify requests have TTL=3D255 -- if it = is=20 >> not >> 255 then it should drop the packet. >> c) an LLMNR responder should respond with TTL=3D1 >> d) I dont' think an LLMNR requestor needs to check the response TTL. >> >> The only issue this doesn't directly solve is a requester being >> spoofed by an off-net attacker, but said attacker would need >> to guess the transaction id of the request in order to send a >> valid response, which is just as likely in LLMNR as it is in >> standard DNS, so it can probably be ignored. >> >> So, other than this issue, does this solve the issue? > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org = with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> --Apple-Mail-8--207754511 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxMTE4NTI1N1owIwYJKoZIhvcNAQkEMRYEFP0O Ia3W8w/x+47YEoXcV/9pDyndMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAApn zOCUjtzfx/HePoVrW9B92akgPc+74/dwmULkkUhYbv/Iw+gASUnplhFK3mz62o1NZYRGb4RuHmjx ar1KWlU8rIl3QoCNBqY8q3QISGI2oApMtnVXMf0abz/IST8hTndYl02br+7iXmDdyNuUrYQmjRyt QYIV3JUzV7Q8UOBiRwPRYuSeiDvJEsCd1h5IMExVNZOBjD69fu3oMK5bVq3gHNPQyKl59BSFkJlE 3w89yzOFPI67eeDhzDVEraXIW8w04oNM6AkzxjJwNugRReSSZAe635ZDBiMFzowtQf7pdNqpSN7c Jr0s0lkNZg2K8rc+5ALBd7MpnTMj44AxUt4AAAAAAAA= --Apple-Mail-8--207754511-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Fri, 12 Mar 2004 11:37:19 -0500 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 17:49:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040228124513.02f35bc8@localhost> References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Precedence: bulk Status: O At 13:00 2004-02-28, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >This RFC was published about 6 months ago so it is now a candidate to >advance through he standards track. >In order to do that we need > evidence of implementation, > interoperabilty test and report. Jakob Schlyter <jakob@rfc.se> has stepped up and will coordinate the interoperabilty testing and write the report. (Thanks Jakob) He needs help from vendors in identifying support, please contact him to participate in the testing. Jakob and I will be contacting some vendors privately asking explicit questions of support and if they want to participate. Even though IETF rules say only two implementation are needed for the interoperabilty test, the chairs would like to include as many as possible. One important reason is the impact RFC3597 support has on the introduction of new RR types. The interoperabilty testing will address all types of DNS functional units: - Authorative servers (primary and secondary) - Recursive Resolvers (including Caches) - Stub Resolvers - Diagnostic tools The standard IETF interoperabilty rules will apply - List of implementations tested will be provided - Any problem identified will be examined to see if the source of the problem is the documentation - There will be NO public disclosure of what implementations had problems only a list of the problems. The goal here is twofold, advance a better document, allow vendors to address any problems identified sooner than later. Olafur (co-chair). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Fri, 12 Mar 2004 15:28:27 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 21:40:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 12 Mar 2004 16:56:27 -0500 Lines: 138 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 23:08:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> (Joshua Graessley's message of "Thu, 11 Mar 2004 10:52:56 -0800") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Hi, Joshua Graessley <jgraessley@apple.com> writes: > Using a TTL of 255 to verify that requests originate from the local > link is not very important. It may be useful to use a unicast query to > specific address from off of the local link to ask for records such as > HINFO. In the case of multicast, unless something is seriously broken > a link-local multicast packet is not going to be forwarded. It's exactly the fact that it's useful in a unicast query that we should do it. You are correct, multicast doesn't care, so we should use the TTL value that gives us the most bang for the buck. What does it hurt us to use TTL=3D255 and verifying it? In neither case does it hurt us. Yes, requests could leave the network, but the responder would drop them (as it should -- it's not link-local!) > Setting the TTL to 1 also unnecessarily prohibits unicast > request/responses from off of the local link. I would consider it more > useful to verify that a response to a link-local multicast came from > the local link. Indeed, this prohibition is EXACTLY WHAT WE WANT! It's not unnecessary. It's a requirement! > To those who are concerned that setting the TTL to 255 on a response > would enable another smurf attack, I would encourage them to try > pinging the all hosts multicast address. Most hosts will respond to > such a ping. Just because a problem exists in another protocol and isn't majorly exploited now does not mean that we should make the same mistake. People HAVE used DNS as a smurf/explosion attack. Pings aren't interesting -- the response is no larger than the request. DNS is VERY interesting, because I could potentially get a LARGE response for a small request. Therefore, we should protect against it. > This has not lead to any serious problems. The solution > to the smurf attack was to drop the subnet broadcast packets in > routers (don't forward them). A link local multicast packet will not > be forwarded. The defense against the smurf style attack is already > implemented. Hosts still respond to pings with subnet broadcasts but > routers never forward such packets, so this is only a local > vulnerability. If someone is local they could just as easily spoof the > source address of their packets as any of the other devices on the > local network. This type of defence does not protect against unicast LLMNR requests. Sure, a properly configured multicast router can stop the multicase requests, but it wont stop the unicast packets. That's yet another reason we should use TTL=3D1 on responses, to make sure unicast messages can't smurf. > If the whole point of changing the TTL is to achieve interoperability > with Rendezvous, then the proposal below fails. No, the whole point of this proposal is to get us out of the deadlock that we've been in by showing how we can use TTLs to get the most bang for the buck. I've listed all the threats that I think we're worried about and I've shown how the largest set of threats can be mitigated by the combined 255/1 TTL. If we can get Apple to move along with us and interoperate, great. But this proposal is not "let's make this look like Rendevous". > -josh So, Olaf and Olafur, I obviously have no technical reason why this should not be adopted ;) -derek > On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > >> >> The chairs are looking for closure and rough consensus on this only >> remaining issue for LLMNR. >> The solution below seems like a good solid compromise. >> Is there any technical reason why this should not be adopted, please >> state so before March 24'th. >> >> Olafur & Olaf >> >> >>> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >>> From: Derek Atkins <derek@ihtfp.com> >>> Date: Tue, 24 Feb 2004 22:14:43 -0500 >>> >>> It sounds like you want two things here, but it also sounds like all >>> of them need to happen in the responder. The attacker could >>> theoretically send packets of any type, with any TTL. So you can't >>> trust anything you receive from the network. To this affect, I think: >>> >>> 1) We want the responder to try to determine that a request came from >>> the local network. The best way to do this is for the responder to >>> check that TTL=3D255 to make sure. If a TTL is less than 255 then it >>> originiated off-net and can be dropped. >>> >>> 2) We want the responder to make sure response packets don't go >>> off-net. In other words, we want the responder to respond with >>> TTL=3D1, to make sure it can't smurf. >>> >>> So, to this affect: >>> >>> a) an LLMNR requestor should send requests with TTL=3D255 >>> b) an LLMNR responder should verify requests have TTL=3D255 -- if it >>> is not >>> 255 then it should drop the packet. >>> c) an LLMNR responder should respond with TTL=3D1 >>> d) I dont' think an LLMNR requestor needs to check the response TTL. >>> >>> The only issue this doesn't directly solve is a requester being >>> spoofed by an off-net attacker, but said attacker would need >>> to guess the transaction id of the request in order to send a >>> valid response, which is just as likely in LLMNR as it is in >>> standard DNS, so it can probably be ignored. >>> >>> So, other than this issue, does this solve the issue? >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: <http://ops.ietf.org/lists/namedroppers/> --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:27:07 +0900 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:35:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >>>no, that really would force tcp, which really would be worse than ip-frag. >> >>If message size is 1400B or so, it is definitely so. >> >>If message size is 4200B or so, it can still be a valid argument. >> >>However, if message size is 64000B, TCP is far better than IP-frag. > yes, that's true. the crossover is probably closer to 4*PMTU. Given 1280B of IPv6 minimum MTU, shouldn't message size limitation be somewhere around 3600 or 4800, but not 4000? Masagtaka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:48:52 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> <4052474B.9010306@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:56:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <4052474B.9010306@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O I wrote: >>yes, that's true. the crossover is probably closer to 4*PMTU. > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? My guess is that current specification of 4000B expects 3 frags over IPv4 that it should be 3600B for IPv6. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 09:35:59 +0900 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 01:53:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Precedence: bulk Status: O From: Derek Atkins <derek@ihtfp.com> >> 1) We want the responder to try to determine that a request came from >> the local network. No, we don't. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 00:58:15 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 02:06:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Sat, 13 Mar 2004 08:27:07 +0900." <4052474B.9010306@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > yes, that's true. the crossover is probably closer to 4*PMTU. > > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? i think it's all very approximate and 4000 is a very fine and round number. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 15:09:22 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 14:28:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Mon, Mar 08, 2004 at 08:32:14PM +0100, Peter Koch wrote: > Bill Fenner wrote: > > was to the "PROTOCOL AND SERVICE NAMES" section, aka > > <http://www.iana.org/assignments/service-names>, and people who looked > > this teaches us that the registry name will need to be specified explicitly, > especially since URL references to the IANA registries are (were when I tried) > only allowed to point to http://www.iana.org/numbers.html. RFC 3232 makes reference to http://www.iana.org/ which in turn makes a reference to http://www.iana.org/numbers.html but then the trail gets cold. There are several potential documents that could be relevant, for instance either http://www.iana.org/assignments/port-numbers (this is the classic /etc/services document we have all been using as a reference, but isn't obviously tied in to DNS) or http://www.iana.org/assignments/service-names (which could be relevant since it is explicitly associated with WKS records). > Elevation of 2782 will give us an opportunity to clarify this. I would like to document the "correct" usage of SRV records at DNSRD, so I agree that the next version of 2782 should explicitly refer to the correct registry document. Now, which one is it? port-numbers or service-names? -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 17:15:25 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 18:27:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 13 Mar 2004 15:09:22 +0200." <20040313130922.GA23428@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > Elevation of 2782 will give us an opportunity to clarify this. > > I would like to document the "correct" usage of SRV records at DNSRD, > so I agree that the next version of 2782 should explicitly refer to the > correct registry document. > > Now, which one is it? port-numbers or service-names? there isn't one. and unless one of you writes an internet-draft which asks iana to import /etc/services and then maintain the master copy of it, then 2782bis will not have anything to point at. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 12:02:40 -0800 Lines: 61 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 21:13:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQIfkyla6nOGvrbT9eb4zFEHTUH4QAtGG7A To: "Derek Atkins" <derek@ihtfp.com>, "Joshua Graessley" <jgraessley@apple.com> X-OriginalArrivalTime: 13 Mar 2004 20:02:38.0054 (UTC) FILETIME=[223D4060:01C40936] Precedence: bulk Status: O Could we agree in any case that the TTL discussion does not apply when = we use TCP?=20 As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=3D255, as = per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of = address ranges is sufficient to guarantee on-link status. Setting = TTL=3D1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of = packet to the local link. On-link attackers can spoof the source = address; off-link attackers generally cannot send multicast packets to = the destination. Checking the TTL provides no protection against on-link = attackers (they can set whatever TTL value is expected). Checking that = the source address belongs to an "on-link" prefix prevents the "smurf = attack to an off-link target". Setting the TTL=3D1 in multicast queries = prevent the side effects of a rare bug in routers, but this bug may not = be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, = including for off-link attackers. Checking TTL=3D255 protects against = spoofing by off-link sources. Checking that the source address belongs = to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the = transaction identifier, which in practice requires an "on-link" = attacker; TTL games do not protect against on-link attackers. Setting = the TTL to 1 protects against unwitting participation in a DOS-attack to = an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some = network topologies that support multicast but require packets to go = through a router -- some wireless networks and some ad hoc networks can = have that property. In practice, checking TTL=3D255 is only useful in UDP unicast queries, = where it provides a slight incremental benefit over a simple check of = the source address prefix. Setting the TTL to 1 provides a limited = benefit in TCP operation, multicast queries and unicast responses, but = contradicts the requirement of TTL=3D255 for IPv6 link-local addresses. = Setting to either value will create operational problems in some future = scenarios. The simplest solution is probably to remove all mentions of TTL checks = from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an = authorized range; 2) The TTL field should be set by the stack to whatever default value is = adequate for the interface and the source address (e.g., TTL=3D255 for = IPv6 link-local addresses.) -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:29:16 +0200 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Derek Atkins <derek@ihtfp.com>, Joshua Graessley <jgraessley@apple.com>, =?ISO-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 23:39:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Christian Huitema <huitema@windows.microsoft.com> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Christian, > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <mika.liljeberg@welho.com> X-From: owner-namedroppers@ops.ietf.org Sun Mar 14 01:32:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Mika Liljeberg <mika.liljeberg@welho.com> of "Sun, 14 Mar 2004 00:29:16 +0200." <1079216956.1930.16.camel@hades> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. "i'll by THAT for a dollar." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 15 Mar 2004 14:08:17 +0900 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040313005815.D96AA14D81@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 06:15:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040313005815.D96AA14D81@sa.vix.com> Precedence: bulk Status: O Paul; >>>yes, that's true. the crossover is probably closer to 4*PMTU. >> >>Given 1280B of IPv6 minimum MTU, shouldn't message size limitation >>be somewhere around 3600 or 4800, but not 4000? > > > i think it's all very approximate and 4000 is a very fine and round number. It could have been so, if PMTUD were usable, which would have resulted in PMTU of 1450~1500. Without PMTUD, however, assumed MTU MUST be 1280, for which very approximate and round should be 3500 or 3600. Or, are there any cryptographic reason that the size is 4000? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 18:52:17 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <20040313171525.8D6F418F48@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:02:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Sat, 13 Mar 2004 17:15:25 GMT." <20040313171525.8D6F418F48@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <25301.1079373136.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Paul Vixie wrote: > > Now, which one is it? port-numbers or service-names? > > there isn't one. and unless one of you writes an internet-draft which > asks iana to import /etc/services and then maintain the master copy of I'm sorry but I do not see any difference between /etc/services and the "port-numbers" registry except for the non-existence of aliases in the latter. What do you miss? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Mon, 15 Mar 2004 10:30:45 -0800 Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <1079216956.1930.16.camel@hades> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-136514579; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:40:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <1079216956.1930.16.camel@hades> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-3-136514579 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Works for me. -josh On Mar 13, 2004, at 2:29 PM, Mika Liljeberg wrote: > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. > > MikaL --Apple-Mail-3-136514579 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNTE4MzA0NlowIwYJKoZIhvcNAQkEMRYEFHrU VLPbNQNtvNopd+r+aqYgPGgTMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAMVP pq29OvSY+jKZQaZQC/DwN6GQ+O7rFsR4Q6EoohlgH38fYMCZ7OwTlKafoMP+kn1kxJK4Cqd8WdQ+ 2PR8K0aTIU9m8SO16+Ou3ddFmgxrB/TpyT75BdB6YsWxdiHMWRrPMXa3udJ4caBrASZ1218a6eM3 fFglGZT8BHoL1bd5ylnjlHbJ5zYOHU9xLliKjacwEwlBV1srKbny1YcRaclaTLPL8rMcwuOggyc9 k3V3G2EgekhjO43lrHH39vU58HqG4fiNUzpsefi9W9KgxyHZntipn2oLO/EUZ1cwsLtZytZLlU0z UHt8+32mJpkXneCh3hLwIAz8cbPUGd4Y53EAAAAAAAA= --Apple-Mail-3-136514579-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 20:00:49 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <pk@TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:13:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Peter Koch <pk@TechFak.Uni-Bielefeld.DE> of "Mon, 15 Mar 2004 18:52:17 +0100." <200403151752.i2FHqHk25304@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > I'm sorry but I do not see any difference between /etc/services and > the "port-numbers" registry except for the non-existence of aliases in the > latter. What do you miss? ftp://ftp.iana.org/assignments/port-numbers' "keyword" field (which wasn't there a few years ago when i last looked at this file) seems like the right answer. however, a purely SRV-discovered service might not _have_ a default port number, in which case ftp://ftp.iana.org/assignments/service-names would be the better choice for an SRV's owner name. and, it would be good to know that iana's policy is to keep synchronization between port-numbers keywords, and service-names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 12:42:37 -0800 Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:54:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O however, a purely SRV-discovered service might not > _have_ a default > port number, in which case > ftp://ftp.iana.org/assignments/service-names would > be the better choice for an SRV's owner name. It seems to me that a good long term objective here would be to stop issuing port numbers completely. The logical extension of SRV is that you look up the service in DNS and get back a report of the name of the server that supports the service, the port address to use plus any parameters that describe the use of the port (I support SSL security with profile X). This is where the Internet will be in a few years time. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Mon, 15 Mar 2004 16:52:00 -0500 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 23:02:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Just a notification from your friendly neighborhood DNSSECbis document editors, to avoid suprising anyone. Miek Gieben and Jelte Jansen pointed out what we are certain is an editorial goof in way we specified calculation of the RRSIG signature value. The current drafts (both -protocol and -records) say that the signature is calculated over RR(i) = name | class | type | OrigTTL | RDATA length | RDATA As Miek and Jelte pointed out to us, the class and type fields here are reversed from the normal RFC 1035 ordering for a wire-encoded RR (not to be confused with the RFC 1035 text format, which has the class, type, and TTL fields in reverse order to avoid parse ambiguities). To the best of our knowledge: a) RFC 2535 did not explictly specify the order, but the algorithm has generally been understood as signing the wire representation; b) There has been no WG action since RFC 2535 that would change this; and c) All current implementations of which we're aware use the wire ordering, not what the DNSSECbis specs currently say. So this seems to have just been an editorial goof, we've fixed it in the editors' working sources, and the fix will be in the next revisions of the drafts we post. If anyone has a problem with this change, please send mail to the editors, the WG chairs, or to namedroppers, as appropriate. Thanks to Miek and Jelte for catching this! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Tue, 16 Mar 2004 09:36:19 +0100 Organization: RIPE NCC Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040315215200.D2A7318E0@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 16 09:44:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org> In-Reply-To: <20040315215200.D2A7318E0@thrintun.hactrn.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.082025 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8ddd797dfea932e40d44a26c70d1f113 Precedence: bulk Status: O Miek, Jelte, Good Catch!! Rob wrote: > a) RFC 2535 did not explictly specify the order, but the algorithm has > generally been understood as signing the wire representation; It is somewhat hidden through a refference from section 4.1.8 (Signature field): " RR(s) is the RRset of the RR(s)(...) in canonical form and order as defined in Section 8. " RFC 2535 section 8.1 applies: For purposes of DNSsecurity, the canonical form for an RR is the wire format of the RR (...) -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST) Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 02:18:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O > Ok, although I would rather suggest: > 1) Nodes should very that the source address of queries belong to an > authorized range; I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. > 2) Use TTL=1 with TCP. This makes sense. > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. This only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 21:54:41 -0800 Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:03:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQLvatlaIXizGLoR++uJyP8Awx4HgAJaJwg To: "Bernard Aboba" <aboba@internaut.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 17 Mar 2004 05:52:47.0441 (UTC) FILETIME=[131E2C10:01C40BE4] Precedence: bulk Status: O > > Ok, although I would rather suggest: >=20 > > 1) Nodes should very that the source address of queries belong to an > > authorized range; >=20 > I'm not sure how to define an "authorized range". A host may not know all > the prefixes present on a given link. In IPv6 at least, the host is suppose to learn the list of on-link prefixes from the RA. But you are right, there are many ways to get this test half-right and cause major operation pain.=20 > > 2) Use TTL=3D1 with TCP. >=20 > This makes sense. >=20 > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. >=20 > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. >=20 > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=3D1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Getting rid of unicast UDP query would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=3D1 also guarantees an on-link peering.=20 The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Wed, 17 Mar 2004 08:07:22 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:11:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Bernard Aboba <aboba@internaut.com> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O On Wed, 2004-03-17 at 03:17, Bernard Aboba wrote: > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. > > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. Well, section 2.4 already says: "Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries." > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Using different TTLs for different messages is awkward from the implementation standpoint. It would be simplest just to require that all requests and responses must be sent to the local link. E.g. use the SO_DONTROUTE socket option. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 06:06:21 -0800 (PST) Lines: 318 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 15:08:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O The text of LLMNR Issue 64 is enclosed below. The proposed resolution is as follows: In Section 2.4, change: "Unicast LLMNR queries SHOULD be sent using TCP." To: "Unicast LLMNR queries MUST be sent using TCP." Change: "Unicast UDP queries MAY be responded to with a UDP response containing an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP." To: "Unicast UDP queries MUST be silently discarded." Change: "If an ICMP "Time Exceeded" message is received in response to a unicast UDP query, or if TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). The UDP sender receiving an ICMP "Time Exceeded" message SHOULD verify that the ICMP error payload contains a valid LLMNR query packet, which matches a query that is currently in progress, so as to guard against a potential Denial of Service (DoS) attack. If a match cannot be made, then the sender relies on the retransmission and timeout behavior described in Section 2.7." To: "If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section)." In Section 2.5, change: "In composing LLMNR queries, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). Even when LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Therefore setting the IPv6 Hop Limit or IPv4 TTL field to one provides an additional precaution against leakage of LLMNR queries. In composing a response to an LLMNR query, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). This is done so as to prevent the use of LLMNR for denial of service attacks across the Internet. Section 2.4 discusses use of TCP for LLMNR queries and responses. The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder." To: "Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. For UDP queries and responses the Hop Limit field in the IPv6 header, and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Rendezvous." In Section 5.1, change: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on both queries and responses. A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can be used to launch denial of service attacks. For example, were the TTL of an LLMNR Response to be set to a value larger than one (1), an attacker could send a large volume of queries from a spoofed source address, causing an off-link target to be deluged with responses. Utilizing a TTL of one (1) in LLMNR responses ensures that they will not be forwarded off-link. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender." To: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing UDP queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on TCP queries and responses. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. When LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may enable denial of service attacks across the Internet. However, since LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal." An edited version of the specification incorporating these changes is available at: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-30.txt -------------------------------------------------------------------- Issue 64: TTL Revisited Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: March 15, 2004 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00299.html Document: LLMNR-29 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Derek Atkins <derek@ihtfp.com> Date: Tue, 24 Feb 2004 22:14:43 -0500 It sounds like you want two things here, but it also sounds like all of them need to happen in the responder. The attacker could theoretically send packets of any type, with any TTL. So you can't trust anything you receive from the network. To this affect, I think: 1) We want the responder to try to determine that a request came from the local network. The best way to do this is for the responder to check that TTL=255 to make sure. If a TTL is less than 255 then it originiated off-net and can be dropped. 2) We want the responder to make sure response packets don't go off-net. In other words, we want the responder to respond with TTL=1, to make sure it can't smurf. So, to this affect: a) an LLMNR requestor should send requests with TTL=255 b) an LLMNR responder should verify requests have TTL=255 -- if it is not 255 then it should drop the packet. c) an LLMNR responder should respond with TTL=1 d) I dont' think an LLMNR requestor needs to check the response TTL. The only issue this doesn't directly solve is a requester being spoofed by an off-net attacker, but said attacker would need to guess the transaction id of the request in order to send a valid response, which is just as likely in LLMNR as it is in standard DNS, so it can probably be ignored. So, other than this issue, does this solve the issue? [Christian Huitema] Could we agree in any case that the TTL discussion does not apply when we use TCP? As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=255, as per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of address ranges is sufficient to guarantee on-link status. Setting TTL=1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of packet to the local link. On-link attackers can spoof the source address; off-link attackers generally cannot send multicast packets to the destination. Checking the TTL provides no protection against on-link attackers (they can set whatever TTL value is expected). Checking that the source address belongs to an "on-link" prefix prevents the "smurf attack to an off-link target". Setting the TTL=1 in multicast queries prevent the side effects of a rare bug in routers, but this bug may not be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, including for off-link attackers. Checking TTL=255 protects against spoofing by off-link sources. Checking that the source address belongs to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the transaction identifier, which in practice requires an "on-link" attacker; TTL games do not protect against on-link attackers. Setting the TTL to 1 protects against unwitting participation in a DOS-attack to an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some network topologies that support multicast but require packets to go through a router -- some wireless networks and some ad hoc networks can have that property. In practice, checking TTL=255 is only useful in UDP unicast queries, where it provides a slight incremental benefit over a simple check of the source address prefix. Setting the TTL to 1 provides a limited benefit in TCP operation, multicast queries and unicast responses, but contradicts the requirement of TTL=255 for IPv6 link-local addresses. Setting to either value will create operational problems in some future scenarios. The simplest solution is probably to remove all mentions of TTL checks from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an authorized range; 2) The TTL field should be set by the stack to whatever default value is adequate for the interface and the source address (e.g., TTL=255 for IPv6 link-local addresses.) [Mika Liljeberg] > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. [Bernard Aboba] I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. TTL=255 on UDP request & responses only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. [Christian Huitema] Getting rid of unicast UDP queries would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=1 also guarantees an on-link peering. The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 17 Mar 2004 11:06:54 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 17:14:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: LLMNR authorized range Date: Wed, 17 Mar 2004 10:19:12 -0800 Lines: 86 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-308620971; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 19:27:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-13-308620971 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 16, 2004, at 5:17 PM, Bernard Aboba wrote: >> Ok, although I would rather suggest: > >> 1) Nodes should very that the source address of queries belong to an >> authorized range; > > I'm not sure how to define an "authorized range". A host may not know > all > the prefixes present on a given link. The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. -josh --Apple-Mail-13-308620971 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzE4MTkxMlowIwYJKoZIhvcNAQkEMRYEFPiN 3vLihLmc6g/UXYaume3X1TIJMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBABID 5kspYzWbi7lBMu8pVrGyZZ2/vNLa7cP+3xgscFyqNHBTYzii2NsnmUe97xQWPBtDJ5PpW1GhanVz DK9XwDPbaTHBBWKmVA5LeHqVhsqzOsYRkRWPU8YmVAnPJbPMH5OvADep2yuoAQvDfkybYIEryOMR o2jfRj8mIXTpwxqKf9hG3OwGleTrEg8bzvOCgGruFIAxm+BiMx2ayDeIYvqfXVy8XU2zTWQUKB+w pyFhIkyJkTbX324Y2wlMAlGlv1zB4KsTqJH62Rb+PsXifl2sW+gD6RMn/XwqJgrteyarMyWMZ+D+ 6IDc848v8NteNdCjpEUrprCGxZqx8KB5QSkAAAAAAAA= --Apple-Mail-13-308620971-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:20:56 +0200 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 20:29:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Josh, On Wed, 2004-03-17 at 20:19, Joshua Graessley wrote: > The current solution of using TCP with a TTL of 1 makes the "authorized > range" pretty simple to understand. Addresses in the authorized range > are those that the host knows about. This highlights a problem with the > current LLMNR draft. If there are two subnets overlaid on a local > network and the hosts are unaware of the opposite subnet, LLMNR will > make it impossible to resolve names of some devices on the same link > just because they exist on a different subnet. As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:25:29 -0500 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 21:33:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O At 13:19 2004-03-17, Joshua Graessley wrote: >The current solution of using TCP with a TTL of 1 makes the "authorized >range" pretty simple to understand. Addresses in the authorized range are >those that the host knows about. This highlights a problem with the >current LLMNR draft. If there are two subnets overlaid on a local network >and the hosts are unaware of the opposite subnet, LLMNR will make it >impossible to resolve names of some devices on the same link just because >they exist on a different subnet. Good point, so what TLL <= N works for you ? N = 5 sounds good to me. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <ogud@ogud.com> X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 22:29:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> of "Wed, 17 Mar 2004 15:25:29 EST." <6.0.3.0.2.20040317152010.02b37e88@localhost> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... If there are two subnets overlaid on a local network and the > > hosts are unaware of the opposite subnet, LLMNR will make it > > impossible to resolve names of some devices on the same link just > > because they exist on a different subnet. that sounds like the right thing, since if they're on different subnets then they will not be able to communicate even though those subnets are in the same broadcast domain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 14:13:00 -0800 Lines: 95 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-322649650; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 23:29:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040317212210.05A5514C51@sa.vix.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-18-322649650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed My friends has a problem with his cable modem provider. He has paid extra to get extra addresses. The addresses are handed out using DHCP. The addresses are not always on the same subnet. I see no reason why LLMNR shouldn't work for him. I may soon have a similar situation at home. I've got sDSL for a small server I run. I'm thinking about getting a cable modem connection so I can get stuff quicker. When I have that setup at home, I'll have two or more subnets running on the local network. All of the devices can communicate using their IPv4 addresses (albeit inefficiently). LLMNR should work in this situation but due to the TTL stuff it may not work. I think there is a simple solution for IPv6. Always use the IPv6 link-local addresses. The only solution that would work 100% of the time for IPv4 would be to use the same link-local multicast to send the response. -josh On Mar 17, 2004, at 1:22 PM, Paul Vixie wrote: >>> ... If there are two subnets overlaid on a local network and the >>> hosts are unaware of the opposite subnet, LLMNR will make it >>> impossible to resolve names of some devices on the same link just >>> because they exist on a different subnet. > > that sounds like the right thing, since if they're on different subnets > then they will not be able to communicate even though those subnets are > in the same broadcast domain. --Apple-Mail-18-322649650 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzIyMTMwMVowIwYJKoZIhvcNAQkEMRYEFGC0 xVKoZ+1an/5iMlJX/1xQw6DpMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAHdE tCTuzek3bgT7uCX+FEcQUYwwsv0Dnpcc8LKbMC7ZUwR6N7Am77lCNPIvw/wZfwm+87pxoori9Cl/ JSVyvPiUgiB/yfipwfUJPdoQIbrD8IbcsleoWSP95c+SAX4Odw1utoo9zbg4ig4sO/xtwQtV2JaA xNfDAhhiuk4+5+GtXf5/fJKEZd+gYa831X6fPBDr+rbVEZYnKO4I89iVrGW4XQ66d61LJ26XIs2/ NNsXHQbq/u9+8p0XUNTauhGPjJH9XVDk9mDt0o23xmbwfPzavUtoDBnvSEt6yASMfaZxUMTPdCD/ F30cuturShwPFbcGw4wSZ0fZmIQOFcG0GRUAAAAAAAA= --Apple-Mail-18-322649650-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 23:23:34 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <jgraessley@apple.com> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 00:31:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Joshua Graessley <jgraessley@apple.com> of "Wed, 17 Mar 2004 14:13:00 PST." <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > My friends has a problem with his cable modem provider. He has paid extra > to get extra addresses. The addresses are handed out using DHCP. The > addresses are not always on the same subnet. I see no reason why LLMNR > shouldn't work for him. i guess if your router is sitting on both subnets and you're willing to go through a router to talk to other hosts in the same broadcast domain, you're right there's no reason LLMNR wouldn't work. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 13:56:57 -0600 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403170606040.10517@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403170606040.10517@internaut.com> To: Bernard Aboba <aboba@internaut.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 8:06 AM, Bernard Aboba wrote: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header MAY be set to any value. However, > it is RECOMMENDED that the value 255 be used for compatibility with > Apple Rendezvous." Why not change it to: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header SHOULD be set to 255. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 17:02:06 -0600 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. It shouldn't work for him because his network is misconfigured. It's not the job of the IETF to arrange for it to be the case that any random configuration error still results in desired behavior, for any arbitrary value of "desired." If you want this to work, you need to go check out the IPv4ll protocol and make sure that it does the right thing in this case. And your friend needs to use IPv4ll. Rendezvous works correctly in this case, doesn't it? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:21:31 -0600 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:07:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 12:19 PM, Joshua Graessley wrote: > If there are two subnets overlaid on a local network and the hosts are > unaware of the opposite subnet, LLMNR will make it impossible to > resolve names of some devices on the same link just because they exist > on a different subnet. I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 20:02:00 -0800 Lines: 26 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 05:11:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution to LLMNR Issue 64: TTL Revisited thread-index: AcQMfLkklVWmcimJRgOk4T8n5ZiKvQAIL36g To: "Ted Lemon" <mellon@fugue.com>, "Bernard Aboba" <aboba@internaut.com> X-OriginalArrivalTime: 18 Mar 2004 04:02:14.0194 (UTC) FILETIME=[CBCEC120:01C40C9D] Precedence: bulk Status: O > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header MAY be set to any value. However, > > it is RECOMMENDED that the value 255 be used for compatibility with > > Apple Rendezvous." >=20 > Why not change it to: >=20 > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header SHOULD be set to 255. Because this is a trade-off. The proper design is to use a TTL=3D1. The only reason to use the 255 value, which has a larger exposure to DOS exploitation, is compatibility with rendezvous. The text that Bernard proposes is a fine compromise. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 23:18:46 -0600 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 06:24:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> To: "Christian Huitema" <huitema@windows.microsoft.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 17, 2004, at 10:02 PM, Christian Huitema wrote: > Because this is a trade-off. The proper design is to use a TTL=1. The > only reason to use the 255 value, which has a larger exposure to DOS > exploitation, is compatibility with rendezvous. The text that Bernard > proposes is a fine compromise. The text I proposed and the text it replaces have exactly the same effect. The difference is that one of them places blame (I think inappropriately, although I think also unintentionally), and the other does not. I can't think of any technical reason to prefer the old text over the new. Can you state such a reason? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: EDNS0 (RFC-2671) questions Date: Thu, 18 Mar 2004 15:25:36 +0200 Lines: 31 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 14:34:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O 1) assuming I send query, which includes the OPT RR (to increase the packet length). If I receive a reply with TC=1 (truncation) and don't find OPT RR in the reply, then I assume the RCODE is the non-extended one? [Just verifying, that I can trust all implementations do it right: if they build an answer and run out of space before inserting the OPT RR, they also fall back to old plain RCODE?] This extended-RCODE makes it somewhat akward, to find RCODE, you have to traverse through all data in Question, Answer and Authority sections, then look OPT RR from Additional section. Doable, but still icky, just to get few extra bits of RCODE that are rarely used. Would have been easier if there was single RCODE value in fixed header to indicate that extended RCODE is in use. 2) Can UDP payload size be < 512? I didn't see any mention of it. Maybe I missed it. I think RFC should state that attempting to use less than 512 is not allowed (and will be ignored). [If < 512 is accepted, there might be some DOS potential in it also] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: correction to RRSIG presentation format in DNSSECbis -records draft Date: Thu, 18 Mar 2004 10:53:08 -0500 Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:04:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-NIST-MailScanner-Information: Please contact the ISP for more information X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Status: O Recently pointed out by Miek and Erik Rozendaal in the Resource Records draft of the DNSSECbis spec is the discrepancy between the ASCII presentation formats of the RRSIG and NSEC RRs. In the text, the RRSIG Type Covered field is supposed to be represented as a RR type mnemonic or an unsigned integer. This goes against the convention in RFC 3597 which states that unknown RR types should be represented as "TYPE<number>" where <number> is the typecode. The text for the representation of the NSEC RR type bitmap already states this (as it was written after RFC3597). The text for the RRSIG representation was changed to be consistent with RFC 3597 and the NSEC text. Section 3.2 paragraph 2 will now read: The Type Covered field is represented as a RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597] (section 5) MUST be used. Thanks, Scott DNSSECbis editors -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 18:14:36 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:19:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 03:21:31PM -0600, Ted Lemon wrote: > A host that you > can't talk to without going through a router isn't "local." Why not? Which part of the Internet-Draft does this violate? >From ...-29.txt: For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. The network overlay scenario is clearly "on link" according to the above definition. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 16:54:57 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 05:02:06PM -0600, Ted Lemon wrote: > On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > >My friends has a problem with his cable modem provider. He has paid > >extra to get extra addresses. The addresses are handed out using DHCP. > >The addresses are not always on the same subnet. I see no reason why > >LLMNR shouldn't work for him. > > It shouldn't work for him because his network is misconfigured. It's > not the job of the IETF to arrange for it to be the case that any > random configuration error still results in desired behavior, for any > arbitrary value of "desired." Exactly how is overlaying two IP network ranges onto one L2 infrastructure misconfigured? -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 17:32:58 +0200 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> Content-Disposition: inline In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. This hits at the crux of what "Link-Local" means in the acronym LLMNR. The above scenario (if indeed regarded as acceptable practice) will be regarded by most people as "local". During the original drafting of the document, did the authors have a specific definition of "link-local" in mind? As I recall, the original spec came out of Stuart Cheshire's work on replacing AppleTalk's naming service; this became Rendezvous and branched off into LLMNR. If this is the case, then the "local" definition was pretty broad, and would probably cover the overlaid network scenario. Also, in the above scenario, forcing TTL=1 will cause the router to drop the packet before it is forwarded back onto the "other" part of the local network. Making TTL=5 (or any other number greater than 1 but less than the worst-case diameter of the Internet) seems to be an ugly solution, and also gets away from the "link-local" part of LLMNR -- why not just call it "restricted scope MNR" then? Or why not just drop the TTL restriction altogether and just allow general MNR? I repeat -- TTL checks are a kludge, and do not capture the idea of "local" networks. There are local networks for which TTL must be greater than 1 to capture locality (eg. multiple IP ranges overlaid on the same L2 medium as above), and there are distinctly non-local networks (eg. LANs bridged through long thin pipes) for which any multicast can cause great harm -- even with TTL=1. In a message to this forum from Bernard Aboba in October 2003: As a result, the ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local specification so as to "do no harm". The current specification no longer mandates a test for a TTL value, and prefers a routable address when available. It is perhaps not as "useful" as the early versions -- but it also does not break the basic interoperability of TCP/IP. I've probably taken the above slightly out of context, but perhaps we should go back to the original multicast slant of LLMNR and drop UDP unicast, as suggested by Bernard in another message. For multicast, the TTL is irrelevant unless we are trying to compensate for potential router bugs. On the other hand, for TCP queries, the TTL should not be restricted. Then, interoperability with an existing protocol seems to be a worthwhile goal, as long as it is not bought at a terrible price. (Why was UDP unicast functionality introduced, anyway?) At the end of the day, I just want to see some finality with LLMNR, whatever it is! Either it is going to be useless and Rendezvous will win out in the marketplace, or it will be useful and over time it may grow to take over from Rendezvous. But right now LLMNR is by definition useless, since it hasn't been finalised. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040318153258.GF9994@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jgraessley@apple.com (Joshua Graessley), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:57:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net (Andras Salamon) In-Reply-To: <20040318153258.GF9994@dns.net> from "Andras Salamon" at Mar 18, 2004 05:32:58 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > > My friends has a problem with his cable modem provider. He has paid > > extra to get extra addresses. The addresses are handed out using DHCP. > > The addresses are not always on the same subnet. I see no reason why > > LLMNR shouldn't work for him. > > This hits at the crux of what "Link-Local" means in the acronym LLMNR. link-local is an unfortunate terminological choice. it might be useful to consider "single broadcast domain", which pretty much eliminates the overlay scenario. > As I recall, the original spec came out of Stuart Cheshire's > work on replacing AppleTalk's naming service; this became Rendezvous and > branched off into LLMNR. If this is the case, then the "local" definition > was pretty broad, and would probably cover the overlaid network scenario. Hum... there were a series of efforts that hit confluence and then diverged... the TBDS research, what became Rendezvous and what might become LLMNR... all are varients that use DNS or DNSlike stuff. > -- Andras Salamon andras@dns.net --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:36:42 -0600 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> <20040318145457.GE9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:51:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318145457.GE9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 8:54 AM, Andras Salamon wrote: > Exactly how is overlaying two IP network ranges onto one L2 > infrastructure > misconfigured? It is misconfigured in the sense that it does not do what the customer expects. The customer expects that the two devices he or she has connected to the network will be able to communicate with each other without relying on the service provider. This is unfortunately not true - they will not be able to communicate other than over the service provider's link, unless they implement Rendezvous (I do not believe that the current IPv4ll draft, for example, will allow them to communicate independent of the ISP). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:47:39 -0600 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <20040318153258.GF9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:59:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318153258.GF9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 9:32 AM, Andras Salamon wrote: > During the original drafting of > the document, did the authors have a specific definition of > "link-local" > in mind? Yes. However, the current document bears only a passing resemblance to what the authors had in mind. The original intention was that the two devices we're discussing would both have IPv4ll addresses, and that MDNS, as it was then called, would uses these addresses, not the globally-routable addresses. Both the IPv4ll spec and the MDNS spec have been changed dramatically since then. IPv4ll no longer works the way it did, and LLMNR doesn't either. At this point, I have to say that it is my sincere hope that neither IPv4ll nor LLMNR make it to standard as they are currently constituted. But if they do make it to standard, my next hope is that they do not fail to interoperate with Rendezvous. If they do not interoperate reliably with Rendezvous, then the only purpose they will serve is to make sure that no reliable mechanism exists whereby two arbitrary hosts can automatically communicate with each other on the local link in the event that the DHCP server is not configured to enable this communication - by having two incompatible mechanisms that do roughly the same thing, we eliminate the possibility of dependable interoperability. I sympathize deeply with your motivation to make LLMNR work correctly in the scenario we're talking about in the absence of any competing protocol, but that is not the domain in which we are operating. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 22:41:55 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 07:41:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O >LLMNR will make it impossible to resolve names of some devices on the >same link just because they exist on a different subnet. No. All but PTR RR queries will be sent to the link-scope multicast address, so they will be resolved without a problem. >As far as I can see, that is only a problem with PTR queries, which >often fail anyway. Yes. Only PTR queries are sent via TCP. Given that other queries will work and applications need to be prepared for PTR RR queries to fail anyway, you'll only see somewhat degraded performance. On the other hand, there is a performance improvement for other cases, since TTL=1 causes unresolvable PTR RR queries to fail quickly, rather than having to wait for LLMNR_TIMEOUT. So this is really just an optimization issue and I'm not clear that optimizing for an uncommon case (e.g. TTL=5) makes sense. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Fri, 19 Mar 2004 10:16:42 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> <20040318161436.GA10775@dns.net> <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 09:48:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Thu, Mar 18, 2004 at 12:34:32PM -0600, Ted Lemon wrote: > On Mar 18, 2004, at 10:14 AM, Andras Salamon wrote: > >The network overlay scenario is clearly "on link" according to the > >above definition. > > Sure, and you could argue that the definition you've quoted is correct > and that mine is wrong. I'm not especially interested in arguing about whose definition is right or wrong. However, the current LLMNR Internet-Draft defines its scope to include the scenario of address ranges overlaid onto the same L2 infrastructure (maybe I'm wrong here, but no-one has yet objected). Hence, either we need to change the wording of the I-D, or we need to accept the wording and its consequences. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 03:47:00 -0800 (PST) Lines: 47 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 12:51:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [Joshua Graessley] said: The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. [Ted Lemon] replied: I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? [Mika Liljeberg] said: As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? [Bernard Aboba] In practice, I don't believe this issue will arise. Section 1 says: "The assumption is that if a network has a gateway, then the network is able to provide DNS server configuration." Therefore in the "overlapping subnet" case LLMNR assumes that the host has DNS configuration. From early on, LLMNR has assumed that the gateway supports the resolution of the names of local hosts using DHCPv4 and dynamic DNS update. However, this assumption cannot be made for IPv6 at this point. So if we are talking about multiple subnets on a link in IPv4, then a conventional DNS query will be sent first, and local names can be resolved by the gateway. If we are talking about IPV6, then Router Advertisement enables the host to become aware of the multiple subnets, so that TCP-based queries can be sent on the local link, rather than forwarded by a router. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 14:23:14 +0200 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 13:31:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: aboba@internaut.com In-reply-to: <Pine.LNX.4.56.0403200335280.8666@internaut.com> (message from Bernard Aboba on Sat, 20 Mar 2004 03:47:00 -0800 (PST)) Precedence: bulk Status: O > From: Bernard Aboba <aboba@internaut.com> > > ... If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, Terminology confusion? What subnets are in RA? RA can have multiple prefixes to be used on the link (if L=1), but they are not subnets. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR authorized range Date: Sat, 20 Mar 2004 10:48:18 -0800 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 19:58:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR authorized range thread-index: AcQOdygluZmu2G4uTO+NBskGu1hyLwANJJKA To: "Markku Savela" <msa@burp.tkv.asdf.org>, <aboba@internaut.com> X-OriginalArrivalTime: 20 Mar 2004 18:48:03.0805 (UTC) FILETIME=[E04548D0:01C40EAB] Precedence: bulk Status: O > > From: Bernard Aboba <aboba@internaut.com> > > > > ... If we are > > talking about IPV6, then Router Advertisement enables > > the host to become aware of the multiple subnets, >=20 > Terminology confusion? What subnets are in RA? RA can have multiple > prefixes to be used on the link (if L=3D1), but they are not subnets. Uh? There is no official definition of subnet, but the generally agreed definition is "the set of addresses that shares a specified prefix". -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 12:12:48 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: msa@burp.tkv.asdf.org (Markku Savela), aboba@internaut.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 21:21:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: huitema@windows.microsoft.com (Christian Huitema) In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> from "Christian Huitema" at Mar 20, 2004 10:48:18 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > > From: Bernard Aboba <aboba@internaut.com> > > > > > > ... If we are > > > talking about IPV6, then Router Advertisement enables > > > the host to become aware of the multiple subnets, > > > > Terminology confusion? What subnets are in RA? RA can have multiple > > prefixes to be used on the link (if L=1), but they are not subnets. > > Uh? There is no official definition of subnet, but the generally agreed > definition is "the set of addresses that shares a specified prefix". That is not generally agreed on in most circles I run in. The working definition here is: "a single broadcast domain" e.g. more layer two'ish. > -- Christian Huitema --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 16:18:45 -0500 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 22:26:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200403202012.i2KKCn418994@karoshi.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > > > Uh? There is no official definition of subnet, but the generally agreed > > definition is "the set of addresses that shares a specified prefix". > > That is not generally agreed on in most circles I run in. > The working definition here is: "a single broadcast domain" > e.g. more layer two'ish. I think you're both right, but Christian's righter. IP "subnets" (the term's a bit dated given CIDR, but comes from the old subnetting extension to the original class A/B/C extension to the original original IPv4 address architecture's static 255.0.0.0 network mask) are an IP (layer 3) concept referring to a set of IP addresses sharing a particular prefix. The fact that IP subnets usually (but not always) map 1-to-1 with link-layer broadcast domains has led to sloppy terminology even in the IP world, and there are certainly other uses of the term "subnet" which mean something entirely different (eg, at one point I think the entire ARPANET was referred to as a "subnet" of the ARPANET/MILNET system, and some link layer specs do use the term "subnet" to mean link layer broadcast domain, as Bill suggests). So for precision you have to state the context (including layer) in which you're using the term, but since this is the IETF, and around here we mostly talk about IP, any use of the term "subnet" in IETF documents should generally be presumed to be talking about IP addresses with a shared prefix unless stated or proven otherwise. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Sun, 21 Mar 2004 08:07:45 +0900 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20040320211845.29FEB18F8@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Mar 21 00:15:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Rob Austein <sra@isc.org> In-Reply-To: <20040320211845.29FEB18F8@thrintun.hactrn.net> Precedence: bulk Status: O Rob Austein; > At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > >>>Uh? There is no official definition of subnet, but the generally agreed >>>definition is "the set of addresses that shares a specified prefix". >> >> That is not generally agreed on in most circles I run in. >> The working definition here is: "a single broadcast domain" >> e.g. more layer two'ish. > > > I think you're both right, but Christian's righter. No, Christian is not. According to the CATENET model of the Internet, the Internet is composed from local networks (of RFC791). local network = subnet = link = broadcast domain The proper way to assign a local network multiple addresses is to let all the hosts (of RFC791) in the local network share multiple prefixes of equal length using identiral host parts (intra-subnet) addresses, which still means local network = subnet = link = broadcast domain Confusions caused by any other configuration are the problems of the configuration. The configuration is responsible to make the model visible from other protocols local network = subnet = link = broadcast domain > any use of the term "subnet" in IETF > documents should generally be presumed to be talking about IP > addresses with a shared prefix unless stated or proven otherwise. It's "shared prefixes", not "a shared prefix". Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Mon, 22 Mar 2004 10:40:10 -0800 Lines: 104 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-741880068; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 22 19:53:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403200335280.8666@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-32-741880068 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Based on prior discussions and reading the draft, I was under the impression that if a DNS query fails (response with answercount of zero or a response with an error of NXDOMAIN), the query would be performed using LLMNR. It seems very plausible that someone might setup their computers to respond to LLMNR queries for names such as josh.llmnr or josh.thisdomainmustfailtoresolve. This would allow someone to locally refer to their computers by name no matter what the local addresses are and whether or not a DNS server is available. This would also be perfectly valid according to the current LLMNR spec. In this valid scenario, if there are multiple subnets on the same local network, LLMNR will fail. -josh On Mar 20, 2004, at 3:47 AM, Bernard Aboba wrote: > [Bernard Aboba] In practice, I don't believe this issue will arise. > Section 1 says: > > "The assumption is that if a network has a gateway, > then the network is able to provide DNS server configuration." > > Therefore in the "overlapping subnet" case LLMNR > assumes that the host has DNS configuration. From early > on, LLMNR has assumed that the gateway supports the > resolution of the names of local hosts using DHCPv4 and > dynamic DNS update. However, this assumption cannot be > made for IPv6 at this point. > > So if we are talking about multiple subnets on a link in > IPv4, then a conventional DNS query will be sent first, > and local names can be resolved by the gateway. If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, > so that TCP-based queries can be sent on the local > link, rather than forwarded by a router. --Apple-Mail-32-741880068 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMyMjE4NDAxMVowIwYJKoZIhvcNAQkEMRYEFDl8 9/kmuygyZVn0ISG4dH3oZKYDMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAKeo F6CpAFWpAvOdpM0OBoVrJenuTybGod5v/4E0F44x70U/JOeZApkZAK1dREIeT1M42J4b9iWk52CX 4mb++kOUH65xD77FH6xWNihVCHOIQF8W8+OHRO7yJSVuD6xYjahCpUVyF9KupoIzvGV1fBwz3Jml DtzmKAISHUTzXsZrLvKtvpUKcsouw3UMuiiE8GVWBsoInmA3w66Wd8EMSFmyJpVlry9lG/9VNemZ 8/+sQrWmxHBlfeweschkXXzXKqnMaliaRurH330kVS3V1lCmD340JsL8xbcpC19nGgQWPxGJlbAM ZYJSAmxRXO/uIlf95HB5A1FPEE16WGQ3Z5QAAAAAAAA= --Apple-Mail-32-741880068-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Tue, 23 Mar 2004 15:14:16 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 23 07:20:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O Josh; > In this valid > scenario, if there are multiple subnets on the same local network, LLMNR > will fail. With IPv6, there is no reason not to share all the prefixes of a link by all the hosts on the link, which means there is only a single subnet. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Advance: draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 24 Mar 2004 09:16:56 +0100 Organization: RIPE NCC Lines: 98 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, jakob@schlyter.se X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 09:28:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Thomas Narten" <narten@us.ibm.com>, "Margaret Wasserman" <margaret@thingmagic.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.015749 / 0.0 / 0.0 / disabled X-RIPE-Signature: d65dbcaea04193b902f993fc8813be54 Precedence: bulk Status: O Thomas, Margaret, Hereby the advancement questionnaire (www.mip4.org/2004/draft-writeup-items.html) for "DNSSEC NSEC RDATA Format" draft-ietf-dnsext-nsec-rdata-05.txt. The questionaire serves as a request to advance the document to proposed standard. 1. Chairs review. The chair responsible for tracking this document has read it and considers it ready for IESG review. 2. Working Group member review. The proposed format has been discussed on the list as well as during the IETF 58 meeting. The content of the comments received during last call indicate that a number of people have closely reviewed the document. 3. Is more review from a particular perspective needed. In the chairs opinion not. 4. Specific Issues and concerns the AD/IESG should be aware of. The document _only_ changes a format. The security section therefore does not go into the details of NSEC security. Note however that the text describing this format will be directly 'cut-n-pasted' into the dnssec-bis document set. The dnssec-bis intro document set covers the security considerations, e.g. NSEC cain walking, in more detail. 5. How solid is the WG consensus. The format was chosen during IETF58. The document itself got explicit consensus from only a few individuals. On the other hand this is has not been contentious issue. 6. Thread for appeal. None. 7. _all_ ID nits addressed. All are addressed. 8. References There is a normative reference to an I-D that has been advanced. Also not that this document will be merged and obsoleted by the dnssec-bis document set. 9. Writeup. Technical Summary To prevent the introduction of an extension mechanism once DNSSEC has a deployed base this document redefines the wire format of the "Type Bit Map" field in the NSEC resource record RDATA format to cover the full RR type space. The new format of the type bitmap is easy to implement, can cover the full range of type codes, is economical in the common case and has a maximum size of approximately 8.5 kilobytes. Efficient searching of the type bitmap for presence of a type had a lower priority. Working Group Summary The format was chosen from 6 different candidates that were presented to the working group. There is consensus on the chosen representation. Protocol Quality There are 3 independent implementations of this format. 1 implementation provides both a server and a client, 1 implementation only a server and 1 implementation only a client. These interoperate. -- Olaf Kolkman Olafur Gudmundsson -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis Q-30: DNAME awareness Date: Wed, 24 Mar 2004 14:08:52 -0500 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 20:23:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Q-30: Should the DNSSECbis specs require DNAME-awareness? Approximate text to be added if the WG agrees: [To be inserted somewhere in Section 3.x of -protocol] A security-aware name server which synthesizes CNAME RRs from DNAME RRs as described in RFC 2672 SHOULD NOT generate signatures for the synthesized CNAMEs. [To be inserted somewhere in Section 4.x of -protocol] A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs which could have been synthesized from the DNAME RR as described in RFC-2672, at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so. Background: RFC-2672 recommends that name servers synthesize CNAME RRs based on DNAME RRs, for backwards compatability with DNAME-oblivious resolvers. RFC-2672 goes on to suggest that DNSSEC-capable name servers might want to keep the zone key online in order to sign these synthesized CNAME RRs, for the benefit of security-aware DNAME-oblivious resolvers. This has obvious security issues, and also adds some complexity. In fairness, note that when RFC-2672 came out, DNSSEC-classic (RFC 2535) had already shipped, so one could argue that this was the least bad backwards compatability hack available to the author of RFC-2672. So the question here is whether there is any need for DNSSECbis to support security-aware DNAME-oblivious implementations. Specifically, can we eliminate the case of a security-aware DNAME-oblivious resolver expecting name servers to synthesize signed CNAME RRs from signed DNAME RRs? DNSSECbis question Q-27 already covered part of this space, by allowing a security-aware recursive name server to set the AD bit for responses containing synthesized CNAME RRs. Q-27 did not, however address whether name servers should attempt to sign synthesized CNAME records or whether resolvers should expect to receive signatures for synthesized CNAME records. Whether a validating resolver choses to retain synthesized CNAMEs or not appears to be an implementation and local policy choice, since CNAME synthesis itself is only a SHOULD in RFC-2672 and thus not something on which any DNS-using software can depend. Deadline and default: Per instructions from the WG chairs, this question will time out on 4 April 2003 with a default action to accept these changes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Thu, 25 Mar 2004 09:57:08 +0100 (CET) Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> <6.0.3.0.2.20040312111536.02678528@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Mar 25 10:11:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040312111536.02678528@localhost> Precedence: bulk Status: O interested parties should visit http://www.rfc.se/interop3597/ and join the mailing-list at http://www.rfc.se/mailman/listinfo/interop3597. before testing starts, I need help with filling the test zone (published as interop3597.rfc.se) with useful, and wierd, data. please send suggestions me or to the list above. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSSECbis Q-30: DNAME awareness Date: Fri, 26 Mar 2004 11:33:53 -0500 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> <20040324190852.67C5618C9@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 17:51:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040324190852.67C5618C9@thrintun.hactrn.net> To: Rob Austein <sra@isc.org> Precedence: bulk Status: O I like what these words say. At 14:08 -0500 3/24/04, Rob Austein wrote: >Q-30: Should the DNSSECbis specs require DNAME-awareness? > >Approximate text to be added if the WG agrees: > > [To be inserted somewhere in Section 3.x of -protocol] > > A security-aware name server which synthesizes CNAME RRs from DNAME > RRs as described in RFC 2672 SHOULD NOT generate signatures for the > synthesized CNAMEs. > > [To be inserted somewhere in Section 4.x of -protocol] > > A validating security-aware resolver MUST treat the signature of a > valid signed DNAME RR as also covering unsigned CNAME RRs which > could have been synthesized from the DNAME RR as described in > RFC-2672, at least to the extent of not rejecting a response > message solely because it contains such CNAME RRs. The resolver > MAY retain such CNAME RRs in its cache or in the answers it hands > back, but is not required to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-30.txt Date: Fri, 26 Mar 2004 15:49:27 -0500 Lines: 96 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 22:06:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-30.txt Pages : 26 Date : 2004-3-26 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-30.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-30.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-30.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>

From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Olaf Kolkman Subject: DNSEXT list policy Date: Mon, 1 Mar 2004 08:35:01 +0100 Lines: 190 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 01 08:48:38 2004 Return-path: To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.500000 / 0.0 / 0.0 X-RIPE-Signature: 32d842149ec8e2859401da1280faf172 Precedence: bulk Status: RO - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at . Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format ISSUE: Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 02 Mar 2004 00:24:45 -0500 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> <20040226144216.GA7166@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba <aboba@internaut.com>, huitema@microsoft.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 02 06:35:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040226144216.GA7166@dns.net> (Andras Salamon's message of "Thu, 26 Feb 2004 16:42:16 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: >> If there is to be a "compromise" I believe that it should be >> to set TTL=255 on responses and (optionally) check on the sender, while >> *always* setting TTL=1 on queries. > > Sounds reasonable to me. But now you're open to smurf attacks, where I send a LLMNR request to a responder, setting YOUR ip address as the source, and setting the TTL to make sure the packet arrives "properly". Or do we just not care about this? I can make sure you send the packet, and with TTL=255 the response will always make it back to the "sender" (which is YOUR ip address in this case). So, what is the threat(s) we're trying to solve? In particular, what threat does TTL=255 on responses actually solve? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: draft-ietf-dnsext-nsec-rdata-04 Date: Wed, 3 Mar 2004 20:08:54 +0900 (KST) Lines: 15 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 03 12:20:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Precedence: bulk Status: O I've just submitted an updated version of this draft to the drafts editor. For those who want to read it now, you can find a copy (and a diff against -03) at the following location: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.txt http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.wdiff jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: comment on NSEC RDATA format draft -04 Date: Thu, 4 Mar 2004 08:37:31 -0500 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 04 15:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The text states that there are no special TTL requirements for the NSEC RR. However, in the new DNSSECbis specs, we have the following suggestion for TTL values (records draft-07): The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308]. Minor difference since the above is a suggestion, and there are no real special requirements for the TTL. I think the NSEC data draft should include the above for consistancy. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:03:22 +0100 Lines: 143 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 15:15:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Hello, being new to rfc2782, I have a number of questions. I would be grateful for any enlightenment anyone could provide. Regards Barry Desborough Barry.Desborough@wanadoo.fr SRV RR FORMAT >From rfc2782 page 2 "The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target" But rfc1035 page 29 describes the generic RR header as being NAME TYPE CLASS TTL RDLENGTH RDATA According to 1035, and assuming that 'SRV' refers to TYPE, (not specified in 2782), it seems that the SRV RR should be _Service._Proto.Name SRV Class TTL RDLENGTH Priority Weight Port Target where _Service._Proto.Name corresponds to NAME SRV is the TYPE (33) Class, TTL and RDLENGTH are 1035 standard and Priority Weight, Port and Target correspond to RDATA Q1) Which rfc is correct? Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? Could not the contents of Target have been be reported in the NAME field and the Target field be dispensed with? TARGET SELECTION >From page 3 of rfc2782 " ............................................ The following algorithm SHOULD be used to order the SRV RRs of the same priority: To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority." Let's say we have only two targets of the same priority, with weights 1 and 2. If the weights are ordered 1 then 2, then we have Wt Sum ----------- 1 1 2 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 1 1 2 2 2nd contact 2 2 1 1 This gives each target equal probability of being contacted first. If the weights are ordered 2 then 1, then we have Wt Sum ----------- 2 2 1 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 2 2 2 1 2nd contact 1 1 1 2 The weight 2 target is contacted first with a probability of 3/4. Overall the probabilities for 1st contact are 3/8 and 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ _order_is_randomly_chosen_, but this is not specified. According to my reckoning, consistent, correct results are obtained if the random number is chosen to be between _ONE_ and the sum computed. Q3) Does anyone agree or disagree with this? If what is meant by 1st contact is the 1st successful attempt to find a Target, from whereupon this target's service is always used until it's TTL expiry or failure, then load sharing is only effected by different clients choosing different 1st contacts. On the other hand, if it means that a client which is a frequent, heavy user of a service client works down a sequence of targets to select which one provides the service next, all targets are selected with equal frequency. It seems to me that there is an assumption here that target contact selection from any particular client is very infrequent, and that load sharing occurs by virtue of different clients making 1st contact to different targets. In a system who's application makes frequent heavy of a service, service selection should be purely probabilistic based on the relative weights of the highest priority records available. Q4) Can anyone clarify this matter? Q5) Does anyone have any DNS SRV sniffer trace they could send directly to me to throw more light on the message format? (Please mail the group to say you have responded to this one, to save me being flooded!) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: bill <bmanning@karoshi.com> Subject: Re: comment on NSEC RDATA format draft -04 Date: Sat, 6 Mar 2004 06:57:33 -0800 (PST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:03:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: scottr@nist.gov (Scott Rose) In-Reply-To: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> from "Scott Rose" at Mar 04, 2004 08:37:31 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The > text states that there are no special TTL requirements for the NSEC RR. > However, in the new DNSSECbis specs, we have the following suggestion for > TTL values (records draft-07): > > The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL > field. This is in the spirit of negative caching [RFC2308]. > > Minor difference since the above is a suggestion, and there are no real > special requirements for the TTL. I think the NSEC data draft should > include the above for consistancy. > > Scott ack. this is a reasonable thing to do. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 10:31:55 -0500 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:41:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Barry Desborough <Barry.Desborough@wanadoo.fr> In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > From page 3 of rfc2782 > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive) > Random number case 0 1 2 3 > 1st contact 1 1 2 2 > 2nd contact 2 2 1 1 You appear to be computing a random integer, rather than a random real number, as was intended. If you choose a random real number, you'll get the appropriate distribution (a server with weight 2 is chosen twice as often with a server of weight 1). I would have much preferred a statement which used random integers (which is something you can actually do on a computer), but the working group was having a little trouble coming up with an algorithm statement that actually worked, so we decided to go with one which we strongly believed was correct even if it wasn't very clear and which didn't translate easily into code. It's particularly galling to me that we didn't even state explicitly what kind of number is to be chosen (integer, rational, computable, real, complex...), and then we threw in this parenthetical note "(inclusive)" which actually has no effect on the outcome if real numbers are being chosen. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. Neither of these choices seems appropriate. The TTL only applies to the DNS data itself, not the processing of it, so it would be wrong to choose a server once and then stick with it until the TTL expires. It would also be wrong to walk the list of choices when making multiple successful contacts; the idea is to walk the list when making a single contact until you are successful, then throw the list away. The next time you make a contact, you should start all over again and choose a new contact order randomly according to the weights. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 19:08:47 +0200 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:19:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 03:03:22PM +0100, Barry Desborough wrote: > Here is the format of the SRV RR, whose DNS type code is 33: > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > NAME TYPE CLASS TTL RDLENGTH RDATA RFC1035 deals with the on-the-wire encoding, while the SRV text above seems to be related to the usual BIND-style zone file format. The examples in RFC 2782 bear this out. However, re-reading RFC 2782 and RFC 2052, I could not determine a definitive on-the-wire encoding of SRV records -- this seems to be undefined. Presumably, implementors have just looked at how BIND returns SRV records and gone with that. > According to 1035, and assuming that 'SRV' refers to TYPE, > (not specified in 2782), The section "Usage rules" mentions QTYPE=SRV, and there is further text the SRV RR, whose DNS type code is 33 and The IANA has assigned RR type value 33 to the SRV RR which seems to tie SRV to TYPE, although perhaps not very directly. > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? I tried to find an online deployment of SRV records to feed to tcpdump, but the closest I came was an SOA record for _tcp.microsoft.com (one of the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no appear to have _tcp subdomains. Does anyone actually have a deployment of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? I also tried to find the IANA assignments for the Service tags, as referred to in RFC 2782, and couldn't locate any. Have any actually been standardized? If so, a pointer would be appreciated! -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 12:29:42 -0500 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:40:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? We appear to have: _sip._tcp.mit.edu _sip._udp.mit.edu _sip._tcp.sipxchange.mit.edu _sip._udp.sipxchange.mit.edu _kerberos._udp.athena.mit.edu _kerberos-master._udp.athena.mit.edu _kerberos-adm._tcp.athena.mit.edu -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:37:28 +0000 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <Barry.Desborough@wanadoo.fr> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:46:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from "Barry Desborough" <Barry.Desborough@wanadoo.fr> of "Sat, 06 Mar 2004 15:03:22 +0100." <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > From rfc2782 page 2 > > "The format of the SRV RR > > Here is the format of the SRV RR, whose DNS type code is 33: > > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > > NAME TYPE CLASS TTL RDLENGTH RDATA > ... > Q1) Which rfc is correct? both. rdlength is a protocol element describing rdata. the <rdlength,rdata> tuple is used to represent the rr data, which in this case is itself a tuple: <Priority,Weight,Port,Target>. in "dns master file" format as entered into zone files and as displayed by utilities such as "dig", rdlength is used to encode and decode the rr data but is never specified or displayed directly. > Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? > Could not the contents of Target have been be reported in the NAME field > and the Target field be dispensed with? because the names of the servers capable of responding to requests may not have names equal or similar to the name of the service. this is analagous to MX records, where the target name can be a service provider even though the query name is that of a customer. > ... > Overall the probabilities for 1st contact are 3/8 and > 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ > _order_is_randomly_chosen_, but this is not specified. > > According to my reckoning, consistent, correct results are > obtained if the random number is chosen to be between > _ONE_ and the sum computed. > > Q3) Does anyone agree or disagree with this? it seems reasonable to me, but i didn't write that part of the rfc and i'm not sure i ever understood it. greg hudson's answer was that the numbers had to be real not integer, and this may indeed be the case. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. > > It seems to me that there is an assumption here that target contact > selection from any particular client is very infrequent, and that > load sharing occurs by virtue of different clients making 1st contact > to different targets. no, actually we contemplated a web-like service where an object and all of the sub-objects (such as images) mentioned in that object should ideally be fetched from the same server, in case that server was capable of opportunistic pipelining or prefetching. > In a system who's application makes frequent heavy of a service, > service selection should be purely probabilistic based on the relative > weights of the highest priority records available. > > Q4) Can anyone clarify this matter? we contemplated making "sticky-ness" or "re-use" a protocol element but we felt that the SRV algorythm was already beyond its complexity horizon. the right thing to do now is: remove that part of the spec and designate re-use as "requestor-specific local policy". > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? (Please > mail the group to say you have responded to this one, to save me being > flooded!) ;; QUESTION SECTION: ;_kerberos._udp.vix.com. IN SRV ;; ANSWER SECTION: _kerberos._udp.vix.com. 3600 IN SRV 0 1 88 kerberos-0.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-1.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-2.vix.com. ;; AUTHORITY SECTION: vix.com. 3178 IN NS ns.lah1.vix.com. vix.com. 3178 IN NS ns.sql1.vix.com. vix.com. 3178 IN NS ns-ext.isc.org. ;; ADDITIONAL SECTION: ns.lah1.vix.com. 2429 IN A 204.152.188.234 ns.lah1.vix.com. 2429 IN AAAA 2001:4f8:2::9 ns.sql1.vix.com. 2429 IN A 204.152.184.135 ns.sql1.vix.com. 2429 IN AAAA 2001:4f8:3::9 ns-ext.isc.org. 3055 IN A 204.152.184.64 ns-ext.isc.org. 3057 IN AAAA 2001:4f8:0:2::13 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:48:11 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:53:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 06 Mar 2004 19:08:47 +0200." <20040306170847.GB24117@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > ... > RFC1035 deals with the on-the-wire encoding, while the SRV text > above seems to be related to the usual BIND-style zone file format. > The examples in RFC 2782 bear this out. However, re-reading RFC 2782 > and RFC 2052, I could not determine a definitive on-the-wire encoding > of SRV records -- this seems to be undefined. Presumably, implementors > have just looked at how BIND returns SRV records and gone with that. note that if BIND is shown to be wrong, we (isc) will of course fix it. > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? vix.com has no SRV-discovered services that use tcp as their transport. (presumably if we were a macintosh shop or a windows shop, we would?) _kerberos._udp.vix.com/IN/SRV has some data for you, though. > I also tried to find the IANA assignments for the Service tags, as > referred to in RFC 2782, and couldn't locate any. Have any actually > been standardized? If so, a pointer would be appreciated! here's the problem. SRV is experimental. 2052 was "snuck through" the ietf process when iesg's attention was focused elsewhere, and they got Really Angry about it when they found out. i've apologized, since mostly i was acting in ignorance and without malice, but it hasn't helped. so, in spite of the significant deployment of SRV in the community (like with the service discovery protocols currently shipped by microsoft and apple), SRV remains experimental. and as long as it's only experimental, iana's charter does not cover it. what we need to do is in two stages. first, iesg has to tell me how i can mend relations and achieve some kind of pardon for past SRV-related misdeeds. (perhaps a public apologia at an iesg plenary would suffice?) second, iana should create a registry of service identifiers, by importing the BSD file "/etc/services" and then periodically amending it for new standards -- and new standards should allocate a service name not just a default port number. i don't know how to do either of those things but that's the list, anyway. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jarle Greipsland <jarle@uninett.no> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 20:01:52 +0100 (CET) Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:07:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV > outside pseudo-DNS dynamic zones tied to DHCP servers? _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV -jarle -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 14:08:35 -0500 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:14:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 13:48, Paul Vixie wrote: > here's the problem. SRV is experimental. 2052 was "snuck through" the > ietf process when iesg's attention was focused elsewhere, and they got > Really Angry about it when they found out. Your history seems to be omitting the part where we got RFC 2782 published as a proposed standard (with you as one of the authors). That one certainly wasn't snuck through the IESG; we got significant feedback about the static weighting system, among other things. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 19:49:01 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <ghudson@MIT.EDU> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:56:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU> of "Sat, 06 Mar 2004 14:08:35 EST." <1078600115.9992.140.camel@error-messages.mit.edu> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > here's the problem. SRV is experimental. 2052 was "snuck through" the > > ietf process when iesg's attention was focused elsewhere, and they got > > Really Angry about it when they found out. > > Your history seems to be omitting the part where we got RFC 2782 > published as a proposed standard (with you as one of the authors). That > one certainly wasn't snuck through the IESG; we got significant feedback > about the static weighting system, among other things. indeed. i was thinking only of 2052 in my recounting. in that case there's nothing stopping someone from writing an rfc to immortalize /etc/services and making that file an iana database. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: David Shaw <dshaw@jabberwocky.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:13:42 -0500 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 21:20:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <20040306170847.GB24117@dns.net> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 07:08:47PM +0200, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV outside > pseudo-DNS dynamic zones tied to DHCP servers? _hkp._tcp.pgp.net to help find PGP keyservers. David -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sun, 7 Mar 2004 18:24:27 +0200 (EET) Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 03:29:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Hi, [[ note: I'm not subscribed... ]] I took a quick look at the DNSSEC intro document; it was in a very good shape. Two major comments: 1) the document requires the use of EDNS0. However, current EDNS0 implementations typically advertise the larger sizes than they can handle at the IP layer, causing fragmentation. You can argue that this is OK as long as the result of NOT fragmenting would end up with a worse result than as you would be without it (e.g., requiring falling back to TCP, or whatever). With DNSSEC, I'm not sure that this holds anymore. It seems to me that the best behaviour would be to avoid IP fragmentation by having correct implementations of EDNS0, and if some data must be left out, that it would be fetched separately, over second, third, ..., nth query over UDP. Shouldn't that be possible and reasonable? 2) Security considerations lists a number of threats, but does not discuss whether they have been fixed or mitigated at all (e.g., relating to dynamic updates and signing). It might not hurt to be a bit more explicit on this. Similarly, maybe some of this text could be included in the DNS security analysis document as well... editorial --------- page 4, chapter 2, replace "RRsets forms" with "RRsets forming" -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 03:09:22 +0000 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 04:15:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Sun, 07 Mar 2004 18:24:27 +0200." <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). most of <http://research.compaq.com/wrl/techreports/abstracts/87.3.html>'s concerns about fragmentation have been addressed, and the ones which still apply are relevant to small-mtu connections ("don't do that") and to high performance/demand mobygram applications (nfs, tcp). for dns, it's okay. > With DNSSEC, I'm not sure that this holds anymore. It seems to me > that the best behaviour would be to avoid IP fragmentation by having > correct implementations of EDNS0, and if some data must be left out, > that it would be fetched separately, over second, third, ..., nth > query over UDP. Shouldn't that be possible and reasonable? no, that really would force tcp, which really would be worse than ip-frag. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 13:47:21 +0900 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 05:55:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O Paul; > no, that really would force tcp, which really would be worse than ip-frag. If message size is 1400B or so, it is definitely so. If message size is 4200B or so, it can still be a valid argument. However, if message size is 64000B, TCP is far better than IP-frag. I understand the problem is not of DNSSEC but of EDNS0. But with the current EDNS0 specification lacking rational upper limit on message size, it will be safe if DNSSEC says: messages over UDP MUST NOT be larger than 4000 Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 05:02:50 +0000 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 06:08:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 13:47:21 +0900." <404BFAD9.80109@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > no, that really would force tcp, which really would be worse than ip-frag. > > If message size is 1400B or so, it is definitely so. > > If message size is 4200B or so, it can still be a valid argument. > > However, if message size is 64000B, TCP is far better than IP-frag. yes, that's true. the crossover is probably closer to 4*PMTU. > I understand the problem is not of DNSSEC but of EDNS0. > > But with the current EDNS0 specification lacking rational upper > limit on message size, it will be safe if DNSSEC says: > > messages over UDP MUST NOT be larger than 4000 it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E is for Estimated) but this isn't the time or place to make that change. so perhaps an advisory statement like "Note: advertising a buffer size larger than EPMTU could lead to unfortunate overaggressive IP fragmentation" would be enough to tell the dnssec implementor crowd -- who is likely to be the first real stress-testers of EDNS0's buffer size extension -- what they need to know, without actually amending the EDNS0 specification by side effect. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 14:58:13 +0900 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:02:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >> messages over UDP MUST NOT be larger than 4000 > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. I meant DNSSEC entities MUST NOT send messages larger than 4000 over UDP Can it be within the scope of DNSSEC? > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E > is for Estimated) but this isn't the time or place to make that change. If EDNS0 is to be changed (in the future, of course), reference to PMTUD should be clarified (removed entirely), because EDNS0 seemingly assumes fragmentation is always enabled, which means there is no room for PMTUD, which means, with IPv6, packets must be fragmented at the source. Or, if you think some form of PMTUD should be performed, it should be documented (though I think PMTUD practically impossible). > so perhaps an advisory statement like "Note: advertising a buffer size larger > than EPMTU could lead to unfortunate overaggressive IP fragmentation" would > be enough to tell the dnssec implementor crowd -- who is likely to be the > first real stress-testers of EDNS0's buffer size extension -- what they need > to know, without actually amending the EDNS0 specification by side effect. :-) Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:26:31 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:33:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Mon, 08 Mar 2004 07:37:47 +0200." <Pine.LNX.4.44.0403080733160.16733-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... would force tcp, which really would be worse than ip-frag. > > Seems like a flaw in DNS spec -- too coarse granularity: > 1) "everything fits in one UDP datagram", or > 2) "just use TCP". > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > datagram of specific size, query again, but only the missing data this > time". sense, yes, but the atomicity requirements are hard to adjust in that light. for example, if what you're trying to send is a referral, and the query and authority sections are all that fits, and you decide to just send that much and let the initiator re-query for the parts that would have been in the additional-data section, then it might end up being the case that they can never query for it. consider an authority section whose names are all under the referral cut. in earlier work once proposed as part of EDNS0 and then reintroduced as EDNS1, the idea came up to indicate in a response that there were multiple messages in the answer. we called it MD ("more data"). ultimately this turned out to be a lot more complicated than it sounded, and it's since been abandoned. i dearly wish that EDNS0 had made TTCP its prerequisite. ("ah, hindsight.") > Not sure if that would make sense but instead of forcing everything in > one, probably fragmented message, it would seem to encourage "proper" > operation with big DNS replies. in general, if you think the response might be larger than 3*EPMTU, use tcp, and that will amortize the complexity nicely. note that PMTUD hasn't been a raging success, and that EPMTU is probably 1500 octets most of the time, and that's where masataka's "4000" number comes from. > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. yes but on such a host, the EDNS0 initiator would presumably be able to discover this limitation and advertise a 1500-octet buffer. that's what the EDNS0 spec says it should do, at any rate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:29:28 +0000 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:34:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 14:58:13 +0900." <404C0B75.3000303@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > of scope. > > I meant > > DNSSEC entities MUST NOT send messages larger than 4000 > over UDP > > Can it be within the scope of DNSSEC? then it would be within scope for this docset, but extremely controversial since it places a requirement more stringent than EDNS0. far better to make it advisory and avoid the fight. > > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU > > (where E is for Estimated) but this isn't the time or place to make > > that change. > > If EDNS0 is to be changed (in the future, of course), reference to > PMTUD should be clarified (removed entirely), because EDNS0 seemingly > assumes fragmentation is always enabled, which means there is no room > for PMTUD, which means, with IPv6, packets must be fragmented at the > source. > > Or, if you think some form of PMTUD should be performed, it should be > documented (though I think PMTUD practically impossible). i think that you're right and that all hope of PMTUD should be abandoned in the next update of EDNS, which at this point would be EDNS1 rather than a reissue of EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 10:11:02 +0100 Organization: NIC France Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <20040306.200152.46801952.jarle@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 10:22:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jarle Greipsland <jarle@uninett.no> Content-Disposition: inline In-Reply-To: <20040306.200152.46801952.jarle@uninett.no> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.25-1-k7 i686 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 08:01:52PM +0100, Jarle Greipsland <jarle@uninett.no> wrote a message of 16 lines which said: > _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV Which is documented in: http://mailbox.univie.ac.at/~gw/draft-sanz-whois-srv-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 11:10:08 +0100 Lines: 196 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <1078587114.9992.126.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C404FD.EAE798E0" Cc: "Attila" <Attila.Sipos@VegaStream.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 11:32:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Greg Hudson" <ghudson@MIT.EDU> 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 Precedence: bulk Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your help, Greg. There's a note below about selection using random integers. ----- Original Message -----=20 From: "Greg Hudson" <ghudson@MIT.EDU> To: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Cc: <namedroppers@ops.ietf.org> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: DNS SRV Clarification sought > On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > > From page 3 of rfc2782 > > Compute the sum of the weights of those RRs, and with each = RR > > associate the running sum in the selected order. Then choose = a > > uniform random number between 0 and the sum computed > > (inclusive) > > > Random number case 0 1 2 3 > > 1st contact 1 1 2 2 > > 2nd contact 2 2 1 1 > > You appear to be computing a random integer, rather than a random real > number, as was intended. If you choose a random real number, you'll = get > the appropriate distribution (a server with weight 2 is chosen twice = as > often with a server of weight 1). > > I would have much preferred a statement which used random integers > (which is something you can actually do on a computer), but the = working > group was having a little trouble coming up with an algorithm = statement > that actually worked, so we decided to go with one which we strongly > believed was correct even if it wasn't very clear and which didn't > translate easily into code. Demonstration of selection using random integers. (Hope the fixed font is preserved and there's no line folding) Item Cumulative (weight) sum ---- -----=20 a a b a+b c a+b+c . . . . n a+b+c+...+n i.e.(sum(a...n)) Choosing a random integer between 1 and sum(a...n) inclusive and = selecting the first item greater than or equal to the random integer, we have - Random integer range 1...a a+1...a+b a+b+1...a+b+c Random integer frequency a (a+b)-(a+1)+1=3Db = (a+b+c)-(a+b+1)+1=3Dc Probability a/sum(a...n) b/sum(a...n) c/sum(a...n) For any item say, i, h being the previous item, Random integer range sum(a...h)+1...sum(a...i) Random integer frequency sum(a...i)-(sum(a...h)+1)+1=3Di Probability i/sum(a...n) Barry Desborough ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV>Thanks for your help, = Greg. There's a note=20 below about selection using random integers. ----- Original = Message -----=20 From: "Greg Hudson" <<A = href=3D"mailto:ghudson@MIT.EDU"><FONT=20 face=3DArial size=3D2>ghudson@MIT.EDU</A>> To:=20 "Barry Desborough" <<A = href=3D"mailto:Barry.Desborough@wanadoo.fr"><FONT=20 face=3DArial size=3D2>Barry.Desborough@wanadoo.fr</A>> Cc: <<A = href=3D"mailto:namedroppers@ops.ietf.org"><FONT=20 face=3DArial size=3D2>namedroppers@ops.ietf.org</A>> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: = DNS SRV=20 Clarification sought > On Sat, 2004-03-06 at 09:03, Barry=20 Desborough wrote: > > From page 3 of rfc2782 >=20 > Compute the sum of = the=20 weights of those RRs, and with each RR >=20 > associate the = running sum=20 in the selected order. Then choose a >=20 > uniform random = number=20 between 0 and the sum computed >=20 > = (inclusive) > >=20 > Random number case 0 1 2 3 > > 1st=20 contact = =20 1 1 2 2 > > 2nd=20 contact = =20 2 2 1 1 > > You appear to be computing a random integer, = rather than=20 a random real > number, as was intended. If you choose a = random real=20 number, you'll get > the appropriate distribution (a server with = weight 2=20 is chosen twice as > often with a server of weight = 1). > > I=20 would have much preferred a statement which used random integers > = (which=20 is something you can actually do on a computer), but the working > = group=20 was having a little trouble coming up with an algorithm = statement > that=20 actually worked, so we decided to go with one which we strongly > = believed=20 was correct even if it wasn't very clear and which didn't > = translate=20 easily into code. Demonstration of = selection=20 using random integers. (Hope the fixed font is preserved and there's = no line=20 folding) Item =20 Cumulative</DIV> <DIV>(weight) =20 sum ---- -----=20 a =20 a b =20 a+b c =20 a+b+c . =20 . . =20 . n a+b+c+...+n = i.e.(sum(a...n)) Choosing a random integer between 1 and = sum(a...n)=20 inclusive and selecting the first item greater than or equal to the = random=20 integer, we have -</DIV> <DIV> Random integer=20 range =20 1...a =20 a+1...a+b = a+b+1...a+b+c Random=20 integer frequency =20 a =20 (a+b)-(a+1)+1=3Db =20 (a+b+c)-(a+b+1)+1=3Dc Probability &= nbsp; =20 a/sum(a...n) b/sum(a...n) = c/sum(a...n) For any=20 item say, i, h being the previous item,</DIV> <DIV> Random integer=20 range sum(a...h)+1...sum(a...i) Random = integer=20 frequency =20 sum(a...i)-(sum(a...h)+1)+1=3Di Probability &nb= sp; =20 i/sum(a...n) Barry Desborough </DIV></BODY></HTML> ------=_NextPart_000_0007_01C404FD.EAE798E0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:59:49 -0500 Organization: NIST Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Pekka Savola" <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 16:39:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O ----- Original Message ----- From: "Paul Vixie" <paul@vix.com> > > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > > of scope. > > > > I meant > > > > DNSSEC entities MUST NOT send messages larger than 4000 > > over UDP > > > > Can it be within the scope of DNSSEC? > > then it would be within scope for this docset, but extremely controversial > since it places a requirement more stringent than EDNS0. far better to make > it advisory and avoid the fight. > It would also be an arbitrary limit based on current underlying network layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or EDNS0. It would best not be made a strict constraint that might be made obsolete by non-DNS factors. I agree with Paul in that it would be better to be an advisory statement, but not necessary to the specification. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 19:10:10 +1100 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 09:41:34 +0200." <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > What's your issue here? > > > > IPv4 has reassembly buffer size limits. > > IPv6 has reassembly buffer size limits. > > > > In either case you don't advertise a EDNS UDP buffer bigger > > than this limit. > > It would be nice if EDNS0 implementations conformed to these buffer > sizes then. On what platforms do the existing implementation not take these into account. Note most *nix platforms support 4k UDP datagrams already. > Currently it seems they have zero relation to MTU or PMTU, or buffer > sizes. There doesn't have to be a *explict* relationship to these. The current recommendations already take these into account. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 07:37:47 +0200 (EET) Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > With DNSSEC, I'm not sure that this holds anymore. It seems to me > > that the best behaviour would be to avoid IP fragmentation by having > > correct implementations of EDNS0, and if some data must be left out, > > that it would be fetched separately, over second, third, ..., nth > > query over UDP. Shouldn't that be possible and reasonable? > > no, that really would force tcp, which really would be worse than ip-frag. Seems like a flaw in DNS spec -- too coarse granularity: 1) "everything fits in one UDP datagram", or 2) "just use TCP". Would it make sense to add 1.5) there, "if it doesn't fit to a UDP datagram of specific size, query again, but only the missing data this time". Not sure if that would make sense but instead of forcing everything in one, probably fragmented message, it would seem to encourage "proper" operation with big DNS replies. Btw: note that IPv6 implementations aren't even required to defragment a datagram which is larger than 1500 bytes once assembled.. so we're in a bit murky waters here. I'd certainly want to try to avoid packet sizes >= ~1500. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:41:34 +0200 (EET) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200403080658.i286wXcq013551@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080658.i286wXcq013551@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > What's your issue here? > > IPv4 has reassembly buffer size limits. > IPv6 has reassembly buffer size limits. > > In either case you don't advertise a EDNS UDP buffer bigger > than this limit. It would be nice if EDNS0 implementations conformed to these buffer sizes then. Currently it seems they have zero relation to MTU or PMTU, or buffer sizes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 17:58:33 +1100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:05:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 06:26:31 -0000." <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. What's your issue here? IPv4 has reassembly buffer size limits. IPv6 has reassembly buffer size limits. In either case you don't advertise a EDNS UDP buffer bigger than this limit. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 10:08:33 -0600 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:18:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> Precedence: bulk Status: O On 3/6/2004 12:48 PM, Paul Vixie wrote: > iana should create a registry of service identifiers, by importing the > BSD file "/etc/services" and then periodically amending it for new > standards Is that really feasible? Service definitions may require weighting values and client-selection algorithms to be useful, all of which requires some level of agreement among implementors. If we start with a list of defaults and then update the list on-the-fly, how does the client know which version of the list entry is in use for those SRV RRs that they encounter? The nice thing about the current model is that an entry in the list connotes agreement among implementors, or at least carries a footnote. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 17:25:32 +0100 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <404C9A81.2040708@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:34:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 10:08:33 CST." <404C9A81.2040708@ehsco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <26114.1078763131.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Eric A. Hall wrote: > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards which would be different from <http://www.iana.org/assignments/port-numbers>? > Is that really feasible? Service definitions may require weighting values What weighting values are you talking about? Those in the SRV RR are not supposed to carry any additional meaning. RFC 2782 is pretty clear about the service names to be used: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. [...] Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. STD 2 is obsoleted by RFC 3232, again pointing to the URL above (although rather indirectly). What may be missing is a list of services without portnumber. In the whois case mentioned earlier inthis thread (which, btw uses "nicname" instead of the more prominent "whois" because of the "Service" requirement cited above) one would sometimes like to further differentiate the service without really using a different protocol, e.g. _ripe_whois.tcp... -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:21:20 +0200 (EET) Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <200403080810.i288AAcq036874@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:24:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080810.i288AAcq036874@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > > It would be nice if EDNS0 implementations conformed to these buffer > > sizes then. > > On what platforms do the existing implementation not take > these into account. Note most *nix platforms support 4k > UDP datagrams already. I don't know, maybe some embedded systems have restrictions. In any case 4000 byte UDP buffers does not equal being able to defragment datagrams worth of 4000 bytes total, right? > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > sizes. > > There doesn't have to be a *explict* relationship to these. > The current recommendations already take these into account. Well, about all the implementations I've seen set the EDNS0 irrespective of the MTU or PMTU configured on the system, which might make sense. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET) Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:25:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > > ... would force tcp, which really would be worse than ip-frag. > > > > Seems like a flaw in DNS spec -- too coarse granularity: > > 1) "everything fits in one UDP datagram", or > > 2) "just use TCP". > > > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > > datagram of specific size, query again, but only the missing data this > > time". > > sense, yes, but the atomicity requirements are hard to adjust in that light. Precisely -- but IMHO we need to figure out whether such atomicity requirements exist. They very certainly exist with 512 byte limit and DNSSEC. But do they exist e.g., with 1400 bytes? I'm a bit doubtful.. but I'd be interested in hearing what might be a "typical case", a "bad case", and "worst case". (We'll never be able to handle the last one, of course.) > > Not sure if that would make sense but instead of forcing everything in > > one, probably fragmented message, it would seem to encourage "proper" > > operation with big DNS replies. > > in general, if you think the response might be larger than 3*EPMTU, use tcp, > and that will amortize the complexity nicely. note that PMTUD hasn't been a > raging success, and that EPMTU is probably 1500 octets most of the time, and > that's where masataka's "4000" number comes from. Yep, EPMTU is 1500 bytes or a bit less -- but isn't that sufficient for about all intents and purposes? > > Btw: note that IPv6 implementations aren't even required to defragment > > a datagram which is larger than 1500 bytes once assembled.. so we're > > in a bit murky waters here. I'd certainly want to try to avoid packet > > sizes >= ~1500. > > yes but on such a host, the EDNS0 initiator would presumably be able to > discover this limitation and advertise a 1500-octet buffer. that's what > the EDNS0 spec says it should do, at any rate. Should, yes :). Does, no. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 12:03:05 -0600 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:10:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O On 3/8/2004 10:25 AM, Peter Koch wrote: > Eric A. Hall wrote: >> Is that really feasible? Service definitions may require weighting >> values > > What weighting values are you talking about? Those in the SRV RR are > not supposed to carry any additional meaning. The 'priority' field is different from the 'weight' field. RFC2782 says the following about the weight: | In the absence of a protocol whose specification calls for the | use of other weighting information, a client arranges the SRV | RRs of the same Priority in the order in which target hosts, | specified by the SRV RRs, will be contacted. > RFC 2782 is pretty clear about the service names to be used: Well, that's not the whole ball of wax. Service names can vary for reasosn other than protocol (http != www). Service names are relative labels which do not describe behavioral rules which may be associated with the service in general (algorithm may require SRV for in-addr space, or domain-wide space, or host-specific maps). Etc. Really, it seems to me that it's best to leave the list of well-known definitions for those SRV mappings and algorithms which are actually defined by the affected community. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: <fenner@research.att.com> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 03:47:36 +0900 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:54:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: pk@TechFak.Uni-Bielefeld.DE Versions: dmail (solaris) 2.5a/makemail 2.9d Precedence: bulk Status: O >> > iana should create a registry of service identifiers, by importing the >> > BSD file "/etc/services" and then periodically amending it for new >> > standards > >which would be different from ><http://www.iana.org/assignments/port-numbers>? Actually, I always thought that RFC 2782's [STD 2] reference was to the "PROTOCOL AND SERVICE NAMES" section, aka <http://www.iana.org/assignments/service-names>, and people who looked for the names in port-numbers were confused by the lack of strong binding to the reference (since there's no strong requirement for a port number assignment, just a name). Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 20:32:14 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 20:39:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 09 Mar 2004 03:47:36 +0900." <200403081847.i28IlbS24713@windsor.research.att.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <27142.1078774333.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Bill Fenner wrote: > was to the "PROTOCOL AND SERVICE NAMES" section, aka > <http://www.iana.org/assignments/service-names>, and people who looked this teaches us that the registry name will need to be specified explicitly, especially since URL references to the IANA registries are (were when I tried) only allowed to point to http://www.iana.org/numbers.html. > for the names in port-numbers were confused by the lack of strong binding Thanks, and increase the number of confused :-) > to the reference (since there's no strong requirement for a port number > assignment, just a name). The document you mention references WKS RRs, and since SRV is an orthogonal, though not totally unrelated, concept, it may be useful to use the same registry. However, since WKS uses port numbers (in a bit string) on-the-wire, I'm not too sure I understand the reasoning behind a registry dealing with names *only*. What's more important is some kind of link to the spec describing a) the protocol and b) use of SRV RRs in connection with that protocol. Elevation of 2782 will give us an opportunity to clarify this. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 05:41:18 +1100 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 21:19:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 18:21:20 +0200." <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > > It would be nice if EDNS0 implementations conformed to these buffer > > > sizes then. > > > > On what platforms do the existing implementation not take > > these into account. Note most *nix platforms support 4k > > UDP datagrams already. > > I don't know, maybe some embedded systems have restrictions. Well if you are writing a resolver for such a system you take its IP stack limitations into consideration. There are lots of additional considerations when writing for small memory platforms. Nobody is saying you *MUST* use certain size, just that they are recommended. Named has a switch to set the advertised size to 512. > In any case 4000 byte UDP buffers does not equal being able to > defragment datagrams worth of 4000 bytes total, right? > > > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > > sizes. > > > > There doesn't have to be a *explict* relationship to these. > > The current recommendations already take these into account. > > Well, about all the implementations I've seen set the EDNS0 > irrespective of the MTU or PMTU configured on the system, which might > make sense. With the current Internet the min(MTU,PMTU) will usually be 1500, ethernet/ppp default. Rarely will it be below 1200, slip default. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 13:17:05 -0800 Lines: 76 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 22:23:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Eric A. Hall'" <ehall@ehsco.com>, Paul Vixie <paul@vix.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O Registies are over-rated. Look at the number of programs there are on windows that have their own file format. Important name collisions are pretty rare considering that it is essentially a 3 character identifier. All that matters here is that the identifier be unique and plentiful enough that they do not run out. If you try to impose any requirement that is more stringent than first come first served we end up back with the X-Header problem. We could adopt the hash-cash scheme that Microsoft is pushing for anti-spam as a way of rationing code points in tables. All code points are first come first served. To get the code point 'SPAM' in table 'SRV' you have to provide a string s such that SHA1(s) - SHA1('SPAM+SRV') <> 0 AND |SHA1(s) - SHA1('SPAM+SRV')| < 2^(160-n) I.e. the strings must not be the same and the first n bits must match. The value of n would increase as the code points in the registry were exhausted. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eric A. Hall > Sent: Monday, March 08, 2004 11:09 AM > To: Paul Vixie > Cc: namedroppers@ops.ietf.org > Subject: Re: DNS SRV Clarification sought > > > > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by > importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards > > Is that really feasible? Service definitions may require > weighting values > and client-selection algorithms to be useful, all of which > requires some > level of agreement among implementors. > > If we start with a list of defaults and then update the list > on-the-fly, > how does the client know which version of the list entry is in use for > those SRV RRs that they encounter? > > The nice thing about the current model is that an entry in the list > connotes agreement among implementors, or at least carries a footnote. > > -- > Eric A. Hall > http://www.ehsco.com/ > Internet Core Protocols > http://www.oreilly.com/catalog/coreprot/ > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:02:38 +0900 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> <000301c40521$f3ba77c0$1a1f0681@lapdancer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:08:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Scott Rose <scottr@nist.gov> In-Reply-To: <000301c40521$f3ba77c0$1a1f0681@lapdancer> Precedence: bulk Status: O Scott Rose; > It would also be an arbitrary limit based on current underlying network > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > EDNS0. 512 byte limit is a bound not by DNS but by the current underlying network and transport layers. So? > but not necessary to the specification. It is necessary that DNS message size has a limit in the specification. Masataka Ohta PS The proper limit bound by minimum reassembly buffer size, maximum IP header length and UDP header length is 508. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:46:37 +0900 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:51:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > Why are we arguing about the minimums that have to be > supported by the architecure? Because the minimums of the infrastructure are maximums of DNS. > For example, named has a upper bound on the size of the > EDNS/UDP response it will send. And, it should be specified. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 09:38:11 +0900 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 02:44:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > EDNS and DNS are *different* protocols which share a port and > message format. RFC2671 This document describes backward compatible mechanisms for allowing the protocol to *GROW*. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 09:13:19 +0100 Organization: RIPE NCC Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <1078594181.9992.134.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 09:26:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Greg Hudson <ghudson@MIT.EDU> In-Reply-To: <1078594181.9992.134.camel@error-messages.mit.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.473609 / 0.0 / 0.0 X-RIPE-Signature: 86a7b34adf4294872cd6cf962183ce6b Precedence: bulk Status: O On Sat, 06 Mar 2004 12:29:42 -0500 Greg Hudson <ghudson@MIT.EDU> wrote: > On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > > I tried to find an online deployment of SRV records to feed to tcpdump, > > but the closest I came was an SOA record for _tcp.microsoft.com (one of > > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > > appear to have _tcp subdomains. Does anyone actually have a deployment > > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? > > We appear to have: > > _sip._tcp.mit.edu > _sip._udp.mit.edu > _sip._tcp.sipxchange.mit.edu > _sip._udp.sipxchange.mit.edu Where the use of SRV for SIP is documented in RFC3263 -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 11:23:43 +1100 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:46:37 +0900." <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Mark Andrews; > > > Why are we arguing about the minimums that have to be > > supported by the architecure? > > Because the minimums of the infrastructure are maximums of DNS. We are talking about EDNS. Nobody is thinking about changing the DNS UDP message size. The DNS is constained in this way, EDNS is not. EDNS and DNS are *different* protocols which share a port and message format. EDNS has a UDP request size limit of 512 bytes (inherited from DNS) unless you have reason to believe a larger request can be handled. e.g. you have just made a request and have been told that a bigger request can be handled. EDNS has a *negotiated* response size limit. This is IP stack dependent and will usually be *bigger* than the infrastructure minimums. It can also be smaller the the infrastructure minimums. e.g. you have a IPv6 firewall which is rejecting DNS packets > 512 bytes so you set the EDNS UDP size advertised to 512. The advertised EDNS UDP size is less than the minimum supported by the IPv6. DNS has a UDP request and response size limit of 512 bytes. > > For example, named has a upper bound on the size of the > > EDNS/UDP response it will send. > > And, it should be specified. Why. This is a *implemtation* limit not a *protocol* limit. RFC 2671 already has guidance for seting this limit. > > Masataka Ohta > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 10:35:24 +1100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:02:38 +0900." <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Scott Rose; > > > It would also be an arbitrary limit based on current underlying network > > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > > EDNS0. > > 512 byte limit is a bound not by DNS but by the current underlying > network and transport layers. > > So? > > > but not necessary to the specification. > > It is necessary that DNS message size has a limit in the specification. > > Masataka Ohta > > PS > > The proper limit bound by minimum reassembly buffer size, maximum > IP header length and UDP header length is 508. Why are we arguing about the minimums that have to be supported by the architecure? EDNS is about letting the the other end knowing what you are *capable of handling*. There is *nothing* in to stop a site sending *smaller* EDNS/UDP message than the receiving site is capable of handling. If the client says it can accept a 4k response but you know that your firewall is broken (e.g. drops DNS packets > 512) you are quite entitled to only send a 512 byte EDNS/UDP responses. Set TC as appropriate. For example, named has a upper bound on the size of the EDNS/UDP response it will send. You can advertise a 64k UDP buffer all you want but you will not get more that 4k EDNS/UDP response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 9 Mar 2004 17:04:26 +0100 Organization: RIPE NCC Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 17:12:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> In-Reply-To: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.456200 / 0.0 / 0.0 X-RIPE-Signature: 61983aa15b37f75c7f5207c40c99cbab Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). It seems there _could_ be consensus for an advisory note targeted at implementors, if only there were such a note. Can somebody please come up with text that can be put into the document set so we can focus on getting that correct and the editors can cut-n-paste. Let us not try to fix EDNS0, that is not in scope. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Wed, 10 Mar 2004 17:58:37 +0100 Organization: RIPE NCC Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <20040128203233.08EE614C52@sa.vix.com> <6.0.3.0.2.20040212231103.02da4b80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 18:11:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040212231103.02da4b80@localhost> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000719 / 0.0 / 0.0 X-RIPE-Signature: 022e6963a054024de5098a486a89bbd4 Precedence: bulk Status: O > While attempting to summarize what the consensus of the working group > is on this editors question and trying to interpret this block of text. > Does self-consistently apply to a name or the holy Q-trinity? Having reread the threat I think that the answer to Olafurs question was in the proposed text (only for the _security_ RRs so only for specific holy Q-trinities :-) ). I propose the editors use Paul's initial text with the clarification that this only applies to those _security_ RRs that can exist above and below a delegation point. e.g. like: security aware responders who receive queries security RRs (NSEC or RRSIG RRs) which match the content of more than one zone, for example above and below a delegation point, are encouraged to behave self-consistently, which could mean: always return an error; always return above-delegation records; always return below-delegation records; always return no records; always return both above- and below-delegation records; or always something else entirely. We'll consider this question resolved if no further comments are received before the end of the week. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-04.txt Date: Wed, 10 Mar 2004 15:40:37 -0500 Lines: 86 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 21:48:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-04.txt Pages : 9 Date : 2004-3-10 This document redefines the wire format of the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:34:09 -0500 Lines: 50 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 16:43:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org Precedence: bulk Status: O The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf >Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >From: Derek Atkins <derek@ihtfp.com> >Date: Tue, 24 Feb 2004 22:14:43 -0500 > >It sounds like you want two things here, but it also sounds like all >of them need to happen in the responder. The attacker could >theoretically send packets of any type, with any TTL. So you can't >trust anything you receive from the network. To this affect, I think: > >1) We want the responder to try to determine that a request came from > the local network. The best way to do this is for the responder to > check that TTL=255 to make sure. If a TTL is less than 255 then it > originiated off-net and can be dropped. > >2) We want the responder to make sure response packets don't go > off-net. In other words, we want the responder to respond with > TTL=1, to make sure it can't smurf. > >So, to this affect: > >a) an LLMNR requestor should send requests with TTL=255 >b) an LLMNR responder should verify requests have TTL=255 -- if it is not > 255 then it should drop the packet. >c) an LLMNR responder should respond with TTL=1 >d) I dont' think an LLMNR requestor needs to check the response TTL. > >The only issue this doesn't directly solve is a requester being >spoofed by an off-net attacker, but said attacker would need >to guess the transaction id of the request in order to send a >valid response, which is just as likely in LLMNR as it is in >standard DNS, so it can probably be ignored. > >So, other than this issue, does this solve the issue? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:52:56 -0800 Lines: 161 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--207754511; protocol="application/pkcs7-signature" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 20:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-8--207754511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have an issue with this. Using a TTL of 255 to verify that requests originate from the local=20 link is not very important. It may be useful to use a unicast query to=20= specific address from off of the local link to ask for records such as=20= HINFO. In the case of multicast, unless something is seriously broken a=20= link-local multicast packet is not going to be forwarded. Setting the TTL to 1 also unnecessarily prohibits unicast=20 request/responses from off of the local link. I would consider it more=20= useful to verify that a response to a link-local multicast came from=20 the local link. To those who are concerned that setting the TTL to 255 on a response=20 would enable another smurf attack, I would encourage them to try=20 pinging the all hosts multicast address. Most hosts will respond to=20 such a ping. This has not lead to any serious problems. The solution to=20= the smurf attack was to drop the subnet broadcast packets in routers=20 (don't forward them). A link local multicast packet will not be=20 forwarded. The defense against the smurf style attack is already=20 implemented. Hosts still respond to pings with subnet broadcasts but=20 routers never forward such packets, so this is only a local=20 vulnerability. If someone is local they could just as easily spoof the=20= source address of their packets as any of the other devices on the=20 local network. If the whole point of changing the TTL is to achieve interoperability=20 with Rendezvous, then the proposal below fails. -josh On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > > The chairs are looking for closure and rough consensus on this only > remaining issue for LLMNR. > The solution below seems like a good solid compromise. > Is there any technical reason why this should not be adopted, please > state so before March 24'th. > > Olafur & Olaf > > >> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >> From: Derek Atkins <derek@ihtfp.com> >> Date: Tue, 24 Feb 2004 22:14:43 -0500 >> >> It sounds like you want two things here, but it also sounds like all >> of them need to happen in the responder. The attacker could >> theoretically send packets of any type, with any TTL. So you can't >> trust anything you receive from the network. To this affect, I = think: >> >> 1) We want the responder to try to determine that a request came from >> the local network. The best way to do this is for the responder = to >> check that TTL=3D255 to make sure. If a TTL is less than 255 then = it >> originiated off-net and can be dropped. >> >> 2) We want the responder to make sure response packets don't go >> off-net. In other words, we want the responder to respond with >> TTL=3D1, to make sure it can't smurf. >> >> So, to this affect: >> >> a) an LLMNR requestor should send requests with TTL=3D255 >> b) an LLMNR responder should verify requests have TTL=3D255 -- if it = is=20 >> not >> 255 then it should drop the packet. >> c) an LLMNR responder should respond with TTL=3D1 >> d) I dont' think an LLMNR requestor needs to check the response TTL. >> >> The only issue this doesn't directly solve is a requester being >> spoofed by an off-net attacker, but said attacker would need >> to guess the transaction id of the request in order to send a >> valid response, which is just as likely in LLMNR as it is in >> standard DNS, so it can probably be ignored. >> >> So, other than this issue, does this solve the issue? > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org = with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> --Apple-Mail-8--207754511 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxMTE4NTI1N1owIwYJKoZIhvcNAQkEMRYEFP0O Ia3W8w/x+47YEoXcV/9pDyndMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAApn zOCUjtzfx/HePoVrW9B92akgPc+74/dwmULkkUhYbv/Iw+gASUnplhFK3mz62o1NZYRGb4RuHmjx ar1KWlU8rIl3QoCNBqY8q3QISGI2oApMtnVXMf0abz/IST8hTndYl02br+7iXmDdyNuUrYQmjRyt QYIV3JUzV7Q8UOBiRwPRYuSeiDvJEsCd1h5IMExVNZOBjD69fu3oMK5bVq3gHNPQyKl59BSFkJlE 3w89yzOFPI67eeDhzDVEraXIW8w04oNM6AkzxjJwNugRReSSZAe635ZDBiMFzowtQf7pdNqpSN7c Jr0s0lkNZg2K8rc+5ALBd7MpnTMj44AxUt4AAAAAAAA= --Apple-Mail-8--207754511-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Fri, 12 Mar 2004 11:37:19 -0500 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 17:49:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040228124513.02f35bc8@localhost> References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Precedence: bulk Status: O At 13:00 2004-02-28, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >This RFC was published about 6 months ago so it is now a candidate to >advance through he standards track. >In order to do that we need > evidence of implementation, > interoperabilty test and report. Jakob Schlyter <jakob@rfc.se> has stepped up and will coordinate the interoperabilty testing and write the report. (Thanks Jakob) He needs help from vendors in identifying support, please contact him to participate in the testing. Jakob and I will be contacting some vendors privately asking explicit questions of support and if they want to participate. Even though IETF rules say only two implementation are needed for the interoperabilty test, the chairs would like to include as many as possible. One important reason is the impact RFC3597 support has on the introduction of new RR types. The interoperabilty testing will address all types of DNS functional units: - Authorative servers (primary and secondary) - Recursive Resolvers (including Caches) - Stub Resolvers - Diagnostic tools The standard IETF interoperabilty rules will apply - List of implementations tested will be provided - Any problem identified will be examined to see if the source of the problem is the documentation - There will be NO public disclosure of what implementations had problems only a list of the problems. The goal here is twofold, advance a better document, allow vendors to address any problems identified sooner than later. Olafur (co-chair). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Fri, 12 Mar 2004 15:28:27 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 21:40:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 12 Mar 2004 16:56:27 -0500 Lines: 138 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 23:08:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> (Joshua Graessley's message of "Thu, 11 Mar 2004 10:52:56 -0800") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Hi, Joshua Graessley <jgraessley@apple.com> writes: > Using a TTL of 255 to verify that requests originate from the local > link is not very important. It may be useful to use a unicast query to > specific address from off of the local link to ask for records such as > HINFO. In the case of multicast, unless something is seriously broken > a link-local multicast packet is not going to be forwarded. It's exactly the fact that it's useful in a unicast query that we should do it. You are correct, multicast doesn't care, so we should use the TTL value that gives us the most bang for the buck. What does it hurt us to use TTL=3D255 and verifying it? In neither case does it hurt us. Yes, requests could leave the network, but the responder would drop them (as it should -- it's not link-local!) > Setting the TTL to 1 also unnecessarily prohibits unicast > request/responses from off of the local link. I would consider it more > useful to verify that a response to a link-local multicast came from > the local link. Indeed, this prohibition is EXACTLY WHAT WE WANT! It's not unnecessary. It's a requirement! > To those who are concerned that setting the TTL to 255 on a response > would enable another smurf attack, I would encourage them to try > pinging the all hosts multicast address. Most hosts will respond to > such a ping. Just because a problem exists in another protocol and isn't majorly exploited now does not mean that we should make the same mistake. People HAVE used DNS as a smurf/explosion attack. Pings aren't interesting -- the response is no larger than the request. DNS is VERY interesting, because I could potentially get a LARGE response for a small request. Therefore, we should protect against it. > This has not lead to any serious problems. The solution > to the smurf attack was to drop the subnet broadcast packets in > routers (don't forward them). A link local multicast packet will not > be forwarded. The defense against the smurf style attack is already > implemented. Hosts still respond to pings with subnet broadcasts but > routers never forward such packets, so this is only a local > vulnerability. If someone is local they could just as easily spoof the > source address of their packets as any of the other devices on the > local network. This type of defence does not protect against unicast LLMNR requests. Sure, a properly configured multicast router can stop the multicase requests, but it wont stop the unicast packets. That's yet another reason we should use TTL=3D1 on responses, to make sure unicast messages can't smurf. > If the whole point of changing the TTL is to achieve interoperability > with Rendezvous, then the proposal below fails. No, the whole point of this proposal is to get us out of the deadlock that we've been in by showing how we can use TTLs to get the most bang for the buck. I've listed all the threats that I think we're worried about and I've shown how the largest set of threats can be mitigated by the combined 255/1 TTL. If we can get Apple to move along with us and interoperate, great. But this proposal is not "let's make this look like Rendevous". > -josh So, Olaf and Olafur, I obviously have no technical reason why this should not be adopted ;) -derek > On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > >> >> The chairs are looking for closure and rough consensus on this only >> remaining issue for LLMNR. >> The solution below seems like a good solid compromise. >> Is there any technical reason why this should not be adopted, please >> state so before March 24'th. >> >> Olafur & Olaf >> >> >>> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >>> From: Derek Atkins <derek@ihtfp.com> >>> Date: Tue, 24 Feb 2004 22:14:43 -0500 >>> >>> It sounds like you want two things here, but it also sounds like all >>> of them need to happen in the responder. The attacker could >>> theoretically send packets of any type, with any TTL. So you can't >>> trust anything you receive from the network. To this affect, I think: >>> >>> 1) We want the responder to try to determine that a request came from >>> the local network. The best way to do this is for the responder to >>> check that TTL=3D255 to make sure. If a TTL is less than 255 then it >>> originiated off-net and can be dropped. >>> >>> 2) We want the responder to make sure response packets don't go >>> off-net. In other words, we want the responder to respond with >>> TTL=3D1, to make sure it can't smurf. >>> >>> So, to this affect: >>> >>> a) an LLMNR requestor should send requests with TTL=3D255 >>> b) an LLMNR responder should verify requests have TTL=3D255 -- if it >>> is not >>> 255 then it should drop the packet. >>> c) an LLMNR responder should respond with TTL=3D1 >>> d) I dont' think an LLMNR requestor needs to check the response TTL. >>> >>> The only issue this doesn't directly solve is a requester being >>> spoofed by an off-net attacker, but said attacker would need >>> to guess the transaction id of the request in order to send a >>> valid response, which is just as likely in LLMNR as it is in >>> standard DNS, so it can probably be ignored. >>> >>> So, other than this issue, does this solve the issue? >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: <http://ops.ietf.org/lists/namedroppers/> --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:27:07 +0900 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:35:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >>>no, that really would force tcp, which really would be worse than ip-frag. >> >>If message size is 1400B or so, it is definitely so. >> >>If message size is 4200B or so, it can still be a valid argument. >> >>However, if message size is 64000B, TCP is far better than IP-frag. > yes, that's true. the crossover is probably closer to 4*PMTU. Given 1280B of IPv6 minimum MTU, shouldn't message size limitation be somewhere around 3600 or 4800, but not 4000? Masagtaka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:48:52 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> <4052474B.9010306@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:56:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <4052474B.9010306@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O I wrote: >>yes, that's true. the crossover is probably closer to 4*PMTU. > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? My guess is that current specification of 4000B expects 3 frags over IPv4 that it should be 3600B for IPv6. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 09:35:59 +0900 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 01:53:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Precedence: bulk Status: O From: Derek Atkins <derek@ihtfp.com> >> 1) We want the responder to try to determine that a request came from >> the local network. No, we don't. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 00:58:15 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 02:06:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Sat, 13 Mar 2004 08:27:07 +0900." <4052474B.9010306@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > yes, that's true. the crossover is probably closer to 4*PMTU. > > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? i think it's all very approximate and 4000 is a very fine and round number. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 15:09:22 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 14:28:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Mon, Mar 08, 2004 at 08:32:14PM +0100, Peter Koch wrote: > Bill Fenner wrote: > > was to the "PROTOCOL AND SERVICE NAMES" section, aka > > <http://www.iana.org/assignments/service-names>, and people who looked > > this teaches us that the registry name will need to be specified explicitly, > especially since URL references to the IANA registries are (were when I tried) > only allowed to point to http://www.iana.org/numbers.html. RFC 3232 makes reference to http://www.iana.org/ which in turn makes a reference to http://www.iana.org/numbers.html but then the trail gets cold. There are several potential documents that could be relevant, for instance either http://www.iana.org/assignments/port-numbers (this is the classic /etc/services document we have all been using as a reference, but isn't obviously tied in to DNS) or http://www.iana.org/assignments/service-names (which could be relevant since it is explicitly associated with WKS records). > Elevation of 2782 will give us an opportunity to clarify this. I would like to document the "correct" usage of SRV records at DNSRD, so I agree that the next version of 2782 should explicitly refer to the correct registry document. Now, which one is it? port-numbers or service-names? -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 17:15:25 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 18:27:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 13 Mar 2004 15:09:22 +0200." <20040313130922.GA23428@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > Elevation of 2782 will give us an opportunity to clarify this. > > I would like to document the "correct" usage of SRV records at DNSRD, > so I agree that the next version of 2782 should explicitly refer to the > correct registry document. > > Now, which one is it? port-numbers or service-names? there isn't one. and unless one of you writes an internet-draft which asks iana to import /etc/services and then maintain the master copy of it, then 2782bis will not have anything to point at. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 12:02:40 -0800 Lines: 61 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 21:13:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQIfkyla6nOGvrbT9eb4zFEHTUH4QAtGG7A To: "Derek Atkins" <derek@ihtfp.com>, "Joshua Graessley" <jgraessley@apple.com> X-OriginalArrivalTime: 13 Mar 2004 20:02:38.0054 (UTC) FILETIME=[223D4060:01C40936] Precedence: bulk Status: O Could we agree in any case that the TTL discussion does not apply when = we use TCP?=20 As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=3D255, as = per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of = address ranges is sufficient to guarantee on-link status. Setting = TTL=3D1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of = packet to the local link. On-link attackers can spoof the source = address; off-link attackers generally cannot send multicast packets to = the destination. Checking the TTL provides no protection against on-link = attackers (they can set whatever TTL value is expected). Checking that = the source address belongs to an "on-link" prefix prevents the "smurf = attack to an off-link target". Setting the TTL=3D1 in multicast queries = prevent the side effects of a rare bug in routers, but this bug may not = be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, = including for off-link attackers. Checking TTL=3D255 protects against = spoofing by off-link sources. Checking that the source address belongs = to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the = transaction identifier, which in practice requires an "on-link" = attacker; TTL games do not protect against on-link attackers. Setting = the TTL to 1 protects against unwitting participation in a DOS-attack to = an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some = network topologies that support multicast but require packets to go = through a router -- some wireless networks and some ad hoc networks can = have that property. In practice, checking TTL=3D255 is only useful in UDP unicast queries, = where it provides a slight incremental benefit over a simple check of = the source address prefix. Setting the TTL to 1 provides a limited = benefit in TCP operation, multicast queries and unicast responses, but = contradicts the requirement of TTL=3D255 for IPv6 link-local addresses. = Setting to either value will create operational problems in some future = scenarios. The simplest solution is probably to remove all mentions of TTL checks = from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an = authorized range; 2) The TTL field should be set by the stack to whatever default value is = adequate for the interface and the source address (e.g., TTL=3D255 for = IPv6 link-local addresses.) -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:29:16 +0200 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Derek Atkins <derek@ihtfp.com>, Joshua Graessley <jgraessley@apple.com>, =?ISO-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 23:39:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Christian Huitema <huitema@windows.microsoft.com> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Christian, > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <mika.liljeberg@welho.com> X-From: owner-namedroppers@ops.ietf.org Sun Mar 14 01:32:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Mika Liljeberg <mika.liljeberg@welho.com> of "Sun, 14 Mar 2004 00:29:16 +0200." <1079216956.1930.16.camel@hades> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. "i'll by THAT for a dollar." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 15 Mar 2004 14:08:17 +0900 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040313005815.D96AA14D81@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 06:15:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040313005815.D96AA14D81@sa.vix.com> Precedence: bulk Status: O Paul; >>>yes, that's true. the crossover is probably closer to 4*PMTU. >> >>Given 1280B of IPv6 minimum MTU, shouldn't message size limitation >>be somewhere around 3600 or 4800, but not 4000? > > > i think it's all very approximate and 4000 is a very fine and round number. It could have been so, if PMTUD were usable, which would have resulted in PMTU of 1450~1500. Without PMTUD, however, assumed MTU MUST be 1280, for which very approximate and round should be 3500 or 3600. Or, are there any cryptographic reason that the size is 4000? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 18:52:17 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <20040313171525.8D6F418F48@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:02:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Sat, 13 Mar 2004 17:15:25 GMT." <20040313171525.8D6F418F48@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <25301.1079373136.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Paul Vixie wrote: > > Now, which one is it? port-numbers or service-names? > > there isn't one. and unless one of you writes an internet-draft which > asks iana to import /etc/services and then maintain the master copy of I'm sorry but I do not see any difference between /etc/services and the "port-numbers" registry except for the non-existence of aliases in the latter. What do you miss? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Mon, 15 Mar 2004 10:30:45 -0800 Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <1079216956.1930.16.camel@hades> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-136514579; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:40:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <1079216956.1930.16.camel@hades> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-3-136514579 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Works for me. -josh On Mar 13, 2004, at 2:29 PM, Mika Liljeberg wrote: > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. > > MikaL --Apple-Mail-3-136514579 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNTE4MzA0NlowIwYJKoZIhvcNAQkEMRYEFHrU VLPbNQNtvNopd+r+aqYgPGgTMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAMVP pq29OvSY+jKZQaZQC/DwN6GQ+O7rFsR4Q6EoohlgH38fYMCZ7OwTlKafoMP+kn1kxJK4Cqd8WdQ+ 2PR8K0aTIU9m8SO16+Ou3ddFmgxrB/TpyT75BdB6YsWxdiHMWRrPMXa3udJ4caBrASZ1218a6eM3 fFglGZT8BHoL1bd5ylnjlHbJ5zYOHU9xLliKjacwEwlBV1srKbny1YcRaclaTLPL8rMcwuOggyc9 k3V3G2EgekhjO43lrHH39vU58HqG4fiNUzpsefi9W9KgxyHZntipn2oLO/EUZ1cwsLtZytZLlU0z UHt8+32mJpkXneCh3hLwIAz8cbPUGd4Y53EAAAAAAAA= --Apple-Mail-3-136514579-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 20:00:49 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <pk@TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:13:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Peter Koch <pk@TechFak.Uni-Bielefeld.DE> of "Mon, 15 Mar 2004 18:52:17 +0100." <200403151752.i2FHqHk25304@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > I'm sorry but I do not see any difference between /etc/services and > the "port-numbers" registry except for the non-existence of aliases in the > latter. What do you miss? ftp://ftp.iana.org/assignments/port-numbers' "keyword" field (which wasn't there a few years ago when i last looked at this file) seems like the right answer. however, a purely SRV-discovered service might not _have_ a default port number, in which case ftp://ftp.iana.org/assignments/service-names would be the better choice for an SRV's owner name. and, it would be good to know that iana's policy is to keep synchronization between port-numbers keywords, and service-names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 12:42:37 -0800 Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:54:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O however, a purely SRV-discovered service might not > _have_ a default > port number, in which case > ftp://ftp.iana.org/assignments/service-names would > be the better choice for an SRV's owner name. It seems to me that a good long term objective here would be to stop issuing port numbers completely. The logical extension of SRV is that you look up the service in DNS and get back a report of the name of the server that supports the service, the port address to use plus any parameters that describe the use of the port (I support SSL security with profile X). This is where the Internet will be in a few years time. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Mon, 15 Mar 2004 16:52:00 -0500 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 23:02:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Just a notification from your friendly neighborhood DNSSECbis document editors, to avoid suprising anyone. Miek Gieben and Jelte Jansen pointed out what we are certain is an editorial goof in way we specified calculation of the RRSIG signature value. The current drafts (both -protocol and -records) say that the signature is calculated over RR(i) = name | class | type | OrigTTL | RDATA length | RDATA As Miek and Jelte pointed out to us, the class and type fields here are reversed from the normal RFC 1035 ordering for a wire-encoded RR (not to be confused with the RFC 1035 text format, which has the class, type, and TTL fields in reverse order to avoid parse ambiguities). To the best of our knowledge: a) RFC 2535 did not explictly specify the order, but the algorithm has generally been understood as signing the wire representation; b) There has been no WG action since RFC 2535 that would change this; and c) All current implementations of which we're aware use the wire ordering, not what the DNSSECbis specs currently say. So this seems to have just been an editorial goof, we've fixed it in the editors' working sources, and the fix will be in the next revisions of the drafts we post. If anyone has a problem with this change, please send mail to the editors, the WG chairs, or to namedroppers, as appropriate. Thanks to Miek and Jelte for catching this! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Tue, 16 Mar 2004 09:36:19 +0100 Organization: RIPE NCC Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040315215200.D2A7318E0@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 16 09:44:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org> In-Reply-To: <20040315215200.D2A7318E0@thrintun.hactrn.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.082025 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8ddd797dfea932e40d44a26c70d1f113 Precedence: bulk Status: O Miek, Jelte, Good Catch!! Rob wrote: > a) RFC 2535 did not explictly specify the order, but the algorithm has > generally been understood as signing the wire representation; It is somewhat hidden through a refference from section 4.1.8 (Signature field): " RR(s) is the RRset of the RR(s)(...) in canonical form and order as defined in Section 8. " RFC 2535 section 8.1 applies: For purposes of DNSsecurity, the canonical form for an RR is the wire format of the RR (...) -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST) Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 02:18:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O > Ok, although I would rather suggest: > 1) Nodes should very that the source address of queries belong to an > authorized range; I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. > 2) Use TTL=1 with TCP. This makes sense. > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. This only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 21:54:41 -0800 Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:03:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQLvatlaIXizGLoR++uJyP8Awx4HgAJaJwg To: "Bernard Aboba" <aboba@internaut.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 17 Mar 2004 05:52:47.0441 (UTC) FILETIME=[131E2C10:01C40BE4] Precedence: bulk Status: O > > Ok, although I would rather suggest: >=20 > > 1) Nodes should very that the source address of queries belong to an > > authorized range; >=20 > I'm not sure how to define an "authorized range". A host may not know all > the prefixes present on a given link. In IPv6 at least, the host is suppose to learn the list of on-link prefixes from the RA. But you are right, there are many ways to get this test half-right and cause major operation pain.=20 > > 2) Use TTL=3D1 with TCP. >=20 > This makes sense. >=20 > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. >=20 > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. >=20 > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=3D1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Getting rid of unicast UDP query would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=3D1 also guarantees an on-link peering.=20 The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Wed, 17 Mar 2004 08:07:22 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:11:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Bernard Aboba <aboba@internaut.com> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O On Wed, 2004-03-17 at 03:17, Bernard Aboba wrote: > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. > > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. Well, section 2.4 already says: "Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries." > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Using different TTLs for different messages is awkward from the implementation standpoint. It would be simplest just to require that all requests and responses must be sent to the local link. E.g. use the SO_DONTROUTE socket option. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 06:06:21 -0800 (PST) Lines: 318 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 15:08:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O The text of LLMNR Issue 64 is enclosed below. The proposed resolution is as follows: In Section 2.4, change: "Unicast LLMNR queries SHOULD be sent using TCP." To: "Unicast LLMNR queries MUST be sent using TCP." Change: "Unicast UDP queries MAY be responded to with a UDP response containing an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP." To: "Unicast UDP queries MUST be silently discarded." Change: "If an ICMP "Time Exceeded" message is received in response to a unicast UDP query, or if TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). The UDP sender receiving an ICMP "Time Exceeded" message SHOULD verify that the ICMP error payload contains a valid LLMNR query packet, which matches a query that is currently in progress, so as to guard against a potential Denial of Service (DoS) attack. If a match cannot be made, then the sender relies on the retransmission and timeout behavior described in Section 2.7." To: "If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section)." In Section 2.5, change: "In composing LLMNR queries, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). Even when LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Therefore setting the IPv6 Hop Limit or IPv4 TTL field to one provides an additional precaution against leakage of LLMNR queries. In composing a response to an LLMNR query, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). This is done so as to prevent the use of LLMNR for denial of service attacks across the Internet. Section 2.4 discusses use of TCP for LLMNR queries and responses. The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder." To: "Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. For UDP queries and responses the Hop Limit field in the IPv6 header, and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Rendezvous." In Section 5.1, change: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on both queries and responses. A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can be used to launch denial of service attacks. For example, were the TTL of an LLMNR Response to be set to a value larger than one (1), an attacker could send a large volume of queries from a spoofed source address, causing an off-link target to be deluged with responses. Utilizing a TTL of one (1) in LLMNR responses ensures that they will not be forwarded off-link. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender." To: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing UDP queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on TCP queries and responses. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. When LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may enable denial of service attacks across the Internet. However, since LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal." An edited version of the specification incorporating these changes is available at: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-30.txt -------------------------------------------------------------------- Issue 64: TTL Revisited Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: March 15, 2004 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00299.html Document: LLMNR-29 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Derek Atkins <derek@ihtfp.com> Date: Tue, 24 Feb 2004 22:14:43 -0500 It sounds like you want two things here, but it also sounds like all of them need to happen in the responder. The attacker could theoretically send packets of any type, with any TTL. So you can't trust anything you receive from the network. To this affect, I think: 1) We want the responder to try to determine that a request came from the local network. The best way to do this is for the responder to check that TTL=255 to make sure. If a TTL is less than 255 then it originiated off-net and can be dropped. 2) We want the responder to make sure response packets don't go off-net. In other words, we want the responder to respond with TTL=1, to make sure it can't smurf. So, to this affect: a) an LLMNR requestor should send requests with TTL=255 b) an LLMNR responder should verify requests have TTL=255 -- if it is not 255 then it should drop the packet. c) an LLMNR responder should respond with TTL=1 d) I dont' think an LLMNR requestor needs to check the response TTL. The only issue this doesn't directly solve is a requester being spoofed by an off-net attacker, but said attacker would need to guess the transaction id of the request in order to send a valid response, which is just as likely in LLMNR as it is in standard DNS, so it can probably be ignored. So, other than this issue, does this solve the issue? [Christian Huitema] Could we agree in any case that the TTL discussion does not apply when we use TCP? As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=255, as per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of address ranges is sufficient to guarantee on-link status. Setting TTL=1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of packet to the local link. On-link attackers can spoof the source address; off-link attackers generally cannot send multicast packets to the destination. Checking the TTL provides no protection against on-link attackers (they can set whatever TTL value is expected). Checking that the source address belongs to an "on-link" prefix prevents the "smurf attack to an off-link target". Setting the TTL=1 in multicast queries prevent the side effects of a rare bug in routers, but this bug may not be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, including for off-link attackers. Checking TTL=255 protects against spoofing by off-link sources. Checking that the source address belongs to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the transaction identifier, which in practice requires an "on-link" attacker; TTL games do not protect against on-link attackers. Setting the TTL to 1 protects against unwitting participation in a DOS-attack to an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some network topologies that support multicast but require packets to go through a router -- some wireless networks and some ad hoc networks can have that property. In practice, checking TTL=255 is only useful in UDP unicast queries, where it provides a slight incremental benefit over a simple check of the source address prefix. Setting the TTL to 1 provides a limited benefit in TCP operation, multicast queries and unicast responses, but contradicts the requirement of TTL=255 for IPv6 link-local addresses. Setting to either value will create operational problems in some future scenarios. The simplest solution is probably to remove all mentions of TTL checks from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an authorized range; 2) The TTL field should be set by the stack to whatever default value is adequate for the interface and the source address (e.g., TTL=255 for IPv6 link-local addresses.) [Mika Liljeberg] > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. [Bernard Aboba] I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. TTL=255 on UDP request & responses only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. [Christian Huitema] Getting rid of unicast UDP queries would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=1 also guarantees an on-link peering. The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 17 Mar 2004 11:06:54 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 17:14:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: LLMNR authorized range Date: Wed, 17 Mar 2004 10:19:12 -0800 Lines: 86 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-308620971; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 19:27:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-13-308620971 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 16, 2004, at 5:17 PM, Bernard Aboba wrote: >> Ok, although I would rather suggest: > >> 1) Nodes should very that the source address of queries belong to an >> authorized range; > > I'm not sure how to define an "authorized range". A host may not know > all > the prefixes present on a given link. The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. -josh --Apple-Mail-13-308620971 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzE4MTkxMlowIwYJKoZIhvcNAQkEMRYEFPiN 3vLihLmc6g/UXYaume3X1TIJMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBABID 5kspYzWbi7lBMu8pVrGyZZ2/vNLa7cP+3xgscFyqNHBTYzii2NsnmUe97xQWPBtDJ5PpW1GhanVz DK9XwDPbaTHBBWKmVA5LeHqVhsqzOsYRkRWPU8YmVAnPJbPMH5OvADep2yuoAQvDfkybYIEryOMR o2jfRj8mIXTpwxqKf9hG3OwGleTrEg8bzvOCgGruFIAxm+BiMx2ayDeIYvqfXVy8XU2zTWQUKB+w pyFhIkyJkTbX324Y2wlMAlGlv1zB4KsTqJH62Rb+PsXifl2sW+gD6RMn/XwqJgrteyarMyWMZ+D+ 6IDc848v8NteNdCjpEUrprCGxZqx8KB5QSkAAAAAAAA= --Apple-Mail-13-308620971-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:20:56 +0200 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 20:29:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Josh, On Wed, 2004-03-17 at 20:19, Joshua Graessley wrote: > The current solution of using TCP with a TTL of 1 makes the "authorized > range" pretty simple to understand. Addresses in the authorized range > are those that the host knows about. This highlights a problem with the > current LLMNR draft. If there are two subnets overlaid on a local > network and the hosts are unaware of the opposite subnet, LLMNR will > make it impossible to resolve names of some devices on the same link > just because they exist on a different subnet. As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:25:29 -0500 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 21:33:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O At 13:19 2004-03-17, Joshua Graessley wrote: >The current solution of using TCP with a TTL of 1 makes the "authorized >range" pretty simple to understand. Addresses in the authorized range are >those that the host knows about. This highlights a problem with the >current LLMNR draft. If there are two subnets overlaid on a local network >and the hosts are unaware of the opposite subnet, LLMNR will make it >impossible to resolve names of some devices on the same link just because >they exist on a different subnet. Good point, so what TLL <= N works for you ? N = 5 sounds good to me. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <ogud@ogud.com> X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 22:29:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> of "Wed, 17 Mar 2004 15:25:29 EST." <6.0.3.0.2.20040317152010.02b37e88@localhost> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... If there are two subnets overlaid on a local network and the > > hosts are unaware of the opposite subnet, LLMNR will make it > > impossible to resolve names of some devices on the same link just > > because they exist on a different subnet. that sounds like the right thing, since if they're on different subnets then they will not be able to communicate even though those subnets are in the same broadcast domain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 14:13:00 -0800 Lines: 95 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-322649650; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 23:29:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040317212210.05A5514C51@sa.vix.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-18-322649650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed My friends has a problem with his cable modem provider. He has paid extra to get extra addresses. The addresses are handed out using DHCP. The addresses are not always on the same subnet. I see no reason why LLMNR shouldn't work for him. I may soon have a similar situation at home. I've got sDSL for a small server I run. I'm thinking about getting a cable modem connection so I can get stuff quicker. When I have that setup at home, I'll have two or more subnets running on the local network. All of the devices can communicate using their IPv4 addresses (albeit inefficiently). LLMNR should work in this situation but due to the TTL stuff it may not work. I think there is a simple solution for IPv6. Always use the IPv6 link-local addresses. The only solution that would work 100% of the time for IPv4 would be to use the same link-local multicast to send the response. -josh On Mar 17, 2004, at 1:22 PM, Paul Vixie wrote: >>> ... If there are two subnets overlaid on a local network and the >>> hosts are unaware of the opposite subnet, LLMNR will make it >>> impossible to resolve names of some devices on the same link just >>> because they exist on a different subnet. > > that sounds like the right thing, since if they're on different subnets > then they will not be able to communicate even though those subnets are > in the same broadcast domain. --Apple-Mail-18-322649650 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzIyMTMwMVowIwYJKoZIhvcNAQkEMRYEFGC0 xVKoZ+1an/5iMlJX/1xQw6DpMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAHdE tCTuzek3bgT7uCX+FEcQUYwwsv0Dnpcc8LKbMC7ZUwR6N7Am77lCNPIvw/wZfwm+87pxoori9Cl/ JSVyvPiUgiB/yfipwfUJPdoQIbrD8IbcsleoWSP95c+SAX4Odw1utoo9zbg4ig4sO/xtwQtV2JaA xNfDAhhiuk4+5+GtXf5/fJKEZd+gYa831X6fPBDr+rbVEZYnKO4I89iVrGW4XQ66d61LJ26XIs2/ NNsXHQbq/u9+8p0XUNTauhGPjJH9XVDk9mDt0o23xmbwfPzavUtoDBnvSEt6yASMfaZxUMTPdCD/ F30cuturShwPFbcGw4wSZ0fZmIQOFcG0GRUAAAAAAAA= --Apple-Mail-18-322649650-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 23:23:34 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <jgraessley@apple.com> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 00:31:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Joshua Graessley <jgraessley@apple.com> of "Wed, 17 Mar 2004 14:13:00 PST." <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > My friends has a problem with his cable modem provider. He has paid extra > to get extra addresses. The addresses are handed out using DHCP. The > addresses are not always on the same subnet. I see no reason why LLMNR > shouldn't work for him. i guess if your router is sitting on both subnets and you're willing to go through a router to talk to other hosts in the same broadcast domain, you're right there's no reason LLMNR wouldn't work. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 13:56:57 -0600 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403170606040.10517@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403170606040.10517@internaut.com> To: Bernard Aboba <aboba@internaut.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 8:06 AM, Bernard Aboba wrote: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header MAY be set to any value. However, > it is RECOMMENDED that the value 255 be used for compatibility with > Apple Rendezvous." Why not change it to: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header SHOULD be set to 255. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 17:02:06 -0600 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. It shouldn't work for him because his network is misconfigured. It's not the job of the IETF to arrange for it to be the case that any random configuration error still results in desired behavior, for any arbitrary value of "desired." If you want this to work, you need to go check out the IPv4ll protocol and make sure that it does the right thing in this case. And your friend needs to use IPv4ll. Rendezvous works correctly in this case, doesn't it? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:21:31 -0600 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:07:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 12:19 PM, Joshua Graessley wrote: > If there are two subnets overlaid on a local network and the hosts are > unaware of the opposite subnet, LLMNR will make it impossible to > resolve names of some devices on the same link just because they exist > on a different subnet. I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 20:02:00 -0800 Lines: 26 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 05:11:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution to LLMNR Issue 64: TTL Revisited thread-index: AcQMfLkklVWmcimJRgOk4T8n5ZiKvQAIL36g To: "Ted Lemon" <mellon@fugue.com>, "Bernard Aboba" <aboba@internaut.com> X-OriginalArrivalTime: 18 Mar 2004 04:02:14.0194 (UTC) FILETIME=[CBCEC120:01C40C9D] Precedence: bulk Status: O > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header MAY be set to any value. However, > > it is RECOMMENDED that the value 255 be used for compatibility with > > Apple Rendezvous." >=20 > Why not change it to: >=20 > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header SHOULD be set to 255. Because this is a trade-off. The proper design is to use a TTL=3D1. The only reason to use the 255 value, which has a larger exposure to DOS exploitation, is compatibility with rendezvous. The text that Bernard proposes is a fine compromise. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 23:18:46 -0600 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 06:24:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> To: "Christian Huitema" <huitema@windows.microsoft.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 17, 2004, at 10:02 PM, Christian Huitema wrote: > Because this is a trade-off. The proper design is to use a TTL=1. The > only reason to use the 255 value, which has a larger exposure to DOS > exploitation, is compatibility with rendezvous. The text that Bernard > proposes is a fine compromise. The text I proposed and the text it replaces have exactly the same effect. The difference is that one of them places blame (I think inappropriately, although I think also unintentionally), and the other does not. I can't think of any technical reason to prefer the old text over the new. Can you state such a reason? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: EDNS0 (RFC-2671) questions Date: Thu, 18 Mar 2004 15:25:36 +0200 Lines: 31 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 14:34:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O 1) assuming I send query, which includes the OPT RR (to increase the packet length). If I receive a reply with TC=1 (truncation) and don't find OPT RR in the reply, then I assume the RCODE is the non-extended one? [Just verifying, that I can trust all implementations do it right: if they build an answer and run out of space before inserting the OPT RR, they also fall back to old plain RCODE?] This extended-RCODE makes it somewhat akward, to find RCODE, you have to traverse through all data in Question, Answer and Authority sections, then look OPT RR from Additional section. Doable, but still icky, just to get few extra bits of RCODE that are rarely used. Would have been easier if there was single RCODE value in fixed header to indicate that extended RCODE is in use. 2) Can UDP payload size be < 512? I didn't see any mention of it. Maybe I missed it. I think RFC should state that attempting to use less than 512 is not allowed (and will be ignored). [If < 512 is accepted, there might be some DOS potential in it also] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: correction to RRSIG presentation format in DNSSECbis -records draft Date: Thu, 18 Mar 2004 10:53:08 -0500 Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:04:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-NIST-MailScanner-Information: Please contact the ISP for more information X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Status: O Recently pointed out by Miek and Erik Rozendaal in the Resource Records draft of the DNSSECbis spec is the discrepancy between the ASCII presentation formats of the RRSIG and NSEC RRs. In the text, the RRSIG Type Covered field is supposed to be represented as a RR type mnemonic or an unsigned integer. This goes against the convention in RFC 3597 which states that unknown RR types should be represented as "TYPE<number>" where <number> is the typecode. The text for the representation of the NSEC RR type bitmap already states this (as it was written after RFC3597). The text for the RRSIG representation was changed to be consistent with RFC 3597 and the NSEC text. Section 3.2 paragraph 2 will now read: The Type Covered field is represented as a RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597] (section 5) MUST be used. Thanks, Scott DNSSECbis editors -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 18:14:36 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:19:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 03:21:31PM -0600, Ted Lemon wrote: > A host that you > can't talk to without going through a router isn't "local." Why not? Which part of the Internet-Draft does this violate? >From ...-29.txt: For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. The network overlay scenario is clearly "on link" according to the above definition. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 16:54:57 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 05:02:06PM -0600, Ted Lemon wrote: > On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > >My friends has a problem with his cable modem provider. He has paid > >extra to get extra addresses. The addresses are handed out using DHCP. > >The addresses are not always on the same subnet. I see no reason why > >LLMNR shouldn't work for him. > > It shouldn't work for him because his network is misconfigured. It's > not the job of the IETF to arrange for it to be the case that any > random configuration error still results in desired behavior, for any > arbitrary value of "desired." Exactly how is overlaying two IP network ranges onto one L2 infrastructure misconfigured? -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 17:32:58 +0200 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> Content-Disposition: inline In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. This hits at the crux of what "Link-Local" means in the acronym LLMNR. The above scenario (if indeed regarded as acceptable practice) will be regarded by most people as "local". During the original drafting of the document, did the authors have a specific definition of "link-local" in mind? As I recall, the original spec came out of Stuart Cheshire's work on replacing AppleTalk's naming service; this became Rendezvous and branched off into LLMNR. If this is the case, then the "local" definition was pretty broad, and would probably cover the overlaid network scenario. Also, in the above scenario, forcing TTL=1 will cause the router to drop the packet before it is forwarded back onto the "other" part of the local network. Making TTL=5 (or any other number greater than 1 but less than the worst-case diameter of the Internet) seems to be an ugly solution, and also gets away from the "link-local" part of LLMNR -- why not just call it "restricted scope MNR" then? Or why not just drop the TTL restriction altogether and just allow general MNR? I repeat -- TTL checks are a kludge, and do not capture the idea of "local" networks. There are local networks for which TTL must be greater than 1 to capture locality (eg. multiple IP ranges overlaid on the same L2 medium as above), and there are distinctly non-local networks (eg. LANs bridged through long thin pipes) for which any multicast can cause great harm -- even with TTL=1. In a message to this forum from Bernard Aboba in October 2003: As a result, the ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local specification so as to "do no harm". The current specification no longer mandates a test for a TTL value, and prefers a routable address when available. It is perhaps not as "useful" as the early versions -- but it also does not break the basic interoperability of TCP/IP. I've probably taken the above slightly out of context, but perhaps we should go back to the original multicast slant of LLMNR and drop UDP unicast, as suggested by Bernard in another message. For multicast, the TTL is irrelevant unless we are trying to compensate for potential router bugs. On the other hand, for TCP queries, the TTL should not be restricted. Then, interoperability with an existing protocol seems to be a worthwhile goal, as long as it is not bought at a terrible price. (Why was UDP unicast functionality introduced, anyway?) At the end of the day, I just want to see some finality with LLMNR, whatever it is! Either it is going to be useless and Rendezvous will win out in the marketplace, or it will be useful and over time it may grow to take over from Rendezvous. But right now LLMNR is by definition useless, since it hasn't been finalised. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040318153258.GF9994@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jgraessley@apple.com (Joshua Graessley), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:57:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net (Andras Salamon) In-Reply-To: <20040318153258.GF9994@dns.net> from "Andras Salamon" at Mar 18, 2004 05:32:58 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > > My friends has a problem with his cable modem provider. He has paid > > extra to get extra addresses. The addresses are handed out using DHCP. > > The addresses are not always on the same subnet. I see no reason why > > LLMNR shouldn't work for him. > > This hits at the crux of what "Link-Local" means in the acronym LLMNR. link-local is an unfortunate terminological choice. it might be useful to consider "single broadcast domain", which pretty much eliminates the overlay scenario. > As I recall, the original spec came out of Stuart Cheshire's > work on replacing AppleTalk's naming service; this became Rendezvous and > branched off into LLMNR. If this is the case, then the "local" definition > was pretty broad, and would probably cover the overlaid network scenario. Hum... there were a series of efforts that hit confluence and then diverged... the TBDS research, what became Rendezvous and what might become LLMNR... all are varients that use DNS or DNSlike stuff. > -- Andras Salamon andras@dns.net --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:36:42 -0600 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> <20040318145457.GE9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:51:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318145457.GE9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 8:54 AM, Andras Salamon wrote: > Exactly how is overlaying two IP network ranges onto one L2 > infrastructure > misconfigured? It is misconfigured in the sense that it does not do what the customer expects. The customer expects that the two devices he or she has connected to the network will be able to communicate with each other without relying on the service provider. This is unfortunately not true - they will not be able to communicate other than over the service provider's link, unless they implement Rendezvous (I do not believe that the current IPv4ll draft, for example, will allow them to communicate independent of the ISP). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:47:39 -0600 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <20040318153258.GF9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:59:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318153258.GF9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 9:32 AM, Andras Salamon wrote: > During the original drafting of > the document, did the authors have a specific definition of > "link-local" > in mind? Yes. However, the current document bears only a passing resemblance to what the authors had in mind. The original intention was that the two devices we're discussing would both have IPv4ll addresses, and that MDNS, as it was then called, would uses these addresses, not the globally-routable addresses. Both the IPv4ll spec and the MDNS spec have been changed dramatically since then. IPv4ll no longer works the way it did, and LLMNR doesn't either. At this point, I have to say that it is my sincere hope that neither IPv4ll nor LLMNR make it to standard as they are currently constituted. But if they do make it to standard, my next hope is that they do not fail to interoperate with Rendezvous. If they do not interoperate reliably with Rendezvous, then the only purpose they will serve is to make sure that no reliable mechanism exists whereby two arbitrary hosts can automatically communicate with each other on the local link in the event that the DHCP server is not configured to enable this communication - by having two incompatible mechanisms that do roughly the same thing, we eliminate the possibility of dependable interoperability. I sympathize deeply with your motivation to make LLMNR work correctly in the scenario we're talking about in the absence of any competing protocol, but that is not the domain in which we are operating. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 22:41:55 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 07:41:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O >LLMNR will make it impossible to resolve names of some devices on the >same link just because they exist on a different subnet. No. All but PTR RR queries will be sent to the link-scope multicast address, so they will be resolved without a problem. >As far as I can see, that is only a problem with PTR queries, which >often fail anyway. Yes. Only PTR queries are sent via TCP. Given that other queries will work and applications need to be prepared for PTR RR queries to fail anyway, you'll only see somewhat degraded performance. On the other hand, there is a performance improvement for other cases, since TTL=1 causes unresolvable PTR RR queries to fail quickly, rather than having to wait for LLMNR_TIMEOUT. So this is really just an optimization issue and I'm not clear that optimizing for an uncommon case (e.g. TTL=5) makes sense. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Fri, 19 Mar 2004 10:16:42 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> <20040318161436.GA10775@dns.net> <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 09:48:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Thu, Mar 18, 2004 at 12:34:32PM -0600, Ted Lemon wrote: > On Mar 18, 2004, at 10:14 AM, Andras Salamon wrote: > >The network overlay scenario is clearly "on link" according to the > >above definition. > > Sure, and you could argue that the definition you've quoted is correct > and that mine is wrong. I'm not especially interested in arguing about whose definition is right or wrong. However, the current LLMNR Internet-Draft defines its scope to include the scenario of address ranges overlaid onto the same L2 infrastructure (maybe I'm wrong here, but no-one has yet objected). Hence, either we need to change the wording of the I-D, or we need to accept the wording and its consequences. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 03:47:00 -0800 (PST) Lines: 47 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 12:51:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [Joshua Graessley] said: The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. [Ted Lemon] replied: I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? [Mika Liljeberg] said: As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? [Bernard Aboba] In practice, I don't believe this issue will arise. Section 1 says: "The assumption is that if a network has a gateway, then the network is able to provide DNS server configuration." Therefore in the "overlapping subnet" case LLMNR assumes that the host has DNS configuration. From early on, LLMNR has assumed that the gateway supports the resolution of the names of local hosts using DHCPv4 and dynamic DNS update. However, this assumption cannot be made for IPv6 at this point. So if we are talking about multiple subnets on a link in IPv4, then a conventional DNS query will be sent first, and local names can be resolved by the gateway. If we are talking about IPV6, then Router Advertisement enables the host to become aware of the multiple subnets, so that TCP-based queries can be sent on the local link, rather than forwarded by a router. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 14:23:14 +0200 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 13:31:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: aboba@internaut.com In-reply-to: <Pine.LNX.4.56.0403200335280.8666@internaut.com> (message from Bernard Aboba on Sat, 20 Mar 2004 03:47:00 -0800 (PST)) Precedence: bulk Status: O > From: Bernard Aboba <aboba@internaut.com> > > ... If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, Terminology confusion? What subnets are in RA? RA can have multiple prefixes to be used on the link (if L=1), but they are not subnets. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR authorized range Date: Sat, 20 Mar 2004 10:48:18 -0800 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 19:58:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR authorized range thread-index: AcQOdygluZmu2G4uTO+NBskGu1hyLwANJJKA To: "Markku Savela" <msa@burp.tkv.asdf.org>, <aboba@internaut.com> X-OriginalArrivalTime: 20 Mar 2004 18:48:03.0805 (UTC) FILETIME=[E04548D0:01C40EAB] Precedence: bulk Status: O > > From: Bernard Aboba <aboba@internaut.com> > > > > ... If we are > > talking about IPV6, then Router Advertisement enables > > the host to become aware of the multiple subnets, >=20 > Terminology confusion? What subnets are in RA? RA can have multiple > prefixes to be used on the link (if L=3D1), but they are not subnets. Uh? There is no official definition of subnet, but the generally agreed definition is "the set of addresses that shares a specified prefix". -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 12:12:48 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: msa@burp.tkv.asdf.org (Markku Savela), aboba@internaut.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 21:21:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: huitema@windows.microsoft.com (Christian Huitema) In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> from "Christian Huitema" at Mar 20, 2004 10:48:18 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > > From: Bernard Aboba <aboba@internaut.com> > > > > > > ... If we are > > > talking about IPV6, then Router Advertisement enables > > > the host to become aware of the multiple subnets, > > > > Terminology confusion? What subnets are in RA? RA can have multiple > > prefixes to be used on the link (if L=1), but they are not subnets. > > Uh? There is no official definition of subnet, but the generally agreed > definition is "the set of addresses that shares a specified prefix". That is not generally agreed on in most circles I run in. The working definition here is: "a single broadcast domain" e.g. more layer two'ish. > -- Christian Huitema --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 16:18:45 -0500 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 22:26:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200403202012.i2KKCn418994@karoshi.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > > > Uh? There is no official definition of subnet, but the generally agreed > > definition is "the set of addresses that shares a specified prefix". > > That is not generally agreed on in most circles I run in. > The working definition here is: "a single broadcast domain" > e.g. more layer two'ish. I think you're both right, but Christian's righter. IP "subnets" (the term's a bit dated given CIDR, but comes from the old subnetting extension to the original class A/B/C extension to the original original IPv4 address architecture's static 255.0.0.0 network mask) are an IP (layer 3) concept referring to a set of IP addresses sharing a particular prefix. The fact that IP subnets usually (but not always) map 1-to-1 with link-layer broadcast domains has led to sloppy terminology even in the IP world, and there are certainly other uses of the term "subnet" which mean something entirely different (eg, at one point I think the entire ARPANET was referred to as a "subnet" of the ARPANET/MILNET system, and some link layer specs do use the term "subnet" to mean link layer broadcast domain, as Bill suggests). So for precision you have to state the context (including layer) in which you're using the term, but since this is the IETF, and around here we mostly talk about IP, any use of the term "subnet" in IETF documents should generally be presumed to be talking about IP addresses with a shared prefix unless stated or proven otherwise. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Sun, 21 Mar 2004 08:07:45 +0900 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20040320211845.29FEB18F8@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Mar 21 00:15:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Rob Austein <sra@isc.org> In-Reply-To: <20040320211845.29FEB18F8@thrintun.hactrn.net> Precedence: bulk Status: O Rob Austein; > At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > >>>Uh? There is no official definition of subnet, but the generally agreed >>>definition is "the set of addresses that shares a specified prefix". >> >> That is not generally agreed on in most circles I run in. >> The working definition here is: "a single broadcast domain" >> e.g. more layer two'ish. > > > I think you're both right, but Christian's righter. No, Christian is not. According to the CATENET model of the Internet, the Internet is composed from local networks (of RFC791). local network = subnet = link = broadcast domain The proper way to assign a local network multiple addresses is to let all the hosts (of RFC791) in the local network share multiple prefixes of equal length using identiral host parts (intra-subnet) addresses, which still means local network = subnet = link = broadcast domain Confusions caused by any other configuration are the problems of the configuration. The configuration is responsible to make the model visible from other protocols local network = subnet = link = broadcast domain > any use of the term "subnet" in IETF > documents should generally be presumed to be talking about IP > addresses with a shared prefix unless stated or proven otherwise. It's "shared prefixes", not "a shared prefix". Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Mon, 22 Mar 2004 10:40:10 -0800 Lines: 104 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-741880068; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 22 19:53:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403200335280.8666@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-32-741880068 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Based on prior discussions and reading the draft, I was under the impression that if a DNS query fails (response with answercount of zero or a response with an error of NXDOMAIN), the query would be performed using LLMNR. It seems very plausible that someone might setup their computers to respond to LLMNR queries for names such as josh.llmnr or josh.thisdomainmustfailtoresolve. This would allow someone to locally refer to their computers by name no matter what the local addresses are and whether or not a DNS server is available. This would also be perfectly valid according to the current LLMNR spec. In this valid scenario, if there are multiple subnets on the same local network, LLMNR will fail. -josh On Mar 20, 2004, at 3:47 AM, Bernard Aboba wrote: > [Bernard Aboba] In practice, I don't believe this issue will arise. > Section 1 says: > > "The assumption is that if a network has a gateway, > then the network is able to provide DNS server configuration." > > Therefore in the "overlapping subnet" case LLMNR > assumes that the host has DNS configuration. From early > on, LLMNR has assumed that the gateway supports the > resolution of the names of local hosts using DHCPv4 and > dynamic DNS update. However, this assumption cannot be > made for IPv6 at this point. > > So if we are talking about multiple subnets on a link in > IPv4, then a conventional DNS query will be sent first, > and local names can be resolved by the gateway. If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, > so that TCP-based queries can be sent on the local > link, rather than forwarded by a router. --Apple-Mail-32-741880068 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMyMjE4NDAxMVowIwYJKoZIhvcNAQkEMRYEFDl8 9/kmuygyZVn0ISG4dH3oZKYDMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAKeo F6CpAFWpAvOdpM0OBoVrJenuTybGod5v/4E0F44x70U/JOeZApkZAK1dREIeT1M42J4b9iWk52CX 4mb++kOUH65xD77FH6xWNihVCHOIQF8W8+OHRO7yJSVuD6xYjahCpUVyF9KupoIzvGV1fBwz3Jml DtzmKAISHUTzXsZrLvKtvpUKcsouw3UMuiiE8GVWBsoInmA3w66Wd8EMSFmyJpVlry9lG/9VNemZ 8/+sQrWmxHBlfeweschkXXzXKqnMaliaRurH330kVS3V1lCmD340JsL8xbcpC19nGgQWPxGJlbAM ZYJSAmxRXO/uIlf95HB5A1FPEE16WGQ3Z5QAAAAAAAA= --Apple-Mail-32-741880068-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Tue, 23 Mar 2004 15:14:16 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 23 07:20:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O Josh; > In this valid > scenario, if there are multiple subnets on the same local network, LLMNR > will fail. With IPv6, there is no reason not to share all the prefixes of a link by all the hosts on the link, which means there is only a single subnet. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Advance: draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 24 Mar 2004 09:16:56 +0100 Organization: RIPE NCC Lines: 98 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, jakob@schlyter.se X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 09:28:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Thomas Narten" <narten@us.ibm.com>, "Margaret Wasserman" <margaret@thingmagic.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.015749 / 0.0 / 0.0 / disabled X-RIPE-Signature: d65dbcaea04193b902f993fc8813be54 Precedence: bulk Status: O Thomas, Margaret, Hereby the advancement questionnaire (www.mip4.org/2004/draft-writeup-items.html) for "DNSSEC NSEC RDATA Format" draft-ietf-dnsext-nsec-rdata-05.txt. The questionaire serves as a request to advance the document to proposed standard. 1. Chairs review. The chair responsible for tracking this document has read it and considers it ready for IESG review. 2. Working Group member review. The proposed format has been discussed on the list as well as during the IETF 58 meeting. The content of the comments received during last call indicate that a number of people have closely reviewed the document. 3. Is more review from a particular perspective needed. In the chairs opinion not. 4. Specific Issues and concerns the AD/IESG should be aware of. The document _only_ changes a format. The security section therefore does not go into the details of NSEC security. Note however that the text describing this format will be directly 'cut-n-pasted' into the dnssec-bis document set. The dnssec-bis intro document set covers the security considerations, e.g. NSEC cain walking, in more detail. 5. How solid is the WG consensus. The format was chosen during IETF58. The document itself got explicit consensus from only a few individuals. On the other hand this is has not been contentious issue. 6. Thread for appeal. None. 7. _all_ ID nits addressed. All are addressed. 8. References There is a normative reference to an I-D that has been advanced. Also not that this document will be merged and obsoleted by the dnssec-bis document set. 9. Writeup. Technical Summary To prevent the introduction of an extension mechanism once DNSSEC has a deployed base this document redefines the wire format of the "Type Bit Map" field in the NSEC resource record RDATA format to cover the full RR type space. The new format of the type bitmap is easy to implement, can cover the full range of type codes, is economical in the common case and has a maximum size of approximately 8.5 kilobytes. Efficient searching of the type bitmap for presence of a type had a lower priority. Working Group Summary The format was chosen from 6 different candidates that were presented to the working group. There is consensus on the chosen representation. Protocol Quality There are 3 independent implementations of this format. 1 implementation provides both a server and a client, 1 implementation only a server and 1 implementation only a client. These interoperate. -- Olaf Kolkman Olafur Gudmundsson -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis Q-30: DNAME awareness Date: Wed, 24 Mar 2004 14:08:52 -0500 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 20:23:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Q-30: Should the DNSSECbis specs require DNAME-awareness? Approximate text to be added if the WG agrees: [To be inserted somewhere in Section 3.x of -protocol] A security-aware name server which synthesizes CNAME RRs from DNAME RRs as described in RFC 2672 SHOULD NOT generate signatures for the synthesized CNAMEs. [To be inserted somewhere in Section 4.x of -protocol] A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs which could have been synthesized from the DNAME RR as described in RFC-2672, at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so. Background: RFC-2672 recommends that name servers synthesize CNAME RRs based on DNAME RRs, for backwards compatability with DNAME-oblivious resolvers. RFC-2672 goes on to suggest that DNSSEC-capable name servers might want to keep the zone key online in order to sign these synthesized CNAME RRs, for the benefit of security-aware DNAME-oblivious resolvers. This has obvious security issues, and also adds some complexity. In fairness, note that when RFC-2672 came out, DNSSEC-classic (RFC 2535) had already shipped, so one could argue that this was the least bad backwards compatability hack available to the author of RFC-2672. So the question here is whether there is any need for DNSSECbis to support security-aware DNAME-oblivious implementations. Specifically, can we eliminate the case of a security-aware DNAME-oblivious resolver expecting name servers to synthesize signed CNAME RRs from signed DNAME RRs? DNSSECbis question Q-27 already covered part of this space, by allowing a security-aware recursive name server to set the AD bit for responses containing synthesized CNAME RRs. Q-27 did not, however address whether name servers should attempt to sign synthesized CNAME records or whether resolvers should expect to receive signatures for synthesized CNAME records. Whether a validating resolver choses to retain synthesized CNAMEs or not appears to be an implementation and local policy choice, since CNAME synthesis itself is only a SHOULD in RFC-2672 and thus not something on which any DNS-using software can depend. Deadline and default: Per instructions from the WG chairs, this question will time out on 4 April 2003 with a default action to accept these changes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Thu, 25 Mar 2004 09:57:08 +0100 (CET) Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> <6.0.3.0.2.20040312111536.02678528@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Mar 25 10:11:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040312111536.02678528@localhost> Precedence: bulk Status: O interested parties should visit http://www.rfc.se/interop3597/ and join the mailing-list at http://www.rfc.se/mailman/listinfo/interop3597. before testing starts, I need help with filling the test zone (published as interop3597.rfc.se) with useful, and wierd, data. please send suggestions me or to the list above. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSSECbis Q-30: DNAME awareness Date: Fri, 26 Mar 2004 11:33:53 -0500 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> <20040324190852.67C5618C9@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 17:51:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040324190852.67C5618C9@thrintun.hactrn.net> To: Rob Austein <sra@isc.org> Precedence: bulk Status: O I like what these words say. At 14:08 -0500 3/24/04, Rob Austein wrote: >Q-30: Should the DNSSECbis specs require DNAME-awareness? > >Approximate text to be added if the WG agrees: > > [To be inserted somewhere in Section 3.x of -protocol] > > A security-aware name server which synthesizes CNAME RRs from DNAME > RRs as described in RFC 2672 SHOULD NOT generate signatures for the > synthesized CNAMEs. > > [To be inserted somewhere in Section 4.x of -protocol] > > A validating security-aware resolver MUST treat the signature of a > valid signed DNAME RR as also covering unsigned CNAME RRs which > could have been synthesized from the DNAME RR as described in > RFC-2672, at least to the extent of not rejecting a response > message solely because it contains such CNAME RRs. The resolver > MAY retain such CNAME RRs in its cache or in the answers it hands > back, but is not required to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-30.txt Date: Fri, 26 Mar 2004 15:49:27 -0500 Lines: 96 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 22:06:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-30.txt Pages : 26 Date : 2004-3-26 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-30.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-30.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-30.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Olaf Kolkman <olaf@ripe.net> Subject: DNSEXT list policy Date: Mon, 1 Mar 2004 08:35:01 +0100 Lines: 190 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 01 08:48:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.500000 / 0.0 / 0.0 X-RIPE-Signature: 32d842149ec8e2859401da1280faf172 Precedence: bulk Status: O - List Purpose namedroppers@ops.ietf.org is the mailing list for the IETF DNSEXT working group. See <http://www.ietf.org/html.charters/dnsext-charter.html> for the wg charter. Messages should be on topics appropriate to the dnsext wg, which are various discussion of the DNS protocols or administrivia of the WG itself. - Specific items that are not not appropriate for posting Calls for papers, announcements of events not directly relevant to the DNS protocols, etc. are not appropriate. Discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, pleas for help with specific implementations, etc. should be done on mailing lists for the particular implementations. There is a working group for dns operational practice, DNSOP, whose charter can be found at <http://www.ietf.org/html.charters/dnsop-charter.html>. Items relevant to the DNSOP charter are to be discussed on the DNSOP mailinglist. Discussion about the quality of implementations is outside the scope of this list. - Moderation Moderation is based on "subscriber-only with spam filter". Questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). There is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com - Issue Tracker As of October 2003 this group will use an issue tracker. This is to better organize the work-flow, maintain overview over, and focus the discussions to the working group documents. Please stick to the following procedure when discussing working group work documents. == The system The issue tracker can be found at: https://roundup.machshav.com/dnsext/index The chairs are responsible for maintaining the data in the issue tracker. That task may be delegated to document editors. If a document editor prefers other tracking systems they are free to coordinate that with the chairs. == Creating a new issue. New Issue tickets are only created for working group document. If you have an issue a document please sent in a mail with a subject header of the following format <NAME> ISSUE: <title> Where <NAME> is taken from the I-D's file name draft-ietf-dnsext-<name>-<version> and the <title> is a short description of the issue presented. Please use the following template to submit an issue: To: namedroppers@ops.ietf.org Cc: document-editor@foo.example Subject: FOO-RR-PROCESSING ISSUE: BLA-bit vs FOO-flag interop problem One line description of issue name: Your_Name_Here email: Your_Email_Address_Here Date: Insert_Date_Here Reference: URL to e-mail describing problem, if available Type: ['T'echnical | 'E'ditorial] Priority: ['C'ritical | 'U'rgent | 'B'ug | 'F'eature | 'W'ish ] Document: draft-ietf-dnsext-<name>-<version> Section: Insert_Section_Number_Here Rationale/Explanation of issue: Length description of problem Requested change: Proposal The proposal for the requested change is the most important bit of the issue. Providing a proposed text will focus discussion and relieves the document-editors. A new issue MUST therefore contain a text in the 'requested change' field. Once a new "ISSUE" message is received on the list the chairs or document editors will add the issue to the document tracker and reply to the list providing a URL and a relevant issue identifier. == Discussion of issues. Discussion of issues takes place on the list. Please reply 'in-thread' when discussing an issue and try to stay within scope of the issue at hand. The chairs or the document editors will copy relevant messages, or abstracts thereof to the issue tracker so that the gist of the discussion can be followed using the tracker. There may be a few days lag between the list and the tracker. The archive remains the authoritative log for the discussion. == Bouncing of issues The chairs may decide not to create a entry in the issue tracker if an issue does not relate to a working group document; the issue has already been discussed and the issue has been closed; if there is no proposed change or; if the issue is irrelevant to any of the working group documents. == Discussion of matters not in the issue tracker. Feel free to bring up matters that are not related to working group documents (but appropriate to the group); they do not need an issue tracking number. == Closing of issues. Chairs or document editors will close issues once resolved. In the tracking system a note will be made in which document version the issue was resolved. --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ---------------------------------------------------------------------- $Id: dnsext-list-policy.txt,v 1.4 2003/09/25 08:26:13 olaf Exp $ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 02 Mar 2004 00:24:45 -0500 Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0402251125200.26975@internaut.com> <18511.1077781197@munnari.OZ.AU> <Pine.LNX.4.56.0402260033240.9880@internaut.com> <20040226144216.GA7166@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba <aboba@internaut.com>, huitema@microsoft.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 02 06:35:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040226144216.GA7166@dns.net> (Andras Salamon's message of "Thu, 26 Feb 2004 16:42:16 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote: >> If there is to be a "compromise" I believe that it should be >> to set TTL=255 on responses and (optionally) check on the sender, while >> *always* setting TTL=1 on queries. > > Sounds reasonable to me. But now you're open to smurf attacks, where I send a LLMNR request to a responder, setting YOUR ip address as the source, and setting the TTL to make sure the packet arrives "properly". Or do we just not care about this? I can make sure you send the packet, and with TTL=255 the response will always make it back to the "sender" (which is YOUR ip address in this case). So, what is the threat(s) we're trying to solve? In particular, what threat does TTL=255 on responses actually solve? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: draft-ietf-dnsext-nsec-rdata-04 Date: Wed, 3 Mar 2004 20:08:54 +0900 (KST) Lines: 15 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 03 12:20:00 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> Precedence: bulk Status: O I've just submitted an updated version of this draft to the drafts editor. For those who want to read it now, you can find a copy (and a diff against -03) at the following location: http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.txt http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.wdiff jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: comment on NSEC RDATA format draft -04 Date: Thu, 4 Mar 2004 08:37:31 -0500 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 04 15:29:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The text states that there are no special TTL requirements for the NSEC RR. However, in the new DNSSECbis specs, we have the following suggestion for TTL values (records draft-07): The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308]. Minor difference since the above is a suggestion, and there are no real special requirements for the TTL. I think the NSEC data draft should include the above for consistancy. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:03:22 +0100 Lines: 143 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 15:15:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O Hello, being new to rfc2782, I have a number of questions. I would be grateful for any enlightenment anyone could provide. Regards Barry Desborough Barry.Desborough@wanadoo.fr SRV RR FORMAT >From rfc2782 page 2 "The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target" But rfc1035 page 29 describes the generic RR header as being NAME TYPE CLASS TTL RDLENGTH RDATA According to 1035, and assuming that 'SRV' refers to TYPE, (not specified in 2782), it seems that the SRV RR should be _Service._Proto.Name SRV Class TTL RDLENGTH Priority Weight Port Target where _Service._Proto.Name corresponds to NAME SRV is the TYPE (33) Class, TTL and RDLENGTH are 1035 standard and Priority Weight, Port and Target correspond to RDATA Q1) Which rfc is correct? Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? Could not the contents of Target have been be reported in the NAME field and the Target field be dispensed with? TARGET SELECTION >From page 3 of rfc2782 " ............................................ The following algorithm SHOULD be used to order the SRV RRs of the same priority: To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list. Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority." Let's say we have only two targets of the same priority, with weights 1 and 2. If the weights are ordered 1 then 2, then we have Wt Sum ----------- 1 1 2 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 1 1 2 2 2nd contact 2 2 1 1 This gives each target equal probability of being contacted first. If the weights are ordered 2 then 1, then we have Wt Sum ----------- 2 2 1 3 Outcomes are as follows Random number case 0 1 2 3 1st contact 2 2 2 1 2nd contact 1 1 1 2 The weight 2 target is contacted first with a probability of 3/4. Overall the probabilities for 1st contact are 3/8 and 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ _order_is_randomly_chosen_, but this is not specified. According to my reckoning, consistent, correct results are obtained if the random number is chosen to be between _ONE_ and the sum computed. Q3) Does anyone agree or disagree with this? If what is meant by 1st contact is the 1st successful attempt to find a Target, from whereupon this target's service is always used until it's TTL expiry or failure, then load sharing is only effected by different clients choosing different 1st contacts. On the other hand, if it means that a client which is a frequent, heavy user of a service client works down a sequence of targets to select which one provides the service next, all targets are selected with equal frequency. It seems to me that there is an assumption here that target contact selection from any particular client is very infrequent, and that load sharing occurs by virtue of different clients making 1st contact to different targets. In a system who's application makes frequent heavy of a service, service selection should be purely probabilistic based on the relative weights of the highest priority records available. Q4) Can anyone clarify this matter? Q5) Does anyone have any DNS SRV sniffer trace they could send directly to me to throw more light on the message format? (Please mail the group to say you have responded to this one, to save me being flooded!) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: bill <bmanning@karoshi.com> Subject: Re: comment on NSEC RDATA format draft -04 Date: Sat, 6 Mar 2004 06:57:33 -0800 (PST) Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:03:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: scottr@nist.gov (Scott Rose) In-Reply-To: <00bd01c401ed$d85320e0$b9370681@campus.nist.gov> from "Scott Rose" at Mar 04, 2004 08:37:31 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2. The > text states that there are no special TTL requirements for the NSEC RR. > However, in the new DNSSECbis specs, we have the following suggestion for > TTL values (records draft-07): > > The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL > field. This is in the spirit of negative caching [RFC2308]. > > Minor difference since the above is a suggestion, and there are no real > special requirements for the TTL. I think the NSEC data draft should > include the above for consistancy. > > Scott ack. this is a reasonable thing to do. --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 10:31:55 -0500 Lines: 54 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 16:41:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Barry Desborough <Barry.Desborough@wanadoo.fr> In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > From page 3 of rfc2782 > Compute the sum of the weights of those RRs, and with each RR > associate the running sum in the selected order. Then choose a > uniform random number between 0 and the sum computed > (inclusive) > Random number case 0 1 2 3 > 1st contact 1 1 2 2 > 2nd contact 2 2 1 1 You appear to be computing a random integer, rather than a random real number, as was intended. If you choose a random real number, you'll get the appropriate distribution (a server with weight 2 is chosen twice as often with a server of weight 1). I would have much preferred a statement which used random integers (which is something you can actually do on a computer), but the working group was having a little trouble coming up with an algorithm statement that actually worked, so we decided to go with one which we strongly believed was correct even if it wasn't very clear and which didn't translate easily into code. It's particularly galling to me that we didn't even state explicitly what kind of number is to be chosen (integer, rational, computable, real, complex...), and then we threw in this parenthetical note "(inclusive)" which actually has no effect on the outcome if real numbers are being chosen. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. Neither of these choices seems appropriate. The TTL only applies to the DNS data itself, not the processing of it, so it would be wrong to choose a server once and then stick with it until the TTL expires. It would also be wrong to walk the list of choices when making multiple successful contacts; the idea is to walk the list when making a single contact until you are successful, then throw the list away. The next time you make a contact, you should start all over again and choose a new contact order randomly according to the weights. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 19:08:47 +0200 Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:19:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <001001c40383$c996f850$643264c8@BARRYS2GDELL> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 03:03:22PM +0100, Barry Desborough wrote: > Here is the format of the SRV RR, whose DNS type code is 33: > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > NAME TYPE CLASS TTL RDLENGTH RDATA RFC1035 deals with the on-the-wire encoding, while the SRV text above seems to be related to the usual BIND-style zone file format. The examples in RFC 2782 bear this out. However, re-reading RFC 2782 and RFC 2052, I could not determine a definitive on-the-wire encoding of SRV records -- this seems to be undefined. Presumably, implementors have just looked at how BIND returns SRV records and gone with that. > According to 1035, and assuming that 'SRV' refers to TYPE, > (not specified in 2782), The section "Usage rules" mentions QTYPE=SRV, and there is further text the SRV RR, whose DNS type code is 33 and The IANA has assigned RR type value 33 to the SRV RR which seems to tie SRV to TYPE, although perhaps not very directly. > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? I tried to find an online deployment of SRV records to feed to tcpdump, but the closest I came was an SOA record for _tcp.microsoft.com (one of the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no appear to have _tcp subdomains. Does anyone actually have a deployment of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? I also tried to find the IANA assignments for the Service tags, as referred to in RFC 2782, and couldn't locate any. Have any actually been standardized? If so, a pointer would be appreciated! -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 12:29:42 -0500 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 18:40:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Andras Salamon <andras@dns.net> In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? We appear to have: _sip._tcp.mit.edu _sip._udp.mit.edu _sip._tcp.sipxchange.mit.edu _sip._udp.sipxchange.mit.edu _kerberos._udp.athena.mit.edu _kerberos-master._udp.athena.mit.edu _kerberos-adm._tcp.athena.mit.edu -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:37:28 +0000 Lines: 106 Sender: owner-namedroppers@ops.ietf.org References: <Barry.Desborough@wanadoo.fr> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:46:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from "Barry Desborough" <Barry.Desborough@wanadoo.fr> of "Sat, 06 Mar 2004 15:03:22 +0100." <001001c40383$c996f850$643264c8@BARRYS2GDELL> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > From rfc2782 page 2 > > "The format of the SRV RR > > Here is the format of the SRV RR, whose DNS type code is 33: > > _Service._Proto.Name TTL Class SRV Priority Weight Port Target" > > But rfc1035 page 29 describes the generic RR header as being > > NAME TYPE CLASS TTL RDLENGTH RDATA > ... > Q1) Which rfc is correct? both. rdlength is a protocol element describing rdata. the <rdlength,rdata> tuple is used to represent the rr data, which in this case is itself a tuple: <Priority,Weight,Port,Target>. in "dns master file" format as entered into zone files and as displayed by utilities such as "dig", rdlength is used to encode and decode the rr data but is never specified or displayed directly. > Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR? > Could not the contents of Target have been be reported in the NAME field > and the Target field be dispensed with? because the names of the servers capable of responding to requests may not have names equal or similar to the name of the service. this is analagous to MX records, where the target name can be a service provider even though the query name is that of a customer. > ... > Overall the probabilities for 1st contact are 3/8 and > 5/8 for target weights 1 and 2 respectively, _assuming_the_initial_ > _order_is_randomly_chosen_, but this is not specified. > > According to my reckoning, consistent, correct results are > obtained if the random number is chosen to be between > _ONE_ and the sum computed. > > Q3) Does anyone agree or disagree with this? it seems reasonable to me, but i didn't write that part of the rfc and i'm not sure i ever understood it. greg hudson's answer was that the numbers had to be real not integer, and this may indeed be the case. > If what is meant by 1st contact is the 1st successful attempt to > find a Target, from whereupon this target's service is always used > until it's TTL expiry or failure, then load sharing is only effected > by different clients choosing different 1st contacts. > > On the other hand, if it means that a client which is a frequent, > heavy user of a service client works down a sequence of targets > to select which one provides the service next, all targets > are selected with equal frequency. > > It seems to me that there is an assumption here that target contact > selection from any particular client is very infrequent, and that > load sharing occurs by virtue of different clients making 1st contact > to different targets. no, actually we contemplated a web-like service where an object and all of the sub-objects (such as images) mentioned in that object should ideally be fetched from the same server, in case that server was capable of opportunistic pipelining or prefetching. > In a system who's application makes frequent heavy of a service, > service selection should be purely probabilistic based on the relative > weights of the highest priority records available. > > Q4) Can anyone clarify this matter? we contemplated making "sticky-ness" or "re-use" a protocol element but we felt that the SRV algorythm was already beyond its complexity horizon. the right thing to do now is: remove that part of the spec and designate re-use as "requestor-specific local policy". > Q5) Does anyone have any DNS SRV sniffer trace they could send > directly to me to throw more light on the message format? (Please > mail the group to say you have responded to this one, to save me being > flooded!) ;; QUESTION SECTION: ;_kerberos._udp.vix.com. IN SRV ;; ANSWER SECTION: _kerberos._udp.vix.com. 3600 IN SRV 0 1 88 kerberos-0.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-1.vix.com. _kerberos._udp.vix.com. 3600 IN SRV 1 0 88 kerberos-2.vix.com. ;; AUTHORITY SECTION: vix.com. 3178 IN NS ns.lah1.vix.com. vix.com. 3178 IN NS ns.sql1.vix.com. vix.com. 3178 IN NS ns-ext.isc.org. ;; ADDITIONAL SECTION: ns.lah1.vix.com. 2429 IN A 204.152.188.234 ns.lah1.vix.com. 2429 IN AAAA 2001:4f8:2::9 ns.sql1.vix.com. 2429 IN A 204.152.184.135 ns.sql1.vix.com. 2429 IN AAAA 2001:4f8:3::9 ns-ext.isc.org. 3055 IN A 204.152.184.64 ns-ext.isc.org. 3057 IN AAAA 2001:4f8:0:2::13 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 18:48:11 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 19:53:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 06 Mar 2004 19:08:47 +0200." <20040306170847.GB24117@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > ... > RFC1035 deals with the on-the-wire encoding, while the SRV text > above seems to be related to the usual BIND-style zone file format. > The examples in RFC 2782 bear this out. However, re-reading RFC 2782 > and RFC 2052, I could not determine a definitive on-the-wire encoding > of SRV records -- this seems to be undefined. Presumably, implementors > have just looked at how BIND returns SRV records and gone with that. note that if BIND is shown to be wrong, we (isc) will of course fix it. > I tried to find an online deployment of SRV records to feed to tcpdump, > but the closest I came was an SOA record for _tcp.microsoft.com (one of > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > appear to have _tcp subdomains. Does anyone actually have a deployment > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? vix.com has no SRV-discovered services that use tcp as their transport. (presumably if we were a macintosh shop or a windows shop, we would?) _kerberos._udp.vix.com/IN/SRV has some data for you, though. > I also tried to find the IANA assignments for the Service tags, as > referred to in RFC 2782, and couldn't locate any. Have any actually > been standardized? If so, a pointer would be appreciated! here's the problem. SRV is experimental. 2052 was "snuck through" the ietf process when iesg's attention was focused elsewhere, and they got Really Angry about it when they found out. i've apologized, since mostly i was acting in ignorance and without malice, but it hasn't helped. so, in spite of the significant deployment of SRV in the community (like with the service discovery protocols currently shipped by microsoft and apple), SRV remains experimental. and as long as it's only experimental, iana's charter does not cover it. what we need to do is in two stages. first, iesg has to tell me how i can mend relations and achieve some kind of pardon for past SRV-related misdeeds. (perhaps a public apologia at an iesg plenary would suffice?) second, iana should create a registry of service identifiers, by importing the BSD file "/etc/services" and then periodically amending it for new standards -- and new standards should allocate a service name not just a default port number. i don't know how to do either of those things but that's the list, anyway. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Jarle Greipsland <jarle@uninett.no> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 20:01:52 +0100 (CET) Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:07:06 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net In-Reply-To: <20040306170847.GB24117@dns.net> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Precedence: bulk Status: O Andras Salamon <andras@dns.net> writes: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV > outside pseudo-DNS dynamic zones tied to DHCP servers? _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV -jarle -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Greg Hudson <ghudson@MIT.EDU> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 14:08:35 -0500 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:14:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> X-Mailer: Ximian Evolution 1.4.4 Precedence: bulk Status: O On Sat, 2004-03-06 at 13:48, Paul Vixie wrote: > here's the problem. SRV is experimental. 2052 was "snuck through" the > ietf process when iesg's attention was focused elsewhere, and they got > Really Angry about it when they found out. Your history seems to be omitting the part where we got RFC 2782 published as a proposed standard (with you as one of the authors). That one certainly wasn't snuck through the IESG; we got significant feedback about the static weighting system, among other things. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 06 Mar 2004 19:49:01 +0000 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <ghudson@MIT.EDU> X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 20:56:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Greg Hudson <ghudson@MIT.EDU> of "Sat, 06 Mar 2004 14:08:35 EST." <1078600115.9992.140.camel@error-messages.mit.edu> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > here's the problem. SRV is experimental. 2052 was "snuck through" the > > ietf process when iesg's attention was focused elsewhere, and they got > > Really Angry about it when they found out. > > Your history seems to be omitting the part where we got RFC 2782 > published as a proposed standard (with you as one of the authors). That > one certainly wasn't snuck through the IESG; we got significant feedback > about the static weighting system, among other things. indeed. i was thinking only of 2052 in my recounting. in that case there's nothing stopping someone from writing an rfc to immortalize /etc/services and making that file an iana database. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: David Shaw <dshaw@jabberwocky.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 6 Mar 2004 15:13:42 -0500 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 06 21:20:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Mail-Followup-To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <20040306170847.GB24117@dns.net> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (99% of Full) User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 07:08:47PM +0200, Andras Salamon wrote: > I tried to find an online deployment of SRV records to feed to > tcpdump, but the closest I came was an SOA record for > _tcp.microsoft.com (one of the authors of RFC 2782 was at > Microsoft). Neither vix.com or troll.no appear to have _tcp > subdomains. Does anyone actually have a deployment of SRV outside > pseudo-DNS dynamic zones tied to DHCP servers? _hkp._tcp.pgp.net to help find PGP keyservers. David -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sun, 7 Mar 2004 18:24:27 +0200 (EET) Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 03:29:30 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] Hi, [[ note: I'm not subscribed... ]] I took a quick look at the DNSSEC intro document; it was in a very good shape. Two major comments: 1) the document requires the use of EDNS0. However, current EDNS0 implementations typically advertise the larger sizes than they can handle at the IP layer, causing fragmentation. You can argue that this is OK as long as the result of NOT fragmenting would end up with a worse result than as you would be without it (e.g., requiring falling back to TCP, or whatever). With DNSSEC, I'm not sure that this holds anymore. It seems to me that the best behaviour would be to avoid IP fragmentation by having correct implementations of EDNS0, and if some data must be left out, that it would be fetched separately, over second, third, ..., nth query over UDP. Shouldn't that be possible and reasonable? 2) Security considerations lists a number of threats, but does not discuss whether they have been fixed or mitigated at all (e.g., relating to dynamic updates and signing). It might not hurt to be a bit more explicit on this. Similarly, maybe some of this text could be included in the DNS security analysis document as well... editorial --------- page 4, chapter 2, replace "RRsets forms" with "RRsets forming" -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 03:09:22 +0000 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 04:15:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Sun, 07 Mar 2004 18:24:27 +0200." <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). most of <http://research.compaq.com/wrl/techreports/abstracts/87.3.html>'s concerns about fragmentation have been addressed, and the ones which still apply are relevant to small-mtu connections ("don't do that") and to high performance/demand mobygram applications (nfs, tcp). for dns, it's okay. > With DNSSEC, I'm not sure that this holds anymore. It seems to me > that the best behaviour would be to avoid IP fragmentation by having > correct implementations of EDNS0, and if some data must be left out, > that it would be fetched separately, over second, third, ..., nth > query over UDP. Shouldn't that be possible and reasonable? no, that really would force tcp, which really would be worse than ip-frag. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 13:47:21 +0900 Lines: 26 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 05:55:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O Paul; > no, that really would force tcp, which really would be worse than ip-frag. If message size is 1400B or so, it is definitely so. If message size is 4200B or so, it can still be a valid argument. However, if message size is 64000B, TCP is far better than IP-frag. I understand the problem is not of DNSSEC but of EDNS0. But with the current EDNS0 specification lacking rational upper limit on message size, it will be safe if DNSSEC says: messages over UDP MUST NOT be larger than 4000 Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 05:02:50 +0000 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 06:08:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 13:47:21 +0900." <404BFAD9.80109@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > no, that really would force tcp, which really would be worse than ip-frag. > > If message size is 1400B or so, it is definitely so. > > If message size is 4200B or so, it can still be a valid argument. > > However, if message size is 64000B, TCP is far better than IP-frag. yes, that's true. the crossover is probably closer to 4*PMTU. > I understand the problem is not of DNSSEC but of EDNS0. > > But with the current EDNS0 specification lacking rational upper > limit on message size, it will be safe if DNSSEC says: > > messages over UDP MUST NOT be larger than 4000 it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E is for Estimated) but this isn't the time or place to make that change. so perhaps an advisory statement like "Note: advertising a buffer size larger than EPMTU could lead to unfortunate overaggressive IP fragmentation" would be enough to tell the dnssec implementor crowd -- who is likely to be the first real stress-testers of EDNS0's buffer size extension -- what they need to know, without actually amending the EDNS0 specification by side effect. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 14:58:13 +0900 Lines: 41 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:02:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >> messages over UDP MUST NOT be larger than 4000 > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out of scope. I meant DNSSEC entities MUST NOT send messages larger than 4000 over UDP Can it be within the scope of DNSSEC? > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU (where E > is for Estimated) but this isn't the time or place to make that change. If EDNS0 is to be changed (in the future, of course), reference to PMTUD should be clarified (removed entirely), because EDNS0 seemingly assumes fragmentation is always enabled, which means there is no room for PMTUD, which means, with IPv6, packets must be fragmented at the source. Or, if you think some form of PMTUD should be performed, it should be documented (though I think PMTUD practically impossible). > so perhaps an advisory statement like "Note: advertising a buffer size larger > than EPMTU could lead to unfortunate overaggressive IP fragmentation" would > be enough to tell the dnssec implementor crowd -- who is likely to be the > first real stress-testers of EDNS0's buffer size extension -- what they need > to know, without actually amending the EDNS0 specification by side effect. :-) Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:26:31 +0000 Lines: 49 Sender: owner-namedroppers@ops.ietf.org References: <pekkas@netcore.fi> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:33:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Pekka Savola <pekkas@netcore.fi> of "Mon, 08 Mar 2004 07:37:47 +0200." <Pine.LNX.4.44.0403080733160.16733-100000@netcore.fi> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... would force tcp, which really would be worse than ip-frag. > > Seems like a flaw in DNS spec -- too coarse granularity: > 1) "everything fits in one UDP datagram", or > 2) "just use TCP". > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > datagram of specific size, query again, but only the missing data this > time". sense, yes, but the atomicity requirements are hard to adjust in that light. for example, if what you're trying to send is a referral, and the query and authority sections are all that fits, and you decide to just send that much and let the initiator re-query for the parts that would have been in the additional-data section, then it might end up being the case that they can never query for it. consider an authority section whose names are all under the referral cut. in earlier work once proposed as part of EDNS0 and then reintroduced as EDNS1, the idea came up to indicate in a response that there were multiple messages in the answer. we called it MD ("more data"). ultimately this turned out to be a lot more complicated than it sounded, and it's since been abandoned. i dearly wish that EDNS0 had made TTCP its prerequisite. ("ah, hindsight.") > Not sure if that would make sense but instead of forcing everything in > one, probably fragmented message, it would seem to encourage "proper" > operation with big DNS replies. in general, if you think the response might be larger than 3*EPMTU, use tcp, and that will amortize the complexity nicely. note that PMTUD hasn't been a raging success, and that EPMTU is probably 1500 octets most of the time, and that's where masataka's "4000" number comes from. > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. yes but on such a host, the EDNS0 initiator would presumably be able to discover this limitation and advertise a 1500-octet buffer. that's what the EDNS0 spec says it should do, at any rate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 06:29:28 +0000 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 07:34:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Mon, 08 Mar 2004 14:58:13 +0900." <404C0B75.3000303@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > of scope. > > I meant > > DNSSEC entities MUST NOT send messages larger than 4000 > over UDP > > Can it be within the scope of DNSSEC? then it would be within scope for this docset, but extremely controversial since it places a requirement more stringent than EDNS0. far better to make it advisory and avoid the fight. > > perhaps we should reissue EDNS0 with a recommendation like 4*EPMTU > > (where E is for Estimated) but this isn't the time or place to make > > that change. > > If EDNS0 is to be changed (in the future, of course), reference to > PMTUD should be clarified (removed entirely), because EDNS0 seemingly > assumes fragmentation is always enabled, which means there is no room > for PMTUD, which means, with IPv6, packets must be fragmented at the > source. > > Or, if you think some form of PMTUD should be performed, it should be > documented (though I think PMTUD practically impossible). i think that you're right and that all hope of PMTUD should be abandoned in the next update of EDNS, which at this point would be EDNS1 rather than a reissue of EDNS0. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 10:11:02 +0100 Organization: NIC France Lines: 15 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <20040306.200152.46801952.jarle@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 10:22:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Jarle Greipsland <jarle@uninett.no> Content-Disposition: inline In-Reply-To: <20040306.200152.46801952.jarle@uninett.no> X-Operating-System: Debian GNU/Linux testing/unstable X-Kernel: Linux 2.4.25-1-k7 i686 X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.5.1+cvs20040105i Precedence: bulk Status: O On Sat, Mar 06, 2004 at 08:01:52PM +0100, Jarle Greipsland <jarle@uninett.no> wrote a message of 16 lines which said: > _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV Which is documented in: http://mailbox.univie.ac.at/~gw/draft-sanz-whois-srv-00.txt -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Subject: Re: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 11:10:08 +0100 Lines: 196 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <1078587114.9992.126.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C404FD.EAE798E0" Cc: "Attila" <Attila.Sipos@VegaStream.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 11:32:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Greg Hudson" <ghudson@MIT.EDU> 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 Precedence: bulk Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your help, Greg. There's a note below about selection using random integers. ----- Original Message -----=20 From: "Greg Hudson" <ghudson@MIT.EDU> To: "Barry Desborough" <Barry.Desborough@wanadoo.fr> Cc: <namedroppers@ops.ietf.org> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: DNS SRV Clarification sought > On Sat, 2004-03-06 at 09:03, Barry Desborough wrote: > > From page 3 of rfc2782 > > Compute the sum of the weights of those RRs, and with each = RR > > associate the running sum in the selected order. Then choose = a > > uniform random number between 0 and the sum computed > > (inclusive) > > > Random number case 0 1 2 3 > > 1st contact 1 1 2 2 > > 2nd contact 2 2 1 1 > > You appear to be computing a random integer, rather than a random real > number, as was intended. If you choose a random real number, you'll = get > the appropriate distribution (a server with weight 2 is chosen twice = as > often with a server of weight 1). > > I would have much preferred a statement which used random integers > (which is something you can actually do on a computer), but the = working > group was having a little trouble coming up with an algorithm = statement > that actually worked, so we decided to go with one which we strongly > believed was correct even if it wasn't very clear and which didn't > translate easily into code. Demonstration of selection using random integers. (Hope the fixed font is preserved and there's no line folding) Item Cumulative (weight) sum ---- -----=20 a a b a+b c a+b+c . . . . n a+b+c+...+n i.e.(sum(a...n)) Choosing a random integer between 1 and sum(a...n) inclusive and = selecting the first item greater than or equal to the random integer, we have - Random integer range 1...a a+1...a+b a+b+1...a+b+c Random integer frequency a (a+b)-(a+1)+1=3Db = (a+b+c)-(a+b+1)+1=3Dc Probability a/sum(a...n) b/sum(a...n) c/sum(a...n) For any item say, i, h being the previous item, Random integer range sum(a...h)+1...sum(a...i) Random integer frequency sum(a...i)-(sum(a...h)+1)+1=3Di Probability i/sum(a...n) Barry Desborough ------=_NextPart_000_0007_01C404FD.EAE798E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV>Thanks for your help, = Greg. There's a note=20 below about selection using random integers. ----- Original = Message -----=20 From: "Greg Hudson" <<A = href=3D"mailto:ghudson@MIT.EDU"><FONT=20 face=3DArial size=3D2>ghudson@MIT.EDU</A>> To:=20 "Barry Desborough" <<A = href=3D"mailto:Barry.Desborough@wanadoo.fr"><FONT=20 face=3DArial size=3D2>Barry.Desborough@wanadoo.fr</A>> Cc: <<A = href=3D"mailto:namedroppers@ops.ietf.org"><FONT=20 face=3DArial size=3D2>namedroppers@ops.ietf.org</A>> Sent: Saturday, 06 March, 2004 16:31 PM Subject: Re: = DNS SRV=20 Clarification sought > On Sat, 2004-03-06 at 09:03, Barry=20 Desborough wrote: > > From page 3 of rfc2782 >=20 > Compute the sum of = the=20 weights of those RRs, and with each RR >=20 > associate the = running sum=20 in the selected order. Then choose a >=20 > uniform random = number=20 between 0 and the sum computed >=20 > = (inclusive) > >=20 > Random number case 0 1 2 3 > > 1st=20 contact = =20 1 1 2 2 > > 2nd=20 contact = =20 2 2 1 1 > > You appear to be computing a random integer, = rather than=20 a random real > number, as was intended. If you choose a = random real=20 number, you'll get > the appropriate distribution (a server with = weight 2=20 is chosen twice as > often with a server of weight = 1). > > I=20 would have much preferred a statement which used random integers > = (which=20 is something you can actually do on a computer), but the working > = group=20 was having a little trouble coming up with an algorithm = statement > that=20 actually worked, so we decided to go with one which we strongly > = believed=20 was correct even if it wasn't very clear and which didn't > = translate=20 easily into code. Demonstration of = selection=20 using random integers. (Hope the fixed font is preserved and there's = no line=20 folding) Item =20 Cumulative</DIV> <DIV>(weight) =20 sum ---- -----=20 a =20 a b =20 a+b c =20 a+b+c . =20 . . =20 . n a+b+c+...+n = i.e.(sum(a...n)) Choosing a random integer between 1 and = sum(a...n)=20 inclusive and selecting the first item greater than or equal to the = random=20 integer, we have -</DIV> <DIV> Random integer=20 range =20 1...a =20 a+1...a+b = a+b+1...a+b+c Random=20 integer frequency =20 a =20 (a+b)-(a+1)+1=3Db =20 (a+b+c)-(a+b+1)+1=3Dc Probability &= nbsp; =20 a/sum(a...n) b/sum(a...n) = c/sum(a...n) For any=20 item say, i, h being the previous item,</DIV> <DIV> Random integer=20 range sum(a...h)+1...sum(a...i) Random = integer=20 frequency =20 sum(a...i)-(sum(a...h)+1)+1=3Di Probability &nb= sp; =20 i/sum(a...n) Barry Desborough </DIV></BODY></HTML> ------=_NextPart_000_0007_01C404FD.EAE798E0-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Scott Rose" <scottr@nist.gov> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:59:49 -0500 Organization: NIST Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "Pekka Savola" <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 16:39:05 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> 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 Precedence: bulk Status: O ----- Original Message ----- From: "Paul Vixie" <paul@vix.com> > > > it can't be a MUST NOT or it modifies the EDNS0 spec, which is out > > > of scope. > > > > I meant > > > > DNSSEC entities MUST NOT send messages larger than 4000 > > over UDP > > > > Can it be within the scope of DNSSEC? > > then it would be within scope for this docset, but extremely controversial > since it places a requirement more stringent than EDNS0. far better to make > it advisory and avoid the fight. > It would also be an arbitrary limit based on current underlying network layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or EDNS0. It would best not be made a strict constraint that might be made obsolete by non-DNS factors. I agree with Paul in that it would be better to be an advisory statement, but not necessary to the specification. Scott -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 19:10:10 +1100 Lines: 45 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 09:41:34 +0200." <Pine.LNX.4.44.0403080940330.18259-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > What's your issue here? > > > > IPv4 has reassembly buffer size limits. > > IPv6 has reassembly buffer size limits. > > > > In either case you don't advertise a EDNS UDP buffer bigger > > than this limit. > > It would be nice if EDNS0 implementations conformed to these buffer > sizes then. On what platforms do the existing implementation not take these into account. Note most *nix platforms support 4k UDP datagrams already. > Currently it seems they have zero relation to MTU or PMTU, or buffer > sizes. There doesn't have to be a *explict* relationship to these. The current recommendations already take these into account. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 07:37:47 +0200 (EET) Lines: 44 Sender: owner-namedroppers@ops.ietf.org References: <20040308030922.AB3E714C51@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:54 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308030922.AB3E714C51@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > With DNSSEC, I'm not sure that this holds anymore. It seems to me > > that the best behaviour would be to avoid IP fragmentation by having > > correct implementations of EDNS0, and if some data must be left out, > > that it would be fetched separately, over second, third, ..., nth > > query over UDP. Shouldn't that be possible and reasonable? > > no, that really would force tcp, which really would be worse than ip-frag. Seems like a flaw in DNS spec -- too coarse granularity: 1) "everything fits in one UDP datagram", or 2) "just use TCP". Would it make sense to add 1.5) there, "if it doesn't fit to a UDP datagram of specific size, query again, but only the missing data this time". Not sure if that would make sense but instead of forcing everything in one, probably fragmented message, it would seem to encourage "proper" operation with big DNS replies. Btw: note that IPv6 implementations aren't even required to defragment a datagram which is larger than 1500 bytes once assembled.. so we're in a bit murky waters here. I'd certainly want to try to avoid packet sizes >= ~1500. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 09:41:34 +0200 (EET) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <200403080658.i286wXcq013551@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:04:59 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080658.i286wXcq013551@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > What's your issue here? > > IPv4 has reassembly buffer size limits. > IPv6 has reassembly buffer size limits. > > In either case you don't advertise a EDNS UDP buffer bigger > than this limit. It would be nice if EDNS0 implementations conformed to these buffer sizes then. Currently it seems they have zero relation to MTU or PMTU, or buffer sizes. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 08 Mar 2004 17:58:33 +1100 Lines: 32 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Cc: Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:05:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 06:26:31 -0000." <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Btw: note that IPv6 implementations aren't even required to defragment > a datagram which is larger than 1500 bytes once assembled.. so we're > in a bit murky waters here. I'd certainly want to try to avoid packet > sizes >= ~1500. What's your issue here? IPv4 has reassembly buffer size limits. IPv6 has reassembly buffer size limits. In either case you don't advertise a EDNS UDP buffer bigger than this limit. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 10:08:33 -0600 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040306184811.B96C914C51@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:18:19 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Paul Vixie <paul@vix.com> In-Reply-To: <20040306184811.B96C914C51@sa.vix.com> Precedence: bulk Status: O On 3/6/2004 12:48 PM, Paul Vixie wrote: > iana should create a registry of service identifiers, by importing the > BSD file "/etc/services" and then periodically amending it for new > standards Is that really feasible? Service definitions may require weighting values and client-selection algorithms to be useful, all of which requires some level of agreement among implementors. If we start with a list of defaults and then update the list on-the-fly, how does the client know which version of the list entry is in use for those SRV RRs that they encounter? The nice thing about the current model is that an entry in the list connotes agreement among implementors, or at least carries a footnote. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 17:25:32 +0100 Lines: 43 Sender: owner-namedroppers@ops.ietf.org References: <404C9A81.2040708@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 17:34:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Mon, 08 Mar 2004 10:08:33 CST." <404C9A81.2040708@ehsco.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <26114.1078763131.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Eric A. Hall wrote: > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards which would be different from <http://www.iana.org/assignments/port-numbers>? > Is that really feasible? Service definitions may require weighting values What weighting values are you talking about? Those in the SRV RR are not supposed to carry any additional meaning. RFC 2782 is pretty clear about the service names to be used: Applicability Statement In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. [...] Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. STD 2 is obsoleted by RFC 3232, again pointing to the URL above (although rather indirectly). What may be missing is a list of services without portnumber. In the whois case mentioned earlier inthis thread (which, btw uses "nicname" instead of the more prominent "whois" because of the "Service" requirement cited above) one would sometimes like to further differentiate the service without really using a different protocol, e.g. _ripe_whois.tcp... -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:21:20 +0200 (EET) Lines: 42 Sender: owner-namedroppers@ops.ietf.org References: <200403080810.i288AAcq036874@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:24:57 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403080810.i288AAcq036874@drugs.dv.isc.org> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Mark Andrews wrote: > > It would be nice if EDNS0 implementations conformed to these buffer > > sizes then. > > On what platforms do the existing implementation not take > these into account. Note most *nix platforms support 4k > UDP datagrams already. I don't know, maybe some embedded systems have restrictions. In any case 4000 byte UDP buffers does not equal being able to defragment datagrams worth of 4000 bytes total, right? > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > sizes. > > There doesn't have to be a *explict* relationship to these. > The current recommendations already take these into account. Well, about all the implementations I've seen set the EDNS0 irrespective of the MTU or PMTU configured on the system, which might make sense. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Pekka Savola <pekkas@netcore.fi> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 8 Mar 2004 18:25:16 +0200 (EET) Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <20040308062631.C827814750@sa.vix.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 18:25:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308062631.C827814750@sa.vix.com> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mon, 8 Mar 2004, Paul Vixie wrote: > > > ... would force tcp, which really would be worse than ip-frag. > > > > Seems like a flaw in DNS spec -- too coarse granularity: > > 1) "everything fits in one UDP datagram", or > > 2) "just use TCP". > > > > Would it make sense to add 1.5) there, "if it doesn't fit to a UDP > > datagram of specific size, query again, but only the missing data this > > time". > > sense, yes, but the atomicity requirements are hard to adjust in that light. Precisely -- but IMHO we need to figure out whether such atomicity requirements exist. They very certainly exist with 512 byte limit and DNSSEC. But do they exist e.g., with 1400 bytes? I'm a bit doubtful.. but I'd be interested in hearing what might be a "typical case", a "bad case", and "worst case". (We'll never be able to handle the last one, of course.) > > Not sure if that would make sense but instead of forcing everything in > > one, probably fragmented message, it would seem to encourage "proper" > > operation with big DNS replies. > > in general, if you think the response might be larger than 3*EPMTU, use tcp, > and that will amortize the complexity nicely. note that PMTUD hasn't been a > raging success, and that EPMTU is probably 1500 octets most of the time, and > that's where masataka's "4000" number comes from. Yep, EPMTU is 1500 bytes or a bit less -- but isn't that sufficient for about all intents and purposes? > > Btw: note that IPv6 implementations aren't even required to defragment > > a datagram which is larger than 1500 bytes once assembled.. so we're > > in a bit murky waters here. I'd certainly want to try to avoid packet > > sizes >= ~1500. > > yes but on such a host, the EDNS0 initiator would presumably be able to > discover this limitation and advertise a 1500-octet buffer. that's what > the EDNS0 spec says it should do, at any rate. Should, yes :). Does, no. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Eric A. Hall" <ehall@ehsco.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 12:03:05 -0600 Lines: 40 Sender: owner-namedroppers@ops.ietf.org References: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:10:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: namedroppers@ops.ietf.org In-Reply-To: <200403081625.i28GPWj26118@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O On 3/8/2004 10:25 AM, Peter Koch wrote: > Eric A. Hall wrote: >> Is that really feasible? Service definitions may require weighting >> values > > What weighting values are you talking about? Those in the SRV RR are > not supposed to carry any additional meaning. The 'priority' field is different from the 'weight' field. RFC2782 says the following about the weight: | In the absence of a protocol whose specification calls for the | use of other weighting information, a client arranges the SRV | RRs of the same Priority in the order in which target hosts, | specified by the SRV RRs, will be contacted. > RFC 2782 is pretty clear about the service names to be used: Well, that's not the whole ball of wax. Service names can vary for reasosn other than protocol (http != www). Service names are relative labels which do not describe behavioral rules which may be associated with the service in general (algorithm may require SRV for in-addr space, or domain-wide space, or host-specific maps). Etc. Really, it seems to me that it's best to leave the list of well-known definitions for those SRV mappings and algorithms which are actually defined by the affected community. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: <fenner@research.att.com> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 03:47:36 +0900 Lines: 22 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 19:54:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: pk@TechFak.Uni-Bielefeld.DE Versions: dmail (solaris) 2.5a/makemail 2.9d Precedence: bulk Status: O >> > iana should create a registry of service identifiers, by importing the >> > BSD file "/etc/services" and then periodically amending it for new >> > standards > >which would be different from ><http://www.iana.org/assignments/port-numbers>? Actually, I always thought that RFC 2782's [STD 2] reference was to the "PROTOCOL AND SERVICE NAMES" section, aka <http://www.iana.org/assignments/service-names>, and people who looked for the names in port-numbers were confused by the lack of strong binding to the reference (since there's no strong requirement for a port number assignment, just a name). Bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 08 Mar 2004 20:32:14 +0100 Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 20:39:02 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Tue, 09 Mar 2004 03:47:36 +0900." <200403081847.i28IlbS24713@windsor.research.att.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <27142.1078774333.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Bill Fenner wrote: > was to the "PROTOCOL AND SERVICE NAMES" section, aka > <http://www.iana.org/assignments/service-names>, and people who looked this teaches us that the registry name will need to be specified explicitly, especially since URL references to the IANA registries are (were when I tried) only allowed to point to http://www.iana.org/numbers.html. > for the names in port-numbers were confused by the lack of strong binding Thanks, and increase the number of confused :-) > to the reference (since there's no strong requirement for a port number > assignment, just a name). The document you mention references WKS RRs, and since SRV is an orthogonal, though not totally unrelated, concept, it may be useful to use the same registry. However, since WKS uses port numbers (in a bit string) on-the-wire, I'm not too sure I understand the reasoning behind a registry dealing with names *only*. What's more important is some kind of link to the spec describing a) the protocol and b) use of SRV RRs in connection with that protocol. Elevation of 2782 will give us an opportunity to clarify this. -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 05:41:18 +1100 Lines: 60 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 21:19:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Pekka Savola <pekkas@netcore.fi> In-reply-to: Your message of "Mon, 08 Mar 2004 18:21:20 +0200." <Pine.LNX.4.44.0403081819030.25661-100000@netcore.fi> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > On Mon, 8 Mar 2004, Mark Andrews wrote: > > > It would be nice if EDNS0 implementations conformed to these buffer > > > sizes then. > > > > On what platforms do the existing implementation not take > > these into account. Note most *nix platforms support 4k > > UDP datagrams already. > > I don't know, maybe some embedded systems have restrictions. Well if you are writing a resolver for such a system you take its IP stack limitations into consideration. There are lots of additional considerations when writing for small memory platforms. Nobody is saying you *MUST* use certain size, just that they are recommended. Named has a switch to set the advertised size to 512. > In any case 4000 byte UDP buffers does not equal being able to > defragment datagrams worth of 4000 bytes total, right? > > > > Currently it seems they have zero relation to MTU or PMTU, or buffer > > > sizes. > > > > There doesn't have to be a *explict* relationship to these. > > The current recommendations already take these into account. > > Well, about all the implementations I've seen set the EDNS0 > irrespective of the MTU or PMTU configured on the system, which might > make sense. With the current Internet the min(MTU,PMTU) will usually be 1500, ethernet/ppp default. Rarely will it be below 1200, slip default. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 8 Mar 2004 13:17:05 -0800 Lines: 76 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 08 22:23:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Eric A. Hall'" <ehall@ehsco.com>, Paul Vixie <paul@vix.com> X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O Registies are over-rated. Look at the number of programs there are on windows that have their own file format. Important name collisions are pretty rare considering that it is essentially a 3 character identifier. All that matters here is that the identifier be unique and plentiful enough that they do not run out. If you try to impose any requirement that is more stringent than first come first served we end up back with the X-Header problem. We could adopt the hash-cash scheme that Microsoft is pushing for anti-spam as a way of rationing code points in tables. All code points are first come first served. To get the code point 'SPAM' in table 'SRV' you have to provide a string s such that SHA1(s) - SHA1('SPAM+SRV') <> 0 AND |SHA1(s) - SHA1('SPAM+SRV')| < 2^(160-n) I.e. the strings must not be the same and the first n bits must match. The value of n would increase as the code points in the registry were exhausted. > -----Original Message----- > From: owner-namedroppers@ops.ietf.org > [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of Eric A. Hall > Sent: Monday, March 08, 2004 11:09 AM > To: Paul Vixie > Cc: namedroppers@ops.ietf.org > Subject: Re: DNS SRV Clarification sought > > > > On 3/6/2004 12:48 PM, Paul Vixie wrote: > > > iana should create a registry of service identifiers, by > importing the > > BSD file "/etc/services" and then periodically amending it for new > > standards > > Is that really feasible? Service definitions may require > weighting values > and client-selection algorithms to be useful, all of which > requires some > level of agreement among implementors. > > If we start with a list of defaults and then update the list > on-the-fly, > how does the client know which version of the list entry is in use for > those SRV RRs that they encounter? > > The nice thing about the current model is that an entry in the list > connotes agreement among implementors, or at least carries a footnote. > > -- > Eric A. Hall > http://www.ehsco.com/ > Internet Core Protocols > http://www.oreilly.com/catalog/coreprot/ > > -- > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:02:38 +0900 Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <20040308062928.A818E14C73@sa.vix.com> <000301c40521$f3ba77c0$1a1f0681@lapdancer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:08:18 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Scott Rose <scottr@nist.gov> In-Reply-To: <000301c40521$f3ba77c0$1a1f0681@lapdancer> Precedence: bulk Status: O Scott Rose; > It would also be an arbitrary limit based on current underlying network > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > EDNS0. 512 byte limit is a bound not by DNS but by the current underlying network and transport layers. So? > but not necessary to the specification. It is necessary that DNS message size has a limit in the specification. Masataka Ohta PS The proper limit bound by minimum reassembly buffer size, maximum IP header length and UDP header length is 508. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 08:46:37 +0900 Lines: 21 Sender: owner-namedroppers@ops.ietf.org References: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 00:51:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403082335.i28NZOcq081725@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > Why are we arguing about the minimums that have to be > supported by the architecure? Because the minimums of the infrastructure are maximums of DNS. > For example, named has a upper bound on the size of the > EDNS/UDP response it will send. And, it should be specified. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 09:38:11 +0900 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 02:44:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Mark Andrews <Mark_Andrews@isc.org> In-Reply-To: <200403090023.i290Nhcq082341@drugs.dv.isc.org> Precedence: bulk Status: O Mark Andrews; > EDNS and DNS are *different* protocols which share a port and > message format. RFC2671 This document describes backward compatible mechanisms for allowing the protocol to *GROW*. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNS SRV Clarification sought Date: Tue, 9 Mar 2004 09:13:19 +0100 Organization: RIPE NCC Lines: 31 Sender: owner-namedroppers@ops.ietf.org References: <001001c40383$c996f850$643264c8@BARRYS2GDELL> <20040306170847.GB24117@dns.net> <1078594181.9992.134.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: andras@dns.net, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 09:26:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Greg Hudson <ghudson@MIT.EDU> In-Reply-To: <1078594181.9992.134.camel@error-messages.mit.edu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.473609 / 0.0 / 0.0 X-RIPE-Signature: 86a7b34adf4294872cd6cf962183ce6b Precedence: bulk Status: O On Sat, 06 Mar 2004 12:29:42 -0500 Greg Hudson <ghudson@MIT.EDU> wrote: > On Sat, 2004-03-06 at 12:08, Andras Salamon wrote: > > I tried to find an online deployment of SRV records to feed to tcpdump, > > but the closest I came was an SOA record for _tcp.microsoft.com (one of > > the authors of RFC 2782 was at Microsoft). Neither vix.com or troll.no > > appear to have _tcp subdomains. Does anyone actually have a deployment > > of SRV outside pseudo-DNS dynamic zones tied to DHCP servers? > > We appear to have: > > _sip._tcp.mit.edu > _sip._udp.mit.edu > _sip._tcp.sipxchange.mit.edu > _sip._udp.sipxchange.mit.edu Where the use of SRV for SIP is documented in RFC3263 -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 11:23:43 +1100 Lines: 58 Sender: owner-namedroppers@ops.ietf.org References: <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:46:37 +0900." <404D05DD.2080402@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Mark Andrews; > > > Why are we arguing about the minimums that have to be > > supported by the architecure? > > Because the minimums of the infrastructure are maximums of DNS. We are talking about EDNS. Nobody is thinking about changing the DNS UDP message size. The DNS is constained in this way, EDNS is not. EDNS and DNS are *different* protocols which share a port and message format. EDNS has a UDP request size limit of 512 bytes (inherited from DNS) unless you have reason to believe a larger request can be handled. e.g. you have just made a request and have been told that a bigger request can be handled. EDNS has a *negotiated* response size limit. This is IP stack dependent and will usually be *bigger* than the infrastructure minimums. It can also be smaller the the infrastructure minimums. e.g. you have a IPv6 firewall which is rejecting DNS packets > 512 bytes so you set the EDNS UDP size advertised to 512. The advertised EDNS UDP size is less than the minimum supported by the IPv6. DNS has a UDP request and response size limit of 512 bytes. > > For example, named has a upper bound on the size of the > > EDNS/UDP response it will send. > > And, it should be specified. Why. This is a *implemtation* limit not a *protocol* limit. RFC 2671 already has guidance for seting this limit. > > Masataka Ohta > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mark Andrews <Mark_Andrews@isc.org> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 09 Mar 2004 10:35:24 +1100 Lines: 59 Sender: owner-namedroppers@ops.ietf.org References: <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Cc: Scott Rose <scottr@nist.gov>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 16:42:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Tue, 09 Mar 2004 08:02:38 +0900." <404CFB8E.4080409@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] > Scott Rose; > > > It would also be an arbitrary limit based on current underlying network > > layers. The 4000 byte limit is not really a bound by DNS (with DNSSEC) or > > EDNS0. > > 512 byte limit is a bound not by DNS but by the current underlying > network and transport layers. > > So? > > > but not necessary to the specification. > > It is necessary that DNS message size has a limit in the specification. > > Masataka Ohta > > PS > > The proper limit bound by minimum reassembly buffer size, maximum > IP header length and UDP header length is 508. Why are we arguing about the minimums that have to be supported by the architecure? EDNS is about letting the the other end knowing what you are *capable of handling*. There is *nothing* in to stop a site sending *smaller* EDNS/UDP message than the receiving site is capable of handling. If the client says it can accept a 4k response but you know that your firewall is broken (e.g. drops DNS packets > 512) you are quite entitled to only send a 512 byte EDNS/UDP responses. Set TC as appropriate. For example, named has a upper bound on the size of the EDNS/UDP response it will send. You can advertise a 64k UDP buffer all you want but you will not get more that 4k EDNS/UDP response. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Tue, 9 Mar 2004 17:04:26 +0100 Organization: RIPE NCC Lines: 28 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Tue Mar 09 17:12:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> In-Reply-To: <Pine.LNX.4.44.0403071816180.4334-100000@netcore.fi> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.456200 / 0.0 / 0.0 X-RIPE-Signature: 61983aa15b37f75c7f5207c40c99cbab Precedence: bulk Status: O > 1) the document requires the use of EDNS0. However, current EDNS0 > implementations typically advertise the larger sizes than they can > handle at the IP layer, causing fragmentation. You can argue that > this is OK as long as the result of NOT fragmenting would end up with > a worse result than as you would be without it (e.g., requiring > falling back to TCP, or whatever). It seems there _could_ be consensus for an advisory note targeted at implementors, if only there were such a note. Can somebody please come up with text that can be put into the document set so we can focus on getting that correct and the editors can cut-n-paste. Let us not try to fix EDNS0, that is not in scope. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: Q-23 Direct NSEC queries; specs for resolvers and servers. Date: Wed, 10 Mar 2004 17:58:37 +0100 Organization: RIPE NCC Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <20040128203233.08EE614C52@sa.vix.com> <6.0.3.0.2.20040212231103.02da4b80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 18:11:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040212231103.02da4b80@localhost> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.000719 / 0.0 / 0.0 X-RIPE-Signature: 022e6963a054024de5098a486a89bbd4 Precedence: bulk Status: O > While attempting to summarize what the consensus of the working group > is on this editors question and trying to interpret this block of text. > Does self-consistently apply to a name or the holy Q-trinity? Having reread the threat I think that the answer to Olafurs question was in the proposed text (only for the _security_ RRs so only for specific holy Q-trinities :-) ). I propose the editors use Paul's initial text with the clarification that this only applies to those _security_ RRs that can exist above and below a delegation point. e.g. like: security aware responders who receive queries security RRs (NSEC or RRSIG RRs) which match the content of more than one zone, for example above and below a delegation point, are encouraged to behave self-consistently, which could mean: always return an error; always return above-delegation records; always return below-delegation records; always return no records; always return both above- and below-delegation records; or always something else entirely. We'll consider this question resolved if no further comments are received before the end of the week. -- Olaf -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-04.txt Date: Wed, 10 Mar 2004 15:40:37 -0500 Lines: 86 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 10 21:48:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-04.txt Pages : 9 Date : 2004-3-10 This document redefines the wire format of the A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-10150158.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:34:09 -0500 Lines: 50 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 16:43:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org Precedence: bulk Status: O The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf >Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >From: Derek Atkins <derek@ihtfp.com> >Date: Tue, 24 Feb 2004 22:14:43 -0500 > >It sounds like you want two things here, but it also sounds like all >of them need to happen in the responder. The attacker could >theoretically send packets of any type, with any TTL. So you can't >trust anything you receive from the network. To this affect, I think: > >1) We want the responder to try to determine that a request came from > the local network. The best way to do this is for the responder to > check that TTL=255 to make sure. If a TTL is less than 255 then it > originiated off-net and can be dropped. > >2) We want the responder to make sure response packets don't go > off-net. In other words, we want the responder to respond with > TTL=1, to make sure it can't smurf. > >So, to this affect: > >a) an LLMNR requestor should send requests with TTL=255 >b) an LLMNR responder should verify requests have TTL=255 -- if it is not > 255 then it should drop the packet. >c) an LLMNR responder should respond with TTL=1 >d) I dont' think an LLMNR requestor needs to check the response TTL. > >The only issue this doesn't directly solve is a requester being >spoofed by an off-net attacker, but said attacker would need >to guess the transaction id of the request in order to send a >valid response, which is just as likely in LLMNR as it is in >standard DNS, so it can probably be ignored. > >So, other than this issue, does this solve the issue? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Thu, 11 Mar 2004 10:52:56 -0800 Lines: 161 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--207754511; protocol="application/pkcs7-signature" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 11 20:04:34 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> To: =?ISO-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-8--207754511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have an issue with this. Using a TTL of 255 to verify that requests originate from the local=20 link is not very important. It may be useful to use a unicast query to=20= specific address from off of the local link to ask for records such as=20= HINFO. In the case of multicast, unless something is seriously broken a=20= link-local multicast packet is not going to be forwarded. Setting the TTL to 1 also unnecessarily prohibits unicast=20 request/responses from off of the local link. I would consider it more=20= useful to verify that a response to a link-local multicast came from=20 the local link. To those who are concerned that setting the TTL to 255 on a response=20 would enable another smurf attack, I would encourage them to try=20 pinging the all hosts multicast address. Most hosts will respond to=20 such a ping. This has not lead to any serious problems. The solution to=20= the smurf attack was to drop the subnet broadcast packets in routers=20 (don't forward them). A link local multicast packet will not be=20 forwarded. The defense against the smurf style attack is already=20 implemented. Hosts still respond to pings with subnet broadcasts but=20 routers never forward such packets, so this is only a local=20 vulnerability. If someone is local they could just as easily spoof the=20= source address of their packets as any of the other devices on the=20 local network. If the whole point of changing the TTL is to achieve interoperability=20 with Rendezvous, then the proposal below fails. -josh On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > > The chairs are looking for closure and rough consensus on this only > remaining issue for LLMNR. > The solution below seems like a good solid compromise. > Is there any technical reason why this should not be adopted, please > state so before March 24'th. > > Olafur & Olaf > > >> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >> From: Derek Atkins <derek@ihtfp.com> >> Date: Tue, 24 Feb 2004 22:14:43 -0500 >> >> It sounds like you want two things here, but it also sounds like all >> of them need to happen in the responder. The attacker could >> theoretically send packets of any type, with any TTL. So you can't >> trust anything you receive from the network. To this affect, I = think: >> >> 1) We want the responder to try to determine that a request came from >> the local network. The best way to do this is for the responder = to >> check that TTL=3D255 to make sure. If a TTL is less than 255 then = it >> originiated off-net and can be dropped. >> >> 2) We want the responder to make sure response packets don't go >> off-net. In other words, we want the responder to respond with >> TTL=3D1, to make sure it can't smurf. >> >> So, to this affect: >> >> a) an LLMNR requestor should send requests with TTL=3D255 >> b) an LLMNR responder should verify requests have TTL=3D255 -- if it = is=20 >> not >> 255 then it should drop the packet. >> c) an LLMNR responder should respond with TTL=3D1 >> d) I dont' think an LLMNR requestor needs to check the response TTL. >> >> The only issue this doesn't directly solve is a requester being >> spoofed by an off-net attacker, but said attacker would need >> to guess the transaction id of the request in order to send a >> valid response, which is just as likely in LLMNR as it is in >> standard DNS, so it can probably be ignored. >> >> So, other than this issue, does this solve the issue? > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org = with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/namedroppers/> --Apple-Mail-8--207754511 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxMTE4NTI1N1owIwYJKoZIhvcNAQkEMRYEFP0O Ia3W8w/x+47YEoXcV/9pDyndMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAApn zOCUjtzfx/HePoVrW9B92akgPc+74/dwmULkkUhYbv/Iw+gASUnplhFK3mz62o1NZYRGb4RuHmjx ar1KWlU8rIl3QoCNBqY8q3QISGI2oApMtnVXMf0abz/IST8hTndYl02br+7iXmDdyNuUrYQmjRyt QYIV3JUzV7Q8UOBiRwPRYuSeiDvJEsCd1h5IMExVNZOBjD69fu3oMK5bVq3gHNPQyKl59BSFkJlE 3w89yzOFPI67eeDhzDVEraXIW8w04oNM6AkzxjJwNugRReSSZAe635ZDBiMFzowtQf7pdNqpSN7c Jr0s0lkNZg2K8rc+5ALBd7MpnTMj44AxUt4AAAAAAAA= --Apple-Mail-8--207754511-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Fri, 12 Mar 2004 11:37:19 -0500 Lines: 46 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 17:49:08 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040228124513.02f35bc8@localhost> References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> Precedence: bulk Status: O At 13:00 2004-02-28, =D3lafur Gudmundsson/DNSEXT co-chair wrote: >This RFC was published about 6 months ago so it is now a candidate to >advance through he standards track. >In order to do that we need > evidence of implementation, > interoperabilty test and report. Jakob Schlyter <jakob@rfc.se> has stepped up and will coordinate the interoperabilty testing and write the report. (Thanks Jakob) He needs help from vendors in identifying support, please contact him to participate in the testing. Jakob and I will be contacting some vendors privately asking explicit questions of support and if they want to participate. Even though IETF rules say only two implementation are needed for the interoperabilty test, the chairs would like to include as many as possible. One important reason is the impact RFC3597 support has on the introduction of new RR types. The interoperabilty testing will address all types of DNS functional units: - Authorative servers (primary and secondary) - Recursive Resolvers (including Caches) - Stub Resolvers - Diagnostic tools The standard IETF interoperabilty rules will apply - List of implementations tested will be provided - Any problem identified will be examined to see if the source of the problem is the documentation - There will be NO public disclosure of what implementations had problems only a list of the problems. The goal here is twofold, advance a better document, allow vendors to address any problems identified sooner than later. Olafur (co-chair). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Fri, 12 Mar 2004 15:28:27 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 21:40:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-12152206.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Derek Atkins <derek@ihtfp.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Fri, 12 Mar 2004 16:56:27 -0500 Lines: 138 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?q?=D3lafur_Gudmundsson=2FDNSEXT_co-chair?= <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 12 23:08:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <4F82A994-738D-11D8-8FD1-000A95B9474C@apple.com> (Joshua Graessley's message of "Thu, 11 Mar 2004 10:52:56 -0800") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) Precedence: bulk Status: O Hi, Joshua Graessley <jgraessley@apple.com> writes: > Using a TTL of 255 to verify that requests originate from the local > link is not very important. It may be useful to use a unicast query to > specific address from off of the local link to ask for records such as > HINFO. In the case of multicast, unless something is seriously broken > a link-local multicast packet is not going to be forwarded. It's exactly the fact that it's useful in a unicast query that we should do it. You are correct, multicast doesn't care, so we should use the TTL value that gives us the most bang for the buck. What does it hurt us to use TTL=3D255 and verifying it? In neither case does it hurt us. Yes, requests could leave the network, but the responder would drop them (as it should -- it's not link-local!) > Setting the TTL to 1 also unnecessarily prohibits unicast > request/responses from off of the local link. I would consider it more > useful to verify that a response to a link-local multicast came from > the local link. Indeed, this prohibition is EXACTLY WHAT WE WANT! It's not unnecessary. It's a requirement! > To those who are concerned that setting the TTL to 255 on a response > would enable another smurf attack, I would encourage them to try > pinging the all hosts multicast address. Most hosts will respond to > such a ping. Just because a problem exists in another protocol and isn't majorly exploited now does not mean that we should make the same mistake. People HAVE used DNS as a smurf/explosion attack. Pings aren't interesting -- the response is no larger than the request. DNS is VERY interesting, because I could potentially get a LARGE response for a small request. Therefore, we should protect against it. > This has not lead to any serious problems. The solution > to the smurf attack was to drop the subnet broadcast packets in > routers (don't forward them). A link local multicast packet will not > be forwarded. The defense against the smurf style attack is already > implemented. Hosts still respond to pings with subnet broadcasts but > routers never forward such packets, so this is only a local > vulnerability. If someone is local they could just as easily spoof the > source address of their packets as any of the other devices on the > local network. This type of defence does not protect against unicast LLMNR requests. Sure, a properly configured multicast router can stop the multicase requests, but it wont stop the unicast packets. That's yet another reason we should use TTL=3D1 on responses, to make sure unicast messages can't smurf. > If the whole point of changing the TTL is to achieve interoperability > with Rendezvous, then the proposal below fails. No, the whole point of this proposal is to get us out of the deadlock that we've been in by showing how we can use TTLs to get the most bang for the buck. I've listed all the threats that I think we're worried about and I've shown how the largest set of threats can be mitigated by the combined 255/1 TTL. If we can get Apple to move along with us and interoperate, great. But this proposal is not "let's make this look like Rendevous". > -josh So, Olaf and Olafur, I obviously have no technical reason why this should not be adopted ;) -derek > On Mar 11, 2004, at 7:34 AM, =D3lafur Gudmundsson/DNSEXT co-chair wrote: > >> >> The chairs are looking for closure and rough consensus on this only >> remaining issue for LLMNR. >> The solution below seems like a good solid compromise. >> Is there any technical reason why this should not be adopted, please >> state so before March 24'th. >> >> Olafur & Olaf >> >> >>> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal >>> From: Derek Atkins <derek@ihtfp.com> >>> Date: Tue, 24 Feb 2004 22:14:43 -0500 >>> >>> It sounds like you want two things here, but it also sounds like all >>> of them need to happen in the responder. The attacker could >>> theoretically send packets of any type, with any TTL. So you can't >>> trust anything you receive from the network. To this affect, I think: >>> >>> 1) We want the responder to try to determine that a request came from >>> the local network. The best way to do this is for the responder to >>> check that TTL=3D255 to make sure. If a TTL is less than 255 then it >>> originiated off-net and can be dropped. >>> >>> 2) We want the responder to make sure response packets don't go >>> off-net. In other words, we want the responder to respond with >>> TTL=3D1, to make sure it can't smurf. >>> >>> So, to this affect: >>> >>> a) an LLMNR requestor should send requests with TTL=3D255 >>> b) an LLMNR responder should verify requests have TTL=3D255 -- if it >>> is not >>> 255 then it should drop the packet. >>> c) an LLMNR responder should respond with TTL=3D1 >>> d) I dont' think an LLMNR requestor needs to check the response TTL. >>> >>> The only issue this doesn't directly solve is a requester being >>> spoofed by an off-net attacker, but said attacker would need >>> to guess the transaction id of the request in order to send a >>> valid response, which is just as likely in LLMNR as it is in >>> standard DNS, so it can probably be ignored. >>> >>> So, other than this issue, does this solve the issue? >> >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: <http://ops.ietf.org/lists/namedroppers/> --=20 Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:27:07 +0900 Lines: 24 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:35:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040308050250.7E53114C73@sa.vix.com> Precedence: bulk Status: O Paul; >>>no, that really would force tcp, which really would be worse than ip-frag. >> >>If message size is 1400B or so, it is definitely so. >> >>If message size is 4200B or so, it can still be a valid argument. >> >>However, if message size is 64000B, TCP is far better than IP-frag. > yes, that's true. the crossover is probably closer to 4*PMTU. Given 1280B of IPv6 minimum MTU, shouldn't message size limitation be somewhere around 3600 or 4800, but not 4000? Masagtaka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 08:48:52 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <20040308050250.7E53114C73@sa.vix.com> <4052474B.9010306@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org, Pekka Savola <pekkas@netcore.fi> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 00:56:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> In-Reply-To: <4052474B.9010306@necom830.hpcl.titech.ac.jp> Precedence: bulk Status: O I wrote: >>yes, that's true. the crossover is probably closer to 4*PMTU. > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? My guess is that current specification of 4000B expects 3 frags over IPv4 that it should be 3600B for IPv6. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: Fwd: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 09:35:59 +0900 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 01:53:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: namedroppers@ops.ietf.org In-Reply-To: <6.0.3.0.2.20040311102716.02bdb8c8@localhost> Precedence: bulk Status: O From: Derek Atkins <derek@ihtfp.com> >> 1) We want the responder to try to determine that a request came from >> the local network. No, we don't. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Sat, 13 Mar 2004 00:58:15 +0000 Lines: 12 Sender: owner-namedroppers@ops.ietf.org References: <mohta@necom830.hpcl.titech.ac.jp> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 02:06:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> of "Sat, 13 Mar 2004 08:27:07 +0900." <4052474B.9010306@necom830.hpcl.titech.ac.jp> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > yes, that's true. the crossover is probably closer to 4*PMTU. > > Given 1280B of IPv6 minimum MTU, shouldn't message size limitation > be somewhere around 3600 or 4800, but not 4000? i think it's all very approximate and 4000 is a very fine and round number. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Andras Salamon <andras@dns.net> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 15:09:22 +0200 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <200403081847.i28IlbS24713@windsor.research.att.com> <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 14:28:47 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Content-Disposition: inline In-Reply-To: <200403081932.i28JWEp27144@grimsvotn.TechFak.Uni-Bielefeld.DE> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Mon, Mar 08, 2004 at 08:32:14PM +0100, Peter Koch wrote: > Bill Fenner wrote: > > was to the "PROTOCOL AND SERVICE NAMES" section, aka > > <http://www.iana.org/assignments/service-names>, and people who looked > > this teaches us that the registry name will need to be specified explicitly, > especially since URL references to the IANA registries are (were when I tried) > only allowed to point to http://www.iana.org/numbers.html. RFC 3232 makes reference to http://www.iana.org/ which in turn makes a reference to http://www.iana.org/numbers.html but then the trail gets cold. There are several potential documents that could be relevant, for instance either http://www.iana.org/assignments/port-numbers (this is the classic /etc/services document we have all been using as a reference, but isn't obviously tied in to DNS) or http://www.iana.org/assignments/service-names (which could be relevant since it is explicitly associated with WKS records). > Elevation of 2782 will give us an opportunity to clarify this. I would like to document the "correct" usage of SRV records at DNSRD, so I agree that the next version of 2782 should explicitly refer to the correct registry document. Now, which one is it? port-numbers or service-names? -- Andras Salamon andras@dns.net -- DNS Resources Directory http://www.dns.net/dnsrd/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Sat, 13 Mar 2004 17:15:25 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <andras@dns.net> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 18:27:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Andras Salamon <andras@dns.net> of "Sat, 13 Mar 2004 15:09:22 +0200." <20040313130922.GA23428@dns.net> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > Elevation of 2782 will give us an opportunity to clarify this. > > I would like to document the "correct" usage of SRV records at DNSRD, > so I agree that the next version of 2782 should explicitly refer to the > correct registry document. > > Now, which one is it? port-numbers or service-names? there isn't one. and unless one of you writes an internet-draft which asks iana to import /etc/services and then maintain the master copy of it, then 2782bis will not have anything to point at. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sat, 13 Mar 2004 12:02:40 -0800 Lines: 61 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: =?iso-8859-1?Q?=D3lafur_Gudmundsson/DNSEXT_co-chair?= <ogud@ogud.com>, <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 21:13:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQIfkyla6nOGvrbT9eb4zFEHTUH4QAtGG7A To: "Derek Atkins" <derek@ihtfp.com>, "Joshua Graessley" <jgraessley@apple.com> X-OriginalArrivalTime: 13 Mar 2004 20:02:38.0054 (UTC) FILETIME=[223D4060:01C40936] Precedence: bulk Status: O Could we agree in any case that the TTL discussion does not apply when = we use TCP?=20 As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=3D255, as = per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of = address ranges is sufficient to guarantee on-link status. Setting = TTL=3D1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of = packet to the local link. On-link attackers can spoof the source = address; off-link attackers generally cannot send multicast packets to = the destination. Checking the TTL provides no protection against on-link = attackers (they can set whatever TTL value is expected). Checking that = the source address belongs to an "on-link" prefix prevents the "smurf = attack to an off-link target". Setting the TTL=3D1 in multicast queries = prevent the side effects of a rare bug in routers, but this bug may not = be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, = including for off-link attackers. Checking TTL=3D255 protects against = spoofing by off-link sources. Checking that the source address belongs = to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the = transaction identifier, which in practice requires an "on-link" = attacker; TTL games do not protect against on-link attackers. Setting = the TTL to 1 protects against unwitting participation in a DOS-attack to = an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some = network topologies that support multicast but require packets to go = through a router -- some wireless networks and some ad hoc networks can = have that property. In practice, checking TTL=3D255 is only useful in UDP unicast queries, = where it provides a slight incremental benefit over a simple check of = the source address prefix. Setting the TTL to 1 provides a limited = benefit in TCP operation, multicast queries and unicast responses, but = contradicts the requirement of TTL=3D255 for IPv6 link-local addresses. = Setting to either value will create operational problems in some future = scenarios. The simplest solution is probably to remove all mentions of TTL checks = from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an = authorized range; 2) The TTL field should be set by the stack to whatever default value is = adequate for the interface and the source address (e.g., TTL=3D255 for = IPv6 link-local addresses.) -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:29:16 +0200 Lines: 38 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Derek Atkins <derek@ihtfp.com>, Joshua Graessley <jgraessley@apple.com>, =?ISO-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 13 23:39:40 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Christian Huitema <huitema@windows.microsoft.com> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Christian, > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Sun, 14 Mar 2004 00:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <mika.liljeberg@welho.com> X-From: owner-namedroppers@ops.ietf.org Sun Mar 14 01:32:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Mika Liljeberg <mika.liljeberg@welho.com> of "Sun, 14 Mar 2004 00:29:16 +0200." <1079216956.1930.16.camel@hades> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. "i'll by THAT for a dollar." -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: draft-ietf-dnsext-dnssec-intro-09: EDNS0 issue Date: Mon, 15 Mar 2004 14:08:17 +0900 Lines: 27 Sender: owner-namedroppers@ops.ietf.org References: <20040313005815.D96AA14D81@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 06:15:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Paul Vixie <paul@vix.com> In-Reply-To: <20040313005815.D96AA14D81@sa.vix.com> Precedence: bulk Status: O Paul; >>>yes, that's true. the crossover is probably closer to 4*PMTU. >> >>Given 1280B of IPv6 minimum MTU, shouldn't message size limitation >>be somewhere around 3600 or 4800, but not 4000? > > > i think it's all very approximate and 4000 is a very fine and round number. It could have been so, if PMTUD were usable, which would have resulted in PMTU of 1450~1500. Without PMTUD, however, assumed MTU MUST be 1280, for which very approximate and round should be 3500 or 3600. Or, are there any cryptographic reason that the size is 4000? Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 18:52:17 +0100 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <20040313171525.8D6F418F48@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:02:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: namedroppers@ops.ietf.org In-reply-to: Your message of "Sat, 13 Mar 2004 17:15:25 GMT." <20040313171525.8D6F418F48@sa.vix.com> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Content-ID: <25301.1079373136.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Precedence: bulk Status: O Paul Vixie wrote: > > Now, which one is it? port-numbers or service-names? > > there isn't one. and unless one of you writes an internet-draft which > asks iana to import /etc/services and then maintain the master copy of I'm sorry but I do not see any difference between /etc/services and the "port-numbers" registry except for the non-existence of aliases in the latter. What do you miss? -Peter -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Mon, 15 Mar 2004 10:30:45 -0800 Lines: 82 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA07EEA6E9@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <1079216956.1930.16.camel@hades> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-136514579; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 19:40:27 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <1079216956.1930.16.camel@hades> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-3-136514579 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Works for me. -josh On Mar 13, 2004, at 2:29 PM, Mika Liljeberg wrote: > Ok, although I would rather suggest: > > 2) Use TTL=1 with TCP. > > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. > > MikaL --Apple-Mail-3-136514579 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNTE4MzA0NlowIwYJKoZIhvcNAQkEMRYEFHrU VLPbNQNtvNopd+r+aqYgPGgTMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAMVP pq29OvSY+jKZQaZQC/DwN6GQ+O7rFsR4Q6EoohlgH38fYMCZ7OwTlKafoMP+kn1kxJK4Cqd8WdQ+ 2PR8K0aTIU9m8SO16+Ou3ddFmgxrB/TpyT75BdB6YsWxdiHMWRrPMXa3udJ4caBrASZ1218a6eM3 fFglGZT8BHoL1bd5ylnjlHbJ5zYOHU9xLliKjacwEwlBV1srKbny1YcRaclaTLPL8rMcwuOggyc9 k3V3G2EgekhjO43lrHH39vU58HqG4fiNUzpsefi9W9KgxyHZntipn2oLO/EUZ1cwsLtZytZLlU0z UHt8+32mJpkXneCh3hLwIAz8cbPUGd4Y53EAAAAAAAA= --Apple-Mail-3-136514579-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 20:00:49 +0000 Lines: 17 Sender: owner-namedroppers@ops.ietf.org References: <pk@TechFak.Uni-Bielefeld.DE> X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:13:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Peter Koch <pk@TechFak.Uni-Bielefeld.DE> of "Mon, 15 Mar 2004 18:52:17 +0100." <200403151752.i2FHqHk25304@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > I'm sorry but I do not see any difference between /etc/services and > the "port-numbers" registry except for the non-existence of aliases in the > latter. What do you miss? ftp://ftp.iana.org/assignments/port-numbers' "keyword" field (which wasn't there a few years ago when i last looked at this file) seems like the right answer. however, a purely SRV-discovered service might not _have_ a default port number, in which case ftp://ftp.iana.org/assignments/service-names would be the better choice for an SRV's owner name. and, it would be good to know that iana's policy is to keep synchronization between port-numbers keywords, and service-names. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Subject: RE: DNS SRV Clarification sought Date: Mon, 15 Mar 2004 12:42:37 -0800 Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 21:54:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "'Paul Vixie'" <paul@vix.com>, namedroppers@ops.ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Precedence: bulk Status: O however, a purely SRV-discovered service might not > _have_ a default > port number, in which case > ftp://ftp.iana.org/assignments/service-names would > be the better choice for an SRV's owner name. It seems to me that a good long term objective here would be to stop issuing port numbers completely. The logical extension of SRV is that you look up the service in DNS and get back a report of the name of the server that supports the service, the port address to use plus any parameters that describe the use of the port (I support SSL security with profile X). This is where the Internet will be in a few years time. Phill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Mon, 15 Mar 2004 16:52:00 -0500 Lines: 40 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Mon Mar 15 23:02:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Just a notification from your friendly neighborhood DNSSECbis document editors, to avoid suprising anyone. Miek Gieben and Jelte Jansen pointed out what we are certain is an editorial goof in way we specified calculation of the RRSIG signature value. The current drafts (both -protocol and -records) say that the signature is calculated over RR(i) = name | class | type | OrigTTL | RDATA length | RDATA As Miek and Jelte pointed out to us, the class and type fields here are reversed from the normal RFC 1035 ordering for a wire-encoded RR (not to be confused with the RFC 1035 text format, which has the class, type, and TTL fields in reverse order to avoid parse ambiguities). To the best of our knowledge: a) RFC 2535 did not explictly specify the order, but the algorithm has generally been understood as signing the wire representation; b) There has been no WG action since RFC 2535 that would change this; and c) All current implementations of which we're aware use the wire ordering, not what the DNSSECbis specs currently say. So this seems to have just been an editorial goof, we've fixed it in the editors' working sources, and the fix will be in the next revisions of the drafts we post. If anyone has a problem with this change, please send mail to the editors, the WG chairs, or to namedroppers, as appropriate. Thanks to Miek and Jelte for catching this! -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Re: DNSSECbis specification glitch (type/class order reversed in signatures) Date: Tue, 16 Mar 2004 09:36:19 +0100 Organization: RIPE NCC Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040315215200.D2A7318E0@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 16 09:44:51 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Rob Austein <sra@isc.org> In-Reply-To: <20040315215200.D2A7318E0@thrintun.hactrn.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.082025 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8ddd797dfea932e40d44a26c70d1f113 Precedence: bulk Status: O Miek, Jelte, Good Catch!! Rob wrote: > a) RFC 2535 did not explictly specify the order, but the algorithm has > generally been understood as signing the wire representation; It is somewhat hidden through a refference from section 4.1.8 (Signature field): " RR(s) is the RRset of the RR(s)(...) in canonical form and order as defined in Section 8. " RFC 2535 section 8.1 applies: For purposes of DNSsecurity, the canonical form for an RR is the wire format of the RR (...) -- Olaf ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 17:17:11 -0800 (PST) Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 02:18:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O > Ok, although I would rather suggest: > 1) Nodes should very that the source address of queries belong to an > authorized range; I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. > 2) Use TTL=1 with TCP. This makes sense. > 3) No TTL requirements for UDP requests and responses, but recommend > setting to 255 for compatibility with Rendezvous. This only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Tue, 16 Mar 2004 21:54:41 -0800 Lines: 51 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:03:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR and Rendezvous TTL disagreement, a modest proposal thread-index: AcQLvatlaIXizGLoR++uJyP8Awx4HgAJaJwg To: "Bernard Aboba" <aboba@internaut.com>, <namedroppers@ops.ietf.org> X-OriginalArrivalTime: 17 Mar 2004 05:52:47.0441 (UTC) FILETIME=[131E2C10:01C40BE4] Precedence: bulk Status: O > > Ok, although I would rather suggest: >=20 > > 1) Nodes should very that the source address of queries belong to an > > authorized range; >=20 > I'm not sure how to define an "authorized range". A host may not know all > the prefixes present on a given link. In IPv6 at least, the host is suppose to learn the list of on-link prefixes from the RA. But you are right, there are many ways to get this test half-right and cause major operation pain.=20 > > 2) Use TTL=3D1 with TCP. >=20 > This makes sense. >=20 > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. >=20 > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. >=20 > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=3D1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Getting rid of unicast UDP query would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=3D1 also guarantees an on-link peering.=20 The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal Date: Wed, 17 Mar 2004 08:07:22 +0200 Lines: 30 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 07:11:53 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Bernard Aboba <aboba@internaut.com> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O On Wed, 2004-03-17 at 03:17, Bernard Aboba wrote: > > 3) No TTL requirements for UDP requests and responses, but recommend > > setting to 255 for compatibility with Rendezvous. > > This only works if UDP unicast requests are prohibited. Otherwise, LLMNR > would send unicast PTR RR queries off the local link, which is not > acceptable. Well, section 2.4 already says: "Unicast LLMNR queries SHOULD be sent using TCP. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries." > An alternative would be to have no TTL requirements for multicast UDP > request and unicast UDP responses, but setting to 255 for compatibility > with Rendezvous. But requiring either TTL=1 for UDP unicast queries or > get rid of unicast UDP queries entirely. Using different TTLs for different messages is awkward from the implementation standpoint. It would be simplest just to require that all requests and responses must be sent to the local link. E.g. use the SO_DONTROUTE socket option. MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 06:06:21 -0800 (PST) Lines: 318 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 15:08:39 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O The text of LLMNR Issue 64 is enclosed below. The proposed resolution is as follows: In Section 2.4, change: "Unicast LLMNR queries SHOULD be sent using TCP." To: "Unicast LLMNR queries MUST be sent using TCP." Change: "Unicast UDP queries MAY be responded to with a UDP response containing an empty answer section and the TC bit set, so as to require the sender to resend the query using TCP." To: "Unicast UDP queries MUST be silently discarded." Change: "If an ICMP "Time Exceeded" message is received in response to a unicast UDP query, or if TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section). The UDP sender receiving an ICMP "Time Exceeded" message SHOULD verify that the ICMP error payload contains a valid LLMNR query packet, which matches a query that is currently in progress, so as to guard against a potential Denial of Service (DoS) attack. If a match cannot be made, then the sender relies on the retransmission and timeout behavior described in Section 2.7." To: "If TCP connection setup cannot be completed in order to send a unicast TCP query, this is treated as a response that no records of the specified type and class exist for the specified name (it is treated the same as a response with RCODE=0 and an empty answer section)." In Section 2.5, change: "In composing LLMNR queries, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). Even when LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Therefore setting the IPv6 Hop Limit or IPv4 TTL field to one provides an additional precaution against leakage of LLMNR queries. In composing a response to an LLMNR query, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the response to one (1). This is done so as to prevent the use of LLMNR for denial of service attacks across the Internet. Section 2.4 discusses use of TCP for LLMNR queries and responses. The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder." To: "Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder. For UDP queries and responses the Hop Limit field in the IPv6 header, and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with Apple Rendezvous." In Section 5.1, change: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on both queries and responses. A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can be used to launch denial of service attacks. For example, were the TTL of an LLMNR Response to be set to a value larger than one (1), an attacker could send a large volume of queries from a spoofed source address, causing an off-link target to be deluged with responses. Utilizing a TTL of one (1) in LLMNR responses ensures that they will not be forwarded off-link. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender." To: "Since LLMNR is typically deployed in situations where no trust model can be assumed, it is likely that LLMNR queries and responses will be unauthenticated. In the absence of authentication, LLMNR reduces the exposure to such threats by utilizing UDP queries sent to a link-scope multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) fields to one (1) on TCP queries and responses. Using a TTL of one (1) to set up a TCP connection in order to send a unicast LLMNR query reduces the likelihood of both denial of service attacks and spoofed responses. Checking that an LLMNR query is sent to a link-scope multicast address should prevent spoofing of multicast queries by off-link attackers. While this limits the ability of off-link attackers to spoof LLMNR queries and responses, it does not eliminate it. For example, it is possible for an attacker to spoof a response to a frequent query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. When LLMNR queries are sent to a link-scope multicast address, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may enable denial of service attacks across the Internet. However, since LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, it is believed that this threat is minimal." An edited version of the specification incorporating these changes is available at: http://www.drizzle.com/~aboba/DNSEXT/draft-ietf-dnsext-mdns-30.txt -------------------------------------------------------------------- Issue 64: TTL Revisited Submitter name: Olafur Gudmundsson Submitter email address: ogud@ogud.com Date first submitted: March 15, 2004 Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00299.html Document: LLMNR-29 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The chairs are looking for closure and rough consensus on this only remaining issue for LLMNR. The solution below seems like a good solid compromise. Is there any technical reason why this should not be adopted, please state so before March 24'th. Olafur & Olaf Subject: Re: LLMNR and Rendezvous TTL disagreement, a modest proposal From: Derek Atkins <derek@ihtfp.com> Date: Tue, 24 Feb 2004 22:14:43 -0500 It sounds like you want two things here, but it also sounds like all of them need to happen in the responder. The attacker could theoretically send packets of any type, with any TTL. So you can't trust anything you receive from the network. To this affect, I think: 1) We want the responder to try to determine that a request came from the local network. The best way to do this is for the responder to check that TTL=255 to make sure. If a TTL is less than 255 then it originiated off-net and can be dropped. 2) We want the responder to make sure response packets don't go off-net. In other words, we want the responder to respond with TTL=1, to make sure it can't smurf. So, to this affect: a) an LLMNR requestor should send requests with TTL=255 b) an LLMNR responder should verify requests have TTL=255 -- if it is not 255 then it should drop the packet. c) an LLMNR responder should respond with TTL=1 d) I dont' think an LLMNR requestor needs to check the response TTL. The only issue this doesn't directly solve is a requester being spoofed by an off-net attacker, but said attacker would need to guess the transaction id of the request in order to send a valid response, which is just as likely in LLMNR as it is in standard DNS, so it can probably be ignored. So, other than this issue, does this solve the issue? [Christian Huitema] Could we agree in any case that the TTL discussion does not apply when we use TCP? As far as I can tell, I would split the problem as follow: 1) Source address is an IPv6 local-link address: must use TTL=255, as per IPv6. No need for special code, this is done by the stack. 2) Operation over TCP: three-ways handshake prevents spoofing. Test of address ranges is sufficient to guarantee on-link status. Setting TTL=1 provides additional benefit. 3) Multicast query: multicast routing normally limits propagation of packet to the local link. On-link attackers can spoof the source address; off-link attackers generally cannot send multicast packets to the destination. Checking the TTL provides no protection against on-link attackers (they can set whatever TTL value is expected). Checking that the source address belongs to an "on-link" prefix prevents the "smurf attack to an off-link target". Setting the TTL=1 in multicast queries prevent the side effects of a rare bug in routers, but this bug may not be very frequent anyhow. 4) UDP unicast query: spoofing of the source address is very easy, including for off-link attackers. Checking TTL=255 protects against spoofing by off-link sources. Checking that the source address belongs to a local range also affords some protection. 5) UDP unicast response: spoofing of the response requires guessing the transaction identifier, which in practice requires an "on-link" attacker; TTL games do not protect against on-link attackers. Setting the TTL to 1 protects against unwitting participation in a DOS-attack to an off-link target, if the source address of the query was spoofed. 6) Setting the TTL to either 1 or 255 will create failures in some network topologies that support multicast but require packets to go through a router -- some wireless networks and some ad hoc networks can have that property. In practice, checking TTL=255 is only useful in UDP unicast queries, where it provides a slight incremental benefit over a simple check of the source address prefix. Setting the TTL to 1 provides a limited benefit in TCP operation, multicast queries and unicast responses, but contradicts the requirement of TTL=255 for IPv6 link-local addresses. Setting to either value will create operational problems in some future scenarios. The simplest solution is probably to remove all mentions of TTL checks from the LLMNR document, and simply state that: 1) Nodes should verify that the source address of queries belong to an authorized range; 2) The TTL field should be set by the stack to whatever default value is adequate for the interface and the source address (e.g., TTL=255 for IPv6 link-local addresses.) [Mika Liljeberg] > Setting the TTL to 1 provides a limited benefit in TCP operation, > multicast queries and unicast responses, but contradicts the > requirement of TTL=255 for IPv6 link-local addresses. Setting to > either value will create operational problems in some future > scenarios. This is untrue. IPv6 does not require nor enforce hop limit 255 for link-local addresses. Only ICMPv6 neighbor discovery packets use hop limit 255. This is not a constraint for LLMNR. > The simplest solution is probably to remove all mentions of TTL checks > from the LLMNR document, and simply state that: > 1) Nodes should verify that the source address of queries belong to an > authorized range; This seems useful. > 2) The TTL field should be set by the stack to whatever default value > is adequate for the interface and the source address (e.g., TTL=255 > for IPv6 link-local addresses.) Ok, although I would rather suggest: 2) Use TTL=1 with TCP. 3) No TTL requirements for UDP requests and responses, but recommend setting to 255 for compatibility with Rendezvous. [Bernard Aboba] I'm not sure how to define an "authorized range". A host may not know all the prefixes present on a given link. TTL=255 on UDP request & responses only works if UDP unicast requests are prohibited. Otherwise, LLMNR would send unicast PTR RR queries off the local link, which is not acceptable. An alternative would be to have no TTL requirements for multicast UDP request and unicast UDP responses, but setting to 255 for compatibility with Rendezvous. But requiring either TTL=1 for UDP unicast queries or get rid of unicast UDP queries entirely. [Christian Huitema] Getting rid of unicast UDP queries would be by far the most robust solution. Multicast routing pretty much guaranties that a multicast request only travels one single hop; the TCP 3-ways handshake combined with TTL=1 also guarantees an on-link peering. The residual risk is address spoofing by an on-link source, to enroll the LLMNR responder in a reflection attack. But as long as we devise the protocol so that only one node respond to a query, we have not created an extra vulnerability. Regular DNS servers are just as easy to enroll in a reflection attack... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 17 Mar 2004 11:06:54 -0500 Lines: 88 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 17:14:43 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC NSEC RDATA Format Author(s) : J. Schlyter Filename : draft-ietf-dnsext-nsec-rdata-05.txt Pages : 9 Date : 2004-3-12 This document redefines the wire format of the 'Type Bit Map' field in the NSEC resource record RDATA format to cover the full RR type space. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-nsec-rdata-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-nsec-rdata-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-nsec-rdata-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-17112510.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: LLMNR authorized range Date: Wed, 17 Mar 2004 10:19:12 -0800 Lines: 86 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-308620971; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 19:27:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403161709190.28827@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-13-308620971 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Mar 16, 2004, at 5:17 PM, Bernard Aboba wrote: >> Ok, although I would rather suggest: > >> 1) Nodes should very that the source address of queries belong to an >> authorized range; > > I'm not sure how to define an "authorized range". A host may not know > all > the prefixes present on a given link. The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. -josh --Apple-Mail-13-308620971 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzE4MTkxMlowIwYJKoZIhvcNAQkEMRYEFPiN 3vLihLmc6g/UXYaume3X1TIJMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBABID 5kspYzWbi7lBMu8pVrGyZZ2/vNLa7cP+3xgscFyqNHBTYzii2NsnmUe97xQWPBtDJ5PpW1GhanVz DK9XwDPbaTHBBWKmVA5LeHqVhsqzOsYRkRWPU8YmVAnPJbPMH5OvADep2yuoAQvDfkybYIEryOMR o2jfRj8mIXTpwxqKf9hG3OwGleTrEg8bzvOCgGruFIAxm+BiMx2ayDeIYvqfXVy8XU2zTWQUKB+w pyFhIkyJkTbX324Y2wlMAlGlv1zB4KsTqJH62Rb+PsXifl2sW+gD6RMn/XwqJgrteyarMyWMZ+D+ 6IDc848v8NteNdCjpEUrprCGxZqx8KB5QSkAAAAAAAA= --Apple-Mail-13-308620971-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Mika Liljeberg <mika.liljeberg@welho.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:20:56 +0200 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 20:29:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: Ximian Evolution 1.4.5 Precedence: bulk Status: O Josh, On Wed, 2004-03-17 at 20:19, Joshua Graessley wrote: > The current solution of using TCP with a TTL of 1 makes the "authorized > range" pretty simple to understand. Addresses in the authorized range > are those that the host knows about. This highlights a problem with the > current LLMNR draft. If there are two subnets overlaid on a local > network and the hosts are unaware of the opposite subnet, LLMNR will > make it impossible to resolve names of some devices on the same link > just because they exist on a different subnet. As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? MikaL -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:25:29 -0500 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 21:33:36 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: post@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O At 13:19 2004-03-17, Joshua Graessley wrote: >The current solution of using TCP with a TTL of 1 makes the "authorized >range" pretty simple to understand. Addresses in the authorized range are >those that the host knows about. This highlights a problem with the >current LLMNR draft. If there are two subnets overlaid on a local network >and the hosts are unaware of the opposite subnet, LLMNR will make it >impossible to resolve names of some devices on the same link just because >they exist on a different subnet. Good point, so what TLL <= N works for you ? N = 5 sounds good to me. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 21:22:10 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <ogud@ogud.com> X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 22:29:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= <ogud@ogud.com> of "Wed, 17 Mar 2004 15:25:29 EST." <6.0.3.0.2.20040317152010.02b37e88@localhost> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > > ... If there are two subnets overlaid on a local network and the > > hosts are unaware of the opposite subnet, LLMNR will make it > > impossible to resolve names of some devices on the same link just > > because they exist on a different subnet. that sounds like the right thing, since if they're on different subnets then they will not be able to communicate even though those subnets are in the same broadcast domain. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 14:13:00 -0800 Lines: 95 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-322649650; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Wed Mar 17 23:29:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040317212210.05A5514C51@sa.vix.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-18-322649650 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed My friends has a problem with his cable modem provider. He has paid extra to get extra addresses. The addresses are handed out using DHCP. The addresses are not always on the same subnet. I see no reason why LLMNR shouldn't work for him. I may soon have a similar situation at home. I've got sDSL for a small server I run. I'm thinking about getting a cable modem connection so I can get stuff quicker. When I have that setup at home, I'll have two or more subnets running on the local network. All of the devices can communicate using their IPv4 addresses (albeit inefficiently). LLMNR should work in this situation but due to the TTL stuff it may not work. I think there is a simple solution for IPv6. Always use the IPv6 link-local addresses. The only solution that would work 100% of the time for IPv4 would be to use the same link-local multicast to send the response. -josh On Mar 17, 2004, at 1:22 PM, Paul Vixie wrote: >>> ... If there are two subnets overlaid on a local network and the >>> hosts are unaware of the opposite subnet, LLMNR will make it >>> impossible to resolve names of some devices on the same link just >>> because they exist on a different subnet. > > that sounds like the right thing, since if they're on different subnets > then they will not be able to communicate even though those subnets are > in the same broadcast domain. --Apple-Mail-18-322649650 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMxNzIyMTMwMVowIwYJKoZIhvcNAQkEMRYEFGC0 xVKoZ+1an/5iMlJX/1xQw6DpMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAHdE tCTuzek3bgT7uCX+FEcQUYwwsv0Dnpcc8LKbMC7ZUwR6N7Am77lCNPIvw/wZfwm+87pxoori9Cl/ JSVyvPiUgiB/yfipwfUJPdoQIbrD8IbcsleoWSP95c+SAX4Odw1utoo9zbg4ig4sO/xtwQtV2JaA xNfDAhhiuk4+5+GtXf5/fJKEZd+gYa831X6fPBDr+rbVEZYnKO4I89iVrGW4XQ66d61LJ26XIs2/ NNsXHQbq/u9+8p0XUNTauhGPjJH9XVDk9mDt0o23xmbwfPzavUtoDBnvSEt6yASMfaZxUMTPdCD/ F30cuturShwPFbcGw4wSZ0fZmIQOFcG0GRUAAAAAAAA= --Apple-Mail-18-322649650-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Paul Vixie <paul@vix.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 23:23:34 +0000 Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <jgraessley@apple.com> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 00:31:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: Message from Joshua Graessley <jgraessley@apple.com> of "Wed, 17 Mar 2004 14:13:00 PST." <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Precedence: bulk Status: O > My friends has a problem with his cable modem provider. He has paid extra > to get extra addresses. The addresses are handed out using DHCP. The > addresses are not always on the same subnet. I see no reason why LLMNR > shouldn't work for him. i guess if your router is sitting on both subnets and you're willing to go through a router to talk to other hosts in the same broadcast domain, you're right there's no reason LLMNR wouldn't work. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 13:56:57 -0600 Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403170606040.10517@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403170606040.10517@internaut.com> To: Bernard Aboba <aboba@internaut.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 8:06 AM, Bernard Aboba wrote: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header MAY be set to any value. However, > it is RECOMMENDED that the value 255 be used for compatibility with > Apple Rendezvous." Why not change it to: > For UDP queries and responses the Hop Limit field in the IPv6 header, > and the TTL field in the IPV4 header SHOULD be set to 255. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 17:02:06 -0600 Lines: 29 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:05:56 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. It shouldn't work for him because his network is misconfigured. It's not the job of the IETF to arrange for it to be the case that any random configuration error still results in desired behavior, for any arbitrary value of "desired." If you want this to work, you need to go check out the IPv4ll protocol and make sure that it does the right thing in this case. And your friend needs to use IPv4ll. Rendezvous works correctly in this case, doesn't it? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@fugue.com> Subject: Re: LLMNR authorized range Date: Wed, 17 Mar 2004 15:21:31 -0600 Lines: 23 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 01:07:38 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> To: Joshua Graessley <jgraessley@apple.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O [ Moderators note: Post by non-subscriber. With the massive amount of spam, it is easy to miss and therefore delete relevant posts by non-subsrcibers. Please fix your subscription addresses. ] On Mar 17, 2004, at 12:19 PM, Joshua Graessley wrote: > If there are two subnets overlaid on a local network and the hosts are > unaware of the opposite subnet, LLMNR will make it impossible to > resolve names of some devices on the same link just because they exist > on a different subnet. I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 20:02:00 -0800 Lines: 26 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 05:11:24 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Resolution to LLMNR Issue 64: TTL Revisited thread-index: AcQMfLkklVWmcimJRgOk4T8n5ZiKvQAIL36g To: "Ted Lemon" <mellon@fugue.com>, "Bernard Aboba" <aboba@internaut.com> X-OriginalArrivalTime: 18 Mar 2004 04:02:14.0194 (UTC) FILETIME=[CBCEC120:01C40C9D] Precedence: bulk Status: O > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header MAY be set to any value. However, > > it is RECOMMENDED that the value 255 be used for compatibility with > > Apple Rendezvous." >=20 > Why not change it to: >=20 > > For UDP queries and responses the Hop Limit field in the IPv6 header, > > and the TTL field in the IPV4 header SHOULD be set to 255. Because this is a trade-off. The proper design is to use a TTL=3D1. The only reason to use the 255 value, which has a larger exposure to DOS exploitation, is compatibility with rendezvous. The text that Bernard proposes is a fine compromise. -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: Proposed Resolution to LLMNR Issue 64: TTL Revisited Date: Wed, 17 Mar 2004 23:18:46 -0600 Lines: 18 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 06:24:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA08048B1C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> To: "Christian Huitema" <huitema@windows.microsoft.com> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 17, 2004, at 10:02 PM, Christian Huitema wrote: > Because this is a trade-off. The proper design is to use a TTL=1. The > only reason to use the 255 value, which has a larger exposure to DOS > exploitation, is compatibility with rendezvous. The text that Bernard > proposes is a fine compromise. The text I proposed and the text it replaces have exactly the same effect. The difference is that one of them places blame (I think inappropriately, although I think also unintentionally), and the other does not. I can't think of any technical reason to prefer the old text over the new. Can you state such a reason? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:50 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: EDNS0 (RFC-2671) questions Date: Thu, 18 Mar 2004 15:25:36 +0200 Lines: 31 Sender: owner-namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 14:34:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O 1) assuming I send query, which includes the OPT RR (to increase the packet length). If I receive a reply with TC=1 (truncation) and don't find OPT RR in the reply, then I assume the RCODE is the non-extended one? [Just verifying, that I can trust all implementations do it right: if they build an answer and run out of space before inserting the OPT RR, they also fall back to old plain RCODE?] This extended-RCODE makes it somewhat akward, to find RCODE, you have to traverse through all data in Question, Answer and Authority sections, then look OPT RR from Additional section. Doable, but still icky, just to get few extra bits of RCODE that are rarely used. Would have been easier if there was single RCODE value in fixed header to indicate that extended RCODE is in use. 2) Can UDP payload size be < 512? I didn't see any mention of it. Maybe I missed it. I think RFC should state that attempting to use less than 512 is not allowed (and will be ignored). [If < 512 is accepted, there might be some DOS potential in it also] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Scott Rose" <scottr@nist.gov> Subject: correction to RRSIG presentation format in DNSSECbis -records draft Date: Thu, 18 Mar 2004 10:53:08 -0500 Lines: 32 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:04:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: <namedroppers@ops.ietf.org> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-NIST-MailScanner-Information: Please contact the ISP for more information X-NIST-MailScanner: Found to be clean X-MailScanner-From: scottr@nist.gov Precedence: bulk Status: O Recently pointed out by Miek and Erik Rozendaal in the Resource Records draft of the DNSSECbis spec is the discrepancy between the ASCII presentation formats of the RRSIG and NSEC RRs. In the text, the RRSIG Type Covered field is supposed to be represented as a RR type mnemonic or an unsigned integer. This goes against the convention in RFC 3597 which states that unknown RR types should be represented as "TYPE<number>" where <number> is the typecode. The text for the representation of the NSEC RR type bitmap already states this (as it was written after RFC3597). The text for the RRSIG representation was changed to be consistent with RFC 3597 and the NSEC text. Section 3.2 paragraph 2 will now read: The Type Covered field is represented as a RR type mnemonic. When the mnemonic is not known, the TYPE representation as described in [RFC3597] (section 5) MUST be used. Thanks, Scott DNSSECbis editors -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 18:14:36 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:19:32 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 03:21:31PM -0600, Ted Lemon wrote: > A host that you > can't talk to without going through a router isn't "local." Why not? Which part of the Internet-Draft does this violate? >From ...-29.txt: For IPv4, an "on link" address is defined as a link-local address [IPv4Link] or an address whose prefix belongs to a subnet on the local link. The network overlay scenario is clearly "on link" according to the above definition. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 16:54:57 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joshua Graessley <jgraessley@apple.com>, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:55 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 05:02:06PM -0600, Ted Lemon wrote: > On Mar 17, 2004, at 4:13 PM, Joshua Graessley wrote: > >My friends has a problem with his cable modem provider. He has paid > >extra to get extra addresses. The addresses are handed out using DHCP. > >The addresses are not always on the same subnet. I see no reason why > >LLMNR shouldn't work for him. > > It shouldn't work for him because his network is misconfigured. It's > not the job of the IETF to arrange for it to be the case that any > random configuration error still results in desired behavior, for any > arbitrary value of "desired." Exactly how is overlaying two IP network ranges onto one L2 infrastructure misconfigured? -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 17:32:58 +0200 Lines: 62 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:20:58 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Joshua Graessley <jgraessley@apple.com> Content-Disposition: inline In-Reply-To: <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > My friends has a problem with his cable modem provider. He has paid > extra to get extra addresses. The addresses are handed out using DHCP. > The addresses are not always on the same subnet. I see no reason why > LLMNR shouldn't work for him. This hits at the crux of what "Link-Local" means in the acronym LLMNR. The above scenario (if indeed regarded as acceptable practice) will be regarded by most people as "local". During the original drafting of the document, did the authors have a specific definition of "link-local" in mind? As I recall, the original spec came out of Stuart Cheshire's work on replacing AppleTalk's naming service; this became Rendezvous and branched off into LLMNR. If this is the case, then the "local" definition was pretty broad, and would probably cover the overlaid network scenario. Also, in the above scenario, forcing TTL=1 will cause the router to drop the packet before it is forwarded back onto the "other" part of the local network. Making TTL=5 (or any other number greater than 1 but less than the worst-case diameter of the Internet) seems to be an ugly solution, and also gets away from the "link-local" part of LLMNR -- why not just call it "restricted scope MNR" then? Or why not just drop the TTL restriction altogether and just allow general MNR? I repeat -- TTL checks are a kludge, and do not capture the idea of "local" networks. There are local networks for which TTL must be greater than 1 to capture locality (eg. multiple IP ranges overlaid on the same L2 medium as above), and there are distinctly non-local networks (eg. LANs bridged through long thin pipes) for which any multicast can cause great harm -- even with TTL=1. In a message to this forum from Bernard Aboba in October 2003: As a result, the ZEROCONF WG has had to spend the last year rewriting the IPv4 Link-Local specification so as to "do no harm". The current specification no longer mandates a test for a TTL value, and prefers a routable address when available. It is perhaps not as "useful" as the early versions -- but it also does not break the basic interoperability of TCP/IP. I've probably taken the above slightly out of context, but perhaps we should go back to the original multicast slant of LLMNR and drop UDP unicast, as suggested by Bernard in another message. For multicast, the TTL is irrelevant unless we are trying to compensate for potential router bugs. On the other hand, for TCP queries, the TTL should not be restricted. Then, interoperability with an existing protocol seems to be a worthwhile goal, as long as it is not bought at a terrible price. (Why was UDP unicast functionality introduced, anyway?) At the end of the day, I just want to see some finality with LLMNR, whatever it is! Either it is going to be useless and Rendezvous will win out in the marketplace, or it will be useful and over time it may grow to take over from Rendezvous. But right now LLMNR is by definition useless, since it hasn't been finalised. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 08:50:54 -0800 (PST) Lines: 33 Sender: owner-namedroppers@ops.ietf.org References: <20040318153258.GF9994@dns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jgraessley@apple.com (Joshua Graessley), namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 17:57:03 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: andras@dns.net (Andras Salamon) In-Reply-To: <20040318153258.GF9994@dns.net> from "Andras Salamon" at Mar 18, 2004 05:32:58 PM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > On Wed, Mar 17, 2004 at 02:13:00PM -0800, Joshua Graessley wrote: > > My friends has a problem with his cable modem provider. He has paid > > extra to get extra addresses. The addresses are handed out using DHCP. > > The addresses are not always on the same subnet. I see no reason why > > LLMNR shouldn't work for him. > > This hits at the crux of what "Link-Local" means in the acronym LLMNR. link-local is an unfortunate terminological choice. it might be useful to consider "single broadcast domain", which pretty much eliminates the overlay scenario. > As I recall, the original spec came out of Stuart Cheshire's > work on replacing AppleTalk's naming service; this became Rendezvous and > branched off into LLMNR. If this is the case, then the "local" definition > was pretty broad, and would probably cover the overlaid network scenario. Hum... there were a series of efforts that hit confluence and then diverged... the TBDS research, what became Rendezvous and what might become LLMNR... all are varients that use DNS or DNSlike stuff. > -- Andras Salamon andras@dns.net --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:36:42 -0600 Lines: 20 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <1CC00D48-7867-11D8-8027-000A95D9C74C@fugue.com> <20040318145457.GE9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:51:15 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318145457.GE9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 8:54 AM, Andras Salamon wrote: > Exactly how is overlaying two IP network ranges onto one L2 > infrastructure > misconfigured? It is misconfigured in the sense that it does not do what the customer expects. The customer expects that the two devices he or she has connected to the network will be able to communicate with each other without relying on the service provider. This is unfortunately not true - they will not be able to communicate other than over the service provider's link, unless they implement Rendezvous (I do not believe that the current IPv4ll draft, for example, will allow them to communicate independent of the ISP). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Ted Lemon <mellon@nominum.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 12:47:39 -0600 Lines: 36 Sender: owner-namedroppers@ops.ietf.org References: <20040317212210.05A5514C51@sa.vix.com> <4106D38E-7860-11D8-B9EF-000A95B9474C@apple.com> <20040318153258.GF9994@dns.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Thu Mar 18 19:59:45 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <20040318153258.GF9994@dns.net> To: Andras Salamon <andras@dns.net> X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O On Mar 18, 2004, at 9:32 AM, Andras Salamon wrote: > During the original drafting of > the document, did the authors have a specific definition of > "link-local" > in mind? Yes. However, the current document bears only a passing resemblance to what the authors had in mind. The original intention was that the two devices we're discussing would both have IPv4ll addresses, and that MDNS, as it was then called, would uses these addresses, not the globally-routable addresses. Both the IPv4ll spec and the MDNS spec have been changed dramatically since then. IPv4ll no longer works the way it did, and LLMNR doesn't either. At this point, I have to say that it is my sincere hope that neither IPv4ll nor LLMNR make it to standard as they are currently constituted. But if they do make it to standard, my next hope is that they do not fail to interoperate with Rendezvous. If they do not interoperate reliably with Rendezvous, then the only purpose they will serve is to make sure that no reliable mechanism exists whereby two arbitrary hosts can automatically communicate with each other on the local link in the event that the DHCP server is not configured to enable this communication - by having two incompatible mechanisms that do roughly the same thing, we eliminate the possibility of dependable interoperability. I sympathize deeply with your motivation to make LLMNR work correctly in the scenario we're talking about in the absence of any competing protocol, but that is not the domain in which we are operating. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Thu, 18 Mar 2004 22:41:55 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 07:41:28 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O >LLMNR will make it impossible to resolve names of some devices on the >same link just because they exist on a different subnet. No. All but PTR RR queries will be sent to the link-scope multicast address, so they will be resolved without a problem. >As far as I can see, that is only a problem with PTR queries, which >often fail anyway. Yes. Only PTR queries are sent via TCP. Given that other queries will work and applications need to be prepared for PTR RR queries to fail anyway, you'll only see somewhat degraded performance. On the other hand, there is a performance improvement for other cases, since TTL=1 causes unresolvable PTR RR queries to fail quickly, rather than having to wait for LLMNR_TIMEOUT. So this is really just an optimization issue and I'm not clear that optimizing for an uncommon case (e.g. TTL=5) makes sense. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Andras Salamon <andras@dns.net> Subject: Re: LLMNR authorized range Date: Fri, 19 Mar 2004 10:16:42 +0200 Lines: 22 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403161709190.28827@internaut.com> <97486514-783F-11D8-B9EF-000A95B9474C@apple.com> <0F9FDC6F-7859-11D8-8027-000A95D9C74C@fugue.com> <20040318161436.GA10775@dns.net> <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: namedroppers <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Fri Mar 19 09:48:41 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: Ted Lemon <mellon@fugue.com> Content-Disposition: inline In-Reply-To: <E5F939A2-790A-11D8-8027-000A95D9C74C@fugue.com> User-Agent: Mutt/1.5.6i Precedence: bulk Status: O On Thu, Mar 18, 2004 at 12:34:32PM -0600, Ted Lemon wrote: > On Mar 18, 2004, at 10:14 AM, Andras Salamon wrote: > >The network overlay scenario is clearly "on link" according to the > >above definition. > > Sure, and you could argue that the definition you've quoted is correct > and that mine is wrong. I'm not especially interested in arguing about whose definition is right or wrong. However, the current LLMNR Internet-Draft defines its scope to include the scenario of address ranges overlaid onto the same L2 infrastructure (maybe I'm wrong here, but no-one has yet objected). Hence, either we need to change the wording of the I-D, or we need to accept the wording and its consequences. -- Andras Salamon andras@dns.net -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Bernard Aboba <aboba@internaut.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 03:47:00 -0800 (PST) Lines: 47 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 12:51:23 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org Precedence: bulk Status: O [Joshua Graessley] said: The current solution of using TCP with a TTL of 1 makes the "authorized range" pretty simple to understand. Addresses in the authorized range are those that the host knows about. This highlights a problem with the current LLMNR draft. If there are two subnets overlaid on a local network and the hosts are unaware of the opposite subnet, LLMNR will make it impossible to resolve names of some devices on the same link just because they exist on a different subnet. [Ted Lemon] replied: I guess I don't understand why this is a problem. A host that you can't talk to without going through a router isn't "local." Why would we expect this to work? [Mika Liljeberg] said: As far as I can see, that is only a problem with PTR queries, which often fail anyway. And I'd wager overlaid subnets are not a very common configuration. Do you think this is something we need to worry about? [Bernard Aboba] In practice, I don't believe this issue will arise. Section 1 says: "The assumption is that if a network has a gateway, then the network is able to provide DNS server configuration." Therefore in the "overlapping subnet" case LLMNR assumes that the host has DNS configuration. From early on, LLMNR has assumed that the gateway supports the resolution of the names of local hosts using DHCPv4 and dynamic DNS update. However, this assumption cannot be made for IPv6 at this point. So if we are talking about multiple subnets on a link in IPv4, then a conventional DNS query will be sent first, and local names can be resolved by the gateway. If we are talking about IPV6, then Router Advertisement enables the host to become aware of the multiple subnets, so that TCP-based queries can be sent on the local link, rather than forwarded by a router. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Markku Savela <msa@burp.tkv.asdf.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 14:23:14 +0200 Lines: 16 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 13:31:14 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: aboba@internaut.com In-reply-to: <Pine.LNX.4.56.0403200335280.8666@internaut.com> (message from Bernard Aboba on Sat, 20 Mar 2004 03:47:00 -0800 (PST)) Precedence: bulk Status: O > From: Bernard Aboba <aboba@internaut.com> > > ... If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, Terminology confusion? What subnets are in RA? RA can have multiple prefixes to be used on the link (if L=1), but they are not subnets. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Christian Huitema" <huitema@windows.microsoft.com> Subject: RE: LLMNR authorized range Date: Sat, 20 Mar 2004 10:48:18 -0800 Lines: 20 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: <namedroppers@ops.ietf.org> X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 19:58:33 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7195.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLMNR authorized range thread-index: AcQOdygluZmu2G4uTO+NBskGu1hyLwANJJKA To: "Markku Savela" <msa@burp.tkv.asdf.org>, <aboba@internaut.com> X-OriginalArrivalTime: 20 Mar 2004 18:48:03.0805 (UTC) FILETIME=[E04548D0:01C40EAB] Precedence: bulk Status: O > > From: Bernard Aboba <aboba@internaut.com> > > > > ... If we are > > talking about IPV6, then Router Advertisement enables > > the host to become aware of the multiple subnets, >=20 > Terminology confusion? What subnets are in RA? RA can have multiple > prefixes to be used on the link (if L=3D1), but they are not subnets. Uh? There is no official definition of subnet, but the generally agreed definition is "the set of addresses that shares a specified prefix". -- Christian Huitema -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: bill <bmanning@karoshi.com> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 12:12:48 -0800 (PST) Lines: 25 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: msa@burp.tkv.asdf.org (Markku Savela), aboba@internaut.com, namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 21:21:29 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: huitema@windows.microsoft.com (Christian Huitema) In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> from "Christian Huitema" at Mar 20, 2004 10:48:18 AM X-Mailer: ELM [version 2.5 PL6] Precedence: bulk Status: O > > > From: Bernard Aboba <aboba@internaut.com> > > > > > > ... If we are > > > talking about IPV6, then Router Advertisement enables > > > the host to become aware of the multiple subnets, > > > > Terminology confusion? What subnets are in RA? RA can have multiple > > prefixes to be used on the link (if L=1), but they are not subnets. > > Uh? There is no official definition of subnet, but the generally agreed > definition is "the set of addresses that shares a specified prefix". That is not generally agreed on in most circles I run in. The working definition here is: "a single broadcast domain" e.g. more layer two'ish. > -- Christian Huitema --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: Re: LLMNR authorized range Date: Sat, 20 Mar 2004 16:18:45 -0500 Lines: 34 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Sat Mar 20 22:26:26 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org In-Reply-To: <200403202012.i2KKCn418994@karoshi.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > > > Uh? There is no official definition of subnet, but the generally agreed > > definition is "the set of addresses that shares a specified prefix". > > That is not generally agreed on in most circles I run in. > The working definition here is: "a single broadcast domain" > e.g. more layer two'ish. I think you're both right, but Christian's righter. IP "subnets" (the term's a bit dated given CIDR, but comes from the old subnetting extension to the original class A/B/C extension to the original original IPv4 address architecture's static 255.0.0.0 network mask) are an IP (layer 3) concept referring to a set of IP addresses sharing a particular prefix. The fact that IP subnets usually (but not always) map 1-to-1 with link-layer broadcast domains has led to sloppy terminology even in the IP world, and there are certainly other uses of the term "subnet" which mean something entirely different (eg, at one point I think the entire ARPANET was referred to as a "subnet" of the ARPANET/MILNET system, and some link layer specs do use the term "subnet" to mean link layer broadcast domain, as Bill suggests). So for precision you have to state the context (including layer) in which you're using the term, but since this is the IETF, and around here we mostly talk about IP, any use of the term "subnet" in IETF documents should generally be presumed to be talking about IP addresses with a shared prefix unless stated or proven otherwise. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Sun, 21 Mar 2004 08:07:45 +0900 Lines: 48 Sender: owner-namedroppers@ops.ietf.org References: <DAC3FCB50E31C54987CD10797DA511BA081067AB@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <20040320211845.29FEB18F8@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Sun Mar 21 00:15:07 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Rob Austein <sra@isc.org> In-Reply-To: <20040320211845.29FEB18F8@thrintun.hactrn.net> Precedence: bulk Status: O Rob Austein; > At Sat, 20 Mar 2004 12:12:48 -0800 (PST), Bill Manning wrote: > >>>Uh? There is no official definition of subnet, but the generally agreed >>>definition is "the set of addresses that shares a specified prefix". >> >> That is not generally agreed on in most circles I run in. >> The working definition here is: "a single broadcast domain" >> e.g. more layer two'ish. > > > I think you're both right, but Christian's righter. No, Christian is not. According to the CATENET model of the Internet, the Internet is composed from local networks (of RFC791). local network = subnet = link = broadcast domain The proper way to assign a local network multiple addresses is to let all the hosts (of RFC791) in the local network share multiple prefixes of equal length using identiral host parts (intra-subnet) addresses, which still means local network = subnet = link = broadcast domain Confusions caused by any other configuration are the problems of the configuration. The configuration is responsible to make the model visible from other protocols local network = subnet = link = broadcast domain > any use of the term "subnet" in IETF > documents should generally be presumed to be talking about IP > addresses with a shared prefix unless stated or proven otherwise. It's "shared prefixes", not "a shared prefix". Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Joshua Graessley <jgraessley@apple.com> Subject: Re: LLMNR authorized range Date: Mon, 22 Mar 2004 10:40:10 -0800 Lines: 104 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-741880068; protocol="application/pkcs7-signature" X-From: owner-namedroppers@ops.ietf.org Mon Mar 22 19:53:20 2004 Return-path: <owner-namedroppers@ops.ietf.org> In-Reply-To: <Pine.LNX.4.56.0403200335280.8666@internaut.com> To: namedroppers@ops.ietf.org X-Mailer: Apple Mail (2.613) Precedence: bulk Status: O --Apple-Mail-32-741880068 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Based on prior discussions and reading the draft, I was under the impression that if a DNS query fails (response with answercount of zero or a response with an error of NXDOMAIN), the query would be performed using LLMNR. It seems very plausible that someone might setup their computers to respond to LLMNR queries for names such as josh.llmnr or josh.thisdomainmustfailtoresolve. This would allow someone to locally refer to their computers by name no matter what the local addresses are and whether or not a DNS server is available. This would also be perfectly valid according to the current LLMNR spec. In this valid scenario, if there are multiple subnets on the same local network, LLMNR will fail. -josh On Mar 20, 2004, at 3:47 AM, Bernard Aboba wrote: > [Bernard Aboba] In practice, I don't believe this issue will arise. > Section 1 says: > > "The assumption is that if a network has a gateway, > then the network is able to provide DNS server configuration." > > Therefore in the "overlapping subnet" case LLMNR > assumes that the host has DNS configuration. From early > on, LLMNR has assumed that the gateway supports the > resolution of the names of local hosts using DHCPv4 and > dynamic DNS update. However, this assumption cannot be > made for IPv6 at this point. > > So if we are talking about multiple subnets on a link in > IPv4, then a conventional DNS query will be sent first, > and local names can be resolved by the gateway. If we are > talking about IPV6, then Router Advertisement enables > the host to become aware of the multiple subnets, > so that TCP-based queries can be sent on the local > link, rather than forwarded by a router. --Apple-Mail-32-741880068 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHDCCAtUw ggI+oAMCAQICAwqwATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDMwOTA1MTgyNzUwWhcNMDQwOTA0MTgyNzUwWjBGMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSMwIQYJKoZIhvcNAQkBFhRqZ3JhZXNzbGV5QGFwcGxl LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM7EXVgIo1XLZWghTrlD+Lyvh01y IH3rl7Q5SYYMwX2EQytFr3XZeubyuBy5kV3IjrDiI2R2siVX+pLCDsy7sWccyqCkqusGFRyiDyRI xb6ydueBxrAz26AfavFWmAZp+mdPt4qbXmlhoIwbb5UsqxfgO1mpFMB6Xh/FpS0ZkLMkrsYB0KFN 1STxdwNpZnlVNS7B/MlmaevcC59VzmPn6m2Ud7RTVqxYE49AYqnNDo9f/byj+RwKGjFpD+mjut8I kOpL2J0VM8KcCw9RZS3mZSTIyLYxVEgqLlrcyxo5Bwv0hde+CCYN2ZprMz3D9vymHmpGyhaJsnRe o5oNETuX2nUCAwEAAaMxMC8wHwYDVR0RBBgwFoEUamdyYWVzc2xleUBhcHBsZS5jb20wDAYDVR0T AQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBVU7HfJ6R7f/4YqQ8iEa9pqZX9A9j2MU67D43nWolj XRdeQGxCkCWOrJLG7UgtiUvas7B9mZhRYYj0KrI3xkSX+N3G/IXDHo6OLH2rJY/43PRMj8CbWkP3 rPLTBZg2guU7a2wkgRig1heEaUBinl9h5TxfDosmHXKtiWVUFuVTXDCCAz8wggKooAMCAQICAQ0w DQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0Nl cnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe Fw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688 Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIB BjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEF BQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU13 41YheILcIRk13iSx0x1G/11fZU8xggLnMIIC4wIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDCrABMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDMyMjE4NDAxMVowIwYJKoZIhvcNAQkEMRYEFDl8 9/kmuygyZVn0ISG4dH3oZKYDMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMKsAEwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDCrABMA0GCSqGSIb3DQEBAQUABIIBAKeo F6CpAFWpAvOdpM0OBoVrJenuTybGod5v/4E0F44x70U/JOeZApkZAK1dREIeT1M42J4b9iWk52CX 4mb++kOUH65xD77FH6xWNihVCHOIQF8W8+OHRO7yJSVuD6xYjahCpUVyF9KupoIzvGV1fBwz3Jml DtzmKAISHUTzXsZrLvKtvpUKcsouw3UMuiiE8GVWBsoInmA3w66Wd8EMSFmyJpVlry9lG/9VNemZ 8/+sQrWmxHBlfeweschkXXzXKqnMaliaRurH330kVS3V1lCmD340JsL8xbcpC19nGgQWPxGJlbAM ZYJSAmxRXO/uIlf95HB5A1FPEE16WGQ3Z5QAAAAAAAA= --Apple-Mail-32-741880068-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: LLMNR authorized range Date: Tue, 23 Mar 2004 15:14:16 +0900 Lines: 19 Sender: owner-namedroppers@ops.ietf.org References: <Pine.LNX.4.56.0403200335280.8666@internaut.com> <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Tue Mar 23 07:20:52 2004 Return-path: <owner-namedroppers@ops.ietf.org> 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 To: Joshua Graessley <jgraessley@apple.com> In-Reply-To: <59D40E86-7C30-11D8-B9EF-000A95B9474C@apple.com> Precedence: bulk Status: O Josh; > In this valid > scenario, if there are multiple subnets on the same local network, LLMNR > will fail. With IPv6, there is no reason not to share all the prefixes of a link by all the hosts on the link, which means there is only a single subnet. Masataka Ohta -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: "Olaf M. Kolkman" <olaf@ripe.net> Subject: Advance: draft-ietf-dnsext-nsec-rdata-05.txt Date: Wed, 24 Mar 2004 09:16:56 +0100 Organization: RIPE NCC Lines: 98 Sender: owner-namedroppers@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: namedroppers@ops.ietf.org, jakob@schlyter.se X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 09:28:10 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: "Thomas Narten" <narten@us.ibm.com>, "Margaret Wasserman" <margaret@thingmagic.com> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i686-pc-linux-gnu) X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.015749 / 0.0 / 0.0 / disabled X-RIPE-Signature: d65dbcaea04193b902f993fc8813be54 Precedence: bulk Status: O Thomas, Margaret, Hereby the advancement questionnaire (www.mip4.org/2004/draft-writeup-items.html) for "DNSSEC NSEC RDATA Format" draft-ietf-dnsext-nsec-rdata-05.txt. The questionaire serves as a request to advance the document to proposed standard. 1. Chairs review. The chair responsible for tracking this document has read it and considers it ready for IESG review. 2. Working Group member review. The proposed format has been discussed on the list as well as during the IETF 58 meeting. The content of the comments received during last call indicate that a number of people have closely reviewed the document. 3. Is more review from a particular perspective needed. In the chairs opinion not. 4. Specific Issues and concerns the AD/IESG should be aware of. The document _only_ changes a format. The security section therefore does not go into the details of NSEC security. Note however that the text describing this format will be directly 'cut-n-pasted' into the dnssec-bis document set. The dnssec-bis intro document set covers the security considerations, e.g. NSEC cain walking, in more detail. 5. How solid is the WG consensus. The format was chosen during IETF58. The document itself got explicit consensus from only a few individuals. On the other hand this is has not been contentious issue. 6. Thread for appeal. None. 7. _all_ ID nits addressed. All are addressed. 8. References There is a normative reference to an I-D that has been advanced. Also not that this document will be merged and obsoleted by the dnssec-bis document set. 9. Writeup. Technical Summary To prevent the introduction of an extension mechanism once DNSSEC has a deployed base this document redefines the wire format of the "Type Bit Map" field in the NSEC resource record RDATA format to cover the full RR type space. The new format of the type bitmap is easy to implement, can cover the full range of type codes, is economical in the common case and has a maximum size of approximately 8.5 kilobytes. Efficient searching of the type bitmap for presence of a type had a lower priority. Working Group Summary The format was chosen from 6 different candidates that were presented to the working group. There is consensus on the chosen representation. Protocol Quality There are 3 independent implementations of this format. 1 implementation provides both a server and a client, 1 implementation only a server and 1 implementation only a client. These interoperate. -- Olaf Kolkman Olafur Gudmundsson -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Rob Austein <sra@isc.org> Subject: DNSSECbis Q-30: DNAME awareness Date: Wed, 24 Mar 2004 14:08:52 -0500 Lines: 61 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Wed Mar 24 20:23:13 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: namedroppers@ops.ietf.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Precedence: bulk Status: O Q-30: Should the DNSSECbis specs require DNAME-awareness? Approximate text to be added if the WG agrees: [To be inserted somewhere in Section 3.x of -protocol] A security-aware name server which synthesizes CNAME RRs from DNAME RRs as described in RFC 2672 SHOULD NOT generate signatures for the synthesized CNAMEs. [To be inserted somewhere in Section 4.x of -protocol] A validating security-aware resolver MUST treat the signature of a valid signed DNAME RR as also covering unsigned CNAME RRs which could have been synthesized from the DNAME RR as described in RFC-2672, at least to the extent of not rejecting a response message solely because it contains such CNAME RRs. The resolver MAY retain such CNAME RRs in its cache or in the answers it hands back, but is not required to do so. Background: RFC-2672 recommends that name servers synthesize CNAME RRs based on DNAME RRs, for backwards compatability with DNAME-oblivious resolvers. RFC-2672 goes on to suggest that DNSSEC-capable name servers might want to keep the zone key online in order to sign these synthesized CNAME RRs, for the benefit of security-aware DNAME-oblivious resolvers. This has obvious security issues, and also adds some complexity. In fairness, note that when RFC-2672 came out, DNSSEC-classic (RFC 2535) had already shipped, so one could argue that this was the least bad backwards compatability hack available to the author of RFC-2672. So the question here is whether there is any need for DNSSECbis to support security-aware DNAME-oblivious implementations. Specifically, can we eliminate the case of a security-aware DNAME-oblivious resolver expecting name servers to synthesize signed CNAME RRs from signed DNAME RRs? DNSSECbis question Q-27 already covered part of this space, by allowing a security-aware recursive name server to set the AD bit for responses containing synthesized CNAME RRs. Q-27 did not, however address whether name servers should attempt to sign synthesized CNAME records or whether resolvers should expect to receive signatures for synthesized CNAME records. Whether a validating resolver choses to retain synthesized CNAMEs or not appears to be an implementation and local policy choice, since CNAME synthesis itself is only a SHOULD in RFC-2672 and thus not something on which any DNS-using software can depend. Deadline and default: Per instructions from the WG chairs, this question will time out on 4 April 2003 with a default action to accept these changes. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Jakob Schlyter <jakob@rfc.se> Subject: Re: Advancing RFC3597 Unknown Type support --> to Draft Standard Date: Thu, 25 Mar 2004 09:57:08 +0100 (CET) Lines: 14 Sender: owner-namedroppers@ops.ietf.org References: <6.0.3.0.2.20040228124513.02f35bc8@localhost> <6.0.3.0.2.20040312111536.02678528@localhost> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-From: owner-namedroppers@ops.ietf.org Thu Mar 25 10:11:21 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF DNSEXT WG <namedroppers@ops.ietf.org> In-Reply-To: <6.0.3.0.2.20040312111536.02678528@localhost> Precedence: bulk Status: O interested parties should visit http://www.rfc.se/interop3597/ and join the mailing-list at http://www.rfc.se/mailman/listinfo/interop3597. before testing starts, I need help with filling the test zone (published as interop3597.rfc.se) with useful, and wierd, data. please send suggestions me or to the list above. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Edward Lewis <edlewis@arin.net> Subject: Re: DNSSECbis Q-30: DNAME awareness Date: Fri, 26 Mar 2004 11:33:53 -0500 Lines: 35 Sender: owner-namedroppers@ops.ietf.org References: <200402202051.i1KKpIxS025885@rotala.raleigh.ibm.com> <20040317010352.E2A7518E3@thrintun.hactrn.net> <20040323233046.6F2E218C8@thrintun.hactrn.net> <20040324190852.67C5618C9@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 17:51:44 2004 Return-path: <owner-namedroppers@ops.ietf.org> X-Sender: edlewis@127.0.0.1 In-Reply-To: <20040324190852.67C5618C9@thrintun.hactrn.net> To: Rob Austein <sra@isc.org> Precedence: bulk Status: O I like what these words say. At 14:08 -0500 3/24/04, Rob Austein wrote: >Q-30: Should the DNSSECbis specs require DNAME-awareness? > >Approximate text to be added if the WG agrees: > > [To be inserted somewhere in Section 3.x of -protocol] > > A security-aware name server which synthesizes CNAME RRs from DNAME > RRs as described in RFC 2672 SHOULD NOT generate signatures for the > synthesized CNAMEs. > > [To be inserted somewhere in Section 4.x of -protocol] > > A validating security-aware resolver MUST treat the signature of a > valid signed DNAME RR as also covering unsigned CNAME RRs which > could have been synthesized from the DNAME RR as described in > RFC-2672, at least to the extent of not rejecting a response > message solely because it contains such CNAME RRs. The resolver > MAY retain such CNAME RRs in its cache or in the answers it hands > back, but is not required to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer If time travel were ever to be realized, public key crypto is toast. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/> From owner-namedroppers@ops.ietf.org Fri Dec 29 10:45:51 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-30.txt Date: Fri, 26 Mar 2004 15:49:27 -0500 Lines: 96 Sender: owner-namedroppers@ops.ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: namedroppers@ops.ietf.org X-From: owner-namedroppers@ops.ietf.org Fri Mar 26 22:06:22 2004 Return-path: <owner-namedroppers@ops.ietf.org> To: IETF-Announce: ; Precedence: bulk Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, et al. Filename : draft-ietf-dnsext-mdns-30.txt Pages : 26 Date : 2004-3-26 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name System (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. The goal of LLMNR is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-30.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-30.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-30.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-30.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-26161128.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>