From owner-namedroppers@ops.ietf.org Thu Aug 1 06:18:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18623 for ; Thu, 1 Aug 2002 06:18:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17aCkZ-00055K-00 for namedroppers-data@psg.com; Thu, 01 Aug 2002 03:00:07 -0700 Received: from randy by psg.com with local (Exim 3.36 #1) id 17aCkS-00054h-00 for namedroppers@ops.ietf.org; Thu, 01 Aug 2002 03:00:00 -0700 To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Thu, 01 Aug 2002 03:00:00 -0700 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. 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. 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, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. questions or concerns related to the acceptance or rejection of specific messages to the namedroppers mailing list should first be discussed with the wg chairs, with followup appeals using the normal appeals process of rfc 2026 (i.e., follup with area directors, then iesg, etc.). there is a mailing list for the discussion of ietf processes, which includes any general discussion of the moderation of ietf mailing lists. it is poised@lists.tislabs.com --- NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 2 18:33:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09794 for ; Fri, 2 Aug 2002 18:33:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17akhk-000GGD-00 for namedroppers-data@psg.com; Fri, 02 Aug 2002 15:15:28 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17akhe-000GFy-00 for namedroppers@ops.ietf.org; Fri, 02 Aug 2002 15:15:23 -0700 Received: from h133n1c1o299.bredband.skanova.com (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g72MFJkd015757 for ; Sat, 3 Aug 2002 00:15:20 +0200 To: namedroppers@ops.ietf.org Subject: Comment on draft-ietf-dnsext-dnssec-records X-Hashcash: 020802:namedroppers@ops.ietf.org:b5c993265e2fcc60 From: Simon Josefsson Date: Sat, 03 Aug 2002 00:15:19 +0200 Message-ID: Lines: 57 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Informed Management (RC2), i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk (I forgot which list you were supposed to send comments on this draft to, perhaps it would make sense to mention the list in the draft. Feel free to forward this wherever appropriate.) Tracking down the CERT RR's algorithm field's mnemonic names, I find in RFC 2538: ,---- | The algorithm field is represented as an unsigned integer or a | mnemonic symbol as listed in [RFC 2535]. `---- Since I gather draft-ietf-dnsext-dnssec-records-01 is replacing RFC 2535, I read it instead and find: ,---- | The Algorithm Field is represented as an unsigned integer or as | mnemonic specified. The mnemonic is listed in the document defining | the algorithm. | ... | VALUE Algorithm RFC STATUS | 0 Reserved - - | 1 RSA/MD5 RFC 2536 NOT RECOMMENDED ^ this should be RFC 2537 | 2 Diffie-Hellman RFC 2539 OPTIONAL | 3 DSA RFC 2536 MANDATORY | 4 elliptic curve Work in Progress | 5 RSA/SHA1 RFC 3110 MANDATORY | 6-251 available for assignment - | 252 reserved - indirect keys | 253 private - domain name | 254 private - OID | 255 reserved - - `---- But looking into these RFCs for the mnemonic name isn't very enlightening: RFC 2536, 2537 and draft-ietf-dnsext-ecc-key do not seem to include a mnemonic, although a table in RFC 2535 covers for them. The table isn't present in draft-ietf-dnsext-dnssec-records though. RFC 3110 doesn't include a mnemonic, and the KEY RR algorithm field value used (5) there isn't in the table in RFC 2535 either. The mnemonic names used in the text representation of DNSSEC RR's seems to just have vanished. Or my grepping capabilities are poor. IMO draft-ietf-dnsext-dnssec-records should include a chapter "ASCII Representation of Security RRs" like the one in RFC 2535 and not defer the mnemonic to other documents, as it is clear that those other documents don't contain the answer. IMO2 draft-ietf-dnsext-dnssec-records should contain CERT too. Taking RFC 2538 and fixing a few unclear spots (e.g., whether the PGP CERT RRDATA should include the checksum field or not) should be sufficient. I'll volunteer to do it if human resources is the limiting factor. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 2 20:20:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12431 for ; Fri, 2 Aug 2002 20:20:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17amSG-000IQ4-00 for namedroppers-data@psg.com; Fri, 02 Aug 2002 17:07:36 -0700 Received: from tornado.acmebw.com ([209.8.5.250] helo=tornado.kahlerlarson.org) by psg.com with esmtp (Exim 3.36 #1) id 17amSB-000IPt-00 for namedroppers@ops.ietf.org; Fri, 02 Aug 2002 17:07:32 -0700 Received: from whirlwind (whirlwind.kahlerlarson.org [192.168.0.128]) by tornado.kahlerlarson.org (Postfix) with SMTP id 62171100EBA; Fri, 2 Aug 2002 20:07:30 -0400 (EDT) Message-ID: <044f01c23a81$d347b780$8000a8c0@whirlwind> Reply-To: "Matt Larson" From: "Matt Larson" To: , "Simon Josefsson" References: Subject: Re: Comment on draft-ietf-dnsext-dnssec-records Date: Fri, 2 Aug 2002 20:07:58 -0400 Organization: VeriSign Global Registry Services MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Tracking down the CERT RR's algorithm field's mnemonic names, I find > in RFC 2538: Thanks for pointing that out. One of the things the editors are going to do is take a thorough pass through RFC 2535 and look for omissions in the new documents. We're going to make sure every RFC 2119 word in 2535 is covered in the rewrite, as well. > IMO2 draft-ietf-dnsext-dnssec-records should contain CERT too. Taking > RFC 2538 and fixing a few unclear spots (e.g., whether the PGP CERT > RRDATA should include the checksum field or not) should be sufficient. > I'll volunteer to do it if human resources is the limiting factor. That's out of scope. CERT's never been a part of DNSSEC, even when you expand the term to include TSIG. And the DNSSEC rewrite is an editorial exercise: when we find protocol issues, we bring them to namedroppers. What you describe sounds protocolish and would need namedroppers discussion, anyway. Matt -- Matt Larson VeriSign Global Registry Services -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 2 20:34:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12748 for ; Fri, 2 Aug 2002 20:34:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17amiw-000IkU-00 for namedroppers-data@psg.com; Fri, 02 Aug 2002 17:24:50 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17amis-000IkI-00 for namedroppers@ops.ietf.org; Fri, 02 Aug 2002 17:24:46 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17amis-000DnF-00 for namedroppers@ops.ietf.org; Fri, 02 Aug 2002 17:24:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: From: "FORENSICS.ORG Security Coordinator" To: Cc: Subject: Input needed on DNSSEC for upcoming security advisory Date: Fri, 2 Aug 2002 14:29:58 -1000 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] To Whom It May Interest: A DNS-based security vulnerability exists that has not yet been disclosed publicly. The vulnerability was discovered by a third party and FORENSICS.ORG is acting in the capacity of COORDINATOR pursuant to the Responsible Vulnerability Disclosure Process, referenced below: http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-0 0.txt We are in need of input from persons working with DNSSEC in connection with the planned ADVISORY. Although DNSSEC will not completely solve this particular problem, it is important to include details of the risk factors that ARE mitigated partially when DNSSEC is employed. The most likely security patch will involve mandatory updates to every resolver. In order to discuss the technical details of the threat in a responsible manner, it is necessary for us to disclose the vulnerability in full to a small number of trustworthy individuals with expertise in certain subject areas, DNSSEC being one of these areas. If you are interested in contributing to the content of our forthcoming ADVISORY, please contact us by Thursday, August 8th for consideration by our team of your eligibility for early disclosure. Thank you. FORENSICS.ORG Security Coordinator -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 3 06:36:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01759 for ; Sat, 3 Aug 2002 06:36:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17aw23-0004LD-00 for namedroppers-data@psg.com; Sat, 03 Aug 2002 03:21:11 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17aw1w-0004L2-00 for namedroppers@ops.ietf.org; Sat, 03 Aug 2002 03:21:04 -0700 Received: from h133n1c1o299.bredband.skanova.com (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g73AL0kd023081 for ; Sat, 3 Aug 2002 12:21:01 +0200 To: Subject: Re: Comment on draft-ietf-dnsext-dnssec-records References: <044f01c23a81$d347b780$8000a8c0@whirlwind> X-Hashcash: 020803:namedroppers@ops.ietf.org:5dda237d0066ffbb From: Simon Josefsson Date: Sat, 03 Aug 2002 12:21:00 +0200 In-Reply-To: <044f01c23a81$d347b780$8000a8c0@whirlwind> ("Matt Larson"'s message of "Fri, 2 Aug 2002 20:07:58 -0400") Message-ID: Lines: 26 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Informed Management (RC2), i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Matt Larson" writes: >> IMO2 draft-ietf-dnsext-dnssec-records should contain CERT too. Taking >> RFC 2538 and fixing a few unclear spots (e.g., whether the PGP CERT >> RRDATA should include the checksum field or not) should be sufficient. >> I'll volunteer to do it if human resources is the limiting factor. > > That's out of scope. CERT's never been a part of DNSSEC, even when you > expand the term to include TSIG. And the DNSSEC rewrite is an editorial > exercise: when we find protocol issues, we bring them to namedroppers. What > you describe sounds protocolish and would need namedroppers discussion, > anyway. Anyone with an opinion on whether the RRDATA should include the OpenPGP checksum or not? Essentially I guess the question amounts to whether the RRdata should contain the binary or the ASCII armored version of OpenPGP certificates. I am using binary, but RFC 2538 is not clear that this is what is intended. Discussion on what to do when OpenPGP data exceeds the RRdata limitation should also be included. I'll post the solution I'm using soon. I'm also storing OpenPGP key revocation signatures using the CERT "PGP" type, which might not be intended either. Perhaps a new CERT type for key revocation signatures should be allocated. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 3 13:56:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08164 for ; Sat, 3 Aug 2002 13:56:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17b2rY-0009ZX-00 for namedroppers-data@psg.com; Sat, 03 Aug 2002 10:38:48 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17b2rT-0009ZM-00 for namedroppers@ops.ietf.org; Sat, 03 Aug 2002 10:38:43 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17b2rT-000EC2-00 for namedroppers@ops.ietf.org; Sat, 03 Aug 2002 10:38:43 -0700 Message-Id: <200208031717.g73HHaq0015765@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Fri, 02 Aug 2002 22:28:46 EDT." <3C1E3607B37295439F7C409EFBA08E680E2D42@US-Columbia-CIST.mail.saic.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: namedroppers@ops.ietf.org, design@lists.freeswan.org cc: "Loomis, Rip" Subject: the KEY debate Date: Sat, 03 Aug 2002 13:17:36 -0400 From: Michael Richardson X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,LINES_OF_YELLING,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Loomis," == Loomis, Rip writes: Loomis> First, I agree with Matt's recommendation to take the Loomis> discussion to namedroppers...but as another way to state what Loomis> Matt already stated quite well above, it's not that having Loomis> lots of non-DNSSEC info in KEY records "breaks DNSSEC". It's Loomis> that having to sort through all the possible cruft at the top Loomis> of a zone and look for the "right" key causes the DNSSEC Loomis> signature verification process to take too long. There's not Loomis> much IMHO that can realistically be done to engineer either Loomis> the software or the protocol to fix this...other than limiting Loomis> the KEY record as that I-D discusses, and using APPKEY or Loomis> something similar to store the non-DNS application keys. Loomis> If anyone sees any holes in my summary above...ask me on Loomis> namedroppers. Let's be clear. Some people who are not application developers, and who have no deployed code, want to obsolete KEY EVERYWHERE for non-DNS use because they think that it might cause problems if put at the apex of a zone. Who wants to put non-DNS KEY records at the apex of a zone? What application needs it there? 1) IPsec. nope, needed with host records or reverse records. 2) SSH/telnet. nope, same requirements as IPsec. 3) HTTPS. maybe for supporting "example.com" as an alias for www.example.com, but due to HTTPS limitations, would require a seperate IP address from www.example.com (so that the server could use the proper certificate) A major hassle, and it is unlikely that this is going to matter as long as we do web certificates with X.509 CAs. 4) SMTP. Put an MX record there. Use the KEY record attached to the MX record, and authenticate the server. You might think that you want to authenticate the zone's key, not the server's key. Well, that doesn't work, because you don't know which of potentially many MX servers you will talk to. You could give them all the same private key, but that would be a mistake, given that for best reliability, you want the MXs in different places, run by different people. So, we are left with someone who wants to do: "ssh example.com" rather than "ssh host1.example.com" Of course, they might put 100 A records at "example.com". Will DNSSEC deal with this? Will it be cause the signature verification process to take too long? Massey/Rose write: >differences in more detail. Combining these very different types >of keys into a single sub-typed resource record adds unnecessary >complexity and increases the potential for implementation and deployment >errors. Limited experimental deployment has shown that application >keys stored in KEY records are problematic. Also, they write: >The following table summarizes some of the differences between DNSSEC >keys and Application keys: > > 1. They serve different purposes. > > 2. They are managed by different administrators. > > 3. They are authenticated according to different rules. > > 4. Nameservers use different rules when including them in responses. > > 5. Resolvers process them in different ways. > > 6. Faults/key compromises have different consequences. #1 is confused about the purpose of DNS. DNS serves to map names into things that the network layer can use to connect with. DNS is to permit people to type "telnet host1.example.com" and have it work. In an age of SECURITY, that means that we all of the network blobs required to make that connection. These are *not* APPLICATION keys because "telnet" is not an application, it is a session layer protocol. Emacs is an application. Word is an application. #2 is also confused when it comes to IPsec and SSH keys. IP addresses are FREQUENTLY managed by the same people who manage the hosts that they are assigned to. Even when protocols like DHCP is used to assign IP addresses, we have demonstrated that making the link to the public key can be done at the same time. There are two WGs that want to leverage this kind of thing. They further list #3 - that keys would be exchanged with the parent zone. DS gets rid of that, so this comment is moot. #4 is a concern - but, you MAY NOT deprecate a facility without having provided a replacement facility. The SRV and NAPTR suggestions are unacceptable, as they introduce yet another round trip. There are only two methods which will work: 1) special names. "ipsec.example.com" - might as well use KEY. 2) a RR for each application. Claim #5 is totally confused. They keep saying how application keys must not be used to authenticate data. They then go on to explain how writing application is "hard" because we might have to do DNSSEC ourselves. Not only do want to do that, but we *insist* on doing it. Claim #6 is again totally confused. Where does it say that application keys are used to authenticate DNS data? In general, we regard this draft as a denial of service attack on the effort to secure the Internet. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUwQJIqHRg3pndX9AQFpAAQAyJdloYAEknW4sd+SjXesiUxkVyTk+sEY FBY2LpBQreagS4rF2heLT3GxY+nnt7I6n2okOlPVcdiKveglAZ3Crz6W8LsB/vYf 6LXnNh9QpHqyJ2g7UF8EByPNjL8+NgC1ofmd3IBftXyLTo7y9sw6VbfxihXBXV+M fPEJHcKBWS4= =cDY3 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 3 15:03:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09143 for ; Sat, 3 Aug 2002 15:03:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17b3zN-000APg-00 for namedroppers-data@psg.com; Sat, 03 Aug 2002 11:50:57 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17b3zJ-000APV-00 for namedroppers@ops.ietf.org; Sat, 03 Aug 2002 11:50:53 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 9D8281996; Sat, 3 Aug 2002 14:50:39 -0400 (EDT) Date: Sat, 03 Aug 2002 14:50:39 -0400 From: Rob Austein To: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: the KEY debate In-Reply-To: <200208031717.g73HHaq0015765@marajade.sandelman.ottawa.on.ca> References: <3C1E3607B37295439F7C409EFBA08E680E2D42@US-Columbia-CIST.mail.saic.com> <200208031717.g73HHaq0015765@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020803185039.9D8281996@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I know I'm going to regret this, but.... There is a specific problem with using the KEY RR type for things other than DNSSEC's own internal keying. It's called the "sub-typing problem" and has been discussed namedroppers many times before, please check the archives if you don't already understand the problem. This is a totally separate discussion from whether putting keys for things other than DNSSEC itself into the DNS is a good or bad idea. If we stipulate that such keys should use a different RR type, I'm relatively agnostic on the subject. Confusing the two issues does not help anybody. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 3 15:49:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09806 for ; Sat, 3 Aug 2002 15:49:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17b4of-000B9L-00 for namedroppers-data@psg.com; Sat, 03 Aug 2002 12:43:57 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17b4oa-000B9A-00 for namedroppers@ops.ietf.org; Sat, 03 Aug 2002 12:43:52 -0700 Received: from h133n1c1o299.bredband.skanova.com (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g73Jhdkd026904; Sat, 3 Aug 2002 21:43:40 +0200 To: Rob Austein Cc: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: the KEY debate References: <3C1E3607B37295439F7C409EFBA08E680E2D42@US-Columbia-CIST.mail.saic.com> <200208031717.g73HHaq0015765@marajade.sandelman.ottawa.on.ca> <20020803185039.9D8281996@thrintun.hactrn.net> X-Hashcash: 020803:sra@hactrn.net:1a393c71ec211541 X-Hashcash: 020803:namedroppers@ops.ietf.org:b402736e694ff398 X-Hashcash: 020803:design@lists.freeswan.org:6d147512ca148857 From: Simon Josefsson Date: Sat, 03 Aug 2002 21:43:39 +0200 In-Reply-To: <20020803185039.9D8281996@thrintun.hactrn.net> (Rob Austein's message of "Sat, 03 Aug 2002 14:50:39 -0400") Message-ID: Lines: 24 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Informed Management (RC2), i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Rob Austein writes: > I know I'm going to regret this, but.... > > There is a specific problem with using the KEY RR type for things > other than DNSSEC's own internal keying. It's called the "sub-typing > problem" and has been discussed namedroppers many times before, please > check the archives if you don't already understand the problem. > > This is a totally separate discussion from whether putting keys for > things other than DNSSEC itself into the DNS is a good or bad idea. > If we stipulate that such keys should use a different RR type, I'm > relatively agnostic on the subject. > > Confusing the two issues does not help anybody. Agreed. But removing functionality does not help anybody either, that's why I suggested shipping restrict-key draft together with a migration path in the form of APPKEY, an updated CERT RR specification, or a specification stating that applications should define their own RR for keying material, or whatever approach is preferred by the DNS illuminati. Then the restrict-key people are happy, and the application keys in DNS community is happy. Why is that solution unreasonable? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 3 18:35:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11797 for ; Sat, 3 Aug 2002 18:35:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17b7H3-000DN3-00 for namedroppers-data@psg.com; Sat, 03 Aug 2002 15:21:25 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17b7Gy-000DMr-00 for namedroppers@ops.ietf.org; Sat, 03 Aug 2002 15:21:20 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 03F9A18C9; Sat, 3 Aug 2002 18:21:13 -0400 (EDT) Date: Sat, 03 Aug 2002 18:21:13 -0400 From: Rob Austein To: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: the KEY debate In-Reply-To: References: <3C1E3607B37295439F7C409EFBA08E680E2D42@US-Columbia-CIST.mail.saic.com> <200208031717.g73HHaq0015765@marajade.sandelman.ottawa.on.ca> <20020803185039.9D8281996@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020803222114.03F9A18C9@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sat, 03 Aug 2002 21:43:39 +0200, Simon Josefsson wrote: > > Agreed. But removing functionality does not help anybody either, > that's why I suggested shipping restrict-key draft together with a > migration path in the form of APPKEY, an updated CERT RR > specification, or a specification stating that applications should > define their own RR for keying material, or whatever approach is > preferred by the DNS illuminati. Then the restrict-key people are > happy, and the application keys in DNS community is happy. Why is > that solution unreasonable? If the two halves of this proposal were at equal stages of readiness, this would be a reasonable way forward. Unfortunately, they're not: - The reasons for updating the DNSSEC protocol spec to restrict use of the KEY RR type to DNSSEC internal use have been well understood for years, the DNSEXT WG is actively trying to get the updated DNSSEC spec done and the protocol deployed, and from the DNSSEC core protocol persepctive, there's no reason to delay updating the spec. - The APPKEY/CERT/whatever stuff isn't as far along. No doubt you recall the SIKED BOF this year in Minneapolis, at which several people asked some pretty fundamental questions about the problem spaces people were trying to solve and what the underlying trust models were. No good answers at that time. Not saying there -aren't- good answers, but at that BOF there didn't appear to be any kind of consensus on the subject. So proponants of this idea have some work cut out that either has not yet been done at all yet or has been done but has not yet been walked through the IETF process. Finally, given the above, I have to wonder who would really benefit from delaying the cleanup action on the core DNSSEC spec until the other stuff is done. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 3 19:25:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12407 for ; Sat, 3 Aug 2002 19:25:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17b8BU-000ELk-00 for namedroppers-data@psg.com; Sat, 03 Aug 2002 16:19:44 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17b8BP-000ELX-00 for namedroppers@ops.ietf.org; Sat, 03 Aug 2002 16:19:39 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g73NJ8gs002916; Sun, 4 Aug 2002 09:19:12 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208032319.g73NJ8gs002916@drugs.dv.isc.org> To: Simon Josefsson Cc: Rob Austein , namedroppers@ops.ietf.org, design@lists.freeswan.org From: Mark.Andrews@isc.org Subject: Re: the KEY debate In-reply-to: Your message of "Sat, 03 Aug 2002 21:43:39 +0200." Date: Sun, 04 Aug 2002 09:19:08 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Rob Austein writes: > > > I know I'm going to regret this, but.... > > > > There is a specific problem with using the KEY RR type for things > > other than DNSSEC's own internal keying. It's called the "sub-typing > > problem" and has been discussed namedroppers many times before, please > > check the archives if you don't already understand the problem. > > > > This is a totally separate discussion from whether putting keys for > > things other than DNSSEC itself into the DNS is a good or bad idea. > > If we stipulate that such keys should use a different RR type, I'm > > relatively agnostic on the subject. > > > > Confusing the two issues does not help anybody. > > Agreed. But removing functionality does not help anybody either, > that's why I suggested shipping restrict-key draft together with a > migration path in the form of APPKEY, an updated CERT RR > specification, or a specification stating that applications should > define their own RR for keying material, or whatever approach is > preferred by the DNS illuminati. Then the restrict-key people are > happy, and the application keys in DNS community is happy. Why is > that solution unreasonable? We have basically already made a decision about whether we should have different type or not for application keys. DNSSEC is one application and the decision was made to give it its own type by removing the other uses. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Aug 4 14:31:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10246 for ; Sun, 4 Aug 2002 14:31:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bPtR-000274-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 11:14:17 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17bPtN-00026t-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 11:14:13 -0700 Received: from isi.edu (c1-vpn4.isi.edu [128.9.176.34]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g74IE7r09202; Sun, 4 Aug 2002 11:14:07 -0700 (PDT) Message-ID: <3D4D6F2D.FEB3BDCF@isi.edu> Date: Sun, 04 Aug 2002 14:15:09 -0400 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Richardson CC: namedroppers@ops.ietf.org, design@lists.freeswan.org, "Loomis, Rip" Subject: Re: the KEY debate References: <200208031717.g73HHaq0015765@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I started a more detailed in-line response to the various claims about key restrict but the main points of this discussion remain the same as the last couple times.... - key restrict does not prohibit storing application keys in the DNS and key restrict explicitly states that in a couple places. - key restrict does say the KEY record should not be used to store application keys and it does eliminate KEY record subtypes. - subtypes are a bad way to overload a DNS record and there is consensus that a subtyped KEY record is not the right way to store applications keys in the DNS. There is an orthogonal problem of what is the best way to store application keys in the DNS. Key restrict does not identify one approach as "the solution" for storing application keys, but note that key restrict is 100% compatible with all the approaches being discussed. There are legitimate open issues and trade-offs being considered and there are places to discuss those issues. Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Aug 4 15:10:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11044 for ; Sun, 4 Aug 2002 15:10:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bQgQ-0002wB-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 12:04:54 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17bQgM-0002w0-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 12:04:50 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g74C4wY06720; Sun, 4 Aug 2002 12:04:58 GMT Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g74J4f2d000704; Sun, 4 Aug 2002 12:04:41 -0700 (MST) Date: Sun, 4 Aug 2002 12:04:40 -0700 Subject: Re: the KEY debate Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Loomis, Rip" , design@lists.freeswan.org, namedroppers@ops.ietf.org, Michael Richardson To: Dan Massey From: Ted Lemon In-Reply-To: <3D4D6F2D.FEB3BDCF@isi.edu> Message-Id: <074EBA95-A7DD-11D6-9B8C-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would just like to interject at this point that if the WG's goal is to find the *best* way to put keys in the DNS, we are doomed to fail. The best is the enemy of good enough. The KEY record was not good enough, and I think there's consensus on that, but we will never find out what the best is if we don't come up with something that's good enough, try it, and learn from it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Aug 4 15:48:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11575 for ; Sun, 4 Aug 2002 15:48:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bRFQ-0003aN-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 12:41:04 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17bRFM-0003aC-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 12:41:00 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id E89FA28B6C for ; Sun, 4 Aug 2002 19:40:59 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: the KEY debate In-Reply-To: Message from Ted Lemon of "Sun, 04 Aug 2002 12:04:40 MST." <074EBA95-A7DD-11D6-9B8C-00039317663C@nominum.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Sun, 04 Aug 2002 19:40:59 +0000 Message-Id: <20020804194059.E89FA28B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I would just like to interject at this point that if the WG's goal is to > find the *best* way to put keys in the DNS, we are doomed to fail. The > best is the enemy of good enough. The KEY record was not good enough, and > I think there's consensus on that, but we will never find out what the best > is if we don't come up with something that's good enough, try it, and learn > from it. the working group had better show some leadership, in that case. saying that KEY is wrong for applications due to subtyping is merely _true_. let's try for _helpful_. 1. subtype with subdomains that have leading underscores, like SRV does. 2. carry the key data itself in TXT RR's. if someone writes up a draft showing how openpgp keys and x509 certs can be carried in that fashion, then this whole debate will be over, because you will have demonstrated some leadership. until you do that, all you're doing is trying to take something away from the "appdev" community, and they will fight you to the last binary digit, regardless of the truth of your arguments. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Aug 4 20:31:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16554 for ; Sun, 4 Aug 2002 20:31:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bVYM-0008mX-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 17:16:54 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17bVYF-0008ld-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 17:16:48 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g750GKgs037694; Mon, 5 Aug 2002 10:16:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208050016.g750GKgs037694@drugs.dv.isc.org> To: Michael Richardson Cc: Simon Josefsson , namedroppers@ops.ietf.org, design@lists.freeswan.org From: Mark.Andrews@isc.org Subject: Re: [Design] Re: the KEY debate In-reply-to: Your message of "Sun, 04 Aug 2002 13:01:16 -0400." <200208041701.g74H1GkQ008084@marajade.sandelman.ottawa.on.ca> Date: Mon, 05 Aug 2002 10:16:20 +1000 X-Spam-Status: No, hits=-6.0 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Mark" == Mark Andrews writes: > Mark> We have basically already made a decision about whether we > Mark> should have different type or not for application keys. > Mark> DNSSEC is one application and the decision was made to > Mark> give it its own type by removing the other uses. > > "we", being whom? > I do not agree that there is any consensus on this. > I will agree that there is some concern with KEY records at the APEX. > > The problem was raised in Salt Lake City. > > It would be nice to ask for a specific sub-type, but frankly, I don't care. > Sorting through the types isn't that big of a deal. Given the sizes of the > resource records and the desired presence of DNSSEC, the answers may well be > large already. > > I was unable to attend the SIKED BOF. The reports that I heard indicate > that a small number of people who hadn't actually read any of the drafts that > specify KEY did a bunch of handwaving on how there was no trust model. > > I see these as efforts to derail DNSSEC deployment. > I'm saying that a *implicit* decision was made. The working group made the decision by separating KEY for DNSSEC use only. That set a precedent. If one application (DNSSEC) needs a seperate type to store keys then it can be argued that all applications that needs keys need seperate seperate types. There is no shortage of types. If we exhaust IN then we can add another class. Mark > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architec > t[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device drive > r[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); > [ > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: latin1 > Comment: Finger me for keys > > iQCVAwUBPU1d2YqHRg3pndX9AQFR7AP+JyjTi+mWqYOrSOOqsNXcD86y1EaRvyTR > Jxf9hwNd+BLTkR7vDqZT8lRhIb3eX1dNhvI8u6YlOYqwx8yd44GZChdsu5INcgzE > T5TK+350q+mU829HRSfxntKvmGN4HnmS8nQEZA2IYeUt1ZobRgrZcAXzM2BCvTT5 > 6pGsu2flF/E= > =J88s > -----END PGP SIGNATURE----- -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Aug 4 20:37:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16615 for ; Sun, 4 Aug 2002 20:37:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bVVO-0008hu-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 17:13:50 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17bVVJ-0008hG-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 17:13:46 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 482E4191D; Sun, 4 Aug 2002 20:13:44 -0400 (EDT) Date: Sun, 04 Aug 2002 20:13:44 -0400 From: Rob Austein To: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: [Design] Re: the KEY debate In-Reply-To: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> References: <20020803185039.9D8281996@thrintun.hactrn.net> <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020805001344.482E4191D@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sun, 04 Aug 2002 12:53:03 -0400, Michael Richardson wrote: > > Rob> There is a specific problem with using the KEY RR type for things > Rob> other than DNSSEC's own internal keying. It's called the "sub-typing > Rob> problem" > > Yes, and obsoleting KEY does nothing to solve this problem. Sorry, wrong. (a) it removes the need for DNSSEC-aware resolvers to sift through RRsets picking out individual keys by subtype codes, and (b) it reduces the chances that KEY RRsets will be large enough to trigger DNS message truncation and fallback to TCP. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Aug 4 23:34:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20310 for ; Sun, 4 Aug 2002 23:34:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bYTx-000Crh-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 20:24:33 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17bYTs-000CrM-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 20:24:28 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 156433 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 22:21:44 -0500 Message-ID: <3D4DEFE5.5030102@ehsco.com> Date: Sun, 04 Aug 2002 22:24:21 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers Subject: noodling, looking for stats Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.5 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Following the discussion on the ietf list last week, I've been thinking about ways to quantify the degree of cache misses. It seems that a reasonable way to determine an approximation of this would be by comparing the number of answers for some TLD provided at the root with the number of queries processed for that TLD. For example, how many times in a given hour did x.root-servers.net provide a referral to .com, and how many queries did x.gtld-servers.net get for .com in that same hour. This simple comparison would give a general ratio which could be used to perform some minimal projections, that N% of queries were forwarded from a cached referral, while the remainder were not. Is this kind of detail available? off-list discussions/data welcome if desired -- 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: From owner-namedroppers@ops.ietf.org Sun Aug 4 23:57:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21036 for ; Sun, 4 Aug 2002 23:57:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bYub-000DaY-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 20:52:05 -0700 Received: from portal.east.saic.com ([198.151.13.15]) by psg.com with smtp (Exim 3.36 #1) id 17bYuX-000DaM-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 20:52:01 -0700 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for psg.com [147.28.0.62]) with SMTP; 5 Aug 2002 03:52:01 UT Received: from mcl-its-ieg01.mail.saic.com by mclmx.mail.saic.com for namedroppers@ops.ietf.org; Sun, 4 Aug 2002 23:51:49 -0400 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by mcl-its-ieg01.mail.saic.com (NAVGW 2.5.1.19) with SMTP id M2002080423514902364 ; Sun, 04 Aug 2002 23:51:49 -0400 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2653.19) id ; Sun, 4 Aug 2002 23:51:40 -0400 Message-Id: <3C1E3607B37295439F7C409EFBA08E680E2D49@US-Columbia-CIST.mail.saic.com> From: "Loomis, Rip" To: "'Rob Austein '" Cc: "'namedroppers@ops.ietf.org '" , "'design@lists.freeswan.org '" Subject: RE: the DNS/DNSSEC KEY RR debate Date: Sun, 4 Aug 2002 23:52:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:13 PM (by someone's clock) on 8/4/2002, someone vaguely claiming to be Rob Austein wrote: > At Sun, 04 Aug 2002 12:53:03 -0400, Michael Richardson wrote: > > Rob> There is a specific problem with using the KEY RR > > Rob> type for things other than DNSSEC's own internal > > Rob> keying. It's called the "sub-typing problem" > > > > Yes, and obsoleting KEY does nothing to solve this problem. > Sorry, wrong. (a) it removes the need for DNSSEC-aware resolvers > to sift through RRsets picking out individual keys by subtype > codes, and (b) it reduces the chances that KEY RRsets will be > large enough to trigger DNS message truncation and fallback to > TCP. As a minor point of clarification, and please slap me with the clue-by-four if I missed something, I believe that (b) is a don't care. Are we still considering that there's anyone out there who intends to do DNSSEC and can't/won't support EDNS0 ??? If not, then I don't think that "fallback to TCP" is a strong persuader...and perhaps it shouldn't be bruted about at all for situations such as this. "Fallback to TCP" might still be a valid concern for other DNS enhancements/thingies, but from everything I see it's a non-issue for DNSSEC-aware servers and resolvers. As I indicated, perhaps I missed something--please edu-ma-cate me if I did and you have the time to edu-ma-cate me. Otherwise, I do agree with the points in your original e-mail. --Rip -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 00:22:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21507 for ; Mon, 5 Aug 2002 00:22:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bZIm-000EDW-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 21:17:04 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17bZIi-000EDK-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 21:17:00 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 52E4028B6C for ; Mon, 5 Aug 2002 04:16:59 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: noodling, looking for stats In-Reply-To: Message from "Eric A. Hall" of "Sun, 04 Aug 2002 22:24:21 EST." <3D4DEFE5.5030102@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 05 Aug 2002 04:16:59 +0000 Message-Id: <20020805041659.52E4028B6C@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... This simple comparison would give a general ratio which could be > used to perform some minimal projections, that N% of queries were > forwarded from a cached referral, while the remainder were not. > > Is this kind of detail available? from some of the root servers but probably not from all of them. note that some of the roots servers are also authoritative for some tld's (.edu and .mil are examples) and in this case a referral from the "root" will actually be to a second level name rather than a tld. (i mention this only to avoid evaluating skewed data.) i suspect that verisign would treat this as proprietary data about .com, net, and .org, which are the busiest tld's. you might be able to get some tld operator to go along but i can't think of one that's both (likely AND useful). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 01:45:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23014 for ; Mon, 5 Aug 2002 01:45:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17baXC-000GIz-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 22:36:02 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17baX6-000GHW-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 22:35:56 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 5AE1818D9; Mon, 5 Aug 2002 01:35:54 -0400 (EDT) Date: Mon, 05 Aug 2002 01:35:54 -0400 From: Rob Austein To: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: the DNS/DNSSEC KEY RR debate In-Reply-To: <3C1E3607B37295439F7C409EFBA08E680E2D49@US-Columbia-CIST.mail.saic.com> References: <3C1E3607B37295439F7C409EFBA08E680E2D49@US-Columbia-CIST.mail.saic.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020805053554.5AE1818D9@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sun, 4 Aug 2002 23:52:00 -0400 , Rip Loomis wrote: > > > ... (b) it reduces the chances that KEY RRsets will be > > large enough to trigger DNS message truncation and fallback to > > TCP. > > As a minor point of clarification, and please slap me with the > clue-by-four if I missed something, I believe that (b) is a > don't care. Are we still considering that there's anyone out > there who intends to do DNSSEC and can't/won't support EDNS0 ??? > If not, then I don't think that "fallback to TCP" is a strong > persuader...and perhaps it shouldn't be bruted about at all > for situations such as this. "Fallback to TCP" might still > be a valid concern for other DNS enhancements/thingies, but from > everything I see it's a non-issue for DNSSEC-aware servers and > resolvers. The large print giveth and the small print taketh away. EDNS0 lets you use larger packets. But we've also got SIG RRs, and DS RRs, and KEYs sometimes show up via additional section processing, and we're probably heading for about a decade of IPv4 => IPv6 transition, which means dual stack, which means A and AAAA coexistance. So yeah, EDNS0 helps, but I don't think EDNS0 means we can stop worrying about message size completely. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 01:48:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23070 for ; Mon, 5 Aug 2002 01:48:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17badN-000GUc-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 22:42:25 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17badI-000GUR-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 22:42:20 -0700 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g755goh17702; Mon, 5 Aug 2002 01:42:50 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020805010314.014ec740@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 05 Aug 2002 01:41:50 -0400 To: Paul Vixie , namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: the KEY debate In-Reply-To: <20020804194059.E89FA28B6C@as.vix.com> References: <074EBA95-A7DD-11D6-9B8C-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 15:40 2002-08-04, Paul Vixie wrote: > > I would just like to interject at this point that if the WG's goal is to > > find the *best* way to put keys in the DNS, we are doomed to fail. The > > best is the enemy of good enough. The KEY record was not good enough, > and > > I think there's consensus on that, but we will never find out what the > best > > is if we don't come up with something that's good enough, try it, and > learn > > from it. > >the working group had better show some leadership, in that case. saying that >KEY is wrong for applications due to subtyping is merely _true_. let's try >for _helpful_. > >1. subtype with subdomains that have leading underscores, like SRV does. >2. carry the key data itself in TXT RR's. > >if someone writes up a draft showing how openpgp keys and x509 certs can >be carried in that fashion, then this whole debate will be over, because >you will have demonstrated some leadership. I real sorry to see the efforts of trying to define other ways to carry keying information via DNS are not progressing. SIKED BOF showed us that "unified" approach will not work (IMHO) as the "security mafia" will demand (rightly so) a solid security consideration section that covers all applications (a NP complete task). We need to see if application specific type approach will work as writing a security consideration section for one particular application/protocol should be much simpler. The other thing that needs to be addressed is that different applications have different keying needs, some require Certificates, others require the public key information, others can get away with a signed key footprint. The real reason I think the separate RR type approach is the best one, has to do with dynamic update of application key information. E-mail keys will be updated by the email administration people, IPSEC keys by the remote access group, etc. It is much simpler to grant authority to update a single type for, existing names than allowing the creation/deletion of SRV style name such as _sec._ip. The best the DNSEXT working group right now is to help application people to draft proposals that suite each application needs. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 02:42:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03186 for ; Mon, 5 Aug 2002 02:42:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bbTf-000HyY-00 for namedroppers-data@psg.com; Sun, 04 Aug 2002 23:36:27 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17bbT6-000Hwz-00 for namedroppers@ops.ietf.org; Sun, 04 Aug 2002 23:35:52 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g756ZRgs076390; Mon, 5 Aug 2002 16:35:27 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208050635.g756ZRgs076390@drugs.dv.isc.org> To: "Loomis, Rip" Cc: "'Rob Austein '" , "'namedroppers@ops.ietf.org '" , "'design@lists.freeswan.org '" From: Mark.Andrews@isc.org Subject: Re: the DNS/DNSSEC KEY RR debate In-reply-to: Your message of "Sun, 04 Aug 2002 23:52:00 -0400." <3C1E3607B37295439F7C409EFBA08E680E2D49@US-Columbia-CIST.mail.saic.com> Date: Mon, 05 Aug 2002 16:35:27 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 8:13 PM (by someone's clock) on 8/4/2002, someone vaguely > claiming to be Rob Austein wrote: > > At Sun, 04 Aug 2002 12:53:03 -0400, Michael Richardson wrote: > > > Rob> There is a specific problem with using the KEY RR > > > Rob> type for things other than DNSSEC's own internal > > > Rob> keying. It's called the "sub-typing problem" > > > > > > Yes, and obsoleting KEY does nothing to solve this problem. > > Sorry, wrong. (a) it removes the need for DNSSEC-aware resolvers > > to sift through RRsets picking out individual keys by subtype > > codes, and (b) it reduces the chances that KEY RRsets will be > > large enough to trigger DNS message truncation and fallback to > > TCP. > > As a minor point of clarification, and please slap me with the > clue-by-four if I missed something, I believe that (b) is a > don't care. Are we still considering that there's anyone out > there who intends to do DNSSEC and can't/won't support EDNS0 ??? > If not, then I don't think that "fallback to TCP" is a strong > persuader...and perhaps it shouldn't be bruted about at all > for situations such as this. "Fallback to TCP" might still > be a valid concern for other DNS enhancements/thingies, but from > everything I see it's a non-issue for DNSSEC-aware servers and > resolvers. EDNS/UDP does not save you have *different* key sub-types at the same node. It will get you to ~4k. > As I indicated, perhaps I missed something--please edu-ma-cate > me if I did and you have the time to edu-ma-cate me. Otherwise, > I do agree with the points in your original e-mail. > > --Rip > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 03:39:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04109 for ; Mon, 5 Aug 2002 03:39:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bcKy-000JHx-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 00:31:32 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17bcKt-000JHg-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 00:31:27 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 8540152AF; Mon, 5 Aug 2002 09:31:25 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id B4EC41DE9; Mon, 5 Aug 2002 09:31:24 +0200 (MEST) Date: Mon, 5 Aug 2002 09:31:24 +0200 (CEST) From: Jakob Schlyter To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: Paul Vixie , Subject: Re: the KEY debate In-Reply-To: <5.1.1.6.2.20020805010314.014ec740@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Mon, 5 Aug 2002, Ólafur Guðmundsson wrote: > The best the DNSEXT working group right now is to help application > people to draft proposals that suite each application needs. I though for some time that a unified approach like appkey was the way to go, but I've come to the conclusion that it was a bad idea and that we really should take the time and work to defined new RR types for the protocols needing this kind of mechanism. the number of protocols that is a potentional user of appkey has been few. in fact, I have not seen any other protocols except SSH and IPsec/IKE that would fit the appkey model and even for these two protocols the requirements for a RR type differs a lot if you would do them separately. Wes Griffin and I have written a draft (and code) on how to verify SSH host keys using dnssec and will publish it shortly. I suggest that people interested in doing this for IPsec does that same. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 06:10:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06633 for ; Mon, 5 Aug 2002 06:10:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17beeN-000LYW-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 02:59:43 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17beeI-000LYK-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 02:59:38 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g759xHZX025982; Mon, 5 Aug 2002 11:59:17 +0200 To: Mark.Andrews@isc.org Cc: namedroppers@ops.ietf.org Subject: KEY/SIG/NXT classless (was Re: [Design] Re: the KEY debate) References: <200208050016.g750GKgs037694@drugs.dv.isc.org> X-Hashcash: 020805:Mark.Andrews@isc.org:5597250f1c6b5459 X-Hashcash: 020805:namedroppers@ops.ietf.org:cc6e434f046e804f From: Simon Josefsson Date: Mon, 05 Aug 2002 11:59:17 +0200 In-Reply-To: <200208050016.g750GKgs037694@drugs.dv.isc.org> (Mark.Andrews@isc.org's message of "Mon, 05 Aug 2002 10:16:20 +1000") Message-ID: Lines: 16 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: > There is no shortage of types. If we exhaust IN then we can > add another class. Actually KEY/SIG/NXT apparently isn't restricted to IN. From dnssec-records: The KEY RR is class independent. The SIG RR is class independent, [...] The IANA DNS registration page should probably be updated, it says KEY/SIG/NXT is for IN only. Also, NXT doesn't provide authenticated denial across IN boundaries. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 09:03:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11172 for ; Mon, 5 Aug 2002 09:03:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bhLR-000ON8-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 05:52:21 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17bhLN-000OMx-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 05:52:17 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g758ob23015088; Mon, 5 Aug 2002 08:50:38 GMT Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA16396; Mon, 5 Aug 2002 08:51:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <044f01c23a81$d347b780$8000a8c0@whirlwind> References: <044f01c23a81$d347b780$8000a8c0@whirlwind> Date: Mon, 5 Aug 2002 08:10:52 -0400 To: "Matt Larson" , , "Simon Josefsson" From: Edward Lewis Subject: Re: Comment on draft-ietf-dnsext-dnssec-records Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:07 PM -0400 8/2/02, Matt Larson wrote: >Qouting Simon: >> IMO2 draft-ietf-dnsext-dnssec-records should contain CERT too. Taking >> RFC 2538 and fixing a few unclear spots (e.g., whether the PGP CERT >> RRDATA should include the checksum field or not) should be sufficient. >> I'll volunteer to do it if human resources is the limiting factor. > >That's out of scope. CERT's never been a part of DNSSEC, even when you >expand the term to include TSIG. And the DNSSEC rewrite is an editorial >exercise: when we find protocol issues, we bring them to namedroppers. What >you describe sounds protocolish and would need namedroppers discussion, >anyway. In the earliest slide sets on DNSSEC, I claimed CERT RR as part of DNSSEC. But Matt is right. The CERT RR really isn't part of DNSSEC - other than being chronologically related (look at the RFC numbers). Especially now that the KEY RR is being restricted and a tighter view of DNSSEC is being applied, the CERT RR is further removed from being a part of DNSSEC. I.e., the CERT RR and the application-KEY RR were the forays into a certification publication mechanism (which sometimes has been incorrectly labeled a PKI). -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 09:04:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11242 for ; Mon, 5 Aug 2002 09:04:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bhLM-000OMv-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 05:52:16 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17bhLH-000OMd-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 05:52:11 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g758oe23015092; Mon, 5 Aug 2002 08:50:40 GMT Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA16408; Mon, 5 Aug 2002 08:51:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <3C1E3607B37295439F7C409EFBA08E680E2D42@US-Columbia-CIST.mail.saic.com> <200208031717.g73HHaq0015765@marajade.sandelman.ottawa.on.ca> <20020803185039.9D8281996@thrintun.hactrn.net> Date: Mon, 5 Aug 2002 08:51:18 -0400 To: Simon Josefsson , Rob Austein From: Edward Lewis Subject: Re: the KEY debate Cc: namedroppers@ops.ietf.org, design@lists.freeswan.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:43 PM +0200 8/3/02, Simon Josefsson wrote: >Agreed. But removing functionality does not help anybody either, >that's why I suggested shipping restrict-key draft together with a >migration path in the form of APPKEY, an updated CERT RR >specification, or a specification stating that applications should >define their own RR for keying material, or whatever approach is >preferred by the DNS illuminati. Then the restrict-key people are >happy, and the application keys in DNS community is happy. Why is >that solution unreasonable? This is a philosophical answer. So, if you have code to compile, take care of that and leave this for when you want to counter the effects of all that coffee and cola you've had today. There is a good reason to restrict the use of the KEY RR. The reason is that in doing so we can achieve a tighter definition of DNS security. Having a tighter definition makes the security model clearer and more verifiable (in that it works, not in the sense that I can verify data). Additionally, due to the implementation of DNS (I mean the protocol, not the software), if the KEY RR is unrestricted we can run into performance glitches (TC bit getting turned on). That and the desire to put the KEY RR set in the authority sections when possible drive a desire to limit the size of the set. Then, of course, there is the "fear" (as in FUD) that poorly implemented resolvers may not check whether the KEY RR flags and protocol field are properly set and misuse a key. (Yes, FUD.) Rob has already mentioned the "sub-typing" problem, and referred further discussion to the archives. None of this addresses the application-keys-in-DNS issue. Yes, currently the KEY RR can accommodate them (RFC 2535) and the KEY-restrict draft would stop this. The reasons for the stopping are above, and should be clear in the draft. (I've made comments to that effect already.) In a perfect world (we wouldn't need DNSSEC, but) it would be good to be able to achieve both the restriction on KEY and provide an alternative for the application keys in one fell swoop. In my opinion, this just can't happen. First, one of my goof-ball ideas was that we should just completely ditch the KEY RR for DNSSEC altogether, replacing it with the DNSKEY RR and restrict DNSSEC processing to just that record type. I really am leery of restricting an existing definition because there will always be code out there that implemented the unrestricted version of the definition. Moving to a new RR type would eliminate the problem, but was shot down because the KEY restrict draft was already written. Second, give that restrict key is on the threshold, it can be put in place to alleviate the burden placed on the DNSSEC definition now. Waiting for a solution to application-keys-in-DNS would be a delay I think we could do with out. Partly because of my third point. Third, there's no clear consensus on how to proceed with application keys in DNS. I don't mean DNS* consensus, I mean any sort of a community consensus. (How close are IPsec OE and SSH in agreement on how to approach this?) For my part, I really think that it is a mistake to expect a generic application key solution to come from DNS, rather solutions should come to DNS. (E.g., from the SSH WG or the IPSEC WG.) Yes, solutions in DNS should get some DNS review, but the applications know better their needs and goals. The solutions should also get some Security Area review, as the DNS community is not geared towards security issues (if we were, perhaps DNSSEC would be done by now). Third and a half, I'm hesitant to support any application key approach that relies on the DNSSEC protections to cover delivery of the key material from end to end (e.g., server to client). DNSSEC may be part of the solution (the DNS authoritative server to resolver) but is not the whole (e.g., requiring a client to allow a human user to inspect the fingerprint before blindly accepting is a good idea). Fourth, this is the philosophical comment. Waiting until there is a completely worked out design before going forward is a good way to design a bridge over a river, and is generally a sound engineering approach. A converse example is the OSI protocol suite, especially the session layer protocol, which addressed every conceivable situation in theory and wound up with an unworkable implementation. Another example, much more philosophical, is a human society and the body of law applied to it. No set of lawyers could ever think up every situation ahead of time, so it is sometimes best to partly define the law and let cases set precedents. My point here is that there is sometimes value in partial definitions, especially when the next step to a complete definition is still unsettled. Restricting the KEY RR (or defining my pipe dream of DNSKEY RR) accomplished a known, needed step. Losing the application-key-in-DNS feature (or any feature) isn't a good thing, but there isn't a clearly good alternative. I'd say let's not wait and hold the KEY RR restriction up while testing the best way to accomplish the needs of applications wanting to distribute their keys, possibly via DNS. If you've made it this far, try counting sheep. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 11:34:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17778 for ; Mon, 5 Aug 2002 11:34:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bjm9-00022X-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 08:28:05 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17bjln-000213-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 08:27:43 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g75FNKXA025716; Mon, 5 Aug 2002 08:23:20 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 08:29:21 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D81317E@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Rob Austein , namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: RE: the KEY debate Date: Mon, 5 Aug 2002 08:29:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > - The APPKEY/CERT/whatever stuff isn't as far along. No doubt you > recall the SIKED BOF this year in Minneapolis, at which several > people asked some pretty fundamental questions about the problem > spaces people were trying to solve and what the underlying trust > models were. No good answers at that time. Not saying there > -aren't- good answers, but at that BOF there didn't appear to be any > kind of consensus on the subject. So proponents of this idea have > some work cut out that either has not yet been done at all yet or > has been done but has not yet been walked through the IETF process. I would pretty much agree with Rob here except that I would say that there was no consensus in that meeting on how to use DNSSEC alone to address that problem rather than a lack of consensus in the PKI world on how to address that problem. The complaint from the application vendors attempting to PKI enable apps has been that traditional PKI mechanisms are just too hard to implement. One of the reasons for the complexity of X.509/PKIX PKI is that it was not originally designed as a PKI, it was designed as an after the fact security extension to a directory model. Sound familiar? The PKI world has been working on a key retrieval model PKI for 3 years now and we have a working group in a standards body and actual deployments of XKMS. XKMS is considerably simpler to implement on the client side than PKIX or DNSSEC can hope to be. This is possible because the XKMS design was legacy free. The application makes a Web Service call of the form: Locate the parameters of key with [cryptographic key usage] to communicate with ([identifier] via [protocol]) *. e.g. Locate the parameters of an encryption key to communicate with alice@wherever.test via S/MIME or PGP. Deployment of XKMS does not depend on DNSSEC but it would definitely be useful if an application can locate the XKMS service for wherever.test by means of a DNS SRV record, it is clearly more useful still if that connection is DNSSEC secured. Note that I am the principal advocate of this approach in the XKMS group. The other PKI vendors are understandably nervous about a PKI linkage to DNS which is an area where VeriSign has market share and they do not. At present the SRV argument is accepted on the merits. However I do not see any possibility any of them would go any further down the DNS route. If I thought that the keys in DNS approach had technical merit then it would be in my company interest to push it as hard as I can. Storing DNS keys in DNS makes sense, an argument can be made for storing XKMS keys in DNS, storing unrestricted application keys in DNS makes no more sense than using DNS as an all purpose directory for every piece of application data that might be requested. Maintaining DNS records that are primarily bound to machines is very different from maintaining Public Key records which may be bound to a user, a machine or anything in between. Finally, before attempting to address problems that are already being addressed in open standards process elsewhere DNSEXT needs to first agree to protocol changes that make DNSSEC deployable in .com and .net. Until those changes are made DNSSEC will have precisely as much credibility as a group who has been trying to deploy for 10 years deserves. If DNS is as claimed so complex that necessary changes such as opt in have to be delayed three years (and counting) while non-security experts get comfortable with the idea it is utterly futile to attempt to use DNSSEC as a vehicle for a proposal that has the security area directors distinctly uncomfortable. 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: From owner-namedroppers@ops.ietf.org Mon Aug 5 11:37:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17860 for ; Mon, 5 Aug 2002 11:37:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bjjs-0001xz-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 08:25:44 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17bjjm-0001xo-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 08:25:38 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A2D3D28B6C for ; Mon, 5 Aug 2002 15:25:31 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: the KEY debate In-Reply-To: Message from =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= of "Mon, 05 Aug 2002 01:41:50 -0400." <5.1.1.6.2.20020805010314.014ec740@localhost> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 05 Aug 2002 15:25:31 +0000 Message-Id: <20020805152531.A2D3D28B6C@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > SIKED BOF showed us that "unified" approach will not work (IMHO) as the > "security mafia" will demand (rightly so) a solid security consideration > section that covers all applications (a NP complete task). ah. that is of course ridiculous, but it's nice to know that the reason we can't complete the debate on restricting KEY is due to ridiculousness from outside DNSEXT. > The real reason I think the separate RR type approach is the best one, > has to do with dynamic update of application key information. E-mail > keys will be updated by the email administration people, IPSEC keys by > the remote access group, etc. It is much simpler to grant authority > to update a single type for, existing names than allowing the > creation/deletion of SRV style name such as _sec._ip. had that but been proposed, then we could be discussing it. i however am ready to see _pgp._key. or even _pgp.._key. or _key.._pgp. if that is what it would take to get motion. > The best the DNSEXT working group right now is to help application > people to draft proposals that suite each application needs. if you want to see more botched rdata encodings and more dns-hostile designs along the lines of say GPOS or NIMLOC or (dare i say it?) NAPTR, then by all means push this activity outside of DNSEXT where it can fail. i on the other hand would much rather see success, both for DNSSEC (if you call its best remaining destiny a success, which i'm capable of) and for all the "appdev" folks who just want a place to put their security goo other than $HOME/.gpg and $HOME/.ssh. i think it is reasonable for these folks to oppose the restriction of KEY unless and until there's visible progress made on CERT or APPKEY or some kind of TXT with SRV-like naming or even a series of different RR's, on a per-security-system basis. (ultimately i expect the debate to be closed rather than completed, which is my own private cause for sadness about the "key-restrict" draft.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 13:38:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23775 for ; Mon, 5 Aug 2002 13:38:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17blcL-0005MY-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 10:26:05 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17blcG-0005MI-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 10:26:00 -0700 Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0BA5F18E3; Mon, 5 Aug 2002 13:25:59 -0400 (EDT) Date: Mon, 05 Aug 2002 13:25:58 -0400 From: Rob Austein To: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: [Design] Re: the KEY debate In-Reply-To: <200208050358.g753w4dp010426@marajade.sandelman.ottawa.on.ca> References: <20020805001344.482E4191D@thrintun.hactrn.net> <200208050358.g753w4dp010426@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020805172559.0BA5F18E3@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Sun, 04 Aug 2002 23:58:04 -0400, Michael Richardson wrote: > > Rob> Sorry, wrong. (a) it removes the need for DNSSEC-aware resolvers to > Rob> sift through RRsets picking out individual keys by subtype codes, and > Rob> (b) it reduces the chances that KEY RRsets will be large enough to > Rob> trigger DNS message truncation and fallback to TCP. > > This argument is valid for KEYs at zone APEX only. > DNSSEC only ever cares about KEYs that that point anyway. > > As I have said several times, there is likely little reason to ever have > non-DNSSEC keys there. The only use is seeminly web servers, and the > limitations on HTTPS for virtual hosting means that a single IP can not > serve both both https://www.example.com and https://example.com. > As such, it is very unlikely that such a KEY record would be placed. Your analysis depends on simplifying assumptions about the location of the zone cuts. Not everyone agrees with your assumptions. > If we introduce a new RR for each use, then we can also solve the problem. > I prefer to introduce a new RR for each use. Oddly enough, we are in agreement on this. I've been advocating using separate RR types for this purpose for years now. The usual counter-argument is that it takes too long to deploy new RR types. In theory the recent work on how DNS implementations should handle unrecognized RR types helps here; in practice, well, we'll see. I don't have any particular attachment to the current KEY RR type either, and strictly from a protocol standpoint I suspect that it'd be better to dump it and use a new RR type for DNSSEC's own keys as well, with (at least) the subtype field removed from the RDATA of the new type (fields that don't exist doesn't have to be checked, and can't turn into the sort of mess that ECN did). From a practical standpoint, I don't think it's worth delaying DNSSEC deployment just for this change, which is why I haven't made noise about it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 14:22:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25617 for ; Mon, 5 Aug 2002 14:22:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bmOY-0006iA-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 11:15:54 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17bmOU-0006hz-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 11:15:50 -0700 Received: from isi.edu (wireless207.east.isi.edu [65.123.202.207]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g75IFir02316; Mon, 5 Aug 2002 11:15:44 -0700 (PDT) Message-ID: <3D4EC10C.A75BFED1@isi.edu> Date: Mon, 05 Aug 2002 14:16:44 -0400 From: Dan Massey Organization: USC/ISI X-Mailer: Mozilla 4.73 [en]C-CCK-MCD BA45DSL (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Austein CC: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: [Design] Re: the KEY debate References: <20020805001344.482E4191D@thrintun.hactrn.net> <200208050358.g753w4dp010426@marajade.sandelman.ottawa.on.ca> <20020805172559.0BA5F18E3@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > I don't have any particular attachment to the current KEY RR type > either, and strictly from a protocol standpoint I suspect that it'd be > better to dump it and use a new RR type for DNSSEC's own keys as well, > with (at least) the subtype field removed from the RDATA of the new > type (fields that don't exist doesn't have to be checked, and can't > turn into the sort of mess that ECN did). From a practical > standpoint, I don't think it's worth delaying DNSSEC deployment just > for this change, which is why I haven't made noise about it. This is a good point. In the restrict key form, the KEY record has a protocol octet that must be 3. In addition, there are 2 flag octets where only bit 7 is used. This is a somewhat odd structure at best.and someone starting from scratch would clearly not do this. But it accomplishes the objective with minimal changes and without creating any compatability problems for existing zone keys. In my view, the practical issues of making minimal compatible changes and not futher delaying DNSSEC trumps the desire to further optimize structure. Dan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 14:56:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27305 for ; Mon, 5 Aug 2002 14:56:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bmmP-0007ZC-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 11:40:33 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17bmmK-0007Yy-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 11:40:29 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g75Eda23020156; Mon, 5 Aug 2002 14:39:36 GMT Received: from [192.149.252.231] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA21743; Mon, 5 Aug 2002 14:40:26 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <20020804194059.E89FA28B6C@as.vix.com> References: <20020804194059.E89FA28B6C@as.vix.com> Date: Mon, 5 Aug 2002 14:40:27 -0400 To: Paul Vixie , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: the KEY debate Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 7:40 PM +0000 8/4/02, Paul Vixie wrote: >if someone writes up a draft showing how openpgp keys and x509 certs can >be carried in that fashion, then this whole debate will be over, because >you will have demonstrated some leadership. > >until you do that, all you're doing is trying to take something away from >the "appdev" community, and they will fight you to the last binary digit, >regardless of the truth of your arguments. I would think that a better approach would be to document what determines whether a design of a resource record is "good" or "bad." The document would not need to be a tutorial to RR proposers as much as it would be a resource for DNS reviewers to say "I don't like this RR because of what's in section x.y." A well designed solution to an application key in DNS would have to: 1) Solve the problem facing the application 2) Do so in a way that is in accordance with appropriate security practices 3) Be copacetic with DNS As the DNS community is just one leg of this, I would think that the best we could hope for is defining what is copacetic. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 15:03:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27709 for ; Mon, 5 Aug 2002 15:03:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bn1o-00082q-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 11:56:28 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17bn1e-00082N-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 11:56:18 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C49D428B6C for ; Mon, 5 Aug 2002 18:56:17 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: the KEY debate In-Reply-To: Message from Edward Lewis of "Mon, 05 Aug 2002 14:40:27 -0400." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 05 Aug 2002 18:56:17 +0000 Message-Id: <20020805185617.C49D428B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >until you do that, all you're doing is trying to take something away from > >the "appdev" community, and they will fight you to the last binary digit, > >regardless of the truth of your arguments. > > I would think that a better approach would be to document what > determines whether a design of a resource record is "good" or "bad." > The document would not need to be a tutorial to RR proposers as much > as it would be a resource for DNS reviewers to say "I don't like this > RR because of what's in section x.y." that sounds like a great resource. but it's not going to help "us" reach consensus on key-restrict, even if it were finished (including all the inevitable arguments about the validity of proposed section x.y) TODAY. if you want the community to support the restriction of KEY to just DNS's own security needs, then you will have to put a replacement on the table, and i mean give these people a fish, don't just teach them how to fish. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 16:17:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00415 for ; Mon, 5 Aug 2002 16:17:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bo9L-000A7T-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 13:08:19 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17bo9D-000A7I-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 13:08:12 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 3DFC6529D for ; Mon, 5 Aug 2002 22:08:09 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id EB4C81DE9 for ; Mon, 5 Aug 2002 22:08:08 +0200 (MEST) Date: Mon, 5 Aug 2002 22:08:08 +0200 (CEST) From: Jakob Schlyter To: IETF DNSEXT WG Subject: Re: the KEY debate In-Reply-To: <20020805185617.C49D428B6C@as.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 5 Aug 2002, Paul Vixie wrote: > if you want the community to support the restriction of KEY to just > DNS's own security needs, then you will have to put a replacement on the > table, and i mean give these people a fish, don't just teach them how to > fish. I believe these "people" are SSH and IPsec. since there is no deployed code using key for SSH, noone will complain from that side. IPsec on the other hand has deployed code. my understanding is that opportunistic IPsec uses, our could use, more information (such as security gateway address) than are availible in KEY and therefore need some additional data anyway (TXT, KX, ...). if "people" would get started on writing a draft describing the thing they actually need we might get somewhere instead of discussing key-restrict for six more months. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 18:18:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04979 for ; Mon, 5 Aug 2002 18:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bq5q-000DrM-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 15:12:50 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17bq5m-000DrB-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 15:12:46 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g75MCegs077916; Tue, 6 Aug 2002 08:12:40 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208052212.g75MCegs077916@drugs.dv.isc.org> Cc: Simon Josefsson , namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: KEY/SIG/NXT classless (was Re: [Design] Re: the KEY debate) In-reply-to: Your message of "Tue, 06 Aug 2002 08:09:38 +1000." Date: Tue, 06 Aug 2002 08:12:40 +1000 X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD,MISSING_HEADERS version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > Mark.Andrews@isc.org writes: > > > > > There is no shortage of types. If we exhaust IN then we can > > > add another class. > > > > Actually KEY/SIG/NXT apparently isn't restricted to IN. From > > dnssec-records: > > > > The KEY RR is class independent. > > > > The SIG RR is class independent, [...] > > > > The IANA DNS registration page should probably be updated, it says > > KEY/SIG/NXT is for IN only. > > No. KEY/SIG/NXT are for securing the DNS *independent* of I just re-read what you said. Yes IANA's page needs to be updated if it says IN only. > You missed the entire point of the statement I made. > > If you exhaust the type space in IN then you have additional > classes that you can use. > > > Also, NXT doesn't provide authenticated denial across IN boundaries. > > > > This makes no sense. > > Mark > -- > Mark Andrews, Internet Software Consortium > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 18:21:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05087 for ; Mon, 5 Aug 2002 18:21:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bq31-000Dl8-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 15:09:55 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17bq2w-000Dkv-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 15:09:50 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g75M9cgs077903; Tue, 6 Aug 2002 08:09:42 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208052209.g75M9cgs077903@drugs.dv.isc.org> To: Simon Josefsson Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: KEY/SIG/NXT classless (was Re: [Design] Re: the KEY debate) In-reply-to: Your message of "Mon, 05 Aug 2002 11:59:17 +0200." Date: Tue, 06 Aug 2002 08:09:38 +1000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@isc.org writes: > > > There is no shortage of types. If we exhaust IN then we can > > add another class. > > Actually KEY/SIG/NXT apparently isn't restricted to IN. From > dnssec-records: > > The KEY RR is class independent. > > The SIG RR is class independent, [...] > > The IANA DNS registration page should probably be updated, it says > KEY/SIG/NXT is for IN only. No. KEY/SIG/NXT are for securing the DNS *independent* of class. You missed the entire point of the statement I made. If you exhaust the type space in IN then you have additional classes that you can use. > Also, NXT doesn't provide authenticated denial across IN boundaries. > This makes no sense. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 18:49:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06511 for ; Mon, 5 Aug 2002 18:49:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bqax-000Ezy-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 15:44:59 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17bqar-000Eze-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 15:44:53 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 43AFF28B6C for ; Mon, 5 Aug 2002 22:44:53 +0000 (GMT) From: Paul Vixie To: IETF DNSEXT WG Subject: Re: the KEY debate In-Reply-To: Message from Jakob Schlyter of "Mon, 05 Aug 2002 22:08:08 +0200." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 05 Aug 2002 22:44:53 +0000 Message-Id: <20020805224453.43AFF28B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... since there is no deployed code using key for SSH, noone will complain > from that side. ... i wish i shared your confidence. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 19:39:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07335 for ; Mon, 5 Aug 2002 19:39:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17brLq-000GXo-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 16:33:26 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17brLe-000GXJ-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 16:33:15 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g75NX9i2003184; Tue, 6 Aug 2002 01:33:10 +0200 To: Mark.Andrews@isc.org Cc: namedroppers@ops.ietf.org Subject: Re: KEY/SIG/NXT classless (was Re: [Design] Re: the KEY debate) References: <200208052212.g75MCegs077916@drugs.dv.isc.org> X-Hashcash: 020805:Mark.Andrews@isc.org:6c61e4eb33141c35 X-Hashcash: 020805:namedroppers@ops.ietf.org:302f34dbe639dfd1 From: Simon Josefsson Date: Tue, 06 Aug 2002 01:33:10 +0200 In-Reply-To: <200208052212.g75MCegs077916@drugs.dv.isc.org> (Mark.Andrews@isc.org's message of "Tue, 06 Aug 2002 08:12:40 +1000") Message-ID: Lines: 45 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@isc.org writes: >> >> > Mark.Andrews@isc.org writes: >> > >> > > There is no shortage of types. If we exhaust IN then we can >> > > add another class. >> > >> > Actually KEY/SIG/NXT apparently isn't restricted to IN. From >> > dnssec-records: >> > >> > The KEY RR is class independent. >> > >> > The SIG RR is class independent, [...] >> > >> > The IANA DNS registration page should probably be updated, it says >> > KEY/SIG/NXT is for IN only. >> >> No. KEY/SIG/NXT are for securing the DNS *independent* of > > I just re-read what you said. Yes IANA's page needs to be > updated if it says IN only. > >> You missed the entire point of the statement I made. It was a side comment, I was not trying to rebute your statement. I should have made that more clear. >> If you exhaust the type space in IN then you have additional >> classes that you can use. >> >> > Also, NXT doesn't provide authenticated denial across IN boundaries. >> > >> >> This makes no sense. Sorry, try parsing it again after s/IN/class/. My point is that there is no authenticated denial when different classes are specified in a query. Consider a query for (www.example.org., HESIOD, KEY), what data is returned that securely convince the client that there isn't an answer? We are back to trusting NOERROR with empty answer field, or something similar. Again, this was a side remark and is probably not important until there is any serious non-IN deployment. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 5 20:01:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07936 for ; Mon, 5 Aug 2002 20:01:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17brgB-000HI1-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 16:54:27 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17brg7-000HHp-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 16:54:23 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g75NsDgs078744; Tue, 6 Aug 2002 09:54:13 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208052354.g75NsDgs078744@drugs.dv.isc.org> To: Simon Josefsson Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: KEY/SIG/NXT classless (was Re: [Design] Re: the KEY debate) In-reply-to: Your message of "Tue, 06 Aug 2002 01:33:10 +0200." Date: Tue, 06 Aug 2002 09:54:13 +1000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >> > Also, NXT doesn't provide authenticated denial across IN boundaries. > >> > > >> > >> This makes no sense. > > Sorry, try parsing it again after s/IN/class/. > > My point is that there is no authenticated denial when different > classes are specified in a query. Consider a query for > (www.example.org., HESIOD, KEY), what data is returned that securely > convince the client that there isn't an answer? We are back to > trusting NOERROR with empty answer field, or something similar. > Again, this was a side remark and is probably not important until > there is any serious non-IN deployment. > HS is local secure. You configure your nameservers with the top of the local heirarchies and the keys for them. If you are moving to a new class because we have exhausted the type space in IN then you publish new roots for the new class (they may be the same as the existing roots), You publish the keys for the new roots (again if the roots a co-located with IN roots you could use the same key). This could actually start out being globally secure. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 02:22:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26471 for ; Tue, 6 Aug 2002 02:22:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bxTX-0004hH-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 23:05:47 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17bxTP-0004h6-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 23:05:40 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17bxTO-0000IG-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 23:05:38 -0700 Message-Id: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Sat, 03 Aug 2002 14:50:39 EDT." <20020803185039.9D8281996@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: namedroppers@ops.ietf.org, design@lists.freeswan.org cc: Rob Austein Subject: Re: [Design] Re: the KEY debate Date: Sun, 04 Aug 2002 12:53:03 -0400 From: Michael Richardson X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >>>>> "Rob" == Rob Austein writes: Rob> There is a specific problem with using the KEY RR type for things Rob> other than DNSSEC's own internal keying. It's called the "sub-typing Rob> problem" and has been discussed namedroppers many times before, please Rob> check the archives if you don't already understand the problem. Yes, and obsoleting KEY does nothing to solve this problem. We know that it can be solved by one of two means: 1) well known naming scheme that lets me ask for just what I want. 2) creating a RR for each use. There are various schemes for making the name of #1 be looked up first. They are a total waste of time since they just add a needless layer of indirection (I can't ask for just the NAPTR that I need, can I? I have to sort through them), and they likely cost another round trip. Further, if we decide to designate a well known name for a particular key usage, then there is little reason we can't use "KEY" RR as the format. Rob> This is a totally separate discussion from whether putting keys for Rob> things other than DNSSEC itself into the DNS is a good or bad idea. Rob> If we stipulate that such keys should use a different RR type, I'm Rob> relatively agnostic on the subject. It is not for DNSSEC people to decide if DNSSEC provides the right trust model for another protocol. It is for the designers of that protocol. That means that DNSSEC may not even provide the right trust model for mapping of names to IP addresses for certain end-users! Any proposal that removes functionality without offering an immediate alternative is a complete and total non-starter. You later write: Rob> If the two halves of this proposal were at equal stages of readiness, Rob> this would be a reasonable way forward. Unfortunately, they're not: Until such time as -restrict-key-for-dnssec is massively overhauled to remove the baseless FUD which occupies 90%, then I do not agree that removing KEY has any documented justification. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPU1b7YqHRg3pndX9AQErZwP/Rt5JNzBZeqbTjXWF8ceUPsgKWLnnf5Cw eSK+KnSRTNXSpmDCVPVugcdCgKCIFJG3Mfad/ypEa0RHFCpNgeY9X70sPdUAH9OZ FOXr2B0DBMKAfUhFzjrJcGVqXkkVd5oe5/NvcCJ9J2raLkuWm9ckmcGCWKDDxdNA J9xNcpGM9Ro= =CtA0 -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 02:26:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26571 for ; Tue, 6 Aug 2002 02:26:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17bxTg-0004hV-00 for namedroppers-data@psg.com; Mon, 05 Aug 2002 23:05:56 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17bxTb-0004hK-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 23:05:52 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17bxTa-0000IS-00 for namedroppers@ops.ietf.org; Mon, 05 Aug 2002 23:05:50 -0700 Message-Id: <200208041701.g74H1GkQ008084@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Sun, 04 Aug 2002 09:19:08 +1000." <200208032319.g73NJ8gs002916@drugs.dv.isc.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: Mark.Andrews@isc.org, Simon Josefsson , namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: [Design] Re: the KEY debate Date: Sun, 04 Aug 2002 13:01:16 -0400 From: Michael Richardson X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >>>>> "Mark" == Mark Andrews writes: Mark> We have basically already made a decision about whether we Mark> should have different type or not for application keys. Mark> DNSSEC is one application and the decision was made to Mark> give it its own type by removing the other uses. "we", being whom? I do not agree that there is any consensus on this. I will agree that there is some concern with KEY records at the APEX. The problem was raised in Salt Lake City. It would be nice to ask for a specific sub-type, but frankly, I don't care. Sorting through the types isn't that big of a deal. Given the sizes of the resource records and the desired presence of DNSSEC, the answers may well be large already. I was unable to attend the SIKED BOF. The reports that I heard indicate that a small number of people who hadn't actually read any of the drafts that specify KEY did a bunch of handwaving on how there was no trust model. I see these as efforts to derail DNSSEC deployment. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPU1d2YqHRg3pndX9AQFR7AP+JyjTi+mWqYOrSOOqsNXcD86y1EaRvyTR Jxf9hwNd+BLTkR7vDqZT8lRhIb3eX1dNhvI8u6YlOYqwx8yd44GZChdsu5INcgzE T5TK+350q+mU829HRSfxntKvmGN4HnmS8nQEZA2IYeUt1ZobRgrZcAXzM2BCvTT5 6pGsu2flF/E= =J88s -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 09:14:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10103 for ; Tue, 6 Aug 2002 09:14:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c3uT-000Cep-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 05:58:01 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17c3uJ-000Cee-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 05:57:52 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g76Cvni2013454 for ; Tue, 6 Aug 2002 14:57:49 +0200 To: namedroppers@ops.ietf.org Subject: OpenPGP data in the CERT RR X-Hashcash: 020806:namedroppers@ops.ietf.org:5feafe87930a69e8 From: Simon Josefsson Date: Tue, 06 Aug 2002 14:57:49 +0200 In-Reply-To: (Jakob Schlyter's message of "Mon, 5 Aug 2002 22:08:08 +0200 (CEST)") Message-ID: Lines: 30 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I have tried to summarize the needs OpenPGP data in DNS have, abstract and URL to draft below. Similar discussion also applies to S/MIME, but I'm publishing the OpenPGP document now as it is developed as free software and has more to gain from public debate. It would be nice if this WG could decide which approach for application keying material in DNS they would rather see, otherwise every application is likely to design this separately. The draft below is one attempt to solve this separately, there is a draft for IPSEC with another solution, and drafts for other application seems to be in preparations. Perhaps they can be reviewed and lead to a WG recommendation. I've tried to raise this discussion a few times, but I see little consensus or (in the words of Mr. Vixie) leadership in solving this problem in a way that DNSEXT would prefer. How do you want it to be solved? http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt Abstract This draft describes the decisions made in one pair of applications [4][5] that respectively serves and retrieve OpenPGP [3] Certificates and Revocation Signatures using the CERT Resources Record [2]. The intent is to provide a discussion on the kind of general updates needed to the CERT specification, and some suggested specific updates for the OpenPGP sub-type. It is offered in the hope that this specification, together with similar efforts for other applications, can be reviewed when designing a generic solution or guidelines for storing application keying material in the Domain Name System (DNS), should it ever happen. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 09:17:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10409 for ; Tue, 6 Aug 2002 09:17:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c3wQ-000ChG-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 06:00:02 -0700 Received: from fs3.antd.nist.gov ([129.6.50.151]) by psg.com with esmtp (Exim 3.36 #1) id 17c3wF-000CgM-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 05:59:52 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id g76Cxoe12463; Tue, 6 Aug 2002 08:59:50 -0400 Message-ID: <009b01c23d48$43f2f210$b9370681@BARNACLE> From: "Scott Rose" To: , , "Michael Richardson" Cc: "Rob Austein" References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> Subject: Re: [Design] Re: the KEY debate Date: Tue, 6 Aug 2002 08:53:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Michael Richardson" To: ; Cc: "Rob Austein" Sent: Sunday, August 04, 2002 12:53 PM Subject: Re: [Design] Re: the KEY debate > -----BEGIN PGP SIGNED MESSAGE----- > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > >>>>> "Rob" == Rob Austein writes: > Rob> There is a specific problem with using the KEY RR type for things > Rob> other than DNSSEC's own internal keying. It's called the "sub-typing > Rob> problem" and has been discussed namedroppers many times before, please > Rob> check the archives if you don't already understand the problem. > > Yes, and obsoleting KEY does nothing to solve this problem. > > We know that it can be solved by one of two means: > 1) well known naming scheme that lets me ask for just what I want. > 2) creating a RR for each use. > Restricting KEY to DNSSEC only does solve the sub-typing problem - for DNSSEC. For everything else that wishes to use the DNS to store keys (IPSec and SSH are the only 2 that come to mind). APPKEY faced the same problem - it just pushed the subtyping problem off to all the other protocols and left DNSSEC as the lucky one. Esoteric naming schemes (like SRV) bring an increased chance of admin error (entering RR) and user error (queries). A new RR for each application wishing to use sounds better. If it is good to restrict KEY to DNSSEC, then having a separate RR type for any other public key is a good idea too. Again - we get to avoid the sub-typing problem without resorting to other tricks like naming schemes. > There are various schemes for making the name of #1 be looked up > first. They are a total waste of time since they just add a needless layer of > indirection (I can't ask for just the NAPTR that I need, can I? I have to > sort through them), and they likely cost another round trip. > > Further, if we decide to designate a well known name for a particular key > usage, then there is little reason we can't use "KEY" RR as the format. > > Rob> This is a totally separate discussion from whether putting keys for > Rob> things other than DNSSEC itself into the DNS is a good or bad idea. > Rob> If we stipulate that such keys should use a different RR type, I'm > Rob> relatively agnostic on the subject. > > It is not for DNSSEC people to decide if DNSSEC provides the right trust > model for another protocol. It is for the designers of that protocol. > I think Rob is referring to the ever-ongoing debate every time someone suggests a new RR type be added to the DNS. It's not a security debate, more like a philosophy. Some argue the DNS is fine to use to support other protocols in this way, some consider it a bad thing. I was in camp B. Now I'm leaning towards camp A. If some other protocol thinks that using the DNS is the best way to distribute keys, or other information, then a new RR might be in order. I realize that we aren't the best group to argue what the format of those new RR should be, and that someone experienced with the protocol in question (IPSec, SSH, whatever) needs to be included, but someone with DNS knowledge should be included as well - to make sure it meshes with the agreed DNS spec. > That means that DNSSEC may not even provide the right trust model for > mapping of names to IP addresses for certain end-users! > > Any proposal that removes functionality without offering an immediate > alternative is a complete and total non-starter. You later write: > > Rob> If the two halves of this proposal were at equal stages of readiness, > Rob> this would be a reasonable way forward. Unfortunately, they're not: > > Until such time as -restrict-key-for-dnssec is massively overhauled to > remove the baseless FUD which occupies 90%, then I do not agree that removing > KEY has any documented justification. > Just because this draft restricts KEY to DNSSEC does not mean that there will never be a way of storing other keys in the DNS. Just that the DNS WGs alone aren't the best people to do it. There needs to be some input from the designers of other protocols. First question: what special information (besides the key itself) should be in a IPSec DNS RR RDATA? 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: From owner-namedroppers@ops.ietf.org Tue Aug 6 09:34:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11217 for ; Tue, 6 Aug 2002 09:34:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c4Kh-000D8X-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 06:25:07 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #1) id 17c4Ka-000D81-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 06:25:01 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g76DOn6I021734; Tue, 6 Aug 2002 06:24:49 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g76DOlU8004611; Tue, 6 Aug 2002 06:24:48 -0700 (PDT) Message-Id: <4.3.2.7.2.20020806091805.01a0b398@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Aug 2002 09:24:44 -0400 To: Simon Josefsson From: John Schnizlein Subject: Re: OpenPGP data in the CERT RR Cc: namedroppers@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt Would you please explain how the recommendation below (from the above URL) would accommodate "friendly e-mail addresses" of the form FirstName.LastName@host.example? My concern is that replacing the '@' with '.' in order to use a label format would create a parsing problem for FirstName.LastName.host.example. There could be mailbox for FirstName on a host with the name LastName.host.example. ... However, it is recommended by PGP that such names include the RFC 822 email address of the party, as in "Leslie Example ". If such a format is used, the CERT should be under the standard translation of the email address into a domain name, which would be leslie.host.example in this case. If no RFC 822 name can be extracted from the string name no specific domain name is recommended. John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 09:47:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11725 for ; Tue, 6 Aug 2002 09:47:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c4bN-000DTa-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 06:42:21 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17c4bJ-000DTN-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 06:42:17 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA29980; Tue, 6 Aug 2002 09:42:14 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA14838; Tue, 6 Aug 2002 09:42:13 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA28612; Tue, 6 Aug 2002 09:42:12 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA09286; Tue, 6 Aug 2002 09:42:12 -0400 (EDT) To: Michael Richardson Cc: namedroppers@ops.ietf.org, design@lists.freeswan.org, Rob Austein Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> From: Derek Atkins Date: 06 Aug 2002 09:42:12 -0400 In-Reply-To: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Michael, Remember that the IETF is based on rough consensus, and there has been rough consensus within the DNSEXT working group to restrict "KEY" to only DNSSEC infrastructure. Yes, you object. We know that. We acknowledge that. One objection does not invalidate a rough concensus. May I make a suggestion: instead of using your energy to write long missives about how restrict-key sucks, may I suggest that instead you refocus that time and energy to write a draft that defines a new FSKEY record that defines how to store FreeS/WAN keys in DNS? Feel free to copy-and-paste the text out of 2535 that defines the KEY record, if you feel that is sufficient (I would not actually recommend that -- I don't think you need or want the subtyping in the 2535 KEY record). My recollection of reading the OE draft was that you needed additional information above and beyond what was provided by the KEY record. In particular, IIRC, you needed a pointer to the gateway and the network size to use. This would be the perfect opportunity to combine this all into a single record! I am very sure that if you write such a draft it can progress extremely quickly through the process. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 09:53:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11895 for ; Tue, 6 Aug 2002 09:53:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c4h2-000Dbp-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 06:48:12 -0700 Received: from [202.28.97.2] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17c4gy-000DbN-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 06:48:08 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g76DljG11331; Tue, 6 Aug 2002 20:47:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g76Dl5H26622; Tue, 6 Aug 2002 20:47:05 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: the KEY debate In-Reply-To: <20020805152531.A2D3D28B6C@as.vix.com> References: <20020805152531.A2D3D28B6C@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 2002 20:47:04 +0700 Message-ID: <26620.1028641624@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 05 Aug 2002 15:25:31 +0000 From: Paul Vixie Message-ID: <20020805152531.A2D3D28B6C@as.vix.com> | or even a series of different RR's, on a per-security-system basis. If this stuff has to be in the DNS at all, rather than accessed via some better constructed protocol for the purpose, then that would be the way to accomplish it. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 10:06:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12225 for ; Tue, 6 Aug 2002 10:06:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c4r7-000Dqf-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 06:58:37 -0700 Received: from [202.28.97.2] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17c4px-000Dov-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 06:57:25 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g76DvAG17998; Tue, 6 Aug 2002 20:57:11 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g76DuMH26641; Tue, 6 Aug 2002 20:56:23 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: John Schnizlein cc: Simon Josefsson , namedroppers@ops.ietf.org Subject: Re: OpenPGP data in the CERT RR In-Reply-To: <4.3.2.7.2.20020806091805.01a0b398@wells.cisco.com> References: <4.3.2.7.2.20020806091805.01a0b398@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 2002 20:56:22 +0700 Message-ID: <26639.1028642182@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 06 Aug 2002 09:24:44 -0400 From: John Schnizlein Message-ID: <4.3.2.7.2.20020806091805.01a0b398@wells.cisco.com> | Would you please explain how the recommendation below (from the above URL) | would accommodate "friendly e-mail addresses" of the form | FirstName.LastName@host.example? The same as is done in the SOA.rname field, one would presume. That is, as FirstName\.LastName.host.example. kre ps: this message should not be taking as expressing an opinion on the draft in question. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 10:07:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12290 for ; Tue, 6 Aug 2002 10:07:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c4tb-000DuN-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 07:01:11 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17c4tV-000Du0-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 07:01:05 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA08444; Tue, 6 Aug 2002 10:01:03 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12410; Tue, 6 Aug 2002 10:01:00 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA29730; Tue, 6 Aug 2002 10:00:59 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA09325; Tue, 6 Aug 2002 10:00:59 -0400 (EDT) To: Robert Elz Cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: the KEY debate References: <20020805152531.A2D3D28B6C@as.vix.com> <26620.1028641624@munnari.OZ.AU> From: Derek Atkins Date: 06 Aug 2002 10:00:59 -0400 In-Reply-To: <26620.1028641624@munnari.OZ.AU> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul, Would you be willing to commit "BIND development resources" to implement all these various foo-key records? -derek Robert Elz writes: > Date: Mon, 05 Aug 2002 15:25:31 +0000 > From: Paul Vixie > Message-ID: <20020805152531.A2D3D28B6C@as.vix.com> > > | or even a series of different RR's, on a per-security-system basis. > > If this stuff has to be in the DNS at all, rather than accessed via some > better constructed protocol for the purpose, then that would be the way > to accomplish it. > > kre > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 10:11:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12421 for ; Tue, 6 Aug 2002 10:11:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c4vr-000Dxi-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 07:03:31 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17c4vl-000DxN-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 07:03:25 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g76A2O23028770; Tue, 6 Aug 2002 10:02:24 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA14129; Tue, 6 Aug 2002 10:03:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20020806091805.01a0b398@wells.cisco.com> References: <4.3.2.7.2.20020806091805.01a0b398@wells.cisco.com> Date: Tue, 6 Aug 2002 10:03:06 -0400 To: John Schnizlein , Simon Josefsson From: Edward Lewis Subject: Re: OpenPGP data in the CERT RR Cc: namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I've not read the draft, but seen this issue come up before (e.g., the MNAME in the SOA). FirstName\.LastName.host.example -> FirstName.LastName@host.example. See the note at the bottom of page 36 of RFC 1035. At 9:24 AM -0400 8/6/02, John Schnizlein wrote: >>http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt > >Would you please explain how the recommendation below (from the above URL) >would accommodate "friendly e-mail addresses" of the form >FirstName.LastName@host.example? > >My concern is that replacing the '@' with '.' in order to use a label format >would create a parsing problem for FirstName.LastName.host.example. There >could be mailbox for FirstName on a host with the name LastName.host.example. > > ... However, it is recommended by PGP that such names include > the RFC 822 email address of the party, as in "Leslie Example > ". If such a format is used, the CERT should be > under the standard translation of the email address into a domain > name, which would be leslie.host.example in this case. If no RFC 822 > name can be extracted from the string name no specific domain name is > recommended. > >John > > >-- >to unsubscribe send a message to namedroppers-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 10:21:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12719 for ; Tue, 6 Aug 2002 10:21:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c582-000EGZ-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 07:16:06 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17c57v-000EGM-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 07:15:59 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g76AF523029101; Tue, 6 Aug 2002 10:15:05 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA18143; Tue, 6 Aug 2002 10:15:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 6 Aug 2002 10:15:49 -0400 To: Simon Josefsson , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: OpenPGP data in the CERT RR Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:57 PM +0200 8/6/02, Simon Josefsson wrote: >It would be nice if this WG could decide which approach for >application keying material in DNS they would rather see, otherwise >every application is likely to design this separately. I think it would be preferable for applications to design solutions to their problems, at least at first. If enough applications have designed "experimental" solutions, perhaps then we (DNSers) can extract a systematic solution. Without proper input from the applications, expecting DNSers to design a better approach is unrealistic. >solving this problem in a way that DNSEXT would prefer. How do you >want it to be solved? I understand your rationale for wanting the DNS community to solve this problem to stave off bad solutions from the applications. But I think this is a siren's call. I doubt that a good-for-DNS solution designed by the DNS community will also be good-for-(all-)applications, just as much as you doubt that a good-for-(each-)application solution will also be good-for-DNS. I prefer the former though for a number of previously detailed reasons. I really do want to see documents come from the applications that are interested in distributing keying material via DNS. This is happening, there's a proto-draft for the SSH application in preparation. I was disappointed that there was no IPsec OE input to the SIKED BoF, even though there was a draft available then. I have the OpenPGP draft printed on my desk for reading next. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 10:28:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12972 for ; Tue, 6 Aug 2002 10:28:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c5Fg-000ETN-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 07:24:00 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17c5Fb-000ETB-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 07:23:55 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g76AKW23029267; Tue, 6 Aug 2002 10:20:32 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA20076; Tue, 6 Aug 2002 10:21:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20020805152531.A2D3D28B6C@as.vix.com> <26620.1028641624@munnari.OZ.AU> Date: Tue, 6 Aug 2002 10:21:16 -0400 To: Derek Atkins , Robert Elz From: Edward Lewis Subject: Re: the KEY debate Cc: Paul Vixie , namedroppers@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:00 AM -0400 8/6/02, Derek Atkins wrote: >Paul, > >Would you be willing to commit "BIND development resources" to >implement all these various foo-key records? I would expect that we'd do what we used to do...rely on contributed code ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 11:24:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14804 for ; Tue, 6 Aug 2002 11:24:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c652-000FSd-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 08:17:04 -0700 Received: from [202.28.97.2] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17c64v-000FSR-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 08:17:00 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g76FGhG18101; Tue, 6 Aug 2002 22:16:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g76FG6H27268; Tue, 6 Aug 2002 22:16:07 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Derek Atkins cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: the KEY debate In-Reply-To: References: <20020805152531.A2D3D28B6C@as.vix.com> <26620.1028641624@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 2002 22:16:06 +0700 Message-ID: <27266.1028646966@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: 06 Aug 2002 10:00:59 -0400 From: Derek Atkins Message-ID: | Would you be willing to commit "BIND development resources" to | implement all these various foo-key records? I'm not Paul (nor Ed) but if all of these records have the same syntax, which is what would be required for the magic name variant to work, then the resources needed to support 10 or 20 of the things is essentially the same as those required to support one (just a few extra labels in a couple of case statements for the extra types with the same syntax). On the other hand, if they need to differ, then the magic name scheme doesn't work at all, so there's no choice. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 12:31:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17345 for ; Tue, 6 Aug 2002 12:31:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c75N-000Gh0-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 09:21:29 -0700 Received: from [204.152.187.70] (helo=as.vix.com) by psg.com with esmtp (Exim 3.36 #1) id 17c75J-000Ggl-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 09:21:25 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id A9B8128B6E for ; Tue, 6 Aug 2002 16:21:22 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: the KEY debate In-Reply-To: Message from Edward Lewis of "Tue, 06 Aug 2002 10:21:16 -0400." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 06 Aug 2002 16:21:22 +0000 Message-Id: <20020806162122.A9B8128B6E@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > >Would [ISC] be willing to commit "BIND development resources" to > >implement all these various foo-key records? of course. our charter, from www.isc.org, is ... developing and maintaining production quality Open Source reference implementations of core Internet protocols. > I would expect that we'd do what we used to do...rely on contributed code ;) that's been truer in the past than in the present. we don't "rely" as much on contributed code as we once did. however, please note that contributions of code and equipment (and money) are always welcomed. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 13:23:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19403 for ; Tue, 6 Aug 2002 13:23:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c7vi-000Hnh-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 10:15:34 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17c7vd-000HnA-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 10:15:29 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g76DET23032002; Tue, 6 Aug 2002 13:14:29 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA24123; Tue, 6 Aug 2002 13:15:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 6 Aug 2002 13:15:09 -0400 To: Simon Josefsson , namedroppers@ops.ietf.org From: Edward Lewis Subject: Re: OpenPGP data in the CERT RR Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 2:57 PM +0200 8/6/02, Simon Josefsson wrote: >http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt Issue #1 -> going from a digital signature to finding a copy of a certificate needed to verify the signature. Sigh, always an issue. This is a problem I've had experience with in the X.509 realm. In my lab-baked solution, I just included a domain name with the signature in the data structures I passed. I can understand how this might be different when trying to weld this into existing applications, like email. Defining a convention for determining a domain name from a signature structure is one thing being done in this draft. Not being a PGP expert, I can't comment or really add to the text. One concern about section 2.1 is to make sure that the added bytes don't scrunch up the name (a concern I read in Eric Hall's expired draft on DNS data considerations). A concern in section 2.2 is that relying on a CNAME at one name to point to another limits what can be stored at the owner of the CNAME. Hopefully no other application wants to have data at such a name. (These are examples of why specifying naming conventions can be tricky.) The rest of the issues I've broken down section-by-section: Section 3 is a perfect example of why applications need to do this work and not DNS. (See how "we"[0] screwed up the first time? You want to ask us to do this again?) The same issue happened with SSH and is what prompted APPKEY. For SSH the KEY RR was insufficient because the KEY RR couldn't convey the SSH version information needed to decipher the key. Apparently, "PGP" isn't specific enough for the CERT RR. (Maybe just more algorithm types are needed.) Section 4 is an unforeseen problem for DNS - data too big for an RR, and perhaps even an RR set. I don't know if you want to suffix names though, it separates data, but then again if you are worried about message size you want it separated. I would argue that at this point, just use SRV records and make queries into a system more suited to large data elements. Section 5 twists the key id field, and I don't know that you want to go there. This makes the interpretation of that field (which is supposed to hold the key id of a KEY RR held at the same name, a useless appendage pending restrict-KEY) dependent on the algorithm field, unless we redefine that field altogether, given restrict key. Section 6 talks about revocation, and I'm not sure I know enough PGP to know about this. In X.509, I was able to store both DER-encoded certificates and revocation lists in the PKIX algorithm type. One thing that helped X509 certificates in DNS. Once I managed to locate the initial certificate, it had the domain names of all others I needed - the "AltName" of the issuer and also of the revocation list. So once I entered DNS, I could bounce through the system easily and without neededing a name conversion convention. I was even able to specify multiple domains as AltNames too. [0] No offense intended to the editors, they were working at the beck-and-call of the WG. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 14:51:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23826 for ; Tue, 6 Aug 2002 14:51:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17c9Fj-000JVm-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 11:40:19 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17c9Fe-000JVU-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 11:40:14 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g76EdD23032956; Tue, 6 Aug 2002 14:39:13 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA09841; Tue, 6 Aug 2002 14:39:58 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200208041701.g74H1GkQ008084@marajade.sandelman.ottawa.on.ca> References: <200208041701.g74H1GkQ008084@marajade.sandelman.ottawa.on.ca> Date: Tue, 6 Aug 2002 14:39:34 -0400 To: Michael Richardson , Mark.Andrews@isc.org, Simon Josefsson , namedroppers@ops.ietf.org, design@lists.freeswan.org From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 1:01 PM -0400 8/4/02, Michael Richardson wrote: > I was unable to attend the SIKED BOF. The reports that I heard indicate >that a small number of people who hadn't actually read any of the drafts that >specify KEY did a bunch of handwaving on how there was no trust model. ? The only documents relating to the KEY RR are RFC's 2065 and 2535 (latter obsoletes the former), and neither was under discussion at the SIKED BoF. The fact is that a large part of the discussion did focus on a lack of a trust model, this so-called hand waving was detailed enough to convince the me that we were attacking the problem from the wrong direction - namely from DNS out to the applications. > I see these as efforts to derail DNSSEC deployment. I don't see DNSSEC (deployment) tied to the application key issue at all. No one questioning the SIKED BoF ever raised a an issue with DNSSEC. In fact, the same group (SAAG) that was putting SIKED's feet to the fire are the same that hosted the DNSSEC WG (I didn't misspell DNSIND, DNSEXT, or DNSOP) for much of the 90's, i.e., they started it. While now I know that Michael wasn't able to attend the BoF, I was disappointed that there was no one at the BoF to address the OE work in any capacity. I was really hoping to have someone talk about that to help bolster the pan-application desire for a common DNS solution. Since that didn't materialize, I've come to feel that it is up to the applications to decide what they want independently. Sometime grand unification schemes are not the right approach. (The lack of an OE presentation isn't the only reason I changed my mind, but it was a step towards the change.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 16:32:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27960 for ; Tue, 6 Aug 2002 16:32:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cAoG-000Lgx-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 13:20:04 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17cAo9-000LgI-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 13:19:57 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g76KJfi2021768; Tue, 6 Aug 2002 22:19:41 +0200 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: OpenPGP data in the CERT RR References: X-Hashcash: 020806:edlewis@arin.net:f16e8224f26d17e8 X-Hashcash: 020806:namedroppers@ops.ietf.org:55e462f96bfb85f9 From: Simon Josefsson Date: Tue, 06 Aug 2002 22:19:42 +0200 In-Reply-To: (Edward Lewis's message of "Tue, 6 Aug 2002 13:15:09 -0400") Message-ID: Lines: 107 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 2:57 PM +0200 8/6/02, Simon Josefsson wrote: >>http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt > > Issue #1 -> going from a digital signature to finding a copy of a > certificate needed to verify the signature. Sigh, always an issue. > > This is a problem I've had experience with in the X.509 realm. In my > lab-baked solution, I just included a domain name with the signature > in the data structures I passed. I can understand how this might be > different when trying to weld this into existing applications, like > email. OpenPGP signatures contains the Key ID of the signer, so assuming the recipient has configured her client to look into e.g. dnskeys.josefsson.org, this isn't a problem. When OpenPGP is used in e-mail the sender's email address ("From:") can be used as a hint to find the OpenPGP certificate if the recipient simply enable DNS-based key servers, no need to specify a particular zone to look into. > Defining a convention for determining a domain name from a signature > structure is one thing being done in this draft. Not being a PGP > expert, I can't comment or really add to the text. Actually, this is under discussion, and the text in the draft will be modified and enhanced with a rationale for the owner name recommendation. > One concern about section 2.1 is to make sure that the added bytes > don't scrunch up the name (a concern I read in Eric Hall's expired > draft on DNS data considerations). A concern in section 2.2 is that > relying on a CNAME at one name to point to another limits what can > be stored at the owner of the CNAME. Hopefully no other application > wants to have data at such a name. (These are examples of why > specifying naming conventions can be tricky.) KeyId based owner names will be used in "special" zones. The zone name is either configured by the recipient, or specified in the OpenPGP preferred key server sub-packet. So I don't expect this to be a problem. It would for a generic solution though. > The rest of the issues I've broken down section-by-section: > > Section 3 is a perfect example of why applications need to do this > work and not DNS. (See how "we"[0] screwed up the first time? You > want to ask us to do this again?) The same issue happened with SSH > and is what prompted APPKEY. For SSH the KEY RR was insufficient > because the KEY RR couldn't convey the SSH version information needed > to decipher the key. Apparently, "PGP" isn't specific enough for the > CERT RR. (Maybe just more algorithm types are needed.) The "problem" here, as I perceive it, is that the CERT specification tried to be specific about RDATA but failed. If it simply defined the framework, it could leave the description of individual sub-types to other documents. Defining the framework is what I'd like this WG to do. This also splits the design of the DNS part to DNS WGs and design of application-specific data parts to other people. > Section 4 is an unforeseen problem for DNS - data too big for an RR, > and perhaps even an RR set. I don't know if you want to suffix names > though, it separates data, but then again if you are worried about > message size you want it separated. How would it be solved otherwise? > I would argue that at this point, just use SRV records and make > queries into a system more suited to large data elements. This may lead to security problems. If I store the data in DNS, I can use DNSSEC or TSIG to protect the data, if I use SRV I can only protect the pointer to the server, but the connection to that server is not protected. > Section 5 twists the key id field, and I don't know that you want to > go there. This makes the interpretation of that field (which is > supposed to hold the key id of a KEY RR held at the same name, a > useless appendage pending restrict-KEY) dependent on the algorithm > field, unless we redefine that field altogether, given restrict key. The Key Id field of CERT is computed on the key inside the certificate. It has nothing to do with the KEY RR, except the algorithm numbers are shared. I don't see how this "twists" the field, from how I read the definition in RFC 2538 it looks like I'm using it for exactly what it was intended for -- optimizing cert selection when there are several keys/certs. > Section 6 talks about revocation, and I'm not sure I know enough PGP > to know about this. In X.509, I was able to store both DER-encoded > certificates and revocation lists in the PKIX algorithm type. Problem is that revocation data is small, so I want to separate it from certificate data so packets aren't overflowed. Sub-typing can't do that though, but it was suggested to use different owner names to solve that. > One thing that helped X509 certificates in DNS. Once I managed to > locate the initial certificate, it had the domain names of all others > I needed - the "AltName" of the issuer and also of the revocation > list. So once I entered DNS, I could bounce through the system easily > and without neededing a name conversion convention. I was even able > to specify multiple domains as AltNames too. OpenPGP has something similar, although it is not always used. Just as X.509, that is. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 16:37:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28090 for ; Tue, 6 Aug 2002 16:37:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cAxM-000LtC-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 13:29:28 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17cAxH-000Lt0-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 13:29:23 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g76KTGi2021868; Tue, 6 Aug 2002 22:29:16 +0200 To: Derek Atkins Cc: Michael Richardson , namedroppers@ops.ietf.org, design@lists.freeswan.org, Rob Austein Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> X-Hashcash: 020806:warlord@MIT.EDU:cf50d285fdf89288 X-Hashcash: 020806:mcr@sandelman.ottawa.on.ca:0b96578b11481eb0 X-Hashcash: 020806:namedroppers@ops.ietf.org:bb42c744e006a296 X-Hashcash: 020806:design@lists.freeswan.org:1ffda6fa15db431e X-Hashcash: 020806:sra@hactrn.net:e1fd2c8d155ef02d From: Simon Josefsson Date: Tue, 06 Aug 2002 22:29:17 +0200 In-Reply-To: (Derek Atkins's message of "06 Aug 2002 09:42:12 -0400") Message-ID: Lines: 23 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Derek Atkins writes: > May I make a suggestion: instead of using your energy to write long > missives about how restrict-key sucks, may I suggest that instead you > refocus that time and energy to write a draft that defines a new FSKEY > record that defines how to store FreeS/WAN keys in DNS? Feel free to > copy-and-paste the text out of 2535 that defines the KEY record, if > you feel that is sufficient (I would not actually recommend that -- I > don't think you need or want the subtyping in the 2535 KEY record). Is this the WG blessed answer to storing application keying material in DNS? Defining new RRs, that is. If it isn't the WG blessed solution, why should he follow this suggestion instead of continuing to use what is already implemented and described in a draft? It seems like someone else could suggest FreeS/WAN to sub-type CERT instead, or sub-type KEY (which actually was designed for this purpose once upon a time), or encode the key into AAAA records, and these recommendations would be equally valid and equally useful to someone that has already implemented and documented another solution. Having a blessed (as in reviewed and designed by DNS people) answer to this problem was all that SIKED was about, at least that's my interpretation of it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 16:41:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28232 for ; Tue, 6 Aug 2002 16:40:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cB26-000M0P-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 13:34:22 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17cB1y-000LzO-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 13:34:14 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g76KYAi2021942; Tue, 6 Aug 2002 22:34:11 +0200 To: Edward Lewis Cc: namedroppers@ops.ietf.org Subject: Re: OpenPGP data in the CERT RR References: X-Hashcash: 020806:edlewis@arin.net:455e838878a8c0ac X-Hashcash: 020806:namedroppers@ops.ietf.org:8857442e20011251 From: Simon Josefsson Date: Tue, 06 Aug 2002 22:34:11 +0200 In-Reply-To: (Edward Lewis's message of "Tue, 6 Aug 2002 10:15:49 -0400") Message-ID: Lines: 19 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: > At 2:57 PM +0200 8/6/02, Simon Josefsson wrote: >>It would be nice if this WG could decide which approach for >>application keying material in DNS they would rather see, otherwise >>every application is likely to design this separately. > > I think it would be preferable for applications to design solutions to > their problems, at least at first. If enough applications have > designed "experimental" solutions, perhaps then we (DNSers) can > extract a systematic solution. Without proper input from the > applications, expecting DNSers to design a better approach is > unrealistic. Yes. That's why I wrote the draft. I used to believe that this problem was easy enough so that a framework could be developed by the DNS community for application developers, but I now realized this isn't happening. So I'll solve the problems as an application writer and document it and leave it at that. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 16:45:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28357 for ; Tue, 6 Aug 2002 16:45:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cB6S-000M7z-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 13:38:52 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17cB6L-000M7V-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 13:38:45 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g76Kcbi2021988; Tue, 6 Aug 2002 22:38:37 +0200 To: Edward Lewis Cc: Michael Richardson , Mark.Andrews@isc.org, namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: [Design] Re: the KEY debate References: <200208041701.g74H1GkQ008084@marajade.sandelman.ottawa.on.ca> X-Hashcash: 020806:edlewis@arin.net:03286fe7af710bcf X-Hashcash: 020806:mcr@sandelman.ottawa.on.ca:2cc28c88a9f1f91e X-Hashcash: 020806:Mark.Andrews@isc.org:44a656659e3dad8e X-Hashcash: 020806:namedroppers@ops.ietf.org:02a315d9d7267431 X-Hashcash: 020806:design@lists.freeswan.org:c753563480b0363b From: Simon Josefsson Date: Tue, 06 Aug 2002 22:38:38 +0200 In-Reply-To: (Edward Lewis's message of "Tue, 6 Aug 2002 14:39:34 -0400") Message-ID: Lines: 14 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis writes: >> I see these as efforts to derail DNSSEC deployment. > > I don't see DNSSEC (deployment) tied to the application key issue at > all. I think this depends on what you mean with DNSSEC. If all DNSSEC is to you is a secure DNS infrastructure, then clearly application keys has nothing to do with it. But DNSSEC was designed to support key storage for applications (please read the RFC 2535 abstract), and if you consider DNSSEC to be a bearer for application keys, then removing that functionality from DNSSEC and excluding CERT RR from a DNSSEC update, it clearly derails DNSSEC deployment. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 17:08:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28940 for ; Tue, 6 Aug 2002 17:08:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cBTK-000Mo1-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 14:02:30 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cBTG-000Mnk-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 14:02:26 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g76H1T23034373; Tue, 6 Aug 2002 17:01:29 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA04731; Tue, 6 Aug 2002 17:02:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> Date: Tue, 6 Aug 2002 16:59:11 -0400 To: Simon Josefsson , Derek Atkins From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Cc: Michael Richardson , namedroppers@ops.ietf.org, design@lists.freeswan.org, Rob Austein Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:29 PM +0200 8/6/02, Simon Josefsson wrote: >Is this the WG blessed answer to storing application keying material >in DNS? Defining new RRs, that is. Seems like the best current approach to me, but there's no "blessed" label to apply to it. >Having a blessed (as in reviewed and designed by DNS people) answer to >this problem was all that SIKED was about, at least that's my >interpretation of it. Oh my lord no! SIKED was accidently about DNS folks defining how to put application keys into DNS - only 'cause we started it. SIKED wasn't supposed to be so - which is why it was forked off from DNSEXT. But we kept coming back to DNS and that's why there's no SIKED II BoF. Had SIKED went anywhere, we would have been in the Security Area, not in the areas currently doing DNS (Internet and O&M). Look back at the keydist archives. I tried floating discussion topics, at first trying to define the problem and then later "Let's assume DNS is involved." http://www.cafax.se/keydist/maillist/2001-12/msg00009.html and http://www.cafax.se/keydist/maillist/2002-03/msg00005.html and http://www.cafax.se/keydist/maillist/2002-03/msg00048.html -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 17:12:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29028 for ; Tue, 6 Aug 2002 17:12:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cBTT-000MoC-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 14:02:39 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cBTG-000Mnl-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 14:02:26 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g76H1W23034376; Tue, 6 Aug 2002 17:01:32 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA04735; Tue, 6 Aug 2002 17:02:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <200208041701.g74H1GkQ008084@marajade.sandelman.ottawa.on.ca> Date: Tue, 6 Aug 2002 17:01:46 -0400 To: Simon Josefsson , Edward Lewis From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Cc: Michael Richardson , Mark.Andrews@isc.org, namedroppers@ops.ietf.org, design@lists.freeswan.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 10:38 PM +0200 8/6/02, Simon Josefsson wrote: >has nothing to do with it. But DNSSEC was designed to support key >storage for applications (please read the RFC 2535 abstract), and if I know, I was one who gave many tutorials, workshops, etc. saying this. I was wrong. Mistakes were made. People wasted time. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 17:33:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00267 for ; Tue, 6 Aug 2002 17:33:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cBpH-000NRZ-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 14:25:11 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17cBpC-000NRI-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 14:25:06 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA19709; Tue, 6 Aug 2002 17:25:03 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA29590; Tue, 6 Aug 2002 17:25:00 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id RAA04990; Tue, 6 Aug 2002 17:24:57 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA10098; Tue, 6 Aug 2002 17:24:57 -0400 (EDT) To: Simon Josefsson Cc: Michael Richardson , namedroppers@ops.ietf.org, design@lists.freeswan.org, Rob Austein Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> From: Derek Atkins Date: 06 Aug 2002 17:24:57 -0400 In-Reply-To: Message-ID: Lines: 50 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Simon Josefsson writes: > Is this the WG blessed answer to storing application keying material > in DNS? Defining new RRs, that is. If it isn't the WG blessed > solution, why should he follow this suggestion instead of continuing > to use what is already implemented and described in a draft? It seems > like someone else could suggest FreeS/WAN to sub-type CERT instead, or > sub-type KEY (which actually was designed for this purpose once upon a > time), or encode the key into AAAA records, and these recommendations > would be equally valid and equally useful to someone that has already > implemented and documented another solution. No, it is not the WG blessed answer. It is a suggestion, and was framed as such. You are correct that subtyping CERT is another reasonable approach. I do not believe that subtyping KEY is a reasonable approach (although a copy-and-paste of the text defining KEY into a new draft that defines fooKEY would be reasonable, IMHO). At this point I am just tired of the running around the issue. I give up. I want to see progress. As I was a vocal proponent of sub-typing, I give up and buy into the type-per-application and have encouranged Mr. Richardson to work towards that goal. If this means I need to host a DNSKEY BOF in Atlanta, so be it. > Having a blessed (as in reviewed and designed by DNS people) answer to > this problem was all that SIKED was about, at least that's my > interpretation of it. No, SIKED was trying to be more. I want to see a specific niche carved out: a framework for how to store application keys in DNS for those applications that completely understand all the issues involved. My hope would be that we could create a template that applications could follow to define their own key-type. Most of the work would be writing the security considerations to appease people like Mr. Moore who clearly believes that nobody should trust application keys from DNS, whereas there is clearly a community who believes that DNSSEC-based security is "good enough." So please, Mr. Richardson, write that draft. I look forward to reading it. Perhaps it can be the basis of this "template" (if said pipe-dream of mine ever happens). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 17:48:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00809 for ; Tue, 6 Aug 2002 17:48:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cC43-000Noz-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 14:40:27 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17cC3v-000No9-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 14:40:19 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id CD1CE52AA; Tue, 6 Aug 2002 23:40:12 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 9A9891DE9; Tue, 6 Aug 2002 23:40:06 +0200 (MEST) Date: Tue, 6 Aug 2002 23:40:06 +0200 (CEST) From: Jakob Schlyter To: Simon Josefsson Cc: Derek Atkins , Michael Richardson , IETF DNSEXT WG , , Rob Austein Subject: Re: [Design] Re: the KEY debate In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, 6 Aug 2002, Simon Josefsson wrote: > Is this the WG blessed answer to storing application keying material in > DNS? Defining new RRs, that is. I suggest that the people who believe they have a protocol that would benefit from storing keying material in the DNS define an RRs, write some code and deploy it - then we'll evaluate and see what does work and what does not. the alternative might of course be to discuss this forever and while we're discussing people will go off using TXT records instead. jakob ps. I know OE currently uses TXT records and there is a reason for it since there currently isn't anything better - let's build that better thing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 6 23:47:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10388 for ; Tue, 6 Aug 2002 23:47:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cHY7-0005pc-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 20:31:51 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17cHY3-0005pR-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 20:31:47 -0700 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g773W6h21856 for ; Tue, 6 Aug 2002 23:32:09 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020806223343.015f2c60@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 06 Aug 2002 23:07:41 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: call for consensus: GSSAPI TKEY exchange and TSIG RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Levon Esibov, (principal author of GSSAPI TSIG) asked for further working group input on the issue raised about 10 days ago. GSSAPI TSIG ID has passed working group last call, in this document there is a issue in one section related to the key exchange interaction that is in violation to the TSIG RFC. In section 4.2 of RFC 2845: "The server MUST not generate a signed response to an unsigned request." In GSSAPI TSIG ID the TKEY sequence specifies that the server can sign the last message in order to enable the client to make sure the exchange was successful. In general it is a bad idea to allow extensions to a protocol to modify the base protocol in a non explicit manner. In this case there are following advantages: certain value to the last TSIG from security perspective, no client that is not GSSAPI TSIG participant will see this compliant with deployed base from at least 2 vendors. And following drawbacks: This is a violation with minimal gain and may force change in TSIG processing in existing implementations due to the fact that there is no secret known until after the message is processed. In general TKEY exchanges for all algorithms can derive the same benefits from the behavior specified in GSSAPI TSIG ID. I have been asked to ask the working group if the following change to TSIG RFC is acceptable: In section 4.2 of RFC 2845 replace: "The server MUST not generate a signed response to an unsigned request." With something like: "The server MUST not generate a signed response to an unsigned request, except if specification of an individual signature algorithm explicitly allows this." If this change is not acceptable or feasible, I will ask for guidance from the working group how to best change the GSSAPI TSIG specification. Please send me or the mailing list technical arguments for or against, of particular interest is the effect of this change on existing TSIG implementations. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 00:32:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11982 for ; Wed, 7 Aug 2002 00:32:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cIOn-00073T-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 21:26:17 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17cIOj-00073I-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 21:26:13 -0700 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g774QTh22016; Wed, 7 Aug 2002 00:26:30 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020807000755.01679aa8@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 07 Aug 2002 00:25:50 -0400 To: Simon Josefsson , Edward Lewis From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: [Design] Re: the KEY debate Cc: namedroppers@ops.ietf.org, design@lists.freeswan.org In-Reply-To: References: <200208041701.g74H1GkQ008084@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 16:38 2002-08-06, Simon Josefsson wrote: >Edward Lewis writes: > > >> I see these as efforts to derail DNSSEC deployment. > > > > I don't see DNSSEC (deployment) tied to the application key issue at > > all. > >I think this depends on what you mean with DNSSEC. If all DNSSEC is >to you is a secure DNS infrastructure, then clearly application keys >has nothing to do with it. But DNSSEC was designed to support key >storage for applications (please read the RFC 2535 abstract), and if >you consider DNSSEC to be a bearer for application keys, then removing >that functionality from DNSSEC and excluding CERT RR from a DNSSEC >update, it clearly derails DNSSEC deployment. DNSSEC charter was to secure the DNS infrastructure. In order to do that it was necessary to distribute keys for DNS, it was a logical minor extension to allow other uses of the same record. Since RFC2065 KEY record has been restricted more and more each year as sub-typing is a bad thing. There are three ways that I see that DNS can help applications with keying store the keys in DNS store footprints of the keys in DNS (when protocol can pass the key in-band). point to where the key is available from. The first one can either be done by application specific type or some naming schema, it is much easier to avoid problems with types than with names, it is harder on DNS implementations (until they fully support unknown types). The footprint solution requires new type. The pointer solution needs careful considerations on how trust is transferred from DNS to say LDAP. One other thing that I took from the old KEY discussions was that every application wanted to be able to carry some information along with the key, the only way to do that in KEY RR was by using flags. This is a real bad idea, I hope new KEY RR types will consider what information makes sense to carry with the key and encode that in the RR type. Speaking as a co-char, I encourage new types a this point in time. If I'm wrong, again, so be it, no one can say that one approach is better than the other one, and so we picked one, I hope to see in addition to your PGP draft, one for SSH and another one for IPSEC. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 00:55:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12438 for ; Wed, 7 Aug 2002 00:55:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cIiw-0007YC-00 for namedroppers-data@psg.com; Tue, 06 Aug 2002 21:47:06 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17cIip-0007Xw-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 21:46:59 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17cIim-0000ew-00 for namedroppers@ops.ietf.org; Tue, 06 Aug 2002 21:46:56 -0700 Message-Id: <200208070147.g771lp1k024054@marajade.sandelman.ottawa.on.ca> In-reply-to: Your message of "Tue, 06 Aug 2002 14:39:34 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: [Design] Re: the KEY debate Date: Tue, 06 Aug 2002 21:47:51 -0400 From: Michael Richardson X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >>>>> "Edward" == Edward Lewis writes: Edward> unification schemes are not the right approach. (The lack of an OE Edward> presentation isn't the only reason I changed my mind, but it was a Edward> step towards the change.) The offer was made. I was not placed upon the agenda, as we had a very well developped draft that you could read. The time for the BOF arrived while we were busy trying to debug some "running code" that had died in an unexpected way, and then the time left, and we hadn't moved. That was our fault. But, we could very well not have even been in the building or in the city. That shouldn't affect IETF progress. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPVB8QIqHRg3pndX9AQEb0QQAtOV0hMiQoN/6ABTB9m2p6aBLoIZHhm9j kWJOy05e6BCSY07MKcV7a0mfDnENy3zqTaaxuDW47W8D5RIIvq5xRqT0ehy6rxvI 7EEyvW5v37VYAMh2TBn7gdAzlvTSM9GFELXwn/rTO4H7Utxljo8Iff+isYEeoYGE 3/i2lSkvGpQ= =Xqku -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 09:20:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16781 for ; Wed, 7 Aug 2002 09:20:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cQQa-000EnM-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 06:00:40 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cQQO-000En3-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 06:00:29 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g778xI23040956; Wed, 7 Aug 2002 08:59:18 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA23933; Wed, 7 Aug 2002 08:59:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <200208070147.g771lp1k024054@marajade.sandelman.ottawa.on.ca> References: <200208070147.g771lp1k024054@marajade.sandelman.ottawa.on.ca> Date: Wed, 7 Aug 2002 08:41:29 -0400 To: Michael Richardson , namedroppers@ops.ietf.org, design@lists.freeswan.org From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:47 PM -0400 8/6/02, Michael Richardson wrote: > The offer was made. I was not placed upon the agenda, as we had a very well >developed draft that you could read. I asked but got no reply: http://www.cafax.se/keydist/maillist/2002-02/msg00002.html Since you already had a draft, OE wasn't listed on: http://www.cafax.se/keydist/maillist/2002-01/msg00112.html or http://www.cafax.se/keydist/maillist/2002-01/msg00170.html Had you offered to be on the agenda, we would have liked you to be. I guess we weren't clear enough, at least not in a public forum. > That was our fault. But, we could very well not have even been in the >building or in the city. That shouldn't affect IETF progress. True, and you have been active on the keydist list. (I've dropped off it for various reasons.) As far as affecting progress, it's hard to say, but without a voice in the room to defend the effort from yet-another-angle, momentum for the effort was adversely affected. BTW, there's no official "death certificate" for SIKED, and it is eligible for another BoF - it just needs folks that are willing to pull it off. I think the chairs of the BoF would be willing to pass chair-ships onwards. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 09:38:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17520 for ; Wed, 7 Aug 2002 09:38:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cQqb-000FHR-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 06:27:33 -0700 Received: from fs3.antd.nist.gov ([129.6.50.151]) by psg.com with esmtp (Exim 3.36 #1) id 17cQqV-000FGd-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 06:27:27 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id g77DRJe27216; Wed, 7 Aug 2002 09:27:19 -0400 Message-ID: <010a01c23e15$4585b0e0$b9370681@BARNACLE> From: "Scott Rose" To: "Derek Atkins" Cc: , References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> Subject: Re: [Design] Re: the KEY debate Date: Wed, 7 Aug 2002 09:20:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Derek Atkins" To: "Simon Josefsson" Cc: "Michael Richardson" ; ; ; "Rob Austein" Sent: Tuesday, August 06, 2002 5:24 PM Subject: Re: [Design] Re: the KEY debate > > At this point I am just tired of the running around the issue. I give > up. I want to see progress. As I was a vocal proponent of > sub-typing, I give up and buy into the type-per-application and have > encouranged Mr. Richardson to work towards that goal. > > If this means I need to host a DNSKEY BOF in Atlanta, so be it. > > > Having a blessed (as in reviewed and designed by DNS people) answer to > > this problem was all that SIKED was about, at least that's my > > interpretation of it. > > No, SIKED was trying to be more. I want to see a specific niche > carved out: a framework for how to store application keys in DNS for > those applications that completely understand all the issues involved. > My hope would be that we could create a template that applications > could follow to define their own key-type. Most of the work would be > writing the security considerations to appease people like Mr. Moore > who clearly believes that nobody should trust application keys from > DNS, whereas there is clearly a community who believes that > DNSSEC-based security is "good enough." > I've been thinking the same thing - a BOF about using DNS to support other applications and set up a general framework/process for getting any type of network information in the DNS. Not just keys. The hard part would be to stress that the DNS isn't an end all solution, but a possible option for things like certificates and key distribution, now that DNSSEC has added integrity and source authentication. I always thought SIKED was more of a general purpose "Interent Key Distribution methods" BOF. The fact that "DNS people" started it was supposed to be irrelavent, but I think that may have been one of the caused it didn't catch on: Other people thought it was strickly a DNS group when it was hoped to be more. Correct me if I'm wrong. As for the BOF, why don't we all call it PDNS, for "Pimping DNS for other applications"? Depends on how you view it I guess. 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 09:59:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18450 for ; Wed, 7 Aug 2002 09:59:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cRFD-000Fn7-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 06:52:59 -0700 Received: from outpost.ds9a.nl ([213.244.168.210]) by psg.com with esmtp (Exim 3.36 #1) id 17cRF9-000Fmw-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 06:52:55 -0700 Received: by outpost.ds9a.nl (Postfix, from userid 1000) id EEB333FDC; Wed, 7 Aug 2002 15:52:52 +0200 (CEST) Date: Wed, 7 Aug 2002 15:52:52 +0200 From: bert hubert To: Scott Rose Cc: Derek Atkins , namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: Re: [Design] Re: the KEY debate Message-ID: <20020807135252.GA25989@outpost.ds9a.nl> References: <010a01c23e15$4585b0e0$b9370681@BARNACLE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010a01c23e15$4585b0e0$b9370681@BARNACLE> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Aug 07, 2002 at 09:20:59AM -0400, Scott Rose wrote: > > As for the BOF, why don't we all call it PDNS, for "Pimping DNS for other > applications"? > Depends on how you view it I guess. > Well, our daemon is already called 'pdns' so please don't :-) Regards, bert -- http://www.PowerDNS.com Versatile DNS Software & Services http://www.tk the dot in .tk http://lartc.org Linux Advanced Routing & Traffic Control HOWTO -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 12:17:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26291 for ; Wed, 7 Aug 2002 12:17:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cTHy-000IRP-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 09:03:58 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17cTHt-000IRE-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 09:03:54 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g77FvweD014311; Wed, 7 Aug 2002 08:58:22 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 09:05:11 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D813570@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Scott Rose , Derek Atkins Cc: namedroppers@ops.ietf.org, design@lists.freeswan.org Subject: RE: [Design] Re: the KEY debate Date: Wed, 7 Aug 2002 09:04:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The problem with the SIKED BOF is that the organizers had a preconcieved notion of their solution and platform. The reason that there was little interest in the SIKED approach is that there is already an Open Working Group that is developing a key centric PKI that provides a superset of the proposed SIKED functionality with much less complexity called XKMS. XKMS is supported by all the major PKI vendors and many others. It is an important part of the infrastructure being developed to support Web Services Security. The IETF has spent ten years each developing PKIX and DNSSEC. There is no likelihood that SIKED or anything like it will complete in under three years. Nor after the DNS Directorate/OPTIN debacle can the IETF claim any particular credibility as an open standards organization over W3C or OASIS. This group has no business making proposals for general purpose PKI infrastructure until it has proposed a deployable infrastructure to support DNS itself. 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 15:26:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04666 for ; Wed, 7 Aug 2002 15:26:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cW9U-000Lx0-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 12:07:24 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cW9O-000Lwp-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 12:07:18 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157031; Wed, 07 Aug 2002 14:04:36 -0500 Message-ID: <3D516FE1.9030405@ehsco.com> Date: Wed, 07 Aug 2002 14:07:13 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Scott Rose CC: namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 8:20 AM Scott Rose wrote: > I've been thinking the same thing - a BOF about using DNS to support > other applications and set up a general framework/process for getting > any type of network information in the DNS. Ugh. The more crap we put into DNS the less useful it will be for lightweight lookups. We'll need another DNS if we pimp this one. Might I suggest that it would be more fruitful to work on ways to support applications in one or more external services, and solving the problems with those services such that they would be usable. I am working on the LDAP-WHOIS stuff just for this purpose (give every delegated domain and netblock LDAP referral hooks at the time of delegation). There are lots of other options out there that also deserve attention. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 16:03:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06595 for ; Wed, 7 Aug 2002 16:03:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cWv1-000MtI-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 12:56:31 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17cWux-000Mt6-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 12:56:27 -0700 Received: from [128.177.194.167] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 4C28F137F05; Wed, 7 Aug 2002 12:56:26 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 07 Aug 2002 12:56:35 -0700 Subject: Re: [Design] Re: the KEY debate From: David Conrad To: "Eric A. Hall" , Scott Rose Cc: namedroppers Message-ID: In-Reply-To: <3D516FE1.9030405@ehsco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8/7/02 12:07 PM, "Eric A. Hall" wrote: >> I've been thinking the same thing - a BOF about using DNS to support >> other applications and set up a general framework/process for getting >> any type of network information in the DNS. > > Ugh. The more crap we put into DNS the less useful it will be for > lightweight lookups. We'll need another DNS if we pimp this one. Can we _PLEASE_ stop with this FUD? Explain exactly why adding a new RR type, one that does not change the underlying DNS algorithms, will have any significant impact on the DNS, much less make it "less useful". On the contrary, it would make the DNS more useful, pretty much by definition. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 16:07:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06735 for ; Wed, 7 Aug 2002 16:07:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cWzQ-000Mzq-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 13:01:04 -0700 Received: from nic.crt.se ([193.12.107.10]) by psg.com with esmtp (Exim 3.36 #1) id 17cWzL-000Mzf-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 13:00:59 -0700 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 5438252A6; Wed, 7 Aug 2002 22:00:53 +0200 (MEST) Received: from crt.se (stargate.crt.se [172.16.0.11]) by mail.crt.se (Postfix) with ESMTP id 1EE6E1DE9; Wed, 7 Aug 2002 22:00:48 +0200 (MEST) Date: Wed, 7 Aug 2002 22:00:47 +0200 (CEST) From: Jakob Schlyter To: "Eric A. Hall" Cc: Scott Rose , Subject: Re: [Design] Re: the KEY debate In-Reply-To: <3D516FE1.9030405@ehsco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 7 Aug 2002, Eric A. Hall wrote: > Ugh. The more crap we put into DNS the less useful it will be for > lightweight lookups. We'll need another DNS if we pimp this one. why would more data (aka crap) in the dns render it less useful for lightweight lookups? > Might I suggest that it would be more fruitful to work on ways to > support applications in one or more external services, and solving the > problems with those services such that they would be usable. I am > working on the LDAP-WHOIS stuff just for this purpose (give every > delegated domain and netblock LDAP referral hooks at the time of > delegation). There are lots of other options out there that also deserve > attention. and when you've added redundancy, security and a couple of other nice properties you've suddenly almost built that other DNS and called it LDAP instead. jakob -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 16:10:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06850 for ; Wed, 7 Aug 2002 16:10:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cX3u-000N77-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 13:05:42 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cX3p-000N6t-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 13:05:37 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157038; Wed, 07 Aug 2002 15:02:55 -0500 Message-ID: <3D517D8D.3060200@ehsco.com> Date: Wed, 07 Aug 2002 15:05:33 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: David Conrad CC: Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 2:56 PM David Conrad wrote: > On 8/7/02 12:07 PM, "Eric A. Hall" wrote: >> Ugh. The more crap we put into DNS the less useful it will be for >> lightweight lookups. We'll need another DNS if we pimp this one. > > Can we _PLEASE_ stop with this FUD? > > Explain exactly why adding a new RR type, one that does not change the > underlying DNS algorithms, will have any significant impact on the DNS, > much less make it "less useful". On the contrary, it would make the > DNS more useful, pretty much by definition. Well-know fact that excess RRs bound to an owner will cause overflow of UDP queries for qtype ALL. Adding "just one more" RR to a set means that all first-pass queries for an overloaded owner name fail. Less useful. Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT useful. Cache overflow is already common in large ISPs. Less useful. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 16:13:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06987 for ; Wed, 7 Aug 2002 16:13:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cX5I-000N99-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 13:07:08 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cX5E-000N8x-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 13:07:04 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157041; Wed, 07 Aug 2002 15:04:22 -0500 Message-ID: <3D517DE3.6070507@ehsco.com> Date: Wed, 07 Aug 2002 15:06:59 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Jakob Schlyter CC: Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 3:00 PM Jakob Schlyter wrote: > and when you've added redundancy, security and a couple of other nice > properties you've suddenly almost built that other DNS and called it LDAP > instead. redundancy is in there. security is a vague property, but TLS is in there. what LDAP lacks is what makes DNS useful, which is lightweight datagrams and caching, to name two. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 16:38:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07835 for ; Wed, 7 Aug 2002 16:38:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cXSw-000NnB-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 13:31:34 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17cXSp-000NmG-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 13:31:27 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08317; Wed, 7 Aug 2002 16:31:19 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA22788; Wed, 7 Aug 2002 16:31:18 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA10920; Wed, 7 Aug 2002 16:31:15 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA12555; Wed, 7 Aug 2002 16:31:15 -0400 (EDT) To: "Eric A. Hall" Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 16:31:15 -0400 In-Reply-To: <3D516FE1.9030405@ehsco.com> Message-ID: Lines: 32 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > on 8/7/2002 8:20 AM Scott Rose wrote: > > > I've been thinking the same thing - a BOF about using DNS to support > > other applications and set up a general framework/process for getting > > any type of network information in the DNS. > > Ugh. The more crap we put into DNS the less useful it will be for > lightweight lookups. We'll need another DNS if we pimp this one. HUH? I don't see where this leap in logic comes from. Just because I can make a query for: myserver.host.example. IN SSHKEY does not imply that lookups for myserver.host.example. IN A are any "heavier". So, either you have a specific example in mind which you did not state, or you are just spreading FUD on the topic. I don't know which, but I'd appreciate it if you actually stated facts instead of unsubstantiated non-problems. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 16:55:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08366 for ; Wed, 7 Aug 2002 16:55:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cXg1-000OEK-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 13:45:05 -0700 Received: from bdsl.66.12.174.102.gte.net ([66.12.174.102] helo=mail.digitalmarketplace.com) by psg.com with esmtp (Exim 3.36 #1) id 17cXfr-000ODd-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 13:44:55 -0700 Received: from win2kdev ([208.3.65.160]) by mail.digitalmarketplace.com with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 7 Aug 2002 14:26:17 -0700 Reply-To: From: "Jason Coombs" To: "David Conrad" , "Eric A. Hall" , "Scott Rose" Cc: "namedroppers" Subject: RE: [Design] Re: the KEY debate Date: Wed, 7 Aug 2002 10:55:02 -1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Can we _PLEASE_ stop with this FUD? There IS a valid infosec perspective within this FUD. Adapting DNS to distribute keys for applications other than DNS creates a single point of security failure that impacts many applications instead of just one, and that's bad. When security evaporates suddenly due to bugs in DNSSEC deployments (bad software) or in the unlikely event of a flaw in the protocol extensions to DNS to enable DNSSEC, the damage is great instead of relatively small. Consider the following real-world example of security evaporating suddenly (RIGHT NOW!) with respect to SSL due to a bug in the way that Internet Explorer processes (and trusts) certificate chains. And think about the damage that would be done if something similar happens to DNSSEC with APPKEYs (very, very bad, many applications left unsecured suddenly and automatically) compared to the damage that would be done without APPKEYs (revert to classic DNS security, effectively, but applications still have their own independent mechanisms for establishing trustworthiness of the work they do while bad DNSSEC software is patched and no DNSSEC lookups can be trusted -- just as no SSL connections made using Internet Explorer RIGHT NOW should be trusted: see below). ======================================================================== Internet Explorer SSL Vulnerability 08/05/02 Mike Benham http://www.thoughtcrime.org ======================================================================== Abstract Internet Explorer's implementation of SSL contains a vulnerability that allows for an active, undetected, man in the middle attack. No dialogs are shown, no warnings are given. ======================================================================== Description In the normal case, the administrator of a web site might wish to provide secure communication via SSL. To do so, the administrator generates a certificate and has it signed by a Certificate Authority. The generated certificate should list the URL of the secure web site in the Common Name field of the Distinguished Name section. The CA verifies that the administrator legitimately owns the URL in the CN field, signs the certificate, and gives it back. Assuming the administrator is trying to secure www.thoughtcrime.org, we now have the following certificate structure: [CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] When a web browser receives this, it should verify that the CN field matches the domain it just connected to, and that it's signed using a known CA certificate. No man in the middle attack is possible because it should not be possible to substitute a certificate with a valid CN and a valid signature. However, there is a slightly more complicated scenario. Sometimes it is convenient to delegate signing authority to more localized authorities. In this case, the administrator of www.thoughtcrime.org would get a chain of certificates from the localized authority: [Issuer: VeriSign / Subject: VeriSign] -> [Issuer: VeriSign / Subject: Intermediate CA] -> [Issuer: Intermediate CA / Subject: www.thoughtcrime.org] When a web browser receives this, it should verify that the CN field of the leaf certificate matches the domain it just connected to, that it's signed by the intermediate CA, and that the intermediate CA is signed by a known CA certificate. Finally, the web browser should also check that all intermediate certificates have valid CA Basic Constraints. You guessed it, Internet Explorer does not check the Basic Constraints. ========================================================================== Exploit So what does this mean? This means that as far as IE is concerned, anyone with a valid CA-signed certificate for ANY domain can generate a valid CA-signed certificate for ANY OTHER domain. As the unscrupulous administrator of www.thoughtcrime.org, I can generate a valid certificate and request a signature from VeriSign: [CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] Then I generate a certificate for any domain I want, and sign it using my run-of-the-mill joe-blow CA-signed certificate: [CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject: www.thoughtcrime.org] -> [CERT - Issuer: www.thoughtcrime.org / Subject: www.amazon.com] Since IE doesn't check the Basic Constraints on the www.thoughtcrime.org certificate, it accepts this certificate chain as valid for www.amazon.com. Anyone with any CA-signed certificate (and the corresponding private key) can spoof anyone else. ======================================================================== Severity I would consider this to be incredibly severe. Any of the standard connection hijacking techniques can be combined with this vulnerability to produce a successful man in the middle attack. Since all you need is one constant CA-signed certificate (and the corresponding private key), an attacker can use that to generate spoofed certificates for other domains as connections are intercepted (on the fly). Since no warnings are given and no dialogs are shown, the attacker has effectively circumvented all security that an SSL certificate provides. There is some level of accountability, though, since a user who randomly chooses to view the certificate of the web site she's visiting will see the attacker's certificate in the chain. However, by that point the damage has already been done. All "secure" data has already been transmitted. ========================================================================= Affected Browsers Netscape 4.x and Mozilla are NOT vulnerable. IE 5 and 5.5 are vulnerable straight-up, and IE 6 is mostly vulnerable. When VeriSign issues certificates, usually they leave out the CA Basic Constraint information all together. Thawte tends to explicitly put in a Basic Constraint CA = FALSE with the critical bit set to TRUE. When the CA Basic Constraint on the middle certificate is explicitly set to false and marked as critical, IE 6 does not follow the chain. When it's not mentioned at all, IE 6 follows the chain and is vulnerable. This just means that an attacker needs to use a VeriSign-issued certificate to exploit IE 6. ========================================================================= Working Exploit I've set up a URL to demonstrate this problem. If you want to test browsers not listed above or need proof of this vulnerability, contact me and I'll give you the information. ========================================================================= Vendor Notification Status Last week I saw Microsoft downplay and obfuscate the severity of the IE vulnerability that Adam Megacz reported. After seeing that, I don't feel like wasting time with the Microsoft PR department. - Mike -- http://www.thoughtcrime.org -----Original Message----- From: owner-namedroppers@ops.ietf.org [mailto:owner-namedroppers@ops.ietf.org]On Behalf Of David Conrad Sent: Wednesday, August 07, 2002 9:57 AM To: Eric A. Hall; Scott Rose Cc: namedroppers Subject: Re: [Design] Re: the KEY debate On 8/7/02 12:07 PM, "Eric A. Hall" wrote: >> I've been thinking the same thing - a BOF about using DNS to support >> other applications and set up a general framework/process for getting >> any type of network information in the DNS. > > Ugh. The more crap we put into DNS the less useful it will be for > lightweight lookups. We'll need another DNS if we pimp this one. Can we _PLEASE_ stop with this FUD? Explain exactly why adding a new RR type, one that does not change the underlying DNS algorithms, will have any significant impact on the DNS, much less make it "less useful". On the contrary, it would make the DNS more useful, pretty much by definition. Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 16:57:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08551 for ; Wed, 7 Aug 2002 16:57:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cXiQ-000OK1-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 13:47:34 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17cXiF-000OIg-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 13:47:23 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA07415; Wed, 7 Aug 2002 16:47:20 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA15582; Wed, 7 Aug 2002 16:47:14 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17069; Wed, 7 Aug 2002 16:47:13 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA12592; Wed, 7 Aug 2002 16:47:13 -0400 (EDT) To: "Eric A. Hall" Cc: David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate References: <3D517D8D.3060200@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 16:47:13 -0400 In-Reply-To: <3D517D8D.3060200@ehsco.com> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > Well-know fact that excess RRs bound to an owner will cause overflow of > UDP queries for qtype ALL. Adding "just one more" RR to a set means that Luckily "qtype all" is generally only performed in debugging situations and not by the majority of applications out there. Can you give examples of applications that actually make queries for qtype all? > all first-pass queries for an overloaded owner name fail. Less useful. HUH? What do you mean "all first-pass queries?" My SSH application makes a query for "host.example. IN A". What are YOU talking about? > Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT useful. I'd be very surprised if you exceed a 64KB response! You'd need to add a LOT of 4k RRs to reach this size. Also, that still presupposes 'qtype any' which is NOT what most application should be using anyways. > Cache overflow is already common in large ISPs. Less useful. "cache overflow"? What _ARE_ you talking about? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:10:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09265 for ; Wed, 7 Aug 2002 17:10:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cXr2-000OZn-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 13:56:28 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17cXqx-000OZQ-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 13:56:23 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA10937; Wed, 7 Aug 2002 16:56:20 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA26997; Wed, 7 Aug 2002 16:52:56 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA29964; Wed, 7 Aug 2002 16:52:49 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA12607; Wed, 7 Aug 2002 16:52:49 -0400 (EDT) To: Cc: "David Conrad" , "Eric A. Hall" , "Scott Rose" , "namedroppers" Subject: Re: [Design] Re: the KEY debate References: From: Derek Atkins Date: 07 Aug 2002 16:52:49 -0400 In-Reply-To: Message-ID: Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Jason Coombs" writes: > > Can we _PLEASE_ stop with this FUD? > > There IS a valid infosec perspective within this FUD. > > Adapting DNS to distribute keys for applications other than DNS creates a > single point of security failure that impacts many applications instead of > just one, and that's bad. This is why I stated that it is a niche, only for applications that understand the implications. It is _NOT_ a general solution -- it is a general framework for a couple of specific solutions (e.g. SSH and IPsec). I think the players well understand the implications involved. Note that using X.509 certificates is not necessarily any better (c.f. Verisign's "fake" Microsoft certificate). There are not additional issues using DNSSEC for security, they are just wearing different colors than the same issues in other venues. You can only push those issues off so far until _somebody_ needs to address them (or not, as the case may be). -derek PS: I think the proponents of "application keys in dns" are trying to get "good enough" security as opposed to "world-class, military grade security". -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:16:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09446 for ; Wed, 7 Aug 2002 17:16:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cXz3-000Ond-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:04:45 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17cXyv-000OnH-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:04:37 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g77L48Y17020 for ; Wed, 7 Aug 2002 21:04:08 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g77L4ZX7019356 for ; Wed, 7 Aug 2002 16:04:35 -0500 (CDT) Date: Wed, 7 Aug 2002 16:01:38 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit To: "Eric A. Hall" Mime-Version: 1.0 (Apple Message framework v482) Subject: Re: [Design] Re: the KEY debate From: Ted Lemon Message-Id: <46E7BAC1-AA49-11D6-BBD8-00039367340A@nominum.com> X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Well-know fact that excess RRs bound to an owner will cause overflow of > UDP queries for qtype ALL. Adding "just one more" RR to a set means that > all first-pass queries for an overloaded owner name fail. So what? Which applications, other than dig, look up qtype ALL? Are these applications doing the right thing? I.e., is it the idea of putting more records in the DNS that is broken, or is it the applications that use qtype ALL when they probably don't need all the data? > Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT useful. This is a good argument for srv-style records, but it's not a good argument for not putting keys in the namespace. I don't think there should *be* a dozen keys hanging off a single name - as you say, ETOOMUCHINFO. > Cache overflow is already common in large ISPs. Can you add a little more to this statement? By itself, it could mean "most ISPs don't make their caches big enough," or "lots of trash falls out of the cache, improving performance," or "we have a real problem." You seem to be saying that it's the third option, but you haven't said anything to support that interpretation. Furthermore, the biggest DNS problem I'm aware of right now is misdirected queries. If these are what is thrashing the typical ISP's cache, that's completely orthogonal to the question of what or how much data should go in the DNS. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:20:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09587 for ; Wed, 7 Aug 2002 17:20:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cY6V-000P22-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:12:27 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cY6Q-000P1m-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:12:22 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g77HBZ23047162; Wed, 7 Aug 2002 17:11:35 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA15090; Wed, 7 Aug 2002 17:12:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <3D517D8D.3060200@ehsco.com> Date: Wed, 7 Aug 2002 17:12:08 -0400 To: Derek Atkins , "Eric A. Hall" From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Cc: David Conrad , Scott Rose , namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:47 PM -0400 8/7/02, Derek Atkins wrote: >Can you give examples of applications that actually make queries >for qtype all? dig -x does (or used to). Perhaps also a debugging tool, but this is trivia I've carried for years and have been waiting to use it someday. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:24:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09755 for ; Wed, 7 Aug 2002 17:24:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cY9Z-000P8x-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:15:37 -0700 Received: from bdsl.66.12.174.102.gte.net ([66.12.174.102] helo=mail.digitalmarketplace.com) by psg.com with esmtp (Exim 3.36 #1) id 17cY9T-000P8T-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:15:32 -0700 Received: from win2kdev ([208.3.65.160]) by mail.digitalmarketplace.com with Microsoft SMTPSVC(5.5.1877.197.19); Wed, 7 Aug 2002 14:56:54 -0700 Reply-To: From: "Jason Coombs" To: "Derek Atkins" Cc: "namedroppers" , "Scott Rose" , "Eric A. Hall" , "David Conrad" Subject: RE: [Design] Re: the KEY debate Date: Wed, 7 Aug 2002 11:25:38 -1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Derek, Neither SSH nor IPSec should ever be used to conduct secure communications with arbitrary dynamically-discovered third parties, so your examples don't make much sense to me. Better for you to KNOW the keys needed, in advance, to secure communications with trusted hosts that you have an SSH or IPSec relationship with. Why do you want to discover them dynamically? In particular, why would you EVER want to discover them dynamically *across domains* ? That's just asking for trouble and it's a feature without a purpose. It might also be deficient in the area of common sense. Sincerely, Jason Coombs jasonc@science.org -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Wednesday, August 07, 2002 10:53 AM To: jason@science.org Cc: David Conrad; Eric A. Hall; Scott Rose; namedroppers Subject: Re: [Design] Re: the KEY debate "Jason Coombs" writes: > > Can we _PLEASE_ stop with this FUD? > > There IS a valid infosec perspective within this FUD. > > Adapting DNS to distribute keys for applications other than DNS creates a > single point of security failure that impacts many applications instead of > just one, and that's bad. This is why I stated that it is a niche, only for applications that understand the implications. It is _NOT_ a general solution -- it is a general framework for a couple of specific solutions (e.g. SSH and IPsec). I think the players well understand the implications involved. Note that using X.509 certificates is not necessarily any better (c.f. Verisign's "fake" Microsoft certificate). There are not additional issues using DNSSEC for security, they are just wearing different colors than the same issues in other venues. You can only push those issues off so far until _somebody_ needs to address them (or not, as the case may be). -derek PS: I think the proponents of "application keys in dns" are trying to get "good enough" security as opposed to "world-class, military grade security". -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:34:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10257 for ; Wed, 7 Aug 2002 17:34:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYKi-000PV7-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:27:08 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17cYKc-000PUp-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:27:02 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA22070; Wed, 7 Aug 2002 17:26:59 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA19646; Wed, 7 Aug 2002 17:26:54 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA00836; Wed, 7 Aug 2002 17:26:50 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA12676; Wed, 7 Aug 2002 17:26:49 -0400 (EDT) To: Cc: "namedroppers" , "Scott Rose" , "Eric A. Hall" , "David Conrad" Subject: Re: [Design] Re: the KEY debate References: From: Derek Atkins Date: 07 Aug 2002 17:26:49 -0400 In-Reply-To: Message-ID: Lines: 66 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,ONE_HUNDRED_PC_GUAR,DOUBLE_CAPSWORD, RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Jason Coombs" writes: > Derek, > > Neither SSH nor IPSec should ever be used to conduct secure communications > with arbitrary dynamically-discovered third parties, so your examples don't > make much sense to me. I don't know your background, but it sounds like you're viewing SSH as a telnet replacement, and IPsec as a VPN solution. Unfortunately you'd be wrong on both accounts. I want 100% of my communications encrypted. If I go and ping a host, I want that encrypted. If I finger, I want that encrypted. If I ftp, http, smtp, ntp, or anything else, I want that encrypted. IPsec is the tool I'd like to use (because SSH is subject to the TCP-RST attack). I'd like IPsec to happen and start encrypting traffic with EVERY HOST I contact, regardless of why I contact them, or how. Note that encryption != authentication/authorization. If you want to use SSH or IPsec for authentication/authorization, then you DEFINITELY want to be able to verify the key. However: 1) I am not proposing that, and 2) In many cases, a DNSSec-provided key can be "good enough" for limited authentication/authorization. > Better for you to KNOW the keys needed, in advance, to secure communications > with trusted hosts that you have an SSH or IPSec relationship with. Why do > you want to discover them dynamically? In particular, why would you EVER > want to discover them dynamically *across domains* ? That's just asking for > trouble and it's a feature without a purpose. It might also be deficient in > the area of common sense. So I need to contact this random site out there -- I heard about it through a friend of a friend. I want my traffic encrypted. How do I get their key? I now need to dynamically discover this key across domains. Why? Because I want ubiquitous, end-to-end encryption of all traffic. I could just use ephemeral diffie-helman, but that's vulnerable to a man-in-the-middle. if I had some other key that I could grab, even if it wasn't 100% guaranteed, I've now increased my protection against the MitM. Note that I want "good enough" security, not "protect me from the NSA" security. In this case, IPsec opportunistic encrypting using keys in DNS would solve my problem. This would give me my encryption, which is all I want. If you still do not understand this problem space I'd be more than happy to talk to you offline -- we don't need to waste the list's bandwidth on your education. > Sincerely, > > Jason Coombs > jasonc@science.org -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:43:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10588 for ; Wed, 7 Aug 2002 17:43:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYP7-000Pci-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:31:41 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cYP2-000PcC-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:31:36 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157080; Wed, 07 Aug 2002 16:28:54 -0500 Message-ID: <3D5191B3.8000800@ehsco.com> Date: Wed, 07 Aug 2002 16:31:31 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Derek Atkins CC: Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 3:31 PM Derek Atkins wrote: > HUH? I don't see where this leap in logic comes from. Just because I > can make a query for: > > myserver.host.example. IN SSHKEY > > does not imply that lookups for > > myserver.host.example. IN A > > are any "heavier". Of course they aren't. It is the queries for myserver.host.example. with qtype=ALL that are heavier. And to answer your next question, sendmail and qmail both use qtype=all out of the box. And to give you an example: Z:\>dig @ns1.hotmail.com. hotmail.com. any ; <<>> DiG 8.3 <<>> @ns1.hotmail.com. hotmail.com. any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 24, AUTHORITY: 4, ADDITIONAL: 18 ;; QUERY SECTION: ;; hotmail.com, type = ANY, class = IN ;; ANSWER SECTION: hotmail.com. 1H IN A 64.4.52.7 hotmail.com. 1H IN A 64.4.53.7 hotmail.com. 1H IN A 64.4.43.7 hotmail.com. 1H IN A 64.4.44.7 hotmail.com. 1H IN A 64.4.45.7 hotmail.com. 1H IN MX 5 mx01.hotmail.com. hotmail.com. 1H IN MX 5 mx02.hotmail.com. hotmail.com. 1H IN MX 5 mx04.hotmail.com. hotmail.com. 1H IN MX 5 mx05.hotmail.com. hotmail.com. 1H IN MX 5 mx06.hotmail.com. hotmail.com. 1H IN MX 5 mx07.hotmail.com. hotmail.com. 1H IN MX 5 mx08.hotmail.com. hotmail.com. 1H IN MX 5 mx09.hotmail.com. hotmail.com. 1H IN MX 5 mx10.hotmail.com. hotmail.com. 1H IN MX 5 mx11.hotmail.com. hotmail.com. 1H IN MX 5 mx12.hotmail.com. hotmail.com. 1H IN MX 5 mx13.hotmail.com. hotmail.com. 1H IN MX 5 mx14.hotmail.com. hotmail.com. 1H IN MX 5 mx15.hotmail.com. hotmail.com. 1H IN NS ns1.hotmail.com. hotmail.com. 1H IN NS ns2.hotmail.com. hotmail.com. 1H IN NS ns3.hotmail.com. hotmail.com. 1H IN NS ns4.hotmail.com. hotmail.com. 1H IN SOA ns1.jsnet.com. dns.hotmail.com. ( 2002080603 ; serial 8H ; refresh 1H ; retry 1W ; expiry 1H ) ; minimum ;; AUTHORITY SECTION: hotmail.com. 1H IN NS ns1.hotmail.com. hotmail.com. 1H IN NS ns2.hotmail.com. hotmail.com. 1H IN NS ns3.hotmail.com. hotmail.com. 1H IN NS ns4.hotmail.com. ;; ADDITIONAL SECTION: mx01.hotmail.com. 1H IN A 65.54.254.145 mx02.hotmail.com. 1H IN A 65.54.254.145 mx04.hotmail.com. 1H IN A 65.54.254.145 mx05.hotmail.com. 1H IN A 65.54.254.129 mx06.hotmail.com. 1H IN A 65.54.254.129 mx07.hotmail.com. 1H IN A 65.54.254.129 mx08.hotmail.com. 1H IN A 64.4.49.7 mx09.hotmail.com. 1H IN A 64.4.49.71 mx10.hotmail.com. 1H IN A 64.4.49.135 mx11.hotmail.com. 1H IN A 64.4.49.199 mx12.hotmail.com. 1H IN A 64.4.50.7 mx13.hotmail.com. 1H IN A 64.4.50.71 mx14.hotmail.com. 1H IN A 65.54.232.7 mx15.hotmail.com. 1H IN A 65.54.232.71 ns1.hotmail.com. 1H IN A 216.200.206.140 ns2.hotmail.com. 1H IN A 216.200.206.139 ns3.hotmail.com. 1H IN A 209.185.130.68 ns4.hotmail.com. 1H IN A 64.4.29.24 ;; Total query time: 1000 msec ;; FROM: ferret to SERVER: ns1.hotmail.com. 216.200.206.140 ;; WHEN: Wed Aug 07 16:24:19 2002 ;; MSG SIZE sent: 29 rcvd: 869 ^^^ Just using A, MX, NS and SOA. All sendmail/qmail queries to hotmail.com get restarted. Sure, hotmail could improve this by publishing fewer A and MX RRs and using some kind of load balancer. However, at that point they would have left DNS for some other technology. What is so hostile about my approach that warrants calling it FUD versus the other abandonments (eg, load balancing) that are more common? > So, either you have a specific example in mind which you did not state, > or you are just spreading FUD on the topic. I don't know which, but I'd > appreciate it if you actually stated facts instead of unsubstantiated > non-problems. I will gladly expound on my theories and ideas in detail if you wish. Frankly, I didn't think that it would be necessary. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:44:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10676 for ; Wed, 7 Aug 2002 17:44:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYR0-000Ph3-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:33:38 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17cYQv-000PgE-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:33:33 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g77LX4Y17102 for ; Wed, 7 Aug 2002 21:33:04 GMT Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g77LXWX7019370 for ; Wed, 7 Aug 2002 16:33:32 -0500 (CDT) Date: Wed, 7 Aug 2002 16:33:32 -0500 Subject: Re: [Design] Re: the KEY debate Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Ted Lemon To: "namedroppers" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <522506B8-AA4D-11D6-BBD8-00039367340A@nominum.com> X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Adapting DNS to distribute keys for applications other than DNS creates a > single point of security failure that impacts many applications instead of > just one, and that's bad. No, sorry, this is just more FUD. This is a problem that *any* key management daemon would have - it's got nothing to do with DNS per se. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:45:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10691 for ; Wed, 7 Aug 2002 17:45:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYRe-000Pi1-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:34:18 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cYRa-000Phj-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:34:14 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157082; Wed, 07 Aug 2002 16:31:32 -0500 Message-ID: <3D519251.7060007@ehsco.com> Date: Wed, 07 Aug 2002 16:34:09 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Derek Atkins CC: David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate References: <3D517D8D.3060200@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 3:47 PM Derek Atkins wrote: > "cache overflow"? What _ARE_ you talking about? More data than will fit in memory, resulting in data being dropped. Overloaded caches (being unable to actually make use of cached data) are less useful. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:55:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10898 for ; Wed, 7 Aug 2002 17:55:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYat-000Q02-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:43:51 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cYai-000PzC-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:43:41 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157081; Wed, 07 Aug 2002 16:40:59 -0500 Message-ID: <3D519488.9090804@ehsco.com> Date: Wed, 07 Aug 2002 16:43:36 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Rob Austein CC: Ted Lemon , namedroppers Subject: Re: [Design] Re: the KEY debate References: <46E7BAC1-AA49-11D6-BBD8-00039367340A@nominum.com> <20020807212731.5A15219AD@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [namedroppers re-added] on 8/7/2002 4:27 PM Rob Austein wrote: > [namedroppers was not explictly cced on Ted's message, I'll assume > that was intentional.] > > At Wed, 7 Aug 2002 16:01:38 -0500, Ted Lemon wrote: > >>Which applications, other than dig, look up qtype ALL? Are these >>applications doing the right thing? I.e., is it the idea of putting >>more records in the DNS that is broken, or is it the applications >>that use qtype ALL when they probably don't need all the data? sendmail does it so they can find any MX, A and/or CNAME RRs that exist, using a single query (using multiple queries would be a different kind of hostile). qmail does it to be compatible (djb posted a long message on this, check the archives). -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:56:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10943 for ; Wed, 7 Aug 2002 17:56:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYcQ-00004s-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:45:26 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cYcK-00004O-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:45:21 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157083; Wed, 07 Aug 2002 16:42:38 -0500 Message-ID: <3D5194EB.3000204@ehsco.com> Date: Wed, 07 Aug 2002 16:45:15 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Ted Lemon , namedroppers Subject: Re: [Design] Re: the KEY debate References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 4:01 PM Ted Lemon wrote: >> Cache overflow is already common in large ISPs. > > Can you add a little more to this statement? By itself, it could mean > "most ISPs don't make their caches big enough," or "lots of trash > falls out of the cache, improving performance," or "we have a real > problem." You seem to be saying that it's the third option, but you > haven't said anything to support that interpretation. What I'm saying is (d) the more crap we stick into DNS, the more caches will overflow, making the service less useful -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:58:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10988 for ; Wed, 7 Aug 2002 17:58:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYd3-00006X-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:46:05 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17cYcz-00006D-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:46:01 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id B11E8137F06; Wed, 7 Aug 2002 14:46:00 -0700 (PDT) To: "Eric A. Hall" Cc: David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate In-Reply-To: Message from "Eric A. Hall" of "Wed, 07 Aug 2002 15:05:33 CDT." <3D517D8D.3060200@ehsco.com> Date: Wed, 07 Aug 2002 14:46:00 -0700 Message-ID: <88350.1028756760@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Eric" == Eric A Hall writes: Eric> Well-know fact that excess RRs bound to an owner will cause Eric> overflow of UDP queries for qtype ALL. This is a DNS administration issue rather than one about protocol design. Adding more record types to an owner name just gives a longer piece of rope to the less clueful. And they can already hang themselves without introducing new record types. So why hold back DNS progress -- if that's what putting keys into the DNS is -- because it might make naive users do stupid or bad things? It's not as if stupid and bad DNS configurations are an unheard of phenomona today. Eric> Adding "just one more" RR to a set means that all first-pass Eric> queries for an overloaded owner name fail. Less useful. Maybe. But probably not an issue if EDNS0 was widely deployed. And anyway RFC3225 can be summarised as "use EDNS0 if you want to get crypto gunk from a name server". Another one -- RFC3226 -- says "use EDNS0 with certain UDP buffer sizes if you expect to get A6 and binary labels (may they rest in peace) in the answer". Spot a trend here? And let's not forget that caching will alleviate the impact of any truncation. Sure, my server might get truncation when fetching signed MX records for aol.com (say). But for one lookup per TTL interval to aol.com's name servers. My mail systems will get truncation when they repeat that query to my local cache, but that's no big deal: they won't be beating up the aol.com name servers with those queries. Eric> Adding a bunch of 4k RRs to an owner can exceed TCP capacity. Sorry, I just don't understand this. When did TCP (or name servers) have a problem transferring more than a few Kb? Eric> Cache overflow is already common in large ISPs. Less useful. I'm not sure I know what you mean by "cache overflow". Presumably it is some condition that means truncated responses. If so, how much of that would go away if EDNS0 was more widespread? If this is as much of a problem today as you suggest, have you any numbers to support this claim? Does anyone have name servers that are *really* suffering because of truncated responses and TCP retries? And what percentage of them have a genuine need to truncate responses as opposed to truncating because of hostmaster silliness? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:59:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11063 for ; Wed, 7 Aug 2002 17:59:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYac-000PyT-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:43:34 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #1) id 17cYaX-000Py5-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:43:29 -0700 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g77LhR6I002475; Wed, 7 Aug 2002 14:43:27 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g77LhPTR023427; Wed, 7 Aug 2002 14:43:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20020807173301.01896eb8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 Aug 2002 17:43:23 -0400 To: Derek Atkins From: John Schnizlein Subject: Re: [Design] Re: the KEY debate Cc: namedroppers In-Reply-To: References: <3D517D8D.3060200@ehsco.com> <3D517D8D.3060200@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 04:47 PM 8/7/2002, Derek Atkins wrote: >"Eric A. Hall" writes: > >> Well-know fact that excess RRs bound to an owner will cause overflow of >> UDP queries for qtype ALL. Adding "just one more" RR to a set means that > >Luckily "qtype all" is generally only performed in debugging >situations and not by the majority of applications out there. >Can you give examples of applications that actually make queries >for qtype all? Would "qtype all" be the appropriate way for a DNS client to get the RR-set so that it can check the validity of a signature? Would "qtype all" be much more common when applications demand assurance that the DNS reply is authentic? Not taking sides, but the context of checking signatures should be relevant. John -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 17:59:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11082 for ; Wed, 7 Aug 2002 17:59:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYi2-0000IE-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:51:14 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17cYhw-0000I1-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:51:09 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA00620; Wed, 7 Aug 2002 17:51:07 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA21974; Wed, 7 Aug 2002 17:51:07 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02431; Wed, 7 Aug 2002 17:51:07 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA12736; Wed, 7 Aug 2002 17:51:07 -0400 (EDT) To: John Schnizlein Cc: namedroppers Subject: Re: [Design] Re: the KEY debate References: <3D517D8D.3060200@ehsco.com> <3D517D8D.3060200@ehsco.com> <4.3.2.7.2.20020807173301.01896eb8@wells.cisco.com> From: Derek Atkins Date: 07 Aug 2002 17:51:07 -0400 In-Reply-To: <4.3.2.7.2.20020807173301.01896eb8@wells.cisco.com> Message-ID: Lines: 25 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk John Schnizlein writes: > Would "qtype all" be the appropriate way for a DNS client to get > the RR-set so that it can check the validity of a signature? > Would "qtype all" be much more common when applications demand > assurance that the DNS reply is authentic? No. A DNSSec-aware server is supposed to respond with the appropriate SIG and NXT records on every query, so the client should not have to query for qtype any. > Not taking sides, but the context of checking signatures should > be relevant. It is not. > John -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:00:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11128 for ; Wed, 7 Aug 2002 18:00:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYaL-000Py0-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:43:17 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17cYaG-000Pxk-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:43:12 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA05176; Wed, 7 Aug 2002 17:43:10 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA01867; Wed, 7 Aug 2002 17:43:06 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02135; Wed, 7 Aug 2002 17:43:01 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA12720; Wed, 7 Aug 2002 17:43:01 -0400 (EDT) To: "Eric A. Hall" Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> <3D5191B3.8000800@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 17:43:01 -0400 In-Reply-To: <3D5191B3.8000800@ehsco.com> Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > And to answer your next question, sendmail and qmail both use qtype=all > out of the box. This sounds like a bug in those applications, not a bug in DNS. I presume they are doing this to try to save a round trip? > And to give you an example: [snip] > ;; Total query time: 1000 msec > ;; FROM: ferret to SERVER: ns1.hotmail.com. 216.200.206.140 > ;; WHEN: Wed Aug 07 16:24:19 2002 > ;; MSG SIZE sent: 29 rcvd: 869 > ^^^ Yes, this is bigger than the 512 limit, but would still fit in a UDP response. EDNS0 solves this problem. Turn on EDNS0 and you wont restart your query. > What is so hostile about my approach that warrants calling it FUD versus > the other abandonments (eg, load balancing) that are more common? It's not the abandonment proposal that is FUD, it's your statement that "adding new record types breaks DNS". -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:04:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11210 for ; Wed, 7 Aug 2002 18:04:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYoK-0000SC-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 14:57:44 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cYoF-0000Rk-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 14:57:39 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157087; Wed, 07 Aug 2002 16:54:57 -0500 Message-ID: <3D5197CE.7090505@ehsco.com> Date: Wed, 07 Aug 2002 16:57:34 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Jim Reid CC: David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate References: <88350.1028756760@shell.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 4:46 PM Jim Reid wrote: > So why hold back DNS progress -- if that's what putting keys into the > DNS is -- because it might make naive users do stupid or bad things? Just for the record, I didn't mention keys, and I stayed out of that part of the debate. I am opposed to them in principle but I also realize that the other camps aren't giving up on it, and there isn't a viable alternative. My message was meant to suggest that we should be working on those alternatives so that there is somewhere else to put this stuff. > Eric> Adding a bunch of 4k RRs to an owner can exceed TCP capacity. > > Sorry, I just don't understand this. When did TCP (or name servers) > have a problem transferring more than a few Kb? The TCP size field is a 16-bit value, meaning that a message has a maximum capacity of 64k. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:08:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11346 for ; Wed, 7 Aug 2002 18:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYti-0000fx-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:03:18 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17cYtd-0000fj-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:03:13 -0700 Received: from [128.177.194.167] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5823D137F06; Wed, 7 Aug 2002 15:03:13 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 07 Aug 2002 15:03:23 -0700 Subject: Re: [Design] Re: the KEY debate From: David Conrad To: "Eric A. Hall" , Ted Lemon , namedroppers Message-ID: In-Reply-To: <3D5194EB.3000204@ehsco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8/7/02 2:45 PM, "Eric A. Hall" wrote: > What I'm saying is (d) the more crap we stick into DNS, the more caches > will overflow, making the service less useful Sorry, I don't get this. If the cache is filling up, it is because it is being used for something. This would seem to me to imply that it is being more useful. What am I missing? Rgds, -drc -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:12:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11471 for ; Wed, 7 Aug 2002 18:12:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cYyR-0000wp-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:08:11 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cYyM-0000wZ-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:08:06 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157091; Wed, 07 Aug 2002 17:05:24 -0500 Message-ID: <3D519A42.7080702@ehsco.com> Date: Wed, 07 Aug 2002 17:08:02 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: David Conrad CC: Ted Lemon , namedroppers Subject: Re: [Design] Re: the KEY debate References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 5:03 PM David Conrad wrote: > On 8/7/02 2:45 PM, "Eric A. Hall" wrote: > >>What I'm saying is (d) the more crap we stick into DNS, the more caches >>will overflow, making the service less useful > If the cache is filling up, it is because it is being used for something. > This would seem to me to imply that it is being more useful. > > What am I missing? Assuming a FIFO queue drain, stuff that *was* cached (and which should have stayed in the cache) will be bounced. When that data is needed again, another round of queries will have to be issued. At that point, the benefits of caching have been obviated. Projected outwards with a come-and-get-your-new-RR-and-names mentatility in conjunction with a very high load, it is not impossible to imagine scenarios with inifinite churn. Would DNS without caching be as useful? Obviously there are ways around this -- add more caches, add more memory to fewer caches -- but it is a real concern, not FUD. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:27:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11868 for ; Wed, 7 Aug 2002 18:27:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZ9O-0001Mp-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:19:30 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17cZ9H-0001Ma-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:19:23 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 6D0CA137F06; Wed, 7 Aug 2002 15:19:22 -0700 (PDT) To: "Eric A. Hall" Cc: David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate In-Reply-To: Message from "Eric A. Hall" of "Wed, 07 Aug 2002 16:57:34 CDT." <3D5197CE.7090505@ehsco.com> Date: Wed, 07 Aug 2002 15:19:22 -0700 Message-ID: <90161.1028758762@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Eric" == Eric A Hall writes: Eric> My message was meant to suggest that we should be working on Eric> those alternatives so that there is somewhere else to put Eric> this stuff. Well I fail to see how you can advance that position by making non-sequiturs about TCP window and cache sizes. Eric> Adding a bunch of 4k RRs to an owner can exceed TCP Eric> capacity. >> Sorry, I just don't understand this. When did TCP (or name >> servers) have a problem transferring more than a few Kb? Eric> The TCP size field is a 16-bit value, meaning that a message Eric> has a maximum capacity of 64k. And the point you are making here is.....? Apart from needing some extra TCP headers, how would shifting more than 64k of data present a problem? [BTW it's the window size that has a 16-bit value in TCP. This has nothing to do with message size: a nebulous concept in a byte stream protocol like TCP.] And anyway, doesn't the TCP window scale option allow for *much* bigger windows than 64k? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:27:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11887 for ; Wed, 7 Aug 2002 18:27:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZBH-0001QG-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:21:27 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17cZB8-0001PY-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:21:18 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA17324; Wed, 7 Aug 2002 18:21:16 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA05290; Wed, 7 Aug 2002 18:21:14 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id SAA03593; Wed, 7 Aug 2002 18:21:13 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA12803; Wed, 7 Aug 2002 18:21:13 -0400 (EDT) To: "Eric A. Hall" Cc: Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> <3D5191B3.8000800@ehsco.com> <3D519C57.305@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 18:21:13 -0400 In-Reply-To: <3D519C57.305@ehsco.com> Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > on 8/7/2002 4:43 PM Derek Atkins wrote: > > "Eric A. Hall" writes: > > > It's not the abandonment proposal that is FUD, it's your statement > > that "adding new record types breaks DNS". > > What I said is that adding more crap to DNS makes it less useful. I didn't > say it would break DNS. That would be stupid. My appologies for mis-paraphrasing you. However I think many people here would disagree that it would be less useful, and I believe that your stating so is still FUD. First, I don't think keys are crap. Second, the only real issue are applications that make T_ANY queries, and I maintain those applications are broken (or mainly for debugging purposes, like dig). So unless you are saying that DNS should not be used because sendmail is broken, I think the statement that more data is less useful is FUD. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:27:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11957 for ; Wed, 7 Aug 2002 18:27:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZBv-0001RB-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:22:07 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cZBr-0001Qv-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:22:03 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157107; Wed, 07 Aug 2002 17:19:21 -0500 Message-ID: <3D519D86.2090502@ehsco.com> Date: Wed, 07 Aug 2002 17:21:58 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Jim Reid CC: David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate References: <90161.1028758762@shell.nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 5:19 PM Jim Reid wrote: > Well I fail to see how you can advance that position by making > non-sequiturs about TCP window and cache sizes. Luckily for me, I'm not. Kindly refer to section of 4.2.2 of RFC 1035. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:29:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12068 for ; Wed, 7 Aug 2002 18:29:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZ72-0001J6-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:17:04 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cZ6y-0001It-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:17:00 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157102; Wed, 07 Aug 2002 17:14:18 -0500 Message-ID: <3D519C57.305@ehsco.com> Date: Wed, 07 Aug 2002 17:16:55 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Derek Atkins CC: Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> <3D5191B3.8000800@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 4:43 PM Derek Atkins wrote: > "Eric A. Hall" writes: > It's not the abandonment proposal that is FUD, it's your statement > that "adding new record types breaks DNS". What I said is that adding more crap to DNS makes it less useful. I didn't say it would break DNS. That would be stupid. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:30:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12119 for ; Wed, 7 Aug 2002 18:30:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZ7f-0001KE-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:17:43 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17cZ7b-0001Jt-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:17:39 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA09216; Wed, 7 Aug 2002 18:17:37 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA24311; Wed, 7 Aug 2002 18:17:37 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA14474; Wed, 7 Aug 2002 18:17:36 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA12789; Wed, 7 Aug 2002 18:17:36 -0400 (EDT) To: "Eric A. Hall" Cc: David Conrad , Ted Lemon , namedroppers Subject: Re: [Design] Re: the KEY debate References: <3D519A42.7080702@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 18:17:36 -0400 In-Reply-To: <3D519A42.7080702@ehsco.com> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > Assuming a FIFO queue drain, stuff that *was* cached (and which should Bad assumption. Assume LRU. The rest of your statement doesn't follow anymore. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:33:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12179 for ; Wed, 7 Aug 2002 18:33:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZDo-0001UB-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:24:04 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17cZDj-0001Tw-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:23:59 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA10869; Wed, 7 Aug 2002 18:23:56 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA05548; Wed, 7 Aug 2002 18:23:55 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA16027; Wed, 7 Aug 2002 18:23:55 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA12817; Wed, 7 Aug 2002 18:23:55 -0400 (EDT) To: Jim Reid Cc: "Eric A. Hall" , David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate References: <90161.1028758762@shell.nominum.com> From: Derek Atkins Date: 07 Aug 2002 18:23:55 -0400 In-Reply-To: <90161.1028758762@shell.nominum.com> Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Jim Reid writes: > And the point you are making here is.....? Apart from needing some > extra TCP headers, how would shifting more than 64k of data present a > problem? [BTW it's the window size that has a 16-bit value in TCP. > This has nothing to do with message size: a nebulous concept in a byte > stream protocol like TCP.] And anyway, doesn't the TCP window scale > option allow for *much* bigger windows than 64k? Jim, Eric is right that DNS messages are limited to 64k (even with TCP). Perhaps EDNS1 can fix this (I don't know if EDNS0 does offhand). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:34:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12205 for ; Wed, 7 Aug 2002 18:34:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZIv-0001j1-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:29:21 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17cZIq-0001ib-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:29:16 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id SAA19873; Wed, 7 Aug 2002 18:29:15 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA05919; Wed, 7 Aug 2002 18:29:14 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id SAA03863; Wed, 7 Aug 2002 18:29:13 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id SAA12828; Wed, 7 Aug 2002 18:29:14 -0400 (EDT) To: David Blacka Cc: namedroppers Subject: Re: [Design] Re: the KEY debate References: <3D517D8D.3060200@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 18:29:14 -0400 In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk David Blacka writes: > >>>>> "Derek" == Derek Atkins writes: > > Derek> "Eric A. Hall" writes: > > >> Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT > >> useful. > > Derek> I'd be very surprised if you exceed a 64KB response! You'd > Derek> need to add a LOT of 4k RRs to reach this size. Also, that > Derek> still presupposes 'qtype any' which is NOT what most > Derek> application should be using anyways. > > So... 16 is a LOT? For one application? Yes. > Exceeding the 64k limit for a single message looks like might be > another credible argument against sub-typing application keying data. > I could easily imagine having 64k of CERT or APPKEY-like records at a > given name at some point. Indeed.. You'll notice that I have abandoned the single-RR-type approach for the rrtype-per-app approach. -derek > -- > David Blacka > Sr. Engineer Verisign Applied Research -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:37:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12251 for ; Wed, 7 Aug 2002 18:37:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZJG-0001jx-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:29:42 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17cZJ7-0001jH-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:29:33 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 7B1E6137F06; Wed, 7 Aug 2002 15:29:32 -0700 (PDT) To: "Eric A. Hall" Cc: Ted Lemon , namedroppers Subject: Re: [Design] Re: the KEY debate In-Reply-To: Message from "Eric A. Hall" of "Wed, 07 Aug 2002 16:45:15 CDT." <3D5194EB.3000204@ehsco.com> Date: Wed, 07 Aug 2002 15:29:32 -0700 Message-ID: <90712.1028759372@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Eric" == Eric A Hall writes: Eric> What I'm saying is (d) the more crap we stick into DNS, the Eric> more caches will overflow, making the service less useful This doesn't make sense. Cached data clearly must be of some use because it's being cached. And if someone's cache overflows, where's the problem? There are various well known and widely implemented solutions for this. Like buying more RAM (at how many cents/Mb?) or adding more caching name servers. Or have the name server discard older data to make room for the newer stuff. Even if caches overflow and servers die horrible deaths as a result of caching too much data, this only matters if it generates excessive DNS traffic or causes unbearably long lookup latencies. And once again this would be an administration/engineering problem, not one of protocol design. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:38:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12270 for ; Wed, 7 Aug 2002 18:38:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZGn-0001dV-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:27:09 -0700 Received: from h227.s231.netsol.com ([216.168.231.227] helo=pinion.admin.cto.netsol.com) by psg.com with esmtp (Exim 3.36 #1) id 17cZGj-0001dE-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:27:05 -0700 Received: by pinion.admin.cto.netsol.com (Postfix, from userid 551) id 424431E1AF; Wed, 7 Aug 2002 18:27:04 -0400 (EDT) To: Derek Atkins Cc: namedroppers Subject: Re: [Design] Re: the KEY debate References: <3D517D8D.3060200@ehsco.com> From: David Blacka In-Reply-To: (Derek Atkins's message of "07 Aug 2002 16:47:13 -0400") Date: Wed, 07 Aug 2002 18:27:04 -0400 Message-ID: Lines: 22 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i386-mandrake-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> "Eric A. Hall" writes: >> Adding a bunch of 4k RRs to an owner can exceed TCP capacity. NOT >> useful. Derek> I'd be very surprised if you exceed a 64KB response! You'd Derek> need to add a LOT of 4k RRs to reach this size. Also, that Derek> still presupposes 'qtype any' which is NOT what most Derek> application should be using anyways. So... 16 is a LOT? Exceeding the 64k limit for a single message looks like might be another credible argument against sub-typing application keying data. I could easily imagine having 64k of CERT or APPKEY-like records at a given name at some point. -- David Blacka Sr. Engineer Verisign Applied Research -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:49:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12596 for ; Wed, 7 Aug 2002 18:49:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZYH-0002U0-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:45:13 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cZY8-0002TT-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:45:04 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157123; Wed, 07 Aug 2002 17:42:22 -0500 Message-ID: <3D51A2E9.5050401@ehsco.com> Date: Wed, 07 Aug 2002 17:44:57 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Derek Atkins CC: namedroppers Subject: Re: [Design] Re: the KEY debate References: <3D519A42.7080702@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 5:17 PM Derek Atkins wrote: > "Eric A. Hall" writes: > >>Assuming a FIFO queue drain, stuff that *was* cached (and which should > > Bad assumption. Assume LRU. The rest of your statement doesn't > follow anymore. I'd actually be interested to find out what different vendors do, if they care to share. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:51:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12672 for ; Wed, 7 Aug 2002 18:51:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZWB-0002Nc-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:43:03 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17cZW7-0002NE-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:42:59 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 9F1E8137F06; Wed, 7 Aug 2002 15:42:57 -0700 (PDT) To: Derek Atkins Cc: "Eric A. Hall" , David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate In-Reply-To: Message from Derek Atkins of "07 Aug 2002 18:23:55 EDT." Date: Wed, 07 Aug 2002 15:42:57 -0700 Message-ID: <91502.1028760177@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> Jim, Eric is right that DNS messages are limited to 64k Derek> (even with TCP). Indeed. I got the context wrong: Even so, I don't understand the point Eric was making. How does a response that's comprised of more than 1 DNS-over TCP 64k message cause a problem? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:51:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12686 for ; Wed, 7 Aug 2002 18:51:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZWJ-0002O6-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:43:11 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17cZWD-0002Nb-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:43:05 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g77Mgqi2008186; Thu, 8 Aug 2002 00:42:53 +0200 To: "Eric A. Hall" Cc: Rob Austein , Ted Lemon , namedroppers Subject: Re: [Design] Re: the KEY debate References: <46E7BAC1-AA49-11D6-BBD8-00039367340A@nominum.com> <20020807212731.5A15219AD@thrintun.hactrn.net> <3D519488.9090804@ehsco.com> X-Hashcash: 020807:ehall@ehsco.com:29286fd5cec0825c X-Hashcash: 020807:sra@hactrn.net:c8fe25b876fa29d7 X-Hashcash: 020807:Ted.Lemon@nominum.com:2eb9004fcb921635 X-Hashcash: 020807:namedroppers@ops.ietf.org:2345eed3954b9cfb From: Simon Josefsson Date: Thu, 08 Aug 2002 00:42:54 +0200 In-Reply-To: <3D519488.9090804@ehsco.com> ("Eric A. Hall"'s message of "Wed, 07 Aug 2002 16:43:36 -0500") Message-ID: Lines: 17 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: >>>Which applications, other than dig, look up qtype ALL? Are these >>>applications doing the right thing? I.e., is it the idea of putting >>>more records in the DNS that is broken, or is it the applications >>>that use qtype ALL when they probably don't need all the data? > > sendmail does it so they can find any MX, A and/or CNAME RRs that exist, > using a single query (using multiple queries would be a different kind of > hostile). Not any more. This was fixed in Sendmail 8.12.0. > qmail does it to be compatible (djb posted a long message on this, > check the archives). That discussion probably stopped people from doing such silly 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 18:59:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12802 for ; Wed, 7 Aug 2002 18:59:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZbp-0002bp-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 15:48:53 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17cZbl-0002b6-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 15:48:49 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3E1FF18EC for ; Wed, 7 Aug 2002 18:48:15 -0400 (EDT) Date: Wed, 07 Aug 2002 18:48:15 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: the KEY debate In-Reply-To: <3D5191B3.8000800@ehsco.com> References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> <3D5191B3.8000800@ehsco.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020807224815.3E1FF18EC@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 07 Aug 2002 16:31:31 -0500, Eric A. Hall wrote: > > And to answer your next question, sendmail and qmail both use qtype=all > out of the box. This was a bad idea in 1985, and has not improved with age. It can return the wrong answer under certain conditions, and the defence against that failure mode involves at least as many queries as one would have made if one just queried first for the MX then falling back to querying for the A. This is not hypothetical. We tracked a series of whacky mail failures at MIT-LCS in the early 1990s to another implementation of this same bad idea (in a then-current version of MMDF). We replaced the QTYPE=* query with the obvious MX and A queries and the problems went away. MMAILR never did this. Postfix doesn't do this. It's a misfeature. Plow it under and sow its burial site with salt. Don't defend it. We now return you to your regularly scheduled interminable debate about the true purpose of DNS. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 19:08:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12968 for ; Wed, 7 Aug 2002 19:08:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZpf-00030h-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 16:03:11 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cZpb-00030W-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 16:03:07 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157131; Wed, 07 Aug 2002 18:00:25 -0500 Message-ID: <3D51A726.5010203@ehsco.com> Date: Wed, 07 Aug 2002 18:03:02 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Derek Atkins CC: Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> <3D5191B3.8000800@ehsco.com> <3D519C57.305@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 5:21 PM Derek Atkins wrote: > First, I don't think keys are crap. Nor do I. I just wish there was somewhere else to put them. > Second, the only real issue are > applications that make T_ANY queries, and I maintain those > applications are broken (or mainly for debugging purposes, like dig). > > So unless you are saying that DNS should not be used because sendmail > is broken, I think the statement that more data is less useful is FUD. That would be pretty dumb, too. On the other hand, my bet is that more applications are likely to START doing it once we have IPv6 applications that query for qtype=any instead of doing AAAA before A. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 19:11:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13022 for ; Wed, 7 Aug 2002 19:11:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZsv-0003AY-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 16:06:33 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17cZsN-00039B-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 16:05:59 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g77N5lZ21604; Wed, 7 Aug 2002 16:05:47 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Wed, 7 Aug 2002 16:05:47 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Jim Reid cc: Derek Atkins , "Eric A. Hall" , David Conrad , Scott Rose , namedroppers Subject: Re: [Design] Re: the KEY debate In-Reply-To: <91502.1028760177@shell.nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, 7 Aug 2002, Jim Reid wrote: > >>>>> "Derek" == Derek Atkins writes: > > Derek> Jim, Eric is right that DNS messages are limited to 64k > Derek> (even with TCP). > > Indeed. I got the context wrong: Even so, I don't understand the point > Eric was making. How does a response that's comprised of more than 1 > DNS-over TCP 64k message cause a problem? Last time I checked, DNS didn't specify a mechanism for multiple messages in a response. EDNS1 doesn't count. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 19:12:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13054 for ; Wed, 7 Aug 2002 19:12:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cZs7-00037k-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 16:05:43 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cZs3-00037L-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 16:05:39 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157134; Wed, 07 Aug 2002 18:02:57 -0500 Message-ID: <3D51A7BE.2090003@ehsco.com> Date: Wed, 07 Aug 2002 18:05:34 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: "Eric A. Hall" CC: Derek Atkins , Scott Rose , namedroppers@ops.ietf.org Subject: Re: [Design] Re: the KEY debate References: <200208041653.g74Gr4aR008041@marajade.sandelman.ottawa.on.ca> <010a01c23e15$4585b0e0$b9370681@BARNACLE> <3D516FE1.9030405@ehsco.com> <3D5191B3.8000800@ehsco.com> <3D519C57.305@ehsco.com> <3D51A726.5010203@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=FROM_AND_TO_SAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 6:03 PM Eric A. Hall wrote: > on 8/7/2002 5:21 PM Derek Atkins wrote: > >>First, I don't think keys are crap. > > Nor do I. I just wish there was somewhere else to put them. [...] along with the "other information" that "some other protocol thinks that using the DNS is the best way to distribute" that Scott mentioned in his message which spawned my retort. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 19:45:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13854 for ; Wed, 7 Aug 2002 19:45:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17caKi-00043T-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 16:35:16 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17caKa-00043I-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 16:35:08 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157141 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 18:32:27 -0500 Message-ID: <3D51AEA8.9020600@ehsco.com> Date: Wed, 07 Aug 2002 18:35:04 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers Subject: !! DANGER -- POTENTIAL FUD -- DANGER !! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.6 required=5.0 tests=TO_LOCALPART_EQ_REAL,PLING,DOUBLE_CAPSWORD,SUBJ_ALL_CAPS version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 6:03 PM Eric A. Hall wrote: > On the other hand, my bet is that more applications are likely to START > doing it once we have IPv6 applications that query for qtype=any instead > of doing AAAA before A. It occurs to me that an easy prevention against this potential problem (OKAY ITS FUD, SHEESH) would be define a new query-type for addresses, similar to the old MAILA and MAILB qtypes. Rather than issue two queries for AAAA plus A, and rather than issue a qytpe=ALL, v6-aware applications could issue the qtype=ADDR (or whatever). More efficient. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 19:54:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14135 for ; Wed, 7 Aug 2002 19:54:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17caTT-0004JE-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 16:44:19 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17caTP-0004J2-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 16:44:15 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA07498; Wed, 7 Aug 2002 19:44:13 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA10277; Wed, 7 Aug 2002 19:41:01 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA01189; Wed, 7 Aug 2002 19:41:01 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id TAA12976; Wed, 7 Aug 2002 19:41:01 -0400 (EDT) To: "Eric A. Hall" Cc: namedroppers Subject: QType: ADDR (was Re: !! DANGER -- POTENTIAL FUD -- DANGER !!) References: <3D51AEA8.9020600@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 19:41:01 -0400 In-Reply-To: <3D51AEA8.9020600@ehsco.com> Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,PLING,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > It occurs to me that an easy prevention against this potential problem > (OKAY ITS FUD, SHEESH) would be define a new query-type for addresses, > similar to the old MAILA and MAILB qtypes. Rather than issue two queries > for AAAA plus A, and rather than issue a qytpe=ALL, v6-aware applications > could issue the qtype=ADDR (or whatever). More efficient. Why is this FUD? This is an interesting proposal.. I'm not sure if it is reasonably implementable, but it's still interesting. In particular, I don't know what kind of failure characteristics this would have. Is there a preference of AAAA over A? Would it imply that if no AAAA exists you would have to provide the NXT to prove it? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 20:21:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14579 for ; Wed, 7 Aug 2002 20:21:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cato-0005B5-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 17:11:32 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17catj-0005At-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 17:11:28 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g780BLgs030805; Thu, 8 Aug 2002 10:11:21 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208080011.g780BLgs030805@drugs.dv.isc.org> To: Brian Wellington Cc: namedroppers From: Mark.Andrews@isc.org Subject: Re: [Design] Re: the KEY debate In-reply-to: Your message of "Wed, 07 Aug 2002 16:05:47 MST." Date: Thu, 08 Aug 2002 10:11:21 +1000 X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD,PORN_10 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > On Wed, 7 Aug 2002, Jim Reid wrote: > > > >>>>> "Derek" == Derek Atkins writes: > > > > Derek> Jim, Eric is right that DNS messages are limited to 64k > > Derek> (even with TCP). > > > > Indeed. I got the context wrong: Even so, I don't understand the point > > Eric was making. How does a response that's comprised of more than 1 > > DNS-over TCP 64k message cause a problem? > > Last time I checked, DNS didn't specify a mechanism for multiple messages > in a response. EDNS1 doesn't count. > > Brian Actually it does. It's called AXFR. No clients currently fall back to AXFR but it could be done. The few truncated TCP responses I've followed up have all been for PTR record as a result of SPAM from porn sites. I've never seen the need to implement the fallback. As for DNS caching strategies, I'm sure they will evolve as needed. BIND 9 uses random drop at present. We could also add different max-cache-ttls depending upon rdata set size. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 20:27:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14734 for ; Wed, 7 Aug 2002 20:27:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cb27-0005Qg-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 17:20:07 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cb23-0005QL-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 17:20:03 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157146; Wed, 07 Aug 2002 19:17:21 -0500 Message-ID: <3D51B92E.10804@ehsco.com> Date: Wed, 07 Aug 2002 19:19:58 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Derek Atkins CC: namedroppers Subject: Re: QType: ADDR References: <3D51AEA8.9020600@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 6:41 PM Derek Atkins wrote: > what kind of failure characteristics this would have. Is there a > preference of AAAA over A? I would think that the application would determine its own preference for the returned data. The big concern is with caches. They would have to be limited somewhat. For example, they couldn't answer the query with cached data unless they had positively absolutely passed another qtype=addr or distinct qtype=A and qtype=AAAA queries. Otherwise, they could return any A RRs which had been cached but not AAAA RRs (or vice versa), resulting in an incomplete and erroneous view of the complete answer, thereby causing the client to make the wrong decision. > Would it imply that if no AAAA exists you > would have to provide the NXT to prove it? I disclaim any expertise on DNSSEC. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 7 20:36:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14941 for ; Wed, 7 Aug 2002 20:36:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cbA6-0005jM-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 17:28:22 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17cbA1-0005j8-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 17:28:18 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id UAA16333; Wed, 7 Aug 2002 20:28:16 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA01510; Wed, 7 Aug 2002 20:28:16 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA09427; Wed, 7 Aug 2002 20:28:16 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id UAA13068; Wed, 7 Aug 2002 20:28:16 -0400 (EDT) To: "Eric A. Hall" Cc: namedroppers Subject: Re: QType: ADDR References: <3D51AEA8.9020600@ehsco.com> <3D51B92E.10804@ehsco.com> From: Derek Atkins Date: 07 Aug 2002 20:28:16 -0400 In-Reply-To: <3D51B92E.10804@ehsco.com> Message-ID: Lines: 38 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > I would think that the application would determine its own preference for > the returned data. So the qtype=addr would have you return _ALL_ data, both AAAA and A? Couldn't that be a rather large response? If not, then how does the _server_ know which type to prefer in the response? > The big concern is with caches. They would have to be limited somewhat. > For example, they couldn't answer the query with cached data unless they > had positively absolutely passed another qtype=addr or distinct qtype=A > and qtype=AAAA queries. Otherwise, they could return any A RRs which had > been cached but not AAAA RRs (or vice versa), resulting in an incomplete > and erroneous view of the complete answer, thereby causing the client to > make the wrong decision. Caches are already going to have to do this for proper NXT processing. > > Would it imply that if no AAAA exists you > > would have to provide the NXT to prove it? > > I disclaim any expertise on DNSSEC. Well, you (in general, not Eric Hall specifically) need to think about how it would interact with DNSSEC. > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 21:03:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15491 for ; Wed, 7 Aug 2002 21:03:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cbXf-0006ds-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 17:52:43 -0700 Received: from [3ffe:501:410:0:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17cbXZ-0006ch-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 17:52:38 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E48FF4B22; Thu, 8 Aug 2002 09:52:28 +0900 (JST) To: "Eric A. Hall" Cc: namedroppers In-reply-to: ehall's message of Wed, 07 Aug 2002 18:35:04 EST. <3D51AEA8.9020600@ehsco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: !! DANGER -- POTENTIAL FUD -- DANGER !! From: itojun@iijlab.net Date: Thu, 08 Aug 2002 09:52:28 +0900 Message-Id: <20020808005228.E48FF4B22@coconut.itojun.org> X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,PLING,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >> On the other hand, my bet is that more applications are likely to START >> doing it once we have IPv6 applications that query for qtype=any instead >> of doing AAAA before A. "any" query does not return all available data. it is allowed for a recursize resolver (named) to return data on the cache already, and not with other records actually available. therefore, stub resolvers (libc resolver) that makes "any" query will not work. tojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 7 23:34:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19510 for ; Wed, 7 Aug 2002 23:34:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cdvI-000BZj-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 20:25:16 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17cdvD-000BYO-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 20:25:12 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8A7BA19AD for ; Wed, 7 Aug 2002 23:24:39 -0400 (EDT) Date: Wed, 07 Aug 2002 23:24:39 -0400 From: Rob Austein To: namedroppers Subject: Re: QType: ADDR (was Re: !! DANGER -- POTENTIAL FUD -- DANGER !!) In-Reply-To: References: <3D51AEA8.9020600@ehsco.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020808032439.8A7BA19AD@thrintun.hactrn.net> X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,PLING,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 07 Aug 2002 19:41:01 -0400, Derek Atkins wrote: > > "Eric A. Hall" writes: > > > It occurs to me that an easy prevention against this potential problem > > (OKAY ITS FUD, SHEESH) would be define a new query-type for addresses, > > similar to the old MAILA and MAILB qtypes. Rather than issue two queries > > for AAAA plus A, and rather than issue a qytpe=ALL, v6-aware applications > > could issue the qtype=ADDR (or whatever). More efficient. > > Why is this FUD? This is an interesting proposal.. I'm not sure if > it is reasonably implementable, but it's still interesting. In > particular, I don't know what kind of failure characteristics this > would have. Is there a preference of AAAA over A? Would it imply > that if no AAAA exists you would have to provide the NXT to prove > it? It's not FUD, but I don't think it works: if there's more than one distinct RRset that can satisfy a particular query, you can't predict which RRset(s) you're going to get back in the response unless you're talking to the authoritative server. Additional section processing doesn't count, since in all but a few (reasonably well-understood) cases the additional section is just an efficiency hack and one can just query explictly for whatever one might have wished to find there. This is basicly the same problem as we have with QTYPE=*, hence the occasional reference you might see in old namedroppers archives to MAILA and MAILB as "semi-wildcards". -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 02:14:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01640 for ; Thu, 8 Aug 2002 02:14:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cgMW-000H0O-00 for namedroppers-data@psg.com; Wed, 07 Aug 2002 23:01:32 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17cgMM-000H0C-00 for namedroppers@ops.ietf.org; Wed, 07 Aug 2002 23:01:22 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id JAA18988; Thu, 8 Aug 2002 09:01:20 +0300 Date: Thu, 8 Aug 2002 09:01:20 +0300 Message-Id: <200208080601.JAA18988@burp.tkv.asdf.org> From: Markku Savela To: namedroppers@ops.ietf.org In-reply-to: (message from Derek Atkins on 07 Aug 2002 20:28:16 -0400) Subject: Re: QType: ADDR References: <3D51AEA8.9020600@ehsco.com> <3D51B92E.10804@ehsco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Derek Atkins > So the qtype=addr would have you return _ALL_ data, both AAAA and A? > Couldn't that be a rather large response? If not, then how does the > _server_ know which type to prefer in the response? Just a thought occurs... Instead of having a new query type 'addr', could we just define that AAAA query returns both IPv4 and IPv6 addresses? (And if you want uniform format in reply, put IPv4 addresses into IPv4 mapped format) Unfortunately, due to already existing implementations of AAAA in servers, resolvers would always have to do the A query too (if AAAA doesn't have any IPv4 addresses), but if it did, then it could consider it a "new AAAA" reply and skip A. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 04:33:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05074 for ; Thu, 8 Aug 2002 04:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ciba-000LHj-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 01:25:14 -0700 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 17cibW-000LHY-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 01:25:10 -0700 Received: from localhost ([127.0.0.1] helo=feline.pp.se ident=www-data) by poledra with smtp (Exim 3.33 #1 (Debian)) id 17cibd-0001cp-00 for ; Thu, 08 Aug 2002 10:25:17 +0200 Received: from vots.rit.se ([213.88.136.208]) (SquirrelMail authenticated user feline) by www.feline.pp.se with HTTP; Thu, 8 Aug 2002 10:25:17 +0200 (CEST) Message-ID: <4088.213.88.136.208.1028795117.squirrel@www.feline.pp.se> Date: Thu, 8 Aug 2002 10:25:17 +0200 (CEST) Subject: Re: QType: ADDR From: "Kandra Nygards" To: In-Reply-To: <200208080601.JAA18988@burp.tkv.asdf.org> References: <200208080601.JAA18988@burp.tkv.asdf.org> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.5) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,MSG_ID_ADDED_BY_MTA_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > Just a thought occurs... > > Instead of having a new query type 'addr', could we just define that > AAAA query returns both IPv4 and IPv6 addresses? (And if you want > uniform format in reply, put IPv4 addresses into IPv4 mapped format) If I ask for MX, I want MX as the response. If I ask for AAAA, I want AAAA in the answer. An option could be to respond to AAAA-queries with A in the additional section, but that might also not be desirable, depending on your milage. Best regards, Kandra Nygards -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 09:53:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11964 for ; Thu, 8 Aug 2002 09:53:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cnTx-000PsO-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 06:37:41 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cnTk-000Prt-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 06:37:28 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g789aa23053140; Thu, 8 Aug 2002 09:36:36 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA28954; Thu, 8 Aug 2002 09:37:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <3D517D8D.3060200@ehsco.com> <3D517D8D.3060200@ehsco.com> <4.3.2.7.2.20020807173301.01896eb8@wells.cisco.com> Date: Thu, 8 Aug 2002 09:12:58 -0400 To: Derek Atkins , John Schnizlein From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:51 PM -0400 8/7/02, Derek Atkins wrote: >No. A DNSSec-aware server is supposed to respond with the appropriate >SIG and NXT records on every query, so the client should not have to >query for qtype any. That's changed. Only if the client asks for it. My old site was blocked (months ago) by another because our early DNSSEC-signed zones were returning answers too big - we tripped an IDS. So to be kind to old code, DNSSEC records are only returned when the client requests them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 09:55:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12129 for ; Thu, 8 Aug 2002 09:55:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cnTg-000Prm-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 06:37:24 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cnTb-000PrQ-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 06:37:19 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g789ab23053147; Thu, 8 Aug 2002 09:36:37 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA28966; Thu, 8 Aug 2002 09:37:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <90161.1028758762@shell.nominum.com> Date: Thu, 8 Aug 2002 09:15:17 -0400 To: Derek Atkins , Jim Reid From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Cc: "Eric A. Hall" , David Conrad , Scott Rose , namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 6:23 PM -0400 8/7/02, Derek Atkins wrote: >Jim, Eric is right that DNS messages are limited to 64k (even with >TCP). Perhaps EDNS1 can fix this (I don't know if EDNS0 does >offhand). I doubt that there's a way to fix the size limit. In TCP, you lead with a two byte length field not present in UDP. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 09:55:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12143 for ; Thu, 8 Aug 2002 09:55:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cnTp-000PsA-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 06:37:33 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cnTb-000PrR-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 06:37:19 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g789aY23053122; Thu, 8 Aug 2002 09:36:34 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA28913; Thu, 8 Aug 2002 09:37:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 8 Aug 2002 09:04:18 -0400 To: , "Derek Atkins" From: Edward Lewis Subject: RE: [Design] Re: the KEY debate Cc: "namedroppers" , "Scott Rose" , "Eric A. Hall" , "David Conrad" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 11:25 AM -1000 8/7/02, Jason Coombs wrote: >Better for you to KNOW the keys needed, in advance, to secure communications >with trusted hosts that you have an SSH or IPSec relationship with. Why do >you want to discover them dynamically? In particular, why would you EVER >want to discover them dynamically *across domains* ? That's just asking for >trouble and it's a feature without a purpose. It might also be deficient in >the area of common sense. These questions have dogged me on this for quite a while, ever since our first effort to get SSH and DNS integrated (late 2000). I rarely SSH to a host "for the first time" from across the Internet. On the other hand, there are two reasons why you might not have the keys (etal) of the SSH host that you want to contact while you are on the road. One is that the keys on the host may have been changed (local maintenance, emergency repair). The other is that you may have just recompiled the kernel on your laptop, screwed it up, and had to reload from disk. (Raise your hand if you have ever thought that the flight to the IETF would be a good time to "fix" your kernel. Of course, if you are using security to carry out a truely critical function, you aren't likely going to rebuild your kernel.) One aspect of the debate is not as much "how good" you want security, but is where on the sliding scale between "secure but brittle" and "loose and resilient." Simplicity in security starts with having a restricted system and not letting it stray from the norm, like pinning down the routes to the roots. Resilience in a system means that it will take any action necessary to reach the goal, even if unusual actions maybe needed, such as using alternate roads to travel around DC during rush hour. If you desire resilience and security, you have to be prepared to do a lot of work. Multiple certification chains are one start - although if you expect to use this, you open yourself to potentially eating up CPU cycles as part of a DOS attack. You also had better be prepared to lose the use of your most expensive resource at any time (meaning you will have to budget at least 100% for overhead). "It just goes to show you, it's always something." - I think this was Roseanne Roseanna Danna, a.k.a. Gilda Radner -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 10:24:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13288 for ; Thu, 8 Aug 2002 10:24:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17co1D-0000rm-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 07:12:03 -0700 Received: from fs3.antd.nist.gov ([129.6.50.151]) by psg.com with esmtp (Exim 3.36 #1) id 17co14-0000rK-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 07:11:54 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id g78EB4e10055; Thu, 8 Aug 2002 10:11:04 -0400 Message-ID: <001f01c23ee4$83d7aa90$b9370681@BARNACLE> From: "Scott Rose" To: "John Schnizlein" , "Derek Atkins" , "Edward Lewis" Cc: "namedroppers" References: <3D517D8D.3060200@ehsco.com> <3D517D8D.3060200@ehsco.com> <4.3.2.7.2.20020807173301.01896eb8@wells.cisco.com> Subject: Re: [Design] Re: the KEY debate Date: Thu, 8 Aug 2002 10:04:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Edward Lewis" To: "John Schnizlein" ; "Derek Atkins" Cc: "namedroppers" Sent: Thursday, August 08, 2002 9:10 AM Subject: Re: [Design] Re: the KEY debate > At 5:43 PM -0400 8/7/02, John Schnizlein wrote: > >Would "qtype all" be the appropriate way for a DNS client to get > >the RR-set so that it can check the validity of a signature? > >Would "qtype all" be much more common when applications demand > >assurance that the DNS reply is authentic? > > Not really. There's a different bit that a resolver uses to ask the > server to return DNSSEC records. In dig it is invoked with > "+dnssec," in the protocol I forget whether it became a bit in the > OPT record or not (DNSSEC OK bit)? > Correct. The +dnssec flag in dig adds an OPT record with the DNSSEC OK bit set. That's the only way to get DNSSEC records added to a response. Unless you ask for them specifically (or ANY, I would guess - haven't actually tried). The OK bit is like an flag to the server to say "DNSSEC capabile resolver asking the query" > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-703-227-9854 > ARIN Research Engineer > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 10:40:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11965 for ; Thu, 8 Aug 2002 09:53:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cnU7-000PtD-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 06:37:51 -0700 Received: from smtp1.arin.net ([192.149.252.33]) by psg.com with esmtp (Exim 3.36 #1) id 17cnTc-000Pre-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 06:37:20 -0700 Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id g789aZ23053134; Thu, 8 Aug 2002 09:36:35 GMT Received: from [192.149.252.228] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA28948; Thu, 8 Aug 2002 09:37:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20020807173301.01896eb8@wells.cisco.com> References: <3D517D8D.3060200@ehsco.com> <3D517D8D.3060200@ehsco.com> <4.3.2.7.2.20020807173301.01896eb8@wells.cisco.com> Date: Thu, 8 Aug 2002 09:10:02 -0400 To: John Schnizlein , Derek Atkins From: Edward Lewis Subject: Re: [Design] Re: the KEY debate Cc: namedroppers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 5:43 PM -0400 8/7/02, John Schnizlein wrote: >Would "qtype all" be the appropriate way for a DNS client to get >the RR-set so that it can check the validity of a signature? >Would "qtype all" be much more common when applications demand >assurance that the DNS reply is authentic? Not really. There's a different bit that a resolver uses to ask the server to return DNSSEC records. In dig it is invoked with "+dnssec," in the protocol I forget whether it became a bit in the OPT record or not (DNSSEC OK bit)? The problem with asking QTYPE=All to get the signatures is that this may be answered by a version of a name servers (some old BINDs) that may not keep the SIG records and just the data. Repeatedly asking for All to that server will not get the SIGs returned until the TTL ticks down to 0 for all records at the domain name. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 11:50:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16744 for ; Thu, 8 Aug 2002 11:50:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cpOz-0002lE-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 08:40:41 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cpOv-0002l2-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 08:40:37 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157256; Thu, 08 Aug 2002 10:37:55 -0500 Message-ID: <3D5290F0.8030007@ehsco.com> Date: Thu, 08 Aug 2002 10:40:32 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: itojun@iijlab.net CC: namedroppers Subject: Re: QType: ADDR References: <20020808005228.E48FF4B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/7/2002 7:52 PM itojun@iijlab.net wrote: >>> On the other hand, my bet is that more applications are likely to >>> START doing it once we have IPv6 applications that query for >>> qtype=any instead of doing AAAA before A. > > "any" query does not return all available data. it is allowed for a > recursize resolver (named) to return data on the cache already, and not > with other records actually available. therefore, stub resolvers (libc > resolver) that makes "any" query will not work. You are of course correct. But that didn't stop sendmail from doing it, and it isn't likely to stop v6 apps from doing it. The canonical issue here is that there will (hopefully) be millions of applications which are now faced with having to find two different RRs, whereas this problem has historically been limited to a few hundred MTAs in the past. If we know that a certain percentage of MTAs have done it (for whatever reasons they considered to be valid), then we can also assume that there will be a similar percentage of v6 apps that also do it (using similar reasoning). Secondarily, being able to provide a single query should result in lower overall utilization. The real question at this point is whether or not implementors would care to do it, given the necessary requirement for ensuring synchronization between the cache and the server (this also includes local caches, btw). I'll write this up and submit an I-D and see where it goes. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 8 12:41:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18907 for ; Thu, 8 Aug 2002 12:41:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cqGG-0003tr-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 09:35:44 -0700 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 17cqG8-0003tf-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 09:35:36 -0700 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 8 Aug 2002 09:35:35 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 08 Aug 2002 09:35:35 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 8 Aug 2002 09:35:35 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 8 Aug 2002 09:35:35 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Thu, 8 Aug 2002 09:35:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: QType: ADDR Date: Thu, 8 Aug 2002 09:35:33 -0700 Message-ID: Thread-Topic: QType: ADDR Thread-Index: AcI+t3tuNsdDKV4+QL6fsocUoqbELQAQTVYg From: "Christian Huitema" To: "Kandra Nygards" , X-OriginalArrivalTime: 08 Aug 2002 16:35:35.0493 (UTC) FILETIME=[9EFC9F50:01C23EF9] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA18907 > > Just a thought occurs... > > > > Instead of having a new query type 'addr', could we just define that > > AAAA query returns both IPv4 and IPv6 addresses? (And if you want > > uniform format in reply, put IPv4 addresses into IPv4 mapped format) > > If I ask for MX, I want MX as the response. If I ask for AAAA, I want AAAA > in the answer. An option could be to respond to AAAA-queries with A in the > additional section, but that might also not be desirable, depending on > your milage. There is a difference between MX and AAAA: MX records for a domain may point to another domain, for which the local server may or may not be authoritative; also, there may be several MX records, and it is hard to predict which of the records the client will select, and thus for which of the names additional processing is the most useful. On the contrary, the A and AAAA records are all attached to the same domain name. We can predict that in most cases, a failing AAAA request will be followed by an A request for the exact same name; in fact, there may be strategies in which the host wants to consider the full set of AAAA and A request and pick the "best one" according to some heuristic. This looks like the definition for an "additional response": opportunistic provision of records, because there is a high chance they will be useful. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 8 12:42:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18941 for ; Thu, 8 Aug 2002 12:42:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cqGR-0003ue-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 09:35:55 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17cqGN-0003uR-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 09:35:51 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g78GZ8v19805; Thu, 8 Aug 2002 11:35:09 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g78GZiBe000318; Thu, 8 Aug 2002 11:35:44 -0500 (CDT) Date: Thu, 8 Aug 2002 11:35:43 -0500 Subject: Re: QType: ADDR Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: itojun@iijlab.net, namedroppers To: "Eric A. Hall" From: Ted Lemon In-Reply-To: <3D5290F0.8030007@ehsco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > You are of course correct. But that didn't stop sendmail from doing it, > and it isn't likely to stop v6 apps from doing it. This sounds like a good reason to strategically place some very large RRsets in the DNS at places where these stupid applications will trip over them, not a good reason not to add a useful feature to the protocol. It is not the IETF's business (I hope!) to make life easy for application developers who don't know what they're doing, and can't be bothered to study. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 12:52:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19322 for ; Thu, 8 Aug 2002 12:52:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cqMd-00045T-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 09:42:19 -0700 Received: from [3ffe:501:410:0:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17cqMV-00045B-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 09:42:11 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D39C24B22; Fri, 9 Aug 2002 01:42:03 +0900 (JST) To: Ted Lemon Cc: "Eric A. Hall" , namedroppers In-reply-to: Ted.Lemon's message of Thu, 08 Aug 2002 11:35:43 EST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: QType: ADDR From: itojun@iijlab.net Date: Fri, 09 Aug 2002 01:42:03 +0900 Message-Id: <20020808164203.D39C24B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >It is not the IETF's business (I hope!) to make life easy for application >developers who don't know what they're doing, and can't be bothered to >study. for this reason we have RFC2553. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 12:58:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19513 for ; Thu, 8 Aug 2002 12:58:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cqUm-0004MP-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 09:50:44 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17cqUa-0004M5-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 09:50:32 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157279; Thu, 08 Aug 2002 11:47:50 -0500 Message-ID: <3D52A153.6000005@ehsco.com> Date: Thu, 08 Aug 2002 11:50:27 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Ted Lemon CC: itojun@iijlab.net, namedroppers Subject: Re: QType: ADDR References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/8/2002 11:35 AM Ted Lemon wrote: > This sounds like a good reason to strategically place some very large > RRsets in the DNS at places where these stupid applications will trip > over them, not a good reason not to add a useful feature to the > protocol. That might solve one problem, but not the one I'm worried about. > It is not the IETF's business (I hope!) to make life easy for > application developers who don't know what they're doing, and can't be > bothered to study. Requiring applications to issue 2x the queries (until the majority of nodes have AAAA RRs) doesn't help anybody. Consider also that negative caching has different ramifications (typically shorter TTLs) which mean that the first query (failure) will get passed along more often. An ADDR qtype can help against these potential problems somewhat. So even if everybody learned the lesson (yeah right), there are other good reasons to do it. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 8 13:53:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21166 for ; Thu, 8 Aug 2002 13:53:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17crMQ-0005Z5-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 10:46:10 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17crML-0005Yp-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 10:46:05 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g78HjLv19923; Thu, 8 Aug 2002 12:45:21 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g78HjuBe000333; Thu, 8 Aug 2002 12:45:56 -0500 (CDT) Date: Thu, 8 Aug 2002 12:45:56 -0500 Subject: Re: QType: ADDR Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers To: "Eric A. Hall" From: Ted Lemon In-Reply-To: <3D52A153.6000005@ehsco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Requiring applications to issue 2x the queries (until the majority of > nodes have AAAA RRs) doesn't help anybody. Consider also that negative > caching has different ramifications (typically shorter TTLs) which mean > that the first query (failure) will get passed along more often. An ADDR > qtype can help against these potential problems somewhat. Nobody, so far, has agreed with you that ANY is a good thing for applications to use. Several people who I think know what they are talking about have said that it is not. Applications that used to use it no longer do. So if your goal is to convince us of anything, you can't use the idea that applications need ANYas a basis for your arguments. Honestly, I think you are getting into optimization mentality here - you see a way to do things "more efficiently", and you want to use it, even though you don't have any practical experience that says that your optimization is actually a win. I do this all the time. It makes for complicated and unreliable code. The best way to do start is to implement things the "stupid" way, and optimize if you see that there's a problem. The evidence suggests that there's no problem here. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 14:09:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21647 for ; Thu, 8 Aug 2002 14:09:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17creQ-0005yp-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 11:04:46 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17creL-0005xz-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 11:04:42 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g78HxGeD002533 for ; Thu, 8 Aug 2002 10:59:16 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 11:06:28 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D8137A1@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: namedroppers Subject: RE: [Design] Re: the KEY debate Date: Thu, 8 Aug 2002 11:06:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.6 required=5.0 tests=TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't think that the allegations of FUD are justified, however it is clear that this group does not have a clear understanding of the security issues surrounding key distribution. Single point of failure sounds scary, however that is not the main reason why it is a canonically bad idea to reuse DNS as a key distribution system. The real problem is that DNS is designed operated and deployed as a name infrastructure. The majority of the DNS servers are deployed without any form of security analysis. Only a small number of TLDs have a comprehensive security profile in place. It is a very bad idea to make a change in a deployed protocol that changes its status from a non-security infrastructure to a critical security infrastructure. From a technical point of view it is quite possible to integrate a Kerberos style key distribution mechanism into DNS and if DNS was being designed from scratch that is exactly what I would propose. However retrofitting any type of primary key distribution scheme into a deployed service is completely unacceptable. There is a solution to this problem. DNS -> SRV -> XKMS 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: From owner-namedroppers@ops.ietf.org Thu Aug 8 14:10:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21764 for ; Thu, 8 Aug 2002 14:10:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17crb5-0005tN-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 11:01:19 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17crb1-0005t9-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 11:01:15 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157310; Thu, 08 Aug 2002 12:58:34 -0500 Message-ID: <3D52B1E6.6030502@ehsco.com> Date: Thu, 08 Aug 2002 13:01:10 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Ted Lemon CC: namedroppers Subject: Re: QType: ADDR References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=4.2 required=5.0 tests=NO_EXPERIENCE version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/8/2002 12:45 PM Ted Lemon wrote: >> Requiring applications to issue 2x the queries (until the majority of >> nodes have AAAA RRs) doesn't help anybody. Consider also that >> negative caching has different ramifications (typically shorter TTLs) >> which mean that the first query (failure) will get passed along more >> often. An ADDR qtype can help against these potential problems >> somewhat. > > Nobody, so far, has agreed with you that ANY is a good thing for > applications to use. I haven't said so myself. This doesn't mean I don't think people won't do it. History clearly shows otherwise. > Honestly, I think you are getting into optimization mentality here - > you see a way to do things "more efficiently", and you want to use it, > even though you don't have any practical experience that says that your > optimization is actually a win. Are you saying that there is no experience indicating that fewer queries are better? -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 8 14:36:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22506 for ; Thu, 8 Aug 2002 14:36:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cs4J-0006RK-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 11:31:31 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17cs4C-0006Qb-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 11:31:25 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2D5EC18BA for ; Thu, 8 Aug 2002 14:30:52 -0400 (EDT) Date: Thu, 08 Aug 2002 14:30:44 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: QType: ADDR In-Reply-To: <3D5290F0.8030007@ehsco.com> References: <20020808005228.E48FF4B22@coconut.itojun.org> <3D5290F0.8030007@ehsco.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020808183052.2D5EC18BA@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 08 Aug 2002 10:40:32 -0500, Eric A. Hall wrote: > > You are of course correct. But that didn't stop sendmail from doing it, > and it isn't likely to stop v6 apps from doing it. The canonical issue > here is that there will (hopefully) be millions of applications which are > now faced with having to find two different RRs, whereas this problem has > historically been limited to a few hundred MTAs in the past. If we know > that a certain percentage of MTAs have done it (for whatever reasons they > considered to be valid), then we can also assume that there will be a > similar percentage of v6 apps that also do it (using similar reasoning). Sounds like a case for a (long overdue) document: "Non-debugging Use of DNS `*' Query Type Considered Harmful". > Secondarily, being able to provide a single query should result in lower > overall utilization. It's not that much of a saving, since whatever iterative resolver is doing the work for you should already have the delegation chain cached when (and if) you issue subsequent queries. "Make it right before you make it faster. Keep it right when you make it faster." -- Kernighan & Plauger, "The Elements of Programming Style", 1974. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 14:44:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22831 for ; Thu, 8 Aug 2002 14:44:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17csB2-0006YT-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 11:38:28 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17csAy-0006YF-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 11:38:24 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g78Ibgv20033; Thu, 8 Aug 2002 13:37:42 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g78IcIBe000462; Thu, 8 Aug 2002 13:38:18 -0500 (CDT) Date: Thu, 8 Aug 2002 13:38:18 -0500 Subject: Re: QType: ADDR Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers To: "Eric A. Hall" From: Ted Lemon In-Reply-To: <3D52B1E6.6030502@ehsco.com> Message-Id: <01E6C007-AAFE-11D6-8B54-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,NO_EXPERIENCE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Are you saying that there is no experience indicating that fewer queries > are better? No, I'm saying that there is no experience that suggests that using ANY to reduce the number of queries is better. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 14:54:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23117 for ; Thu, 8 Aug 2002 14:54:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17csII-0006hW-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 11:45:58 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17csI9-0006hE-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 11:45:49 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157332; Thu, 08 Aug 2002 13:43:07 -0500 Message-ID: <3D52BC58.70503@ehsco.com> Date: Thu, 08 Aug 2002 13:45:44 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Ted Lemon CC: namedroppers Subject: Re: QType: ADDR References: <01E6C007-AAFE-11D6-8B54-00039367340A@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=4.2 required=5.0 tests=NO_EXPERIENCE version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/8/2002 1:38 PM Ted Lemon wrote: >> Are you saying that there is no experience indicating that fewer >> queries are better? > > No, I'm saying that there is no experience that suggests that using ANY > to reduce the number of queries is better. Do you think I'm advocating such? [hint: the subject is "qtype: addr" not "qtype: any"] -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 8 15:03:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23531 for ; Thu, 8 Aug 2002 15:03:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17csPw-0006qc-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 11:53:52 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17csPr-0006qN-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 11:53:47 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g78Ir9v20092; Thu, 8 Aug 2002 13:53:09 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g78IrjBe000465; Thu, 8 Aug 2002 13:53:45 -0500 (CDT) Date: Thu, 8 Aug 2002 13:53:45 -0500 Subject: Re: [Design] Re: the KEY debate Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers To: "Hallam-Baker, Phillip" From: Ted Lemon In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40D8137A1@vhqpostal.verisign.com> Message-Id: <2A87B73E-AB00-11D6-8B54-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It is a very bad idea to make a change in a deployed protocol that changes > its status from a non-security infrastructure to a critical security > infrastructure. If this statement is true, then DNSSEC is a bad idea. The whole point of DNSSEC is to be able to authenticate the answers that the name server gives. This is done using a secret key. Compromise of that key allows the one who has compromised it to claim that invalid data is valid in a way that can be cryptographically authenticated. So if you use DNSSEC, the DNS server *is* part of the critical security infrastructure. There is no getting around this. Once that genie is out of the bottle, it doesn't make any difference how many keys you store in the DNS, because you *have* to treat the DNS server as part of your critical security infrastructure. BTW, please note that nobody is saying here that DNS should take the place of Kerberos or something like it. Rather, what is being said is that there are applications where making a key available in the DNS makes sense. For example, an SSH host key can be used to verify that you are talking to the host associated with an A record that you've looked up. This doesn' t grant you access to the server - your private key does that. What it does is to simply verify that you are talking to who you think you are talking to. For this kind of security, storing keys in the DNS makes a lot of sense (to me, at least!). -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 15:18:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23877 for ; Thu, 8 Aug 2002 15:18:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17csdg-00078q-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 12:08:04 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17csdS-00078K-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 12:07:50 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g78J78v20152; Thu, 8 Aug 2002 14:07:08 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g78J7iBe000476; Thu, 8 Aug 2002 14:07:44 -0500 (CDT) Date: Thu, 8 Aug 2002 14:07:44 -0500 Subject: Re: QType: ADDR Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: namedroppers To: "Eric A. Hall" From: Ted Lemon In-Reply-To: <3D52BC58.70503@ehsco.com> Message-Id: <1E667F3A-AB02-11D6-8B54-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Do you think I'm advocating such? > > [hint: the subject is "qtype: addr" not "qtype: any"] Unless I've just been off in space-cadet land, you've been saying that storing application keys in the DNS is wrong, because it means that a query of type ANY will no longer be possible for names with lots of keys. I think that the ADDR query type is a bandaid, not a solution, but that's another debate. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 15:40:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24413 for ; Thu, 8 Aug 2002 15:40:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ct3w-0007ba-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 12:35:12 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17ct3r-0007bP-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 12:35:08 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157349; Thu, 08 Aug 2002 14:32:26 -0500 Message-ID: <3D52C7E7.7000304@ehsco.com> Date: Thu, 08 Aug 2002 14:35:03 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Ted Lemon CC: namedroppers Subject: Re: QType: ADDR References: <1E667F3A-AB02-11D6-8B54-00039367340A@nominum.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/8/2002 2:07 PM Ted Lemon wrote: > Unless I've just been off in space-cadet land, you've been saying that > storing application keys in the DNS is wrong, because it means that a > query of type ANY will no longer be possible for names with lots of > keys. That was one reason cited against willy-nilly RRs (specifically in response to "other protocol data" and not to keys, but I didn't make that clear, so fair play). Lots of RRs force retries for applications that do qtype=any, there are plenty of deployed apps that do qtype=any (popular apps anyway), and there will probably be a lot more of them. I'm not advocating these apps, I'm using them as an example of harm caused from excessive RRs. FWIW, hotmail.com overflows even if you only ask for MX and get a full answer (including all NS and glue). Mark mentioned excess PTRs as a source of TCP overflow problems. So too many of one RR causes problems even for applications that do the "right" thing. [Lord, please don't let this turn into another strawman of me being against MX!] There are other reasons, already mentioned. My opinion should be obvious, that we need to be really conservative with this stuff. Even my dual-mode i18n DNS work focuses on collapsing names into a canonical form for storage, and avoids 2x storage and queries wherever possible. Frankly, I am more concerned with large uses. A billion phones looking for a billion phone numbers in the DNS is not going to be healthy. People talk about storing user data in the DNS from time to time, as if defining and replicating user-specific ACLs for RRs is no big deal. People talk about having DNS be a PKI, with all that it implies. The small stuff adds up too, you know. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 8 15:43:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24492 for ; Thu, 8 Aug 2002 15:43:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ct3Y-0007ao-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 12:34:48 -0700 Received: from peacock.verisign.com ([65.205.251.73]) by psg.com with esmtp (Exim 3.36 #1) id 17ct3Q-0007aX-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 12:34:40 -0700 Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.12.1/) with ESMTP id g78JUOXA008867; Thu, 8 Aug 2002 12:30:24 -0700 (PDT) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 12:36:27 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D8137D3@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Ted Lemon , "Hallam-Baker, Phillip" Cc: namedroppers Subject: RE: [Design] Re: the KEY debate Date: Thu, 8 Aug 2002 12:36:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Your post makes two comparisons which are both inappropriate. First the adding of security to the DNS protocol to secure DNS cannot and should not be conflated with the use of DNS infrastructure to secure other protocols. Then you say nobody is proposing X and go on to propose X. Phill > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Thursday, August 08, 2002 2:54 PM > To: Hallam-Baker, Phillip > Cc: namedroppers > Subject: Re: [Design] Re: the KEY debate > > > > It is a very bad idea to make a change in a deployed > protocol that changes > > its status from a non-security infrastructure to a critical security > > infrastructure. > > If this statement is true, then DNSSEC is a bad idea. The > whole point of > DNSSEC is to be able to authenticate the answers that the > name server gives. > This is done using a secret key. Compromise of that key > allows the one > who has compromised it to claim that invalid data is valid in > a way that > can be cryptographically authenticated. > > So if you use DNSSEC, the DNS server *is* part of the > critical security > infrastructure. There is no getting around this. Once > that genie is out > of the bottle, it doesn't make any difference how many keys > you store in > the DNS, because you *have* to treat the DNS server as part of your > critical security infrastructure. > > BTW, please note that nobody is saying here that DNS should > take the place > of Kerberos or something like it. Rather, what is being > said is that > there are applications where making a key available in the > DNS makes sense. > For example, an SSH host key can be used to verify that > you are talking > to the host associated with an A record that you've looked > up. This doesn' > t grant you access to the server - your private key does > that. What it > does is to simply verify that you are talking to who you > think you are > talking to. For this kind of security, storing keys in the > DNS makes a > lot of sense (to me, at least!). > -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 15:58:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25012 for ; Thu, 8 Aug 2002 15:58:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ctI9-0007sL-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 12:49:53 -0700 Received: from toccata.fugue.com ([204.152.186.142]) by psg.com with esmtp (Exim 3.36 #1) id 17ctI4-0007s6-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 12:49:48 -0700 Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g78JnAv20255 for ; Thu, 8 Aug 2002 14:49:10 -0500 (CDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g78JnlBe000491 for ; Thu, 8 Aug 2002 14:49:47 -0500 (CDT) Date: Thu, 8 Aug 2002 14:49:46 -0500 Subject: Re: [Design] ending the KEY debate Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Ted Lemon To: namedroppers Content-Transfer-Encoding: 7bit In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F40D8137D3@vhqpostal.verisign.com> Message-Id: X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we have ceased to make progress (probably many messages ago). I apologize for continuing to press the argument - I don't think it's accomplished much. :'/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 16:12:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25431 for ; Thu, 8 Aug 2002 16:12:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ctXC-00089A-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 13:05:26 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17ctX2-00088x-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 13:05:16 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id XAA19574; Thu, 8 Aug 2002 23:05:10 +0300 Date: Thu, 8 Aug 2002 23:05:10 +0300 Message-Id: <200208082005.XAA19574@burp.tkv.asdf.org> From: Markku Savela To: ehall@ehsco.com CC: Ted.Lemon@nominum.com, namedroppers@ops.ietf.org In-reply-to: <3D52C7E7.7000304@ehsco.com> (ehall@ehsco.com) Subject: Re: QType: ADDR References: <1E667F3A-AB02-11D6-8B54-00039367340A@nominum.com> <3D52C7E7.7000304@ehsco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: "Eric A. Hall" > Frankly, I am more concerned with large uses. A billion phones looking for > a billion phone numbers in the DNS is not going to be healthy. Yes, phones will ask AAAA and/or A. Please, raise hand if *anyone* knows dual IPv4+IPv6 implementation which actually chose to do qtype=ANY instead of specific A and AAAA? I'm surprised (horrified) if I see any hands! :-) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 8 18:13:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29036 for ; Thu, 8 Aug 2002 18:13:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17cvMH-000AGY-00 for namedroppers-data@psg.com; Thu, 08 Aug 2002 15:02:17 -0700 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.36 #1) id 17cvMD-000AGI-00 for namedroppers@ops.ietf.org; Thu, 08 Aug 2002 15:02:13 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g78M1Qgs082705; Fri, 9 Aug 2002 08:01:28 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208082201.g78M1Qgs082705@drugs.dv.isc.org> To: Edward Lewis Cc: Derek Atkins , Jim Reid , "Eric A. Hall" , David Conrad , Scott Rose , namedroppers From: Mark.Andrews@isc.org Subject: Re: [Design] Re: the KEY debate In-reply-to: Your message of "Thu, 08 Aug 2002 09:15:17 -0400." Date: Fri, 09 Aug 2002 08:01:26 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > At 6:23 PM -0400 8/7/02, Derek Atkins wrote: > >Jim, Eric is right that DNS messages are limited to 64k (even with > >TCP). Perhaps EDNS1 can fix this (I don't know if EDNS0 does > >offhand). > > I doubt that there's a way to fix the size limit. In TCP, you lead > with a two byte length field not present in UDP. It's easy enough to fix this. The problem is how long after you deploy code to fix the problem before you can you reasonable expect to be able to use the new code. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 10 22:14:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23416 for ; Sat, 10 Aug 2002 22:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17dhx2-0003W7-00 for namedroppers-data@psg.com; Sat, 10 Aug 2002 18:55:28 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17dhww-0003Vw-00 for namedroppers@ops.ietf.org; Sat, 10 Aug 2002 18:55:22 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17dhww-000MJf-00 for namedroppers@ops.ietf.org; Sat, 10 Aug 2002 18:55:22 -0700 Message-Id: <200208102013.g7AKDO5C011831@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: Internet-Drafts@ietf.org cc: namedroppers Subject: new draft-richardson-ipsec-rr-00 Date: Sat, 10 Aug 2002 16:13:24 -0400 From: Michael Richardson X-Spam-Status: No, hits=-3.1 required=5.0 tests=LINES_OF_YELLING,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- ID editor, please accept draft-richardson-ipsec-rr-00.txt located at: http://www.sandelman.ca/SSW/ietf/ipsec/dns/draft-richardson-ipsec-rr-00.txt ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPVVz4YqHRg3pndX9AQEG2QP/UDNp9cepRIbxQcvxK83v4icUd3NC/CAz ey6j+nERECEu5qI60bb5BV8l4LyHVJU5uEb91JxHW6fJYtFS99xrwWJAZb1a/TKD mLk5EnKwv7U6xJsWzd2WZBjhD7dRmYZuGADQ+/WDtu26rAfjZXLpgKG/TtWQdyAQ 8vhX0NZcyEc= =+30J -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sat Aug 10 22:15:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23441 for ; Sat, 10 Aug 2002 22:15:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17dhxW-0003WQ-00 for namedroppers-data@psg.com; Sat, 10 Aug 2002 18:55:58 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17dhxR-0003WF-00 for namedroppers@ops.ietf.org; Sat, 10 Aug 2002 18:55:53 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17dhxR-000MKS-00 for namedroppers@ops.ietf.org; Sat, 10 Aug 2002 18:55:53 -0700 Message-Id: <200208102018.g7AKILVI011849@marajade.sandelman.ottawa.on.ca> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII To: design@lists.freeswan.org, namedroppers cc: hugh@mimosa.com Subject: IPSECKEY draft Date: Sat, 10 Aug 2002 16:18:21 -0400 From: Michael Richardson X-Spam-Status: No, hits=-2.5 required=5.0 tests=PORN_10,LINES_OF_YELLING,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- DHR, Derek, Jakob and others, please see: http://www.sandelman.ca/SSW/ietf/ipsec/dns/draft-richardson-ipsec-rr-00.txt Key points: The RDATA for an IPSECKEY RR consists of a series of type/length/ value and type/value records. The canonical ordering of the fields *** oops, changed my mind, there are no type/value options, I'll fix that. is by increasing ordinal values of the type field. A type may not occur more than once. Each field consistsa reserved field, a field type octet, and a length of that field. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | field type | reserved | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / data / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| (XXX - Do we really need a 16-bit length? 8-bits will not suffice for public keys. Or should we go for 11 or 12 bits with a 4 or 5 bit type?) Definitions for field types: 0 no more fields 1 priority of this entry 2 IPv4 address of the gateway for this host 3 IPv6 address of the gateway for this host 4 FQDN of the gateway for this host 5 RSA public key for the gateway Presentation format: 3.1 File Representation of IPSECKEY RRs IPSECKEY RRs may appear as lines in a zone data master file. The preference and at least one key are mandatory. As the IPv4, IPv6 and FQDN references to the gateway are mutually exclusive, they can share a position. If no gateway is to be indicated, then the special tokens of either "-" or "none" may be used. 38.46.139.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 192.139.46.38 RSA: AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 fejrfi1H ) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPVV1CIqHRg3pndX9AQGzDwP5AU5YBjoQ05KsmbDVnakV0q5WzQIm9yED l5CmtH+65hV6ffkg71i4T0XaMCBu/m6j9PfkZQGaTON4iW23pF+PFzlD8fH3ROtR 7c+gsLPBN+L48knrCsun+0e8xoq6aK8obqwCoTMHMtetzwVHxFqFyd4qp7CCXiBF AvF+wVUUmRA= =IuDo -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Sun Aug 11 00:34:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25734 for ; Sun, 11 Aug 2002 00:34:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17dkHN-0005sF-00 for namedroppers-data@psg.com; Sat, 10 Aug 2002 21:24:37 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17dkHI-0005s4-00 for namedroppers@ops.ietf.org; Sat, 10 Aug 2002 21:24:32 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17dkHI-000PvA-00 for namedroppers@ops.ietf.org; Sat, 10 Aug 2002 21:24:32 -0700 In-Reply-To: <200208102018.g7AKILVI011849@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Sun, 11 Aug 2002 00:14:04 -0400 (EDT) From: "D. Hugh Redelmeier" To: Michael Richardson cc: design@lists.freeswan.org, namedroppers Subject: Re: [Design] IPSECKEY draft X-Spam-Status: No, hits=-5.4 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,LINES_OF_YELLING,PGP_SIGNATURE version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] -----BEGIN PGP SIGNED MESSAGE----- | From: Michael Richardson | http://www.sandelman.ca/SSW/ietf/ipsec/dns/draft-richardson-ipsec-rr-00.txt [This is just my initial reaction.] Are there any Son Of Ike implications? We don't want to have to revise this. I don't know much about resource record representations. Are the fields in this proposal represented in ways similar to other resource records? [Not to pick at a sore point, but it seems unfortunate to require each different use of keys to have a new resource record format. Even if the same type cannot be used, we ought to set a pattern that can be reused.] | Key points: | | The RDATA for an IPSECKEY RR consists of a series of type/length/ | value and type/value records. | The canonical ordering of the fields | is by increasing ordinal values of the type field. The value of "0" for "no more fields" kind of contradicts this. Perhaps it should be 255. Also, the format of a "no more fields" entry has not been given. Is it a full T/L/V? That might be good. Or perhaps there need be no 0: the length RDLENGTH gives enough information. | A type may not occur more than once. This is probably a good idea. We would allow multiple records to achieve the same goals, right? Goals are: alternative gateways and alternative keys. I think that the draft should explain the semantics of multiple records ("or", not "and": all should be tried?). The draft says that that types 2, 3, and 4 are mutually exclusive (IPv4 address, IPv6 address, FQDN of gateway). This matches our current use of TXT records. We could change this. If both an IPv6 and IPv4 address are present, then either could be used. This would have the same semantics as having two records, identical except one has the IPv4 address and the other has the IPv6 address. I'm not advocating this. I read the FQDN as being the Phase 1 ID, and not a name is to be resolved. This is the current logic of our system and our OE proposals. This should be spelled out. Here's another approach, but I'm not saying I buy it. There is a Phase 1 ID and an address for the Security Gateway. If the Phase 1 ID is missing, it defaults (like IKE) to be the address. So it would be reasonable to have both an address and a FQDN in the same record. This would allow a Responding OE IKE to use a FQDN ID. I think that this is an improvement on what we currently have. Taking this logic a step further, the record could have a field for address and a field for ID. The address would be IPv4 or IPv6. Perhaps we could also allow some form of indirection (FQDN), but that was intentionally avoided by Henry. One reason is that it slows things down. The ID field could, arguably, be any form recognized by the IKE RFC for Phase 1 ID. Possibly scary. It probably should default (as in the current case) to being the address. The KEY field could be optional (as it is in our current TXT record). The record would simply delegate the SG function. The SG's own IPSECKEY record would then supply the KEY. So a two-step lookup would be required. Dreaming: it would be great if we could figure out how to delegate fora a subnet, not just a single host. This might be the time to organize this. Does there need to be a Security Considerations section? Nit picking: | The list of current Internet-Drafts can be accessed at http:// | www.ietf.org/ietf/1id-abstracts.txt. bad line break | 1.1 Overview | | A ???? | 2.1 IPSECKEY RDATA format | | The RDATA for an IPSECKEY RR consists of a series of type/length/ | | | | Richardson Expires February 8, 2003 [Page 2] | | Internet-Draft ipsecrr August 2002 | | | value and type/value records. The canonical ordering of the fields bad page break | Each field consistsa reserved field, a field type octet, and a length ^of | 2.5 FQDN of the gateway | | The data portion is a %lt;domain-name%gt; encoded as described in ???? ???? | 2.6 RSA public of the gateway | | The data portion of the field contains an RSA public key, encoded as | described in secion 2 of [6], and repeated here: | | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | pub exp length| public key exponent / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / | +- modulus / | | / | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ | | RFC2065 limited the exponent and modulus to 2552 bits in length, and | RFC3110 to 4096 bits. No such limit is specified here for the | purposes of encoding and decoding. The length in octets of the | public exponent length is represented as one octet if it is in the | range of 1 to 255 and by a zero octet followed by a two octet | unsigned length if it is longer than 255 bytes. The public key | modulus field is a multiprecision unsigned integer. The length of | the modulus can be determined from the RDLENGTH and the preceding | RDATA fields including the exponent. This seems wrong: the key is T/L/V, so the length is not RDLENGTH but L. Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253 -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBPVXkl8FAuQPManGZAQESHgP+PeMeoCMqO9HC+MQh3YhLSieBS/ce3JIW 17feB30xGoXnkYNhfKN+JVP4q8pYm/P421A4SrAPIgEYjl/zyyihtHLvhy0lzsD2 dWoTrEnxiu5MrpldSmhvJnftkgp1arZZfeW51QU7KTMTWa+3LfGq0DXWr7V53E7b nj296rYIacI= =pfrU -----END PGP SIGNATURE----- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 12 07:15:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16072 for ; Mon, 12 Aug 2002 07:15:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eCvS-000JoZ-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 03:59:54 -0700 Received: from [202.28.97.2] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17eCvK-000Jny-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 03:59:46 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7CAxeo23898; Mon, 12 Aug 2002 17:59:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7BEvhW09068; Sun, 11 Aug 2002 21:57:43 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: QType: ADDR In-Reply-To: <20020808183052.2D5EC18BA@thrintun.hactrn.net> References: <20020808183052.2D5EC18BA@thrintun.hactrn.net> <20020808005228.E48FF4B22@coconut.itojun.org> <3D5290F0.8030007@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 21:57:43 +0700 Message-ID: <9066.1029077863@munnari.OZ.AU> X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_12_24 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 08 Aug 2002 14:30:44 -0400 From: Rob Austein Message-ID: <20020808183052.2D5EC18BA@thrintun.hactrn.net> | Sounds like a case for a (long overdue) document: | "Non-debugging Use of DNS `*' Query Type Considered Harmful". This is a good idea, but it should be extended to meta queries in general, so we don't keep seeing suggestions like the ADDR meta query, which apart from the size issue, is no different in the problems it causes than ANY. | It's not that much of a saving, since whatever iterative resolver is | doing the work for you should already have the delegation chain cached | when (and if) you issue subsequent queries. Yes. Also the idea of adding A's as additional info on an AAAA query is attractive. The RRset rules mean that if you have any A's, you are able to assume you have the full set. So, adding those A's will get them to the client's local back end resolver cache, meaning just one local very cheap query when the client decides it wants the A's. This doesn't have the negative effects of meta queries, because the answer is only expected to contain the AAAA records (just as including A's with MX queries). If the A's didn't get returned, the later query the client does (we don't need to assume that the stub resolver will be smart enough to cache the A's that appeared in the AAAA query) will fetch them the hard(er) way. If they do, the local cache has them. The best two things about this are that there is no need for any IETF work to make it happen - just a request to the DNS server implementors to do the right thing, and a suggestion to DNS cache implementors (to the extent they're not the same people) that receiving A's in the additional info section of a reply containing AAAA's in the answer section is normal, and not some kind of attack to guard against. And second, it dies naturally, with no effort, when it is no longer useful. That is, when there are no more A's in use any more, there will be none to include, and the whole thing will just stop - domain by domain, as the transition eventually happens (sometime in the far future). As soon as the DNS server implementors decide that there aren't enough A users left to bother supporting, they can rip this code out of their servers. The only effect of that will be that the (very few remaining) queries that still do need A records will result in the extra query going further, but the assumption is that there will be so few of them by then that no-one will notice. So, server/cache people - go try it... I think this is easy (as code to add A's ad additional info is already there, just needs to be enabled for AAAA as it is for MX, NS, and others). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 12 09:49:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22102 for ; Mon, 12 Aug 2002 09:49:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eFOw-000M6m-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 06:38:30 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17eFOa-000M6S-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 06:38:08 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157594; Mon, 12 Aug 2002 08:35:28 -0500 Message-ID: <3D57BA3C.7090003@ehsco.com> Date: Mon, 12 Aug 2002 08:38:04 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: Rob Austein , namedroppers@ops.ietf.org Subject: Re: QType: ADDR References: <20020808183052.2D5EC18BA@thrintun.hactrn.net> <20020808005228.E48FF4B22@coconut.itojun.org> <3D5290F0.8030007@ehsco.com> <9066.1029077863@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/11/2002 9:57 AM Robert Elz wrote: > suggestions like the ADDR meta query, which apart from the size issue, > is no different in the problems it causes than ANY. That's a hollow argument, since "the size issue" is exactly what's trying to be avoided. There's no doubt that these kind of meta-queries have issues. In particular, an ADDR qtype relocates fall-back complexity from the API side of the resolver to the protocol side. It isn't "free", and from an holistic perspective, it's probably a wash. There is also a new cost in terms of fallback failure which comes from having to deal with NOTIMPL responses in downstream agents. OTOH, the prima benefit is still there, which is that it provides application developers an efficient alternative (from their PoV) to qtype=any. > Yes. Also the idea of adding A's as additional info on an AAAA query > is attractive. The RRset rules mean that if you have any A's, you are > able to assume you have the full set. True for resolvers/servers compliant with 2181, but not earlier. Also, this method relocates complexity to the servers, while *also* preserving it on the API side of the resolver. This approach has many of the complexities of qtype=ADDR (potential overload, DNSSEC, and so forth), and we *still* have to worry about developers issuing queries for qtype=all. Holistically, things become more complex, not less. On the other hand, this is also true for qtype=ADDR (at least in the short term), since applications won't be able to assume that it will work, either. One more comment for the record, I'm not convinced that qtype=addr is worth the pain, but I know that qtype=any is worth being avoided. An initial draft has been submitted and should be coming through the pipeline in a day or two, but somebody else will have to do something with it. I'm not going to advocate it. It seems to be a wash. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 12 11:58:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27355 for ; Mon, 12 Aug 2002 11:58:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eHOw-000Nj8-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 08:46:38 -0700 Received: from as7-2-2.bn.g.bonet.se ([217.215.21.151] helo=poledra) by psg.com with esmtp (Exim 3.36 #1) id 17eHOq-000Nim-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 08:46:32 -0700 Received: from amalthea.coyote.org ([192.168.242.14] helo=amalthea) by poledra with asmtp (Exim 3.33 #1 (Debian)) id 17eHP1-0008Q8-00 for ; Mon, 12 Aug 2002 17:46:43 +0200 Message-ID: <006e01c24217$6ee92790$0ef2a8c0@amalthea> From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= To: References: <20020808183052.2D5EC18BA@thrintun.hactrn.net> <20020808005228.E48FF4B22@coconut.itojun.org> <3D5290F0.8030007@ehsco.com> <9066.1029077863@munnari.OZ.AU> <3D57BA3C.7090003@ehsco.com> Subject: Re: QType: ADDR Date: Mon, 12 Aug 2002 17:46:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Eric A. Hall" > > Yes. Also the idea of adding A's as additional info on an AAAA query > > is attractive. The RRset rules mean that if you have any A's, you are > > able to assume you have the full set. > > True for resolvers/servers compliant with 2181, but not earlier. Are there any implementations out there that send incomplete RRsets to any query? > Also, this method relocates complexity to the servers, while *also* > preserving it on the API side of the resolver. This approach has many of > the complexities of qtype=ADDR (potential overload, DNSSEC, and so forth), Potential overload is an even bigger problem on queries such ax MX (assuming we're talking about the same thing). As for DNSSEC, I haven't had the time to get much deeper into it, so I'd welcome any input on potential issues from someone who knows a bit more than me. I still believe that my idea has certain advantages though, most notably the fact that there's no need for any protocol changes. Best regards Kandra Nygards -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 12 13:40:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01897 for ; Mon, 12 Aug 2002 13:40:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eJ0p-000PFd-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 10:29:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17eJ0l-000PFR-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 10:29:47 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17eJ0l-000M5E-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 10:29:47 -0700 In-Reply-To: <200208102018.g7AKILVI011849@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 12 Aug 2002 13:30:24 -0400 (EDT) From: Charlie Brady To: Michael Richardson cc: design@lists.freeswan.org, namedroppers Subject: Re: [Design] IPSECKEY draft X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Sat, 10 Aug 2002, Michael Richardson wrote: > Presentation format: > > 3.1 File Representation of IPSECKEY RRs > > IPSECKEY RRs may appear as lines in a zone data master file. The > preference and at least one key are mandatory. Is this appropriate here? All the world does not use "bind", nor should it. -- Charlie Brady charlieb@e-smith.com Lead Product Developer Network Server Solutions Group http://www.e-smith.com/ Mitel Networks Corporation http://www.mitel.com/ Phone: +1 (613) 592 5660 or 592 2122 Fax: +1 (613) 592 1175 -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 12 14:10:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03781 for ; Mon, 12 Aug 2002 14:10:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eJVe-000Pnq-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 11:01:42 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17eJVZ-000PnM-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 11:01:38 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4BB8818BA; Mon, 12 Aug 2002 14:01:06 -0400 (EDT) Date: Mon, 12 Aug 2002 14:01:06 -0400 From: Rob Austein To: design@lists.freeswan.org, namedroppers Subject: Re: [Design] IPSECKEY draft In-Reply-To: References: <200208102018.g7AKILVI011849@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020812180106.4BB8818BA@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Mon, 12 Aug 2002 13:30:24 -0400 (EDT), Charlie Brady wrote: > > > Presentation format: > > > > 3.1 File Representation of IPSECKEY RRs > > > > IPSECKEY RRs may appear as lines in a zone data master file. The > > preference and at least one key are mandatory. > > Is this appropriate here? All the world does not use "bind", nor should > it. Master file format is not specific to bind, it's part of the DNS spec. Some have argued that it should not have been (opinions vary), but until and unless that aspect of the spec is changed, specifying a master file presentation format is a normal and expected part of proposing a new RR type. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 12 14:52:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05862 for ; Mon, 12 Aug 2002 14:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eK98-0000Xo-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 11:42:30 -0700 Received: from fs3.antd.nist.gov ([129.6.50.151]) by psg.com with esmtp (Exim 3.36 #1) id 17eK8x-0000XQ-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 11:42:20 -0700 Received: from BARNACLE (barnacle.antd.nist.gov [129.6.55.185]) by fs3.antd.nist.gov (8.11.6/8.11.6) with SMTP id g7CIgMe15791; Mon, 12 Aug 2002 14:42:22 -0400 Message-ID: <015f01c2422f$14cc1390$b9370681@BARNACLE> From: "Scott Rose" To: "namedroppers" , References: <200208102013.g7AKDO5C011831@marajade.sandelman.ottawa.on.ca> Subject: Re: new draft-richardson-ipsec-rr-00 Date: Mon, 12 Aug 2002 14:35:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.5 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I really think this is something that will get the ball rolling on if/how to best store application keys in DNS. I noticed that RSA is the only algorithm supported by the IPSECKEY RR. Would there be a benifit to adding an algorithm field to the RDATA to support other algorithms? In an effort of make the IPSECKEY more flexible for other IPSec implementations that might want to use it. Scott ----- Original Message ----- From: "Michael Richardson" To: Cc: "namedroppers" Sent: Saturday, August 10, 2002 4:13 PM Subject: new draft-richardson-ipsec-rr-00 > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > -----BEGIN PGP SIGNED MESSAGE----- > > > ID editor, > please accept draft-richardson-ipsec-rr-00.txt located at: > > http://www.sandelman.ca/SSW/ietf/ipsec/dns/draft-richardson-ipsec-rr-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: From owner-namedroppers@ops.ietf.org Mon Aug 12 16:20:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09879 for ; Mon, 12 Aug 2002 16:20:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eLOi-0001vi-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 13:02:40 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17eLOd-0001vT-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 13:02:35 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA14931; Mon, 12 Aug 2002 16:02:31 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA05862; Mon, 12 Aug 2002 16:02:26 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA02358; Mon, 12 Aug 2002 16:02:21 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA25613; Mon, 12 Aug 2002 16:02:21 -0400 (EDT) To: "Scott Rose" Cc: "namedroppers" , From: Derek Atkins Subject: Re: new draft-richardson-ipsec-rr-00 References: <200208102013.g7AKDO5C011831@marajade.sandelman.ottawa.on.ca> <015f01c2422f$14cc1390$b9370681@BARNACLE> Date: 12 Aug 2002 16:02:21 -0400 In-Reply-To: <015f01c2422f$14cc1390$b9370681@BARNACLE> Message-ID: Lines: 17 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Scott Rose" writes: > I noticed that RSA is the only algorithm supported by the IPSECKEY RR. > Would there be a benifit to adding an algorithm field to the RDATA to > support other algorithms? In an effort of make the IPSECKEY more flexible > for other IPSec implementations that might want to use it. wouldn't that be sub-typing? > Scott -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 12 16:26:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10156 for ; Mon, 12 Aug 2002 16:26:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eLem-0002BC-00 for namedroppers-data@psg.com; Mon, 12 Aug 2002 13:19:16 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17eLeg-0002B1-00 for namedroppers@ops.ietf.org; Mon, 12 Aug 2002 13:19:10 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17eLeb-0004BJ-00; Mon, 12 Aug 2002 13:19:05 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Scott Rose" Cc: "namedroppers" Subject: Re: new draft-richardson-ipsec-rr-00 References: <200208102013.g7AKDO5C011831@marajade.sandelman.ottawa.on.ca> <015f01c2422f$14cc1390$b9370681@BARNACLE> Message-Id: Date: Mon, 12 Aug 2002 13:19:05 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I really think this is something that will get the ball rolling > on if/how to best store application keys in DNS. i wonder what will get the ball rolling on what is best to store application keys? were these discussions not supposed to be where the security folk, who don't necessarily follow dns in detail, could participate? was it not keydist@cafax.se? i would hate to have people go through another lesson of getting 10km down the road before the ietf security folk force a rethink. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 13 08:37:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09837 for ; Tue, 13 Aug 2002 08:37:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eadP-000MZj-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 05:18:51 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17eadK-000MZY-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 05:18:47 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DCIYo10201; Tue, 13 Aug 2002 19:18:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DBmpW22495; Tue, 13 Aug 2002 18:48:51 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= cc: namedroppers@ops.ietf.org Subject: Re: QType: ADDR In-Reply-To: <006e01c24217$6ee92790$0ef2a8c0@amalthea> References: <006e01c24217$6ee92790$0ef2a8c0@amalthea> <20020808183052.2D5EC18BA@thrintun.hactrn.net> <20020808005228.E48FF4B22@coconut.itojun.org> <3D5290F0.8030007@ehsco.com> <9066.1029077863@munnari.OZ.AU> <3D57BA3C.7090003@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 18:48:51 +0700 Message-ID: <22493.1029239331@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 12 Aug 2002 17:46:32 +0200 From: =?iso-8859-1?Q?Kandra_Nyg=E5rds?= Message-ID: <006e01c24217$6ee92790$0ef2a8c0@amalthea> | Are there any implementations out there that send incomplete RRsets to any | query? I have seen incomplete RRsets in the additional info back in the distant past. (That is, fill in RRs until the packet is full, and stop). One hopes that there aren't too many of those around any more. And if you do a query for A records of munnari.oz.au to a root nameserver, you'll get an incomplete RRset back - but that one is caused by a different kind of brain damage. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 13 08:37:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09852 for ; Tue, 13 Aug 2002 08:37:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eadz-000MaU-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 05:19:27 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17eadr-000MZm-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 05:19:21 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DCIqo10325; Tue, 13 Aug 2002 19:18:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DBkdW22485; Tue, 13 Aug 2002 18:46:39 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Eric A. Hall" cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: QType: ADDR In-Reply-To: <3D57BA3C.7090003@ehsco.com> References: <3D57BA3C.7090003@ehsco.com> <20020808183052.2D5EC18BA@thrintun.hactrn.net> <20020808005228.E48FF4B22@coconut.itojun.org> <3D5290F0.8030007@ehsco.com> <9066.1029077863@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 18:46:39 +0700 Message-ID: <22483.1029239199@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 12 Aug 2002 08:38:04 -0500 From: "Eric A. Hall" Message-ID: <3D57BA3C.7090003@ehsco.com> | > suggestions like the ADDR meta query, which apart from the size issue, | > is no different in the problems it causes than ANY. | | That's a hollow argument, since "the size issue" is exactly what's trying | to be avoided. You're missing the point. I know that ADDR is attempting to avoid the size problems with ANY. If that was all that mattered, then (apart from how to actually get it deployed) it would be fine. The issue is that meta queries have other problems (the ones Rob Austein pointed out) - there is simply no way to make them work properly (assuming that caches still exist - no difficulty if we were to do away with cahcing). | There's no doubt that these kind of meta-queries have issues. Yes. They simply don't work reliably. | In | particular, an ADDR qtype relocates fall-back complexity from the API side | of the resolver to the protocol side. It isn't "free", and from an | holistic perspective, it's probably a wash. There is also a new cost in | terms of fallback failure which comes from having to deal with NOTIMPL | responses in downstream agents. All this would be important, but is irrelevant, because of the more serious problem, that it simply doesn't work. (If you were to redefine it to be "any of A or AAAA" instead of "both of A and AAAA" then it would work, but wouldn't be very useful). | OTOH, the prima benefit is still there, | which is that it provides application developers an efficient alternative | (from their PoV) to qtype=any. If it did this, then yes, that would be good. But I don't think it can, as there aren't any of those application developers to provide an alternative to. Certainly qtype=addr would work as well as qtype=any (better because of the usually smaller response), but all that says is that it works as well as something which doesn't work at all. All the evidence is that use of ANY queries (other than for debugging, to answer the question, "just what data is in that cache") is falling from what small favour it had, as people are realising that it doesn't work. | > Yes. Also the idea of adding A's as additional info on an AAAA query | > is attractive. The RRset rules mean that if you have any A's, you are | > able to assume you have the full set. | | True for resolvers/servers compliant with 2181, but not earlier. No. 2181 says it can be assumed. It might be wrong, but you're allowed to assume it anyway. And it is what everyone always did. That is, ask any cache for the A records for foo.example.com, and if it has any (complete, incomplete, or super-complete) it will send you those A records. It won't go looking to see if there are more. That is, it assumes that what it has is the complete set. It was because of that (and because nothing else is reasonable anyway) that 2181 requires that only complete RRSets be included in responses (and that responses not be merged). | Also, this method relocates complexity to the servers, while *also* | preserving it on the API side of the resolver. True. It saves some traffic & delays by making the code more complex. That's not an unusual trade off. | This approach has many of | the complexities of qtype=ADDR (potential overload, DNSSEC, and so forth), No, it doesn't. Additional info has been part of the DNS from the beginning. DNSSEC copes (if necessary, by ignoring it and querying again). | and we *still* have to worry about developers issuing queries for | qtype=all. No, we don't have to worry about that, even if we do nothing. It isn't happening, and there's no sign of it suddenly starting to happen. If the doc that Rob proposed, to explain just why it doesn't work every gets written, then only someone truly ignorant would try it - their stuff ends up failing in all kinds of ways, but who cares, we cannot force anyone (market pressures excepted) from doing anything they like. | One more comment for the record, I'm not convinced that qtype=addr is | worth the pain, but I know that qtype=any is worth being avoided. Agree. And qtype=addr would be worth avoiding too, if it existed. | An | initial draft has been submitted and should be coming through the pipeline | in a day or two, but somebody else will have to do something with it. I'm | not going to advocate it. It seems to be a wash. OK, but I think we can already discard it, don't you? kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 13 12:18:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18529 for ; Tue, 13 Aug 2002 12:18:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eeB3-0000PZ-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 09:05:49 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17eeAy-0000PO-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 09:05:44 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157751 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 11:03:04 -0500 Message-ID: <3D592E51.2090906@ehsco.com> Date: Tue, 13 Aug 2002 11:05:37 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers Subject: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] Content-Type: multipart/mixed; boundary="------------000004000905040304070301" X-Spam-Status: No, hits=3.8 required=5.0 tests=TO_LOCALPART_EQ_REAL,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000004000905040304070301 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------000004000905040304070301 Content-Type: message/rfc822; name="I-D ACTION:draft-hall-qtype-addr-00.txt" Content-Disposition: attachment; filename="I-D ACTION:draft-hall-qtype-addr-00.txt" Return-Path: Received: from loki.ietf.org ([132.151.1.177] verified) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP id 157701 for lists@EHSCO.COM; Tue, 13 Aug 2002 08:31:25 -0500 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA10204 for ietf-123-outbound.02@ietf.org; Tue, 13 Aug 2002 09:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA09300 for ; Tue, 13 Aug 2002 07:28:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07689 for ; Tue, 13 Aug 2002 07:27:41 -0400 (EDT) Message-Id: <200208131127.HAA07689@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hall-qtype-addr-00.txt Date: Tue, 13 Aug 2002 07:27:41 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ADDR DNS Query-Type Author(s) : E. Hall Filename : draft-hall-qtype-addr-00.txt Pages : 7 Date : 12-Aug-02 This document defines a DNS query-type for 'all IP address resource records,' specifically including any A and AAAA resource records which may be bound to the queried domain name. This query- type would allow IPv6-aware applications to issue a single query and determine the capabilities of the remote host, rather than having to issue a second query for A resource records in those cases where no AAAA resource records are available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-00.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-hall-qtype-addr-00.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-hall-qtype-addr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020812145917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hall-qtype-addr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hall-qtype-addr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020812145917.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------000004000905040304070301-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 13 12:51:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02959 for ; Tue, 13 Aug 2002 12:51:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eemr-00016j-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 09:44:53 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17eemm-00016O-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 09:44:48 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id CBBC528B6E for ; Tue, 13 Aug 2002 16:44:47 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] In-Reply-To: Message from "Eric A. Hall" of "Tue, 13 Aug 2002 11:05:37 EST." <3D592E51.2090906@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 13 Aug 2002 16:44:47 +0000 Message-Id: <20020813164447.CBBC528B6E@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Title : The ADDR DNS Query-Type please don't. when rfc1886 was proposed, several of us strongly recommended that "A" RR's be included as additional data when a "AAAA" query was answered. in the same way and for the same reason as we include "A"'s in the additional data section when answering "MX" or "NS" queries. we were shot down. the reason given was "this is only useful during the transition period to V6, after which it's wasted complexity and wasted bandwidth." if you want this functionality, you'll have to answer that objection. (my answer to this objection was EDNS's ability to ask multiple questions in a single query, but this was shot down for a separate set of reasons.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 13 13:16:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03252 for ; Tue, 13 Aug 2002 13:16:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eecv-0000ug-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 09:34:37 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17eecq-0000uR-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 09:34:32 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157756; Tue, 13 Aug 2002 11:31:53 -0500 Message-ID: <3D593514.1000906@ehsco.com> Date: Tue, 13 Aug 2002 11:34:28 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: Rob Austein , namedroppers@ops.ietf.org Subject: Re: QType: ADDR References: <3D57BA3C.7090003@ehsco.com> <20020808183052.2D5EC18BA@thrintun.hactrn.net> <20020808005228.E48FF4B22@coconut.itojun.org> <3D5290F0.8030007@ehsco.com> <9066.1029077863@munnari.OZ.AU> <22483.1029239199@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/13/2002 6:46 AM Robert Elz wrote: > The issue is that meta queries have other problems (the ones Rob > Austein pointed out) - there is simply no way to make them work > properly (assuming that caches still exist - no difficulty if we were > to do away with cahcing). See the I-D for the mechanisms used to make it work. > All the evidence is that use of ANY queries (other than for debugging, > to answer the question, "just what data is in that cache") is falling > from what small favour it had, as people are realising that it doesn't > work. A BCP to this effect would probably be a good idea, then. A BCP telling people to read BCPs would also be a good idea. :) > No, we don't have to worry about that, even if we do nothing. It isn't > happening, and there's no sign of it suddenly starting to happen. As any designer of an idiot-proof system can tell you, God can always make a better idiot. > OK, but I think we can already discard it, don't you? I think it bears some exploration. If it proves to be useless and more trouble than it's worth, it will kill itself. Let's discuss the I-D and whether or not it will work. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 13 13:17:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03529 for ; Tue, 13 Aug 2002 13:17:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ef5o-0001Qn-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 10:04:28 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17ef5j-0001Qa-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 10:04:23 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157768; Tue, 13 Aug 2002 12:01:44 -0500 Message-ID: <3D593C13.4000301@ehsco.com> Date: Tue, 13 Aug 2002 12:04:19 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] References: <20020813164447.CBBC528B6E@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/13/2002 11:44 AM Paul Vixie wrote: > when rfc1886 was proposed, several of us strongly recommended that "A" > RR's be included as additional data when a "AAAA" query was answered. > in the same way and for the same reason as we include "A"'s in the > additional data section when answering "MX" or "NS" queries. > > we were shot down. the reason given was "this is only useful during > the transition period to V6, after which it's wasted complexity and > wasted bandwidth." I would agree with that assessment. The argument doesn't apply when it has been explicitly requested, however. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 13 13:19:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03938 for ; Tue, 13 Aug 2002 13:19:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17efBP-0001Y7-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 10:10:15 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17efBI-0001Xf-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 10:10:08 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 6841428B6E for ; Tue, 13 Aug 2002 17:10:08 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] In-Reply-To: Message from "Eric A. Hall" of "Tue, 13 Aug 2002 12:04:19 EST." <3D593C13.4000301@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 13 Aug 2002 17:10:08 +0000 Message-Id: <20020813171008.6841428B6E@as.vix.com> X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD,PORN_3 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I would agree with that assessment. The argument doesn't apply when it has > been explicitly requested, however. your proposal makes the request implicit, and runs afoul of the same "this will still be in use long after the v4->v6 transition is over" problem. if we're going to pay in complexity for something like ADDR, then let's pay the same price but get something way more general. below, see EDNS1 (expired), and note that we could very easily excerpt just the parts that deal with multiple questions in a query and push the rest of the swill into EDNS2 (as was already done when the original EDNS proposal was split into EDNS0/EDNS1): -------- DNSIND Working Group Paul Vixie INTERNET-DRAFT ISC June, 1999 Extensions to DNS (EDNS1) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a number of extensions within the Extended DNS framework defined by [EDNS0], including several new extended label types and the ability to ask multiple questions in a single request. 1 - Rationale and Scope 1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see [RFC1035]) which provides for larger message sizes, additional label types, and new message flags. 1.2. This document makes use of the EDNS extension mechanisms to add several new extended label types and message options, and the ability to ask multiple questions in a single request. Expires December 1999 [Page 1] INTERNET-DRAFT EDNS1 June 1999 2 - Affected Protocol Elements 2.1. Compression pointers are 14 bits in size and are relative to the start of the DNS Message, which can be 64KB in length. 14 bits restrict pointers to the first 16KB of the message, which makes labels introduced in the last 48KB of the message unreachable by compression pointers. A longer pointer format is needed. 2.2. DNS Messages are limited to 65535 octets in size when sent over TCP. This acts as an effective maximum on RRset size, since multiple TCP messages are only possible in the case of zone transfers. Some mechanism must be created to allow normal DNS responses (other than zone transfers) to span multiple DNS Messages when TCP is used. 2.3. Multiple queries in a question section have not been supported in DNS due the applicability of some DNS Message Header flags (such as AA) and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. Multiple questions per request are desirable, and some way of asking them must be made available. 3 - Extended Label Types 3.1. In [EDNS0], the ``0 1'' label type was specified to denote an extended label type, whose value is encoded in the lower six bits of the first octet of a label, and an extended label type of ``1 1 1 1 1 1'' was further reserved for use in future multibyte extended label types. 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended compression pointer, such that the following two octets comprise a 16-bit compression pointer in network byte order. Like the normal compression pointer, this pointer is relative to the start of the DNS Message. 3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit string label as described in [CRAW98]. 3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long local compression pointer'' as described in [KOCH98]. Expires December 1999 [Page 2] INTERNET-DRAFT EDNS1 June 1999 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags are structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | EXTENDED-RCODE | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: |MD |FM |RRD|LM | Z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As defined by [EDNS0].) VERSION Indicates the implementation level of whoever sets it. Full conformance with the draft standard version of this specification is version ``1.'' Note that both requestors and responders should set this to the highest level they implement, that responders should send back RCODE=BADVERS and that requestors should be prepared to probe using lower version numbers if they receive an RCODE=BADVERS. MD ``More data'' flag. Valid only in TCP streams where message ordering and reliability are guaranteed. This flag indicates that the current message is not the complete request or response, and should be aggregated with the following message(s) before being considered complete. Such messages are called ``segmented.'' It is an error for the RCODE (including the EXTENDED- RCODE), AA flag, or DNS Message ID to differ among segments of a segmented message. It is an error for TC to be set on any message of a segmented message. Any given RR must fit completely within a message, and all messages will both begin and end on RR boundaries. Each section in a multipart message must appear in normal message order, and each section must be complete before later sections are added. All segments of a message must be transmitted contiguously, without interleaving of other messages. FM ``First match'' flag. Notable only when multiple questions are present. If set in a request, questions will be processed in wire order and the first question whose answer would have NOERROR AND ANCOUNT>0 is treated Expires December 1999 [Page 3] INTERNET-DRAFT EDNS1 June 1999 as if it were the only question in the query message. Otherwise, questions can be processed in any order and all possible answer records will be included in the response. Response FM should be ignored by requestors. RRD ``Recursion really desired'' flag. Notable only when a request is processed by an intermediate name server (``forwarder'') who is not authoritative for the zone containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate name server can only answer using unexpired cached answers (either positive or negative) which were atomically acquired using (a) the same QTYPE or set of QTYPEs present in the current question and whose TTLs were each minimized to the smallest among them when first cached, and (b) the same FM and LM settings present in the current question. LM ``Longest match'' flag. If this flag is present in a query message, then for any question whose QNAME is not fully matched by zone or cache data, the longest trailing label-bounded suffix of the QNAME for which zone or cache data is present will be eligible for use as an answer. Note that an intervening wildcard name shall supercede this behaviour and the rules described in [RFC1034 4.3.2, 4.3.3] shall apply, except that the owner name of the answer will be the wildcard name rather than the QNAME. Any of: QTYPE=ANY, or QCLASS=ANY, or QCOUNT>1, shall be considered an error if the LM flag is set. If LM is set in a request, then LM has meaning in the response as follows: If the content of the response would have been different without the LM flag being set on the request, then the response LM will be set; If the content of the response was not determined or affected by the request LM, then the response LM will be cleared. If the request LM was not set, then the response LM is not meaningful and should be set to zero by responders and ignored by requestors. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. Expires December 1999 [Page 4] INTERNET-DRAFT EDNS1 June 1999 5 - Multiple Questions for QUERY 5.1. If QDCOUNT>1, multiple questions are present. All questions must be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. 5.2. RCODE and AA apply to all RRs in the answer section having the QNAME that is shared by all questions in the question section. AA applies to all matching answers, and will not be set unless the exact original request was processed by an authoritative server and the response forwarded in its entirety. 5.3. If a multiple question request is processed by an intermediate server and the authority server does not support multiple questions, the intermediate server must generate an answer iteratively by making multiple requests of the authority server. In this case, AA must never be set in the final answer due to lack of atomicity of the contributing authoritative responses. 5.4. If iteratively processing a multiple question request using an authority server which can only process single question requests, if any contributing request generates a SERVFAIL response, then the final response's RCODE should be SERVFAIL. 6 - Acknowledgements Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton, and Michael Graff were each instrumental in creating this specification. 7 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998 [CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,'' Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March 1998. [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. Expires December 1999 [Page 5] INTERNET-DRAFT EDNS1 June 1999 IETF DNSIND, March 1998. 8 - Author's Address Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1 650 779 7001 Expires December 1999 [Page 6] -------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 13 13:59:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11513 for ; Tue, 13 Aug 2002 13:59:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17efp5-0002Gk-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 10:51:15 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17efoz-0002GQ-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 10:51:09 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 157786; Tue, 13 Aug 2002 12:48:30 -0500 Message-ID: <3D594709.5080006@ehsco.com> Date: Tue, 13 Aug 2002 12:51:05 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] References: <20020813171008.6841428B6E@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/13/2002 12:10 PM Paul Vixie wrote: > your proposal makes the request implicit, explicit > and runs afoul of the same "this will still be in use long after the > v4->v6 transition is over" This is true if the requesting application continues to *DESIRE* both RRsets long after the transition is complete. If the requesting application only wants AAAA, then they can query for AAAA only and get that RRset alone. Nothing is imposed upon them. You can't say the same for that the ~"just include A" counter-proposal, which *is* perpetual and uninvited. > if we're going to pay in complexity for something like ADDR, > then let's pay the same price but get something way more general. I agree with this statement in principle. I'll re-read the draft and comment on it separately. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 13 16:41:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18498 for ; Tue, 13 Aug 2002 16:41:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eiIV-0004eQ-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 13:29:47 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17eiIP-0004eA-00 for namedroppers@ops.ietf.org; Tue, 13 Aug 2002 13:29:41 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17eiIP-000K7p-00; Tue, 13 Aug 2002 13:29:41 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: minutes@ietf.org Cc: namedroppers Subject: DNSSEXT Yokohama Minutes Message-Id: Date: Tue, 13 Aug 2002 13:29:41 -0700 X-Spam-Status: No, hits=3.2 required=5.0 tests=OPT_IN,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Minutes DNSEXT IETF 54, Yokohama, July 2002 ---------------------------------------------------------------------- - Agenda Bashing. ----------- No bashing. ---------------------------------------------------------------------- State of Documents (WG document discussion is minuted below) - Number of documents in the RFC editor queue. + gss-tsig is halted to December to be fixed. It violates the tsig spec + message-size Talks about A6 needs to be redone for AAAA - IETF last call. + restrict-key-for-dnssec Obvious problems. Need to be done + delegation-signer-0.8 Still being worked on. Will be part of the total docset rewrite. - Back to WG's lap + ad-is-secure-06.txt Number of issues raised by IESG. + dnssec-roadmap-05.txt No responses from the WG after comments from the AD. - Ready for last call. + dnssec-records-01.txt Was waiting for OPT-IN but will be pushed + unknow-rrs-03.txt Needs small clarification. + dnssec-intro-01.txt + rfc2536bis-dsa-01 + rfc2539bis-dhk-01 + mdns-10.txt Not clear if it is ready to go. - Not ready to go + axfr-clarify To bind specific + dnssec-opt-in Needs more work (discussed later) + obsolete-iquery-0.3.txt Few last call comments. Need a volunteer for cut-n-paste of comments. Robert Elz volunteered The document needs revision, went to last call. Elz and original author will get in touch and will go over the namedroppers archive. + dns-threats-02 More research is needed. + tkey-renewal-mode-0.2 Will be talked about - Blocked for other documents + ecc-key-01 + dhcid-rr-05 dhcid untouched, work done in dhcp drafts - Other documents + kitamura-ipv6-name-auto-reg-01 + opcode-discover-00.txt Experimental. ---------------------------------------------------------------------- Interoperability reports ------------------------ General remark: IETF interop tests do not name vendors. (see list) RFC1886 Vladimir Ksinant Two implementation are inter-operable Goals: - Advance RFC1886 Non goals: - no benchmark - Two tests: Definition of AAAA and IP6.INT Features tested: A. AAAA .... Test results - two servers where fully inter-operable - two resolvers have identical and correct behaviour - One server partially conformed Mailing list: rfc1886@nic.fr www.ipv6.6wind.com/standard/testRFC1886.nic.fr Comment: Erik Nordman: Merge to one document. DS interop test, Russ Mundy/Sam Weiler. Non complete tests of two implementation. Some of the results maybe implementation problems others may be specification problems. Need more research. Sam Weiller One issue should the TTL be chained down to effect RRs lower in the Derek Atkins: Do it within the zones. Austein question answered by Mundy: DS seem to solve the issues it was designed for: reducing parent-child interactions DNSSEC@cafax.se 'meeting' Ed Lewis lots of people are restarting their experiments. Chairs invite people to publish specific reports and write- ups of workshops and interop tests. ---------------------------------------------------------------------- WG documents discussion ----------------------- Comments where invited for all documents. Relevant comments below. draft-ietf-dnsext-ad-bit-is-secure-06.txt Rob Austein: One of the reason that this is staying is maybe that there is more information needed. Suggestion if ad=on then additional info can be found in the OPT RR. Steve Bellovin: If you trust the the entity that sets the AD bit you have to setup a trusted/secure path between the resolver and the entity. The document must add that as requirement. on the mdns-10.txt Audience: Why both mdns and discover? chairs: because they are different unknown-rrs-03.txt Rob Austein: rfc2535 down-case names in rdata. unknown-rrs-03 forbids this. This can be dealt with in DNSSEC but it needs to be clarified. draft-ietf-dnssext-opt-in-02.txt Roy Arends Changes in opt-in OPT-IN now only on delegation points. - All authoritative RR types must be signed. - The parent is not authoritative for delegation NS RRs. Changes in security model - 2535 NXT proves existence. - OPT in: lack of NXT bit means no secure delegations. OPT-IN Corner Cases. No document yet. - OPT-IN vs AD-bit + AD bit must be cleared on a negative OPT-IN response. + This need clarification Caching Responses - NXT+SIG RRs are statements on security of a response. + Do not cache them individually. + Cache them as properties of a response. There are a number of a caching problems. The issues are really implementation issues. - OPT-IN NXT should really only be cached as a property of another RR. Concerns raised DNSSEC is already complex. Does OPT-IN justify the added complexity. Where is the resolver implementation? If DS turns out to be stable there is little time for OPT-in left. There is a opt-in resolver (and server) implementation. Expected to be in bind soon. There are implementations of opt-in: 2 servers and 1 resolver Nordmark: Is anybody working on the additional implementation complexity? Conrad: OPT in is implemented according to 01. The caching behaviour has not be implemented. Vixie: ISC has no policy on OPT in. Good code will be put in. Austein: Treading the NXT RRs as properties of RRset. There are issues with the TTL. Bush: Current discussion is around corner cases. Both DS and OPT-IN need flag-date; DS signing testing will continue. By and of August there should be a document set for DS. Then estimate how long additional OPT-IN would take. So mid September an assessment will be made if to OPT-IN will be going into the document set. dnsext-dns-threads-01 Thread model not finished yet. Bellovin: There are a lot of '*' MX records. Typos can lead to email going to the wrong place. That is a problem that should be dealt with. Conrad: Implementing the validation was to difficult with bit-string labels. The solution needs on-line signing. There is an implementation that does that now bit-stings have gone. Atkins: tkey-renewal-01 Yuji Kamite presented the draft changes. - renewal process a phase 2 process - defined adoption message to begin using new key. Waiting for IANA considerations need - Only DH will not use GSS. DH will be mandatory no comments. dnsext-dhcid-rr-05 Ted Lemon: DHCID language is correct, DHCPD will be modified; redundant text will be removed. kitamura-ipv6-name-auto-reg-01 Kitamura San presented abstract of draft There is an implementation. Keep discussing and revising. Goal is informational RFC. No comments. draft-dnsext-opcode-discover-00.txt Bill Manni From owner-namedroppers@ops.ietf.org Tue Aug 13 17:18:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20868 for ; Tue, 13 Aug 2002 17:18:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eix2-0005Pq-00 for namedroppers-data@psg.com; Tue, 13 Aug 2002 14:11:40 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17eiwx-0005Pe-00; Tue, 13 Aug 2002 14:11:36 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA24702; Tue, 13 Aug 2002 17:11:33 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA16791; Tue, 13 Aug 2002 17:09:14 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA25462; Tue, 13 Aug 2002 17:04:03 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA00640; Tue, 13 Aug 2002 17:04:02 -0400 (EDT) To: Randy Bush Cc: minutes@ietf.org, namedroppers Subject: Re: DNSSEXT Yokohama Minutes References: From: Derek Atkins Date: 13 Aug 2002 17:04:02 -0400 In-Reply-To: Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_RELAYS_ORDB_ORG,FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Randy Bush writes: > dnsext-dns-threads-01 this should be "threats", not "threads".. Same change for the next couple paragraphs. > Thread model not finished yet. > > Bellovin: There are a lot of '*' MX records. > Typos can lead to email going to the wrong place. That is a > problem that should be dealt with. > > > Conrad: Implementing the validation was to difficult with bit-string > labels. The solution needs on-line signing. There is an > implementation that does that now bit-stings have gone. > > Atkins: My comment was that one approach would be shift the burden of *-expansion from the server to the client.. Sign the actual "*.example. IN MX" record and send that in the response; let the client resolver do the work to convert that into the query-name. > Notes by Olaf Kolkman with help from Scott Rose -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 14 10:28:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10716 for ; Wed, 14 Aug 2002 10:28:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17eyrL-0000Tj-00 for namedroppers-data@psg.com; Wed, 14 Aug 2002 07:10:51 -0700 Received: from pigeon.verisign.com ([65.205.251.71]) by psg.com with esmtp (Exim 3.36 #1) id 17eyrH-0000TV-00; Wed, 14 Aug 2002 07:10:47 -0700 Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g7EE5FeD015070; Wed, 14 Aug 2002 07:05:15 -0700 (PDT) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Aug 2002 07:12:33 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40D813F3D@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: Randy Bush , minutes@ietf.org Cc: namedroppers Subject: RE: DNSSEXT Yokohama Minutes Date: Wed, 14 Aug 2002 07:12:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=3.2 required=5.0 tests=OPT_IN,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Bush: Current discussion is around corner cases. Both DS and > OPT-IN need flag-date; DS signing testing will continue. By > and of August there should be a document set for DS. Then > estimate how long additional OPT-IN would take. So mid > September an assessment will be made if to OPT-IN will be > going into the document set. Randy, DNSSEC is undeployable without the NXT record being fixed. Filibustering will do absolutely nothing to change this fact. I will start the appeals process if any attempt is made to pre-empt OPTIN by announcing a flag date on DS while OPTIN is blocked by political tactics. Phill (Speaking only for myself of course) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 14 15:53:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23020 for ; Wed, 14 Aug 2002 15:53:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17f3yX-000Aj4-00 for namedroppers-data@psg.com; Wed, 14 Aug 2002 12:38:37 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17f3yN-000Aif-00 for namedroppers@ops.ietf.org; Wed, 14 Aug 2002 12:38:27 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 158146; Wed, 14 Aug 2002 14:35:48 -0500 Message-ID: <3D5AB1AF.9090005@ehsco.com> Date: Wed, 14 Aug 2002 14:38:23 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] References: <20020813171008.6841428B6E@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/13/2002 12:10 PM Paul Vixie wrote: > if we're going to pay in complexity for something like ADDR, then let's > pay the same price but get something way more general. below, see EDNS1 > (expired), and note that we could very easily excerpt just the parts > that deal with multiple questions in a query > 5 - Multiple Questions for QUERY > > 5.1. If QDCOUNT>1, multiple questions are present. All questions must > be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. > It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. > > 5.2. RCODE and AA apply to all RRs in the answer section having the > QNAME that is shared by all questions in the question section. AA > applies to all matching answers, and will not be set unless the exact > original request was processed by an authoritative server and the > response forwarded in its entirety. > > 5.3. If a multiple question request is processed by an intermediate > server and the authority server does not support multiple questions, > the intermediate server must generate an answer iteratively by making > multiple requests of the authority server. In this case, AA must never > be set in the final answer due to lack of atomicity of the > contributing authoritative responses. > > 5.4. If iteratively processing a multiple question request using an > authority server which can only process single question requests, if > any contributing request generates a SERVFAIL response, then the final > response's RCODE should be SERVFAIL. This needs a lot more discussion and fleshing out. Are partial answers acceptable (as with a cache that has temporarily lost external connectivity)? Is it possible to indicate positive answers, NODATA and referrals in the same message? How would the "recursion really desired" flag interact with all of this? In general, I think it is a good idea, but I'm not completely convinced that it's possible. It is not nearly as simple as QTYPEADDR, but it certainly does offer longer term rewards due to its generalized nature, if it is feasible at all. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 14 21:28:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29763 for ; Wed, 14 Aug 2002 21:28:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17f9GC-000KCz-00 for namedroppers-data@psg.com; Wed, 14 Aug 2002 18:17:12 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17f9G7-000KCn-00 for namedroppers@ops.ietf.org; Wed, 14 Aug 2002 18:17:07 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 9FFF628B6E for ; Thu, 15 Aug 2002 01:17:06 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] In-Reply-To: Message from "Eric A. Hall" of "Wed, 14 Aug 2002 14:38:23 EST." <3D5AB1AF.9090005@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 15 Aug 2002 01:17:06 +0000 Message-Id: <20020815011706.9FFF628B6E@as.vix.com> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > if we're going to pay in complexity for something like ADDR, then let's > > pay the same price but get something way more general. below, see EDNS1 > > (expired), and note that we could very easily excerpt just the parts > > that deal with multiple questions in a query > > > 5 - Multiple Questions for QUERY > > ... > > This needs a lot more discussion and fleshing out. i've been waiting several years got someone to discuss this with. thank you! > Are partial answers acceptable (as with a cache that has temporarily > lost external connectivity)? this depends on the setting of RRD and whether iteration is being done. if iteration is being done because the authority server is known not to handle QDCOUNT>1, then any SERVFAIL causes the underlying QDCOUNT>1 question to be answered with SERVFAIL. temporary loss of connectivity signals SERVFAIL. (i consider the document to already be clear on this point.) > Is it possible to indicate positive answers, NODATA yes. if you get some answer RR's matching some of the QTYPEs but no RR's matching one or more of the QTYPEs then you know the missing ones are NODATA. (i will upgrade the wording on this point.) > and referrals in the same message? no. if there are NS RR's then there will be a referral, no matter what other RR's are also present. if there are no NS RR's then the answer will not be a referral, no matter what RR types are present and what QTYPEs are present. (i will upgrade the wording on this point.) > How would the "recursion really desired" flag interact with all of this? only in regards to yout first question above ("partial answers acceptable?") > In general, I think it is a good idea, but I'm not completely convinced > that it's possible. It is not nearly as simple as QTYPEADDR, but it > certainly does offer longer term rewards due to its generalized nature, if > it is feasible at all. i'll take that as an invitation to split EDNS1-old into EDNS1-current and EDNS2-current, where EDNS2-current will be all the stuff in EDNS1-old that's not directly competitive to QTYPE=ADDR. (that's how EDNS0 was born and EDNS1 was shelved... but then there was EDNS0.5, appears to be on track to /dev/null) (done. updated EDNS1 and EDNS2 are about to be sent to the drafts editor.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 14 21:31:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29810 for ; Wed, 14 Aug 2002 21:31:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17f9Kj-000KIK-00 for namedroppers-data@psg.com; Wed, 14 Aug 2002 18:21:53 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17f9KW-000KI2-00 for namedroppers@ops.ietf.org; Wed, 14 Aug 2002 18:21:40 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B84F828B6E; Thu, 15 Aug 2002 01:21:39 +0000 (GMT) From: Paul Vixie To: internet-drafts@ietf.org Cc: namedroppers@ops.ietf.org Subject: draft-dnsext-edns1-04.txt X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 15 Aug 2002 01:21:39 +0000 Message-Id: <20020815012139.B84F828B6E@as.vix.com> X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSIND Working Group Paul Vixie INTERNET-DRAFT ISC August, 2002 Extensions to DNS (EDNS1) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a number of extensions within the Extended DNS framework defined by [EDNS0], including several new extended label types and the ability to ask multiple questions in a single request. 1 - Rationale and Scope 1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see [RFC1035]) which provides for larger message sizes, additional label types, and new message flags. 1.2. This document makes use of the EDNS extension mechanisms to add the ability to ask multiple questions in a single request. Expires March 2003 [Page 1] INTERNET-DRAFT EDNS1 August, 2002 2 - Affected Protocol Elements 2.1. Multiple queries in a question section have not been supported in DNS due the applicability of some DNS Message Header flags (such as AA) and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. Multiple questions per request are desirable, and some way of asking them must be made available. 3 - OPT pseudo-RR Flags and Options 3.1. The extended RCODE and flags are structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | extended-rcode | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: |md |FM |RRD|lm | z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ VERSION Indicates the implementation level of whoever sets it. Full conformance with the draft standard version of this specification is version ``1.'' Note that both requestors and responders should set this to the highest level they implement, that responders should send back RCODE=BADVERS and that requestors should be prepared to probe using lower version numbers if they receive an RCODE=BADVERS. FM ``First match'' flag. Notable only when multiple questions are present. If set in a request, questions will be processed in wire order and the first question whose answer would have NOERROR AND ANCOUNT>0 is treated as if it were the only question in the query message. Otherwise, questions can be processed in any order and all possible answer records will be included in the response. Response FM should be ignored by requestors. RRD ``Recursion really desired'' flag. Notable only when a request is processed by an intermediate name server (``forwarder'') who is not authoritative for the zone containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate name server can only answer using unexpired cached answers (either positive or negative) which were atomically acquired using (a) the same QTYPE or set of QTYPEs present in the current question and whose TTLs were each minimized to the Expires March 2003 [Page 2] INTERNET-DRAFT EDNS1 August, 2002 smallest among them when first cached, and (b) the same FM and LM settings present in the current question. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. 4 - Multiple Questions for QUERY 4.1. If QDCOUNT>1, multiple questions are present. All questions must be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. 4.2. RCODE and AA apply to all RRs in the answer section having the QNAME that is shared by all questions in the question section. AA applies to all matching answers, and will not be set unless the exact original request was processed by an authoritative server and the response forwarded in its entirety. 4.3. If a multiple question request is processed by an intermediate server and the authority server does not support multiple questions, the intermediate server must generate an answer iteratively by making multiple requests of the authority server. In this case, AA must never be set in the final answer due to lack of atomicity of the contributing authoritative responses. 4.4. If iteratively processing a multiple question request using an authority server which can only process single question requests, if any contributing request generates a SERVFAIL response, then the final response's RCODE should be SERVFAIL. 4.5. An authority server processing a query for which QDCOUNT>1 will respond with a delegation or referral if any of the multiple QTYPEs present would yield such a response when QDCOUNT==1. 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs where QDCOUNT>1 if the response contains no RRs of that type but some RRs for one of the other QTYPEs present. Expires March 2003 [Page 3] INTERNET-DRAFT EDNS1 August, 2002 5 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 6 - Author's Address Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1.650.779.7001 Expires March 2003 [Page 4] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 14 21:31:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29826 for ; Wed, 14 Aug 2002 21:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17f9Lf-000KKs-00 for namedroppers-data@psg.com; Wed, 14 Aug 2002 18:22:51 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17f9LW-000KKN-00 for namedroppers@ops.ietf.org; Wed, 14 Aug 2002 18:22:42 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id C4AE52984A; Thu, 15 Aug 2002 01:22:39 +0000 (GMT) From: Paul Vixie To: internet-drafts@ietf.org Cc: namedroppers@ops.ietf.org Subject: draft-dnsext-edns2-01.txt X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 15 Aug 2002 01:22:39 +0000 Message-Id: <20020815012239.C4AE52984A@as.vix.com> X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk DNSEXT Working Group Paul Vixie INTERNET-DRAFT ISC August, 2002 Extensions to DNS (EDNS2) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a number of extensions within the Extended DNS framework defined by [RFC2671] and [EDNS1], including several new extended label types. 1 - Rationale and Scope 1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see [RFC1035]) which provides for larger message sizes, additional label types, and new message flags. 1.2. This document makes use of the EDNS extension mechanisms to add several new extended label types and message options. Expires March 2003 [Page 1] INTERNET-DRAFT EDNS2 August, 2002 2 - Affected Protocol Elements 2.1. Compression pointers are 14 bits in size and are relative to the start of the DNS Message, which can be 64KB in length. 14 bits restrict pointers to the first 16KB of the message, which makes labels introduced in the last 48KB of the message unreachable by compression pointers. A longer pointer format is needed. 2.2. DNS Messages are limited to 65535 octets in size when sent over TCP. This acts as an effective maximum on RRset size, since multiple TCP messages are only possible in the case of zone transfers. Some mechanism must be created to allow normal DNS responses (other than zone transfers) to span multiple DNS Messages when TCP is used. 3 - Extended Label Types 3.1. In [EDNS0], the ``0 1'' label type was specified to denote an extended label type, whose value is encoded in the lower six bits of the first octet of a label, and an extended label type of ``1 1 1 1 1 1'' was further reserved for use in future multibyte extended label types. 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended compression pointer, such that the following two octets comprise a 16-bit compression pointer in network byte order. Like the normal compression pointer, this pointer is relative to the start of the DNS Message. 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags are structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | extended-rcode | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: |MD |fm |rrd|LM | z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ VERSION Indicates the implementation level of whoever sets it. Full conformance with the draft standard version of this specification is version ``2.'' Note that both requestors and responders should set this to the highest level they implement, that responders should send back RCODE=BADVERS and that requestors should be prepared to probe using lower version Expires March 2003 [Page 2] INTERNET-DRAFT EDNS2 August, 2002 numbers if they receive an RCODE=BADVERS. MD ``More data'' flag. Valid only in TCP streams where message ordering and reliability are guaranteed. This flag indicates that the current message is not the complete request or response, and should be aggregated with the following message(s) before being considered complete. Such messages are called ``segmented.'' It is an error for the RCODE (including the EXTENDED-RCODE), AA flag, or DNS Message ID to differ among segments of a segmented message. It is an error for TC to be set on any message of a segmented message. Any given RR must fit completely within a message, and all messages will both begin and end on RR boundaries. Each section in a multipart message must appear in normal message order, and each section must be complete before later sections are added. All segments of a message must be transmitted contiguously, without interleaving of other messages. LM ``Longest match'' flag. If this flag is present in a query message, then for any question whose QNAME is not fully matched by zone or cache data, the longest trailing label-bounded suffix of the QNAME for which zone or cache data is present will be eligible for use as an answer. Note that an intervening wildcard name shall supercede this behaviour and the rules described in [RFC1034 4.3.2, 4.3.3] shall apply, except that the owner name of the answer will be the wildcard name rather than the QNAME. Any of: QTYPE=ANY, or QCLASS=ANY, or QCOUNT>1, shall be considered an error if the LM flag is set. If LM is set in a request, then LM has meaning in the response as follows: If the content of the response would have been different without the LM flag being set on the request, then the response LM will be set; If the content of the response was not determined or affected by the request LM, then the response LM will be cleared. If the request LM was not set, then the response LM is not meaningful and should be set to zero by responders and ignored by requestors. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. Expires March 2003 [Page 3] INTERNET-DRAFT EDNS2 August, 2002 5 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 6 - Author's Address Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1.650.779.7001 Expires March 2003 [Page 4] -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 15 00:30:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03849 for ; Thu, 15 Aug 2002 00:30:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17fC85-000OG9-00 for namedroppers-data@psg.com; Wed, 14 Aug 2002 21:21:01 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17fC7w-000OFy-00 for namedroppers@ops.ietf.org; Wed, 14 Aug 2002 21:20:52 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 158220; Wed, 14 Aug 2002 23:18:13 -0500 Message-ID: <3D5B2C20.10504@ehsco.com> Date: Wed, 14 Aug 2002 23:20:48 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] References: <20020815011706.9FFF628B6E@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/14/2002 8:17 PM Paul Vixie wrote: >> Are partial answers acceptable (as with a cache that has temporarily >> lost external connectivity)? > > this depends on the setting of RRD and whether iteration is being done. > if iteration is being done because the authority server is known not to > handle QDCOUNT>1, then any SERVFAIL causes the underlying QDCOUNT>1 > question to be answered with SERVFAIL. temporary loss of connectivity > signals SERVFAIL. I realized the error condition about five minutes later, and was wondering if I'd get pants'd for it. Thanks for keeping the faith alive. Here is the scenario I want to trip: client asks for A, AAAA and MX server has A cached server has AAAAA NODATA cached server has no information about MX and can't/won't go get it It is possible that the server would have learned A and AAAA through some other means (such as glue data, although this doesn't really work with the NODATA part), while also refusing to fetch the MX RR. Signalling the difference between NODATA and referral is pretty difficult, since the client would interpret the referral as being applicable to both AAAA and MX equally. This may be okay, since the only likely harm would be a larger followup question. Tell me it's okay. > i'll take that as an invitation to split EDNS1-old into EDNS1-current > and EDNS2-current, where EDNS2-current will be all the stuff in > EDNS1-old that's not directly competitive to QTYPE=ADDR. You lost me. I'll read the new stuff and try to catch up. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 15 02:45:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15171 for ; Thu, 15 Aug 2002 02:45:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17fEAw-0001Vh-00 for namedroppers-data@psg.com; Wed, 14 Aug 2002 23:32:06 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17fEAq-0001VU-00 for namedroppers@ops.ietf.org; Wed, 14 Aug 2002 23:32:00 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id F3CB028B6E for ; Thu, 15 Aug 2002 06:31:59 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] In-Reply-To: Message from "Eric A. Hall" of "Wed, 14 Aug 2002 23:20:48 EST." <3D5B2C20.10504@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Thu, 15 Aug 2002 06:31:59 +0000 Message-Id: <20020815063159.F3CB028B6E@as.vix.com> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Here is the scenario I want to trip: > > client asks for A, AAAA and MX > server has A cached > server has AAAA NODATA cached > server has no information about MX and can't/won't go get it > > It is possible that the server would have learned A and AAAA through some > other means (such as glue data, although this doesn't really work with the > NODATA part), while also refusing to fetch the MX RR. first off, the promiscuous-cache model practiced by bind4/bind8 is *wrong*, and glue should not be generally cached nor ever upgraded to an answer. glue is like the evil slime that sticks to your shoes in a movie theater, and should only be reused if to satisfy requirements for additional data during the marshalling of an answer to the same query whose original forwarding caused that glue to be received in the first place. that's not germane to the subject, but i didn't want to let the moment pass. second, if the client can't or won't go get it, that means the response to a normal query (QDCOUNT=1, QTYPE=MX) would be SERVFAIL, which according to both the old (1999) and new (today) EDNS1 documents, would cause SERVFAIL to be signalled to the QDCOUNT>1 requestor. so in order to go deeper on this one, you'll have to explain what you mean, exactly, by "can't" and/or "won't". > Signalling the difference between NODATA and referral is pretty difficult, > since the client would interpret the referral as being applicable to both > AAAA and MX equally. This may be okay, since the only likely harm would be > a larger followup question. Tell me it's okay. it's ok, but not for that reason. a referral can only come from an authority server. the section of the document you are worrying about is talking about intermediate recursive/caching servers ("full resolvers" in RFC1035 lingo.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 15 10:53:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28752 for ; Thu, 15 Aug 2002 10:53:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17fLkX-000BWJ-00 for namedroppers-data@psg.com; Thu, 15 Aug 2002 07:37:21 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17fLkT-000BW7-00 for namedroppers@ops.ietf.org; Thu, 15 Aug 2002 07:37:17 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 158271; Thu, 15 Aug 2002 09:34:38 -0500 Message-ID: <3D5BBC97.4090100@ehsco.com> Date: Thu, 15 Aug 2002 09:37:11 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers CC: Paul Vixie Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] References: <20020815063159.F3CB028B6E@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.5 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/15/2002 1:31 AM Paul Vixie wrote: > first off, the promiscuous-cache model practiced by bind4/bind8 is > *wrong* It still happens with bind9x. I'll send you a dig-dump offlist. > second, if the client can't or won't go get it, that means the response > to a normal query (QDCOUNT=1, QTYPE=MX) would be SERVFAIL In the second example, "won't get it" was meant to imply RA=0 -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 15 19:48:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20281 for ; Thu, 15 Aug 2002 19:48:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17fU3t-0003k4-00 for namedroppers-data@psg.com; Thu, 15 Aug 2002 16:29:53 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17fU3j-0003jq-00 for namedroppers@ops.ietf.org; Thu, 15 Aug 2002 16:29:43 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA22974; Thu, 15 Aug 2002 19:29:39 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA17097; Thu, 15 Aug 2002 19:26:45 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA23435; Thu, 15 Aug 2002 19:26:43 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id TAA26047; Thu, 15 Aug 2002 19:26:43 -0400 Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] From: Greg Hudson To: Paul Vixie Cc: namedroppers In-Reply-To: <20020813164447.CBBC528B6E@as.vix.com> References: <20020813164447.CBBC528B6E@as.vix.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 15 Aug 2002 19:26:43 -0400 Message-Id: <1029454003.3694.157.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2002-08-13 at 12:44, Paul Vixie wrote: > we were shot down. the reason given was "this is only useful during the > transition period to V6, after which it's wasted complexity and wasted > bandwidth." That's pretty funny. God forbid that we should write code which will only be useful for two or three decades. (Wasted bandwidth? It's only wasted bandwidth if there are A records to return, right?) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 15 22:51:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24239 for ; Thu, 15 Aug 2002 22:51:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17fWzZ-000JVW-00 for namedroppers-data@psg.com; Thu, 15 Aug 2002 19:37:37 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17fWzQ-000JUO-00 for namedroppers@ops.ietf.org; Thu, 15 Aug 2002 19:37:28 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 0458128B6E for ; Fri, 16 Aug 2002 02:37:28 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: [Fwd: I-D ACTION:draft-hall-qtype-addr-00.txt] In-Reply-To: Message from Greg Hudson of "15 Aug 2002 19:26:43 -0400." <1029454003.3694.157.camel@error-messages.mit.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 16 Aug 2002 02:37:27 +0000 Message-Id: <20020816023728.0458128B6E@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > we were shot down. the reason given was "this is only useful during the > > transition period to V6, after which it's wasted complexity and wasted > > bandwidth." > > That's pretty funny. God forbid that we should write code which will > only be useful for two or three decades. > > (Wasted bandwidth? It's only wasted bandwidth if there are A records to > return, right?) at that time we were in an environment where any one person could say "no" and have it stick, but no set of people could be found who could say "yes" and have it stick. come to think of it, we're still in that environment. (betcha none of this matters, we'll have to wait and see what the dns directorate wants to do, or rather, doesn't want to not do, or however that all works now.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 16 08:05:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12666 for ; Fri, 16 Aug 2002 08:05:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ffZa-0007rc-00 for namedroppers-data@psg.com; Fri, 16 Aug 2002 04:47:22 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17ffZU-0007rR-00 for namedroppers@ops.ietf.org; Fri, 16 Aug 2002 04:47:16 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11978; Fri, 16 Aug 2002 07:45:53 -0400 (EDT) Message-Id: <200208161145.HAA11978@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-edns1-03.txt Date: Fri, 16 Aug 2002 07:45:53 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Extensions to DNS (EDNS1) Author(s) : P. Vixie Filename : draft-ietf-dnsext-edns1-03.txt Pages : 4 Date : 15-Aug-02 This document specifies a number of extensions within the Extended DNS framework defined by [EDNS0], including several new extended label types and the ability to ask multiple questions in a single request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns1-03.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-edns1-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-edns1-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020815150755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-edns1-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-edns1-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020815150755.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 16 08:27:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13184 for ; Fri, 16 Aug 2002 08:27:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ffzg-0008XQ-00 for namedroppers-data@psg.com; Fri, 16 Aug 2002 05:14:20 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17ffzM-0008Ww-00 for namedroppers@ops.ietf.org; Fri, 16 Aug 2002 05:14:00 -0700 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g7GCD7h56855 for ; Fri, 16 Aug 2002 08:13:08 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020815093727.00bb2f60@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 15 Aug 2002 10:30:23 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSEXT WGLC: Unknown types support Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.7 required=5.0 tests=DATE_IN_PAST_12_24 version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Extending the Domain Name System with new Resource Record types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt This draft is slated to be published as informational, if you disagree with that please state why in your response. The Last call completes on August 29'th 2002. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 16 08:28:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13218 for ; Fri, 16 Aug 2002 08:28:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ffzW-0008XH-00 for namedroppers-data@psg.com; Fri, 16 Aug 2002 05:14:10 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17ffzJ-0008Wg-00 for namedroppers@ops.ietf.org; Fri, 16 Aug 2002 05:13:57 -0700 Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g7GCD1h56849 for ; Fri, 16 Aug 2002 08:13:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020815093803.01499be8@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 15 Aug 2002 10:29:18 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: DNSEXT WGLC: Opcode-discover-00 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.7 required=5.0 tests=DATE_IN_PAST_12_24 version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This starts a 2 week last call for this document, the document is slated to be published as EXPERIMENTAL. http://www.ietf.org/internet-drafts/draft-dnsext-opcode-discover-00.txt This document specifies a new opcode that is used to discover DNS servers within the multicast scope of the address sent to. The authors main focus is to get a IANA assigned opcode for experimentation, does this document provide enough technical details for the framework to be experimented with. This working group last call completes on August 30'th 2002. Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 16 08:28:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13243 for ; Fri, 16 Aug 2002 08:28:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ffzO-0008X4-00 for namedroppers-data@psg.com; Fri, 16 Aug 2002 05:14:02 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17ffzJ-0008Wh-00 for namedroppers@ops.ietf.org; Fri, 16 Aug 2002 05:13:57 -0700 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g7GCD1h56850 for ; Fri, 16 Aug 2002 08:13:03 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020815095429.014dff78@localhost> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 16 Aug 2002 08:13:08 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= Gudmundsson/DNSEXT co-chair Subject: DNSSEC editing process (Periodic posting) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13243 The DNSEXT working group has started a rewrite of the DNSSEC specification into a documents that better reflect the protocol and allow a test plan to be constructed from the specification. To accomplish this, a team of volunteers has been formed to generate the documents. The document editing team is tasked with documenting the protocol as specified in RFC's generated by this group and Internet Drafts that the working group has reach consensus on. The editors are NOT ALLOWED to make ANY changes in the protocol. If clarifications are needed due to conflicting definitions, imprecise specification, omission or other reason, the editors MUST bring these issues to the attention of the working group on the namedroppers mailing list. To assist the editors, a small group of people with good understanding of DNSSEC have been recruited to review document drafts and answer questions that the editors have. For simplified communication a mailing list has been created, anyone can send messages to the editors via this mailing list DNSSEC-editors@east.isi.edu. Archive of this mailing list will be made available. Please send minor corrections, comments, suggestions about the DNSSECbis documents to dnssec-editors@east.isi.edu. All major issues should be brought up on namedroppers, editors MAY forward any correspondence to namedroppers, without asking permission, if they deem the issues raised require wider attention. DNSEXT co-chair Ólafur Guðmundsson approves new members on the dnssec-editors malling list. DNSSEC-editors is NOT a design group, it is a document maintenance group. The current members of the mailing list are: Editors: Dan Massey Scott Rose Matt Larson Roy Arends Advisors: Donald Eastlake Brian Wellington Edward Lewis Randy Bush Olafur Gudmundsson The current set of documents produced by dnssec-editors is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-02.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-records-01.txt Soon to be published: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-protocol-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: From owner-namedroppers@ops.ietf.org Mon Aug 19 11:47:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06562 for ; Mon, 19 Aug 2002 11:47:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17goO5-000IIk-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 08:24:13 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17goNw-000IIV-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 08:24:04 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 158865 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 10:21:26 -0500 Message-ID: <3D610D8F.6020002@ehsco.com> Date: Mon, 19 Aug 2002 10:23:59 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: namedroppers Subject: qtype addr scorecard References: <3D592E51.2090906@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.5 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit End-of-thread summary. Based on arguments made so far, a qtype ADDR would be provably better than the existing qtype ALL, and would also be bettter than the include-A-with-AAAA alternative. A qtype ADDR would be slightly better than distinct queries for AAAA followed by A, although it would be a disadvantage during any transition period, and the resulting savings are small enough to make the benefit unworthy of the cost. However, if a sufficient number of people end up using qtype ALL as an alternative to double lookups, the transition costs of qtype ADDR will have been worth it. Paul's proposal for multiple questions is provably better due to its generalized nature (capable of asking for MX as well as AAAA+A, for example). That spec doesn't currently address the weird scenarios that can occur from multiple answer types within a single message so I don't think it's viable in it's current form. Once those descriptions and rules were added, however, I would endorse it completely. Under the assumption that this work will eventually happen, and given that it is more flexible, I think that's where any subsequent discussion should focus. IMO, of course. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 19 12:41:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08825 for ; Mon, 19 Aug 2002 12:41:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17gpRl-000JoE-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 09:32:05 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17gpRa-000Jo1-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 09:31:54 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 208B728B6C for ; Mon, 19 Aug 2002 16:31:54 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: qtype addr scorecard In-Reply-To: Message from "Eric A. Hall" of "Mon, 19 Aug 2002 10:23:59 EST." <3D610D8F.6020002@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 19 Aug 2002 16:31:54 +0000 Message-Id: <20020819163154.208B728B6C@as.vix.com> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > [EDNS1] doesn't currently address the weird scenarios that can occur > from multiple answer types within a single message so I don't think > it's viable in it's current form. I thought that I had addressed your concerns in the rerelease of EDNS1 ("August 2002" version) but I stand ready to make any further corrections. Please let me know what clarifications or changes you think are needed. Since it's only four pages I will include it here. Note that this shows one correction received privately, which was that I hadn't updated the flags picture to account for the DO bit. I've also reset the draft name as directed by the drafts editor. -------- DNSIND Working Group Paul Vixie INTERNET-DRAFT ISC August, 2002 Extensions to DNS (EDNS1) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies an extension within the Extended DNS framework defined by [RFC2671], providing the ability to ask multiple questions in a single request. 1 - Rationale and Scope 1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see [RFC1035]) which provides for larger message sizes, additional label types, and new message flags. 1.2. This document makes use of the EDNS extension mechanisms to add the ability to ask multiple questions in a single request. Expires March 2003 [Page 1] INTERNET-DRAFT EDNS1 August, 2002 2 - Affected Protocol Elements 2.1. Multiple queries in a question section have not been supported in DNS due the applicability of some DNS Message Header flags (such as AA) and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. Multiple questions per request are desirable, and some way of asking them must be made available. 3 - OPT pseudo-RR Flags and Options 3.1. The extended RCODE and flags are structured as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | extended-rcode | VERSION | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: |do |FM |RRD| z | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ VERSION Indicates the implementation level of whoever sets it. Full conformance with the draft standard version of this specification is version ``1.'' Note that both requestors and responders should set this to the highest level they implement, that responders should send back RCODE=BADVERS and that requestors should be prepared to probe using lower version numbers if they receive an RCODE=BADVERS. FM ``First match'' flag. Notable only when multiple questions are present. If set in a request, questions will be processed in wire order and the first question whose answer would have NOERROR AND ANCOUNT>0 is treated as if it were the only question in the query message. Otherwise, questions can be processed in any order and all possible answer records will be included in the response. Response FM should be ignored by requestors. RRD ``Recursion really desired'' flag. Notable only when a request is processed by an intermediate name server (``forwarder'') who is not authoritative for the zone containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate name server can only answer using unexpired cached answers (either positive or negative) which were atomically acquired using (a) the same QTYPE or set of QTYPEs present in the current question and whose TTLs were each minimized to the Expires March 2003 [Page 2] INTERNET-DRAFT EDNS1 August, 2002 smallest among them when first cached, and (b) the same FM and LM settings present in the current question. Z Set to zero by senders and ignored by receivers, unless modified in a subsequent specification. 4 - Multiple Questions for QUERY 4.1. If QDCOUNT>1, multiple questions are present. All questions must be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. 4.2. RCODE and AA apply to all RRs in the answer section having the QNAME that is shared by all questions in the question section. AA applies to all matching answers, and will not be set unless the exact original request was processed by an authoritative server and the response forwarded in its entirety. 4.3. If a multiple question request is processed by an intermediate server and the authority server does not support multiple questions, the intermediate server must generate an answer iteratively by making multiple requests of the authority server. In this case, AA must never be set in the final answer due to lack of atomicity of the contributing authoritative responses. 4.4. If iteratively processing a multiple question request using an authority server which can only process single question requests, if any contributing request generates a SERVFAIL response, then the final response's RCODE should be SERVFAIL. 4.5. An authority server processing a query for which QDCOUNT>1 will respond with a delegation or referral if any of the multiple QTYPEs present would yield such a response when QDCOUNT==1. 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs where QDCOUNT>1 if the response contains no RRs of that type but some RRs for one of the other QTYPEs present. Expires March 2003 [Page 3] INTERNET-DRAFT EDNS1 August, 2002 5 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671, IETF DNSIND, September 1998 6 - Author's Address Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063 +1.650.779.7001 Expires March 2003 [Page 4] -------- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 19 13:14:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09842 for ; Mon, 19 Aug 2002 13:14:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17gptS-000KWp-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 10:00:42 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17gptM-000KWb-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 10:00:37 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7JH0R117240; Tue, 20 Aug 2002 00:00:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7JGfIW26666; Mon, 19 Aug 2002 23:41:18 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Eric A. Hall" cc: namedroppers Subject: Re: qtype addr scorecard In-Reply-To: <3D610D8F.6020002@ehsco.com> References: <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Aug 2002 23:41:18 +0700 Message-ID: <26664.1029775278@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 19 Aug 2002 10:23:59 -0500 From: "Eric A. Hall" Message-ID: <3D610D8F.6020002@ehsco.com> | End-of-thread summary. Based on arguments made so far, a qtype ADDR would | be provably better than the existing qtype ALL, Two comments on that - first, from 1035, the qtype you mean (value 255) is * not ALL. If it is to be represented with a name, using ANY would be a better, as that's what it actually retrieves. And second, being better than that qtype (however it is styled) is precisely equivalent to being better than nothing, as qtype * doesn't work at all for this, or any other non-debugging purpose. | and would also be bettter than the include-A-with-AAAA alternative. As a summary, I fail to see where that came from. A a protocol mod A with AAAA makes little sense. As an implementation hack it is just fine (the only issue to be dealt with is making sure implementations can handle A records in the additional section of a NODATA type response, ie: one where the rcode==0 and answer count == 0). Because A with AAAA can be done as an implementation hack, and backed out the same way, it has essentially no costs. If we assume that nodes query for AAAA before A (which most seem to do), then it means just one round trip to the auth server to load the cache while nodes have A records. When nodes stop having A records, the benefit will tail away, but then the AAAA records that were returned will generally be sufficient, and the later A query will become rare. | A qtype ADDR would be slightly better than distinct queries for AAAA | followed by A, I'm not sure about that even. Look carefully at how a cache would be supposed to implement ADDR. If it does an ADDR query, and gets just AAAA (or just A) records in the answer, how long can it cache the fact that there were none of the alternative? There's no SOA in there from which a negative cache value might normally be taken. Most probably it can't add the negative cache at all. That means that a subsequent query to the same cache is going to either result in the same ADDR query repeated (cache effectiveness== 0), or perhaps reading the draft very carefully, a query for the type that wasn't cached. Assuming the latter, two queries to the cache will result in two queries to the auth server, which is exactly what would have resulted from two AAAA and A pairs of queries to the cache. So the only time ADDR could be better is when nodes have both AAAA and A. | although it would be a disadvantage during any transition | period, and the resulting savings are small enough to make the benefit | unworthy of the cost. I agree with that part. | However, if a sufficient number of people end up | using qtype ALL as an alternative to double lookups, the transition costs | of qtype ADDR will have been worth it. I'm not sure if that's suggesting we should do ADDR just in case someone is dumb enough to try qtype *, or whether it is saying that after we see people using qtype * we'll be lamenting the lack of qtype addr. In either case, since I forsee zero use of qtype * for this purpose, I don't think it matters. | Paul's proposal for multiple questions is provably better due to its | generalized nature' Yes, if we can get that right, we can get plenty of benefits, not just for IPv6 transition, but all over the place. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 19 14:28:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12004 for ; Mon, 19 Aug 2002 14:28:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17gr8W-000IkC-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 11:20:20 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17gr8M-000IdG-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 11:20:10 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 158931; Mon, 19 Aug 2002 13:17:34 -0500 Message-ID: <3D6136D6.4050104@ehsco.com> Date: Mon, 19 Aug 2002 13:20:06 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: namedroppers Subject: Re: qtype addr scorecard References: <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/19/2002 11:41 AM Robert Elz wrote: > | and would also be bettter than the include-A-with-AAAA alternative. > > As a summary, I fail to see where that came from. A a protocol mod A > with AAAA makes little sense. As an implementation hack it is just > fine (the only issue to be dealt with is making sure implementations > can handle A records in the additional section of a NODATA type > response, ie: one where the rcode==0 and answer count == 0). No, that's not the only issue. Additional issues include the potential for message overload which can result from unsolicited extraneous data, and future potential problems with specifications that have AAAA as additional section processing. It's a bad idea. > | Paul's proposal for multiple questions is provably better due to its > | generalized nature' > > Yes, if we can get that right, we can get plenty of benefits, not just > for IPv6 transition, but all over the place. Let's move on this, and leave the other options behind, then. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 19 14:34:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12224 for ; Mon, 19 Aug 2002 14:34:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17grFK-000Kxy-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 11:27:22 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17grFA-000Kwa-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 11:27:12 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 158933; Mon, 19 Aug 2002 13:24:35 -0500 Message-ID: <3D61387C.7060106@ehsco.com> Date: Mon, 19 Aug 2002 13:27:08 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers Subject: Re: qtype addr scorecard References: <20020819163154.208B728B6C@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/19/2002 11:31 AM Paul Vixie wrote: > Please let me know what clarifications or changes you think are needed. As stated earlier, I think it needs a lot more fleshing out. It is currently underspecified, IMO. I gave you an example of this which degraded into an argument over what BIND 9 may or may not do, but the underlying concerns still stand. For any situation where multiple types of answers can be returned (with any level of feasibility), the handling of those commingled answer types needs to be described. Some additional discussion on retry techniques, incomplete cache sets and so forth would also be nice. When a cache needs to fetch missing answers, what are the requirements or issues with coordinating TTLs among the answers, or answer types, for example. It's just too vague for my liking. This is untested waters and it really should be fleshed out, overspecified even, to offset the worries. -- 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: From owner-namedroppers@ops.ietf.org Mon Aug 19 15:38:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13889 for ; Mon, 19 Aug 2002 15:38:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17gsEW-0009yh-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 12:30:36 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17gsES-0009yW-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 12:30:32 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA07056; Mon, 19 Aug 2002 15:30:28 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA06281; Mon, 19 Aug 2002 15:27:58 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA03730; Mon, 19 Aug 2002 15:27:56 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id PAA30337; Mon, 19 Aug 2002 15:27:54 -0400 Subject: Re: qtype addr scorecard From: Greg Hudson To: "Eric A. Hall" Cc: namedroppers In-Reply-To: <3D6136D6.4050104@ehsco.com> References: <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <3D6136D6.4050104@ehsco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 19 Aug 2002 15:27:54 -0400 Message-Id: <1029785274.3694.218.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-08-19 at 14:20, Eric A. Hall wrote: > No, that's not the only issue. Additional issues include the potential for > message overload which can result from unsolicited extraneous data This is a previously solved problem. Any time you might want to put an RR set in the additional section (for any reason), you check if you will overflow the packet, and if you will, you don't put the records in. > and > future potential problems with specifications that have AAAA as additional > section processing. It's a bad idea. I don't understand this issue. Almost anything we do seems like it will work out okay. (Putting in A records when you put in AAAA records, putting in A records only when you don't have any AAAA records to put in, etc.) [About multiple queries:] > Let's move on this, and leave the other options behind, then. That's reasonable, though if we run into a wall on EDNS1, I think remembering A-in-additional would be worthwhile. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 19 16:01:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14554 for ; Mon, 19 Aug 2002 16:01:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17gsbe-000Ajs-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 12:54:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17gsbV-000Ajg-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 12:54:21 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17gsbV-0004yz-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 12:54:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <200208191814.g7JIEDg00375@guam.araneus.fi> In-Reply-To: <5.1.1.6.2.20020815093727.00bb2f60@localhost> References: <5.1.1.6.2.20020815093727.00bb2f60@localhost> Date: Mon, 19 Aug 2002 11:14:13 -0700 (PDT) To: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support From: gson@nominum.com (Andreas Gustafsson) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Ólafur Guðmundsson writes: > Extending the Domain Name System with new Resource Record types > currently requires changes to name server software. This document > specifies the changes necessary to allow future DNS implementations > to handle new RR types transparently. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt > > This draft is slated to be published as informational, if you disagree with > that please state why in your response. I would think it needs to be standards track because it specifies changes to a standards stack protocol (specifically, changes to the the DNSSEC RR canonicalization rules defined in RFC2535). -- Andreas Gustafsson, gson@nominum.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 19 17:52:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16700 for ; Mon, 19 Aug 2002 17:52:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17guDr-000CyM-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 14:38:03 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17gtpt-000Cl6-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 14:13:17 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id D103328B6C for ; Mon, 19 Aug 2002 21:13:14 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: qtype addr scorecard In-Reply-To: Message from "Eric A. Hall" of "Mon, 19 Aug 2002 13:27:08 EST." <3D61387C.7060106@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 19 Aug 2002 21:13:14 +0000 Message-Id: <20020819211314.D103328B6C@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ... For any situation where multiple types of answers can be returned > (with any level of feasibility), the handling of those commingled > answer types needs to be described. please quote the unclear portion of the document and suggest an improvement. > Some additional discussion on retry techniques, incomplete cache sets and > so forth would also be nice. When a cache needs to fetch missing answers, > what are the requirements or issues with coordinating TTLs among the > answers, or answer types, for example. that's all covered in the current document, as far as i can see. could we hear additional voices, since eric and i appear to be at a dead end here? > It's just too vague for my liking. This is untested waters and it really > should be fleshed out, overspecified even, to offset the worries. one of the things mr. bush tried to tell me during the preparation of 1996 and 2136 was that if you include a lot of tutorial jazz you run the risk of having your document disagree with itself. minimalism is best in the core specification. if you think a companion document which explains the model but specifies nothing in and of itself is appropriate, then please write it. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 19 20:35:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19016 for ; Mon, 19 Aug 2002 20:35:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17gwpE-000JCC-00 for namedroppers-data@psg.com; Mon, 19 Aug 2002 17:24:48 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17gwpA-000JC1-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 17:24:44 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17gwpA-000At3-00 for namedroppers@ops.ietf.org; Mon, 19 Aug 2002 17:24:44 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers Subject: draft-ietf-dnsext-axfr-clarify-04.txt Message-Id: Date: Mon, 19 Aug 2002 17:24:44 -0700 X-Spam-Status: No, hits=0.5 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Andreas Gustafsson said (in private email, which is why i quote here): > the main technical motivation for outlawing the behavior of the old > implementations is that it is fundametally incompatible with > incremental zone transfers. The RFC1995 IXFR protocol assumes a > certain level of consistency in the data being transfered (as any > incremental transfer protocol must); for example, that the zone > data does not silently change without incrementing the zone serial > number, and that the data sent by multiple masters showing the same > serial number is the same. If we allow AXFRs to mix in data from > child zones, both of these basic assumptions will be violated. > > Non-incremental zone transfers will interoperate whether or not we > allow the old behavior, but IXFR will not interoperate (or even > operate) reliably if it is allowed. given the above, the chairs are inclined to declare consensus on this draft. last call was a while ago. so if you have a contrary technical argument, now would be a very good time to make it. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 09:54:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14522 for ; Tue, 20 Aug 2002 09:54:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17h9A8-000Cqd-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 06:35:12 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17h9A2-000Col-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 06:35:07 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7KDXe129041; Tue, 20 Aug 2002 20:33:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7KDVIW29370; Tue, 20 Aug 2002 20:31:18 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Eric A. Hall" cc: namedroppers Subject: Re: qtype addr scorecard In-Reply-To: <3D6136D6.4050104@ehsco.com> References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Aug 2002 20:31:18 +0700 Message-ID: <29368.1029850278@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Mon, 19 Aug 2002 13:20:06 -0500 From: "Eric A. Hall" Message-ID: <3D6136D6.4050104@ehsco.com> | No, that's not the only issue. Additional issues include the potential for | message overload which can result from unsolicited extraneous data, This is simply silly. First because of Greg Hudson's answer (this is already a non-problem - at worst it would be equivalent to not implementing the proposal, and an extra query happens) - but more significantly, if AAAA and A records aren't going to fit in the same packet, how can ADDR possibly work (or even a dual query with EDNS1)? You'd have TC responses all over the place, which is much worse than "just do an extra query". In practice, unless you're looking up the NS list for ".", this is just a non-issue (and that one is an issue for AAAA ignoring the A records...) | and | future potential problems with specifications that have AAAA as additional | section processing. Huh? I haven't gone back to check, but I thought that 1886 already said that anything that requires A additional section processing, also requires AAAA additional section processing. And I certainly can't imagine a specification ever (until A is just a zombie) requiring AAAA additional section processing without A. That is, it is already the case, that if you do a MX lookup, and discover that mailsystem.example.com. is the MX target for some domain or other, you will already get both A and AAAA records for mailsystem in the additional section (assuming the server has them to give, of course). | Let's move on this, and leave the other options behind, then. Fine. Just remember that A with AAAA doesn't require any movement here. Nothing has to be specified for that to be done - no protocol work at all. This is something that some implementations can simply decide would be a good idea, and go implement it. I kind of suspect there's been enough discussion of it now that any implementors who feel the need can already be doing it. If none do, that's OK... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 10:53:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16340 for ; Tue, 20 Aug 2002 10:53:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hAEz-000Egc-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 07:44:17 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hAEu-000EgR-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 07:44:12 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159060; Tue, 20 Aug 2002 09:41:36 -0500 Message-ID: <3D6255B8.10203@ehsco.com> Date: Tue, 20 Aug 2002 09:44:08 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: namedroppers Subject: Re: qtype addr scorecard References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/20/2002 8:31 AM Robert Elz wrote: > significantly, if AAAA and A records aren't going to fit in the same > packet, how can ADDR possibly work (or even a dual query with EDNS1)? EDNS can handle a larger message. ADDR and EDNS both allow the sender to specifically request it, meaning they can be prepared for it. A system that does it sometimes but doesn't do it other times and which is not controllable by the requester and which is undocumented is the worst of the options. > Just remember that A with AAAA doesn't require any movement here. You keep saying this like it's a feature, when sympotmatically it amounts to a bug. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 20 12:19:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18508 for ; Tue, 20 Aug 2002 12:19:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hBVO-000Gxu-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 09:05:18 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17hBVJ-000Gxa-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 09:05:13 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 3B1FD28B6F for ; Tue, 20 Aug 2002 16:05:11 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: qtype addr scorecard In-Reply-To: Message from Robert Elz of "Tue, 20 Aug 2002 20:31:18 +0700." <29368.1029850278@munnari.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 20 Aug 2002 16:05:11 +0000 Message-Id: <20020820160511.3B1FD28B6F@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > That is, it is already the case, that if you do a MX lookup, and discover > that > mailsystem.example.com. > is the MX target for some domain or other, you will already get both A > and AAAA records for mailsystem in the additional section (assuming the > server has them to give, of course). we're about to change that with an updated -msgsize- draft. without EDNS, there will be no AAAA glue added, either for MX answers or NS referrals. > Just remember that A with AAAA doesn't require any movement here. > Nothing has to be specified for that to be done - no protocol work at > all. This is something that some implementations can simply decide > would be a good idea, and go implement it. I kind of suspect there's > been enough discussion of it now that any implementors who feel the > need can already be doing it. If none do, that's OK... some versions of BIND already refuse to upgrade additional data to answers, meaning that from a caching standpoint, putting AAAA's into the additional data section of an A answer, or A's into the additional data section of a AAAA answer, will not save as much network traffic as folks would like. (eric brought to isc's attention that bind9.2 doesn't get this right, but let me assure you all that bind9.3 *will* do the right thing in this case.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 13:03:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19478 for ; Tue, 20 Aug 2002 13:03:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hCHj-000ILD-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 09:55:15 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17hCHd-000IKv-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 09:55:09 -0700 Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA26102; Tue, 20 Aug 2002 12:55:08 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20437; Tue, 20 Aug 2002 12:55:07 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20735; Tue, 20 Aug 2002 12:55:04 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id MAA05120; Tue, 20 Aug 2002 12:55:04 -0400 Subject: Re: qtype addr scorecard From: Greg Hudson To: "Eric A. Hall" Cc: namedroppers In-Reply-To: <3D6255B8.10203@ehsco.com> References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 Aug 2002 12:55:04 -0400 Message-Id: <1029862504.1283.243.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2002-08-20 at 10:44, Eric A. Hall wrote: > ADDR and EDNS both allow the sender to specifically request it, meaning > they can be prepared for it. > A system that does it sometimes but doesn't do it other times and which is > not controllable by the requester and which is undocumented is the worst > of the options. But we already have that for, say, A records in the additional section of an MX answer. That's the whole point of the additional section. Simply claiming that it is the "worst of the options" isn't a very strong argument when you can't demonstrate that it's bad. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 14:03:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20730 for ; Tue, 20 Aug 2002 14:03:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hD2v-000JeP-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 10:44:01 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hD2q-000Je9-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 10:43:56 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159083; Tue, 20 Aug 2002 12:41:20 -0500 Message-ID: <3D627FD8.2000303@ehsco.com> Date: Tue, 20 Aug 2002 12:43:52 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Greg Hudson CC: namedroppers Subject: Re: qtype addr scorecard References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/20/2002 11:55 AM Greg Hudson wrote: > But we already have that for, say, A records in the additional section > of an MX answer. That's the whole point of the additional section. > Simply claiming that it is the "worst of the options" isn't a very > strong argument when you can't demonstrate that it's bad. This is not an applicable precedent. The A RRset which is returned in response to an MX answer is (1) documented by the canonical specification for MX, (2) can be expected from all servers, (3) can be expected by all clients, and (4) has additional requirements when truncation occurs which is also documented in the canonical specification (notably, that the NS glue takes precedence in the truncated answer). The just-include approach is not represented by (1), (2), or (3), and can arguably be claimed not to mesh with (4) although I won't make this argument at the moment. > Simply claiming that it is the "worst of the options" isn't a very > strong argument when you can't demonstrate that it's bad. I only need to demonstrate that it is worse than qtype ADDR. There are two arguments in support of this position. First is that just-include increases the overall complexity because it puts a burden on the servers without removing a burden from the clients (the clients cannot rely on the presence of the information since it is optional, and therefore must either continue issuing multiple queries, or be tempted to use qtype ANY). Conversely, the qtype ADDR approach puts complexity on servers but it removes complexity from the client. [both analysis assume that deployment is widespread] Secondarily, the nature of an undocumented server-side option makes pointing to bugs impossible. What if they include the A data but not the delegation glue in a truncated answer. Where is it written that they would be wrong to do this? How can we prove otherwise? [Bonus] DNS is fragile already. Introducing new functionality pretty much requires that the end-points negotiate extended features. Undocumented optional extensions which may or may not be present without client having requested the extension is just begging for trouble. It is the worst possible option, IMO. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 20 14:55:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22137 for ; Tue, 20 Aug 2002 14:55:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hDyq-000LLO-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 11:43:52 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17hDyl-000LL9-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 11:43:47 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g7KIhc9C008446; Tue, 20 Aug 2002 20:43:38 +0200 To: "Eric A. Hall" Cc: Greg Hudson , namedroppers Subject: Re: qtype addr scorecard References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <3D627FD8.2000303@ehsco.com> X-Hashcash: 0:020820:ehall@ehsco.com:6feacaea7e3c95a9 X-Hashcash: 0:020820:ghudson@MIT.EDU:48180a6e24c0eaab X-Hashcash: 0:020820:namedroppers@ops.ietf.org:37bb67557aaa764f From: Simon Josefsson Date: Tue, 20 Aug 2002 20:43:38 +0200 In-Reply-To: <3D627FD8.2000303@ehsco.com> ("Eric A. Hall"'s message of "Tue, 20 Aug 2002 12:43:52 -0500") Message-ID: Lines: 26 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > on 8/20/2002 11:55 AM Greg Hudson wrote: > >> But we already have that for, say, A records in the additional section >> of an MX answer. That's the whole point of the additional section. >> Simply claiming that it is the "worst of the options" isn't a very >> strong argument when you can't demonstrate that it's bad. > > This is not an applicable precedent. The A RRset which is returned in > response to an MX answer is (1) documented by the canonical specification > for MX, (2) can be expected from all servers, (3) can be expected by all > clients, and (4) has additional requirements when truncation occurs which > is also documented in the canonical specification (notably, that the NS > glue takes precedence in the truncated answer). I'm not sure what the argument is here, but if you mean that a client can simply assume it will receive A records for mail servers when asking for MX, I don't think that approach works in the real world. Consider for instance a server for the zone example.org returning the MX's for example.org, say mail.foobar.net and www.barfoo.net. The server for example.org may not know the IP addresses for mail.foobar.net and www.barfoo.net, so it doesn't include them. A client shouldn't break because of this. Is this scenario invalid according to some specification? Which? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 15:15:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22600 for ; Tue, 20 Aug 2002 15:15:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hEEx-000LqT-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 12:00:31 -0700 Received: from pacific-carrier-annex.mit.edu ([18.7.21.83]) by psg.com with esmtp (Exim 3.36 #1) id 17hEEg-000LqC-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 12:00:14 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA10213; Tue, 20 Aug 2002 15:00:12 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20750; Tue, 20 Aug 2002 15:00:12 -0400 (EDT) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22413; Tue, 20 Aug 2002 15:00:10 -0400 (EDT) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id PAA05808; Tue, 20 Aug 2002 15:00:10 -0400 Subject: Re: qtype addr scorecard From: Greg Hudson To: "Eric A. Hall" Cc: namedroppers In-Reply-To: <3D627FD8.2000303@ehsco.com> References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <3D627FD8.2000303@ehsco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 Aug 2002 15:00:10 -0400 Message-Id: <1029870010.3694.257.camel@error-messages.mit.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,RCVD_IN_RELAYS_ORDB_ORG version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2002-08-20 at 13:43, Eric A. Hall wrote: > This is not an applicable precedent. The A RRset which is returned in > response to an MX answer is (1) documented by the canonical specification > for MX, (2) can be expected from all servers, (3) can be expected by all > clients, and (4) has additional requirements when truncation occurs which > is also documented in the canonical specification (notably, that the NS > glue takes precedence in the truncated answer). As Simon pointed out, (2) and (3) are false, so you're pretty much left with (1). If you want to argue that "just include" should be formally documented before implementation, then I won't disagree loudly, though I don't particularly agree either. > I only need to demonstrate that it is worse than qtype ADDR. No, you need to demonstrate that it is so much worse than qtype ADDR as to outweigh the caching problems of qtype ADDR. (For instance, as kre pointed out, if you do a qtype ADDR and get only A record replies, how long can you cache that there are no AAAA records? There is no SOA, so you have no idea.) Even if these problems can be solved, the solution would almost certainly put a much larger burden on servers than "just include A records in AAAA queries" does. > Conversely, the qtype ADDR approach puts > complexity on servers but it removes complexity from the client. [both > analysis assume that deployment is widespread] It takes a long time before deployment is so widespread as to allow clients to stop having to fall back to AAAA and a queries. About as long as the IPv6 migration, if that ever happens. > Secondarily, the nature of an undocumented server-side option makes > pointing to bugs impossible. What if they include the A data but not the > delegation glue in a truncated answer. Where is it written that they would > be wrong to do this? How can we prove otherwise? (Technically, I don't think the answer would qualify as "truncated.") I don't find this issue compelling, but again, I wouldn't disagree with an effort to document the idea. > [Bonus] DNS is fragile already. Not really. It's an old and bizarre standard, but that doesn't really make it fragile. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 16:02:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24372 for ; Tue, 20 Aug 2002 16:02:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hF3U-000NTt-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 12:52:44 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hF3P-000NTe-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 12:52:39 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159115 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 14:50:03 -0500 Message-ID: <3D629E03.40706@ehsco.com> Date: Tue, 20 Aug 2002 14:52:35 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: namedroppers Subject: Re: qtype addr scorecard References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <3D627FD8.2000303@ehsco.com> <1029870010.3694.257.camel@error-messages.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.2 required=5.0 tests=DOUBLE_CAPSWORD,MISSING_HEADERS version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/20/2002 2:00 PM Greg Hudson wrote: > No, you need to demonstrate that it is so much worse than qtype ADDR as > to outweigh the caching problems of qtype ADDR. (For instance, as kre > pointed out, if you do a qtype ADDR and get only A record replies, how > long can you cache that there are no AAAA records? There is no SOA, so > you have no idea.) How is just-include better here? I mean, qtype ADDR can be patched to include SOA with the statement that the value applies to any missing RRsets, and since all available RRsets would be returned, a client would know what that means. You can't do this with an optional undescribed tag-along service. Missing RRsets could mean that (1) the data doesn't exist but since there's no formalized way to indicate NODATA treat it like the cache isn't playing along, or (2) the cache really isn't playing along. In either scenario the just-include approach requires a followup query EVERYTIME the data isn't provided. I would also argue that since clients aren't expecting this data they will probably throw it away whenever it is provided (the resolver won't have anything to pass it to or through). The complexity is twice as large with just-include as it is with qtype ADDR. > It takes a long time before deployment is so widespread as to allow > clients to stop having to fall back to AAAA and a queries. About as > long as the IPv6 migration, if that ever happens. Granted, which is why I said that qtype ADDR is a wash in comparison to separate queries. The opposition is using the end-game of pure v6, not me. Unfortunately for them, the end-game is more efficient with qtype ADDR, since applications can STOP USING IT and just issue qtype AAAA when they get there. >>[Bonus] DNS is fragile already. > > Not really. It's an old and bizarre standard, but that doesn't really > make it fragile. There are a lot of opportunites for problems, is all. cf the bind 9.2 comment made by paul. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 20 16:10:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24687 for ; Tue, 20 Aug 2002 16:10:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hF9h-000NiE-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 12:59:09 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hF9c-000Nhs-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 12:59:04 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159119; Tue, 20 Aug 2002 14:56:28 -0500 Message-ID: <3D629F84.1040103@ehsco.com> Date: Tue, 20 Aug 2002 14:59:00 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Simon Josefsson CC: Greg Hudson , namedroppers Subject: Re: qtype addr scorecard References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <3D627FD8.2000303@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/20/2002 1:43 PM Simon Josefsson wrote: > "Eric A. Hall" writes: >>This is not an applicable precedent. The A RRset which is returned in >>response to an MX answer is (1) documented by the canonical specification >>for MX, (2) can be expected from all servers, (3) can be expected by all >>clients > I'm not sure what the argument is here, but if you mean that a client > can simply assume it will receive A records for mail servers when > asking for MX, I don't think that approach works in the real world. No, the argument is that clients know that it may be provided, they are ready for it, they know what to do when it arrives. This is different mindset from a just-include approach, where the data may show up sometimes but not others, without being requested. -- 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: From owner-namedroppers@ops.ietf.org Tue Aug 20 16:26:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25348 for ; Tue, 20 Aug 2002 16:26:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hFRH-000OM9-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 13:17:19 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17hFRC-000OLw-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 13:17:14 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g7KKH59C009863; Tue, 20 Aug 2002 22:17:05 +0200 To: "Eric A. Hall" Cc: Greg Hudson , namedroppers Subject: Re: qtype addr scorecard References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <3D627FD8.2000303@ehsco.com> <3D629F84.1040103@ehsco.com> X-Hashcash: 0:020820:ehall@ehsco.com:37ed6ec1210d9378 X-Hashcash: 0:020820:ghudson@MIT.EDU:685bd8b3e2666b81 X-Hashcash: 0:020820:namedroppers@ops.ietf.org:c63bd1438b7b33e3 From: Simon Josefsson Date: Tue, 20 Aug 2002 22:17:05 +0200 In-Reply-To: <3D629F84.1040103@ehsco.com> ("Eric A. Hall"'s message of "Tue, 20 Aug 2002 14:59:00 -0500") Message-ID: Lines: 32 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk "Eric A. Hall" writes: > on 8/20/2002 1:43 PM Simon Josefsson wrote: >> "Eric A. Hall" writes: > >>>This is not an applicable precedent. The A RRset which is returned in >>>response to an MX answer is (1) documented by the canonical specification >>>for MX, (2) can be expected from all servers, (3) can be expected by all >>>clients > >> I'm not sure what the argument is here, but if you mean that a client >> can simply assume it will receive A records for mail servers when >> asking for MX, I don't think that approach works in the real world. > > No, the argument is that clients know that it may be provided, they are > ready for it, they know what to do when it arrives. This is different > mindset from a just-include approach, where the data may show up sometimes > but not others, without being requested. MX is almost an just-include approach. There are no guarantees it will happen. The application must be ready to query for MX's addresses. If the server happens to include some IPs in the first reply, the application may optimize things and use that data, although prudent resolvers may not want to do so anyway in some cases (think cache corruption). The only difference I can see is that there is text in a specification suggesting servers to include A records when returning MX, to allow for this optimization. A similar recomendation for A/AAAA could be written, and would perhaps even be a good idea -- I'm annoyed by the doubled DNS delays in modern applications (queries for both A and AAAA). IMHO this path seems easier to get to work than a new QTYPE. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 19:24:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00082 for ; Tue, 20 Aug 2002 19:24:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hI7x-0003zl-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 16:09:33 -0700 Received: from [2002:4051:3012:1fff::dead:beef] (helo=pianosa.catch22.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 17hI7s-0003zZ-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 16:09:29 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id E2ECE484; Tue, 20 Aug 2002 16:09:25 -0700 (PDT) Date: Tue, 20 Aug 2002 16:09:25 -0700 From: David Terrell To: namedroppers Subject: Re: qtype addr scorecard Message-ID: <20020820230925.GA12023@pianosa.catch22.org> Reply-To: David Terrell References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <3D627FD8.2000303@ehsco.com> <3D629F84.1040103@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D629F84.1040103@ehsco.com> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 4:04PM up 5 days, 2:44, 51 users, load averages: 0.38, 0.49, 0.58 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Aug 20, 2002 at 02:59:00PM -0500, Eric A. Hall wrote: > > on 8/20/2002 1:43 PM Simon Josefsson wrote: > > "Eric A. Hall" writes: > > >>This is not an applicable precedent. The A RRset which is returned in > >>response to an MX answer is (1) documented by the canonical specification > >>for MX, (2) can be expected from all servers, (3) can be expected by all > >>clients > > > I'm not sure what the argument is here, but if you mean that a client > > can simply assume it will receive A records for mail servers when > > asking for MX, I don't think that approach works in the real world. > > No, the argument is that clients know that it may be provided, they are > ready for it, they know what to do when it arrives. This is different > mindset from a just-include approach, where the data may show up sometimes > but not others, without being requested. Can you posit or demonstrate a scenario where an application doing a lookup for AAAA and getting an A record in the extra section would be harmful? Assuming we're specifying new, optional behavior and that as always they can fall back to a second A query (as is done today) -- the ADDR query seems more harmful, as it will result in THREE round trips in the likely case of a remote resolver not supporting it (one error, one AAAA, one A). A in the extra data results in no additional round trips if it's not supported. What happens if you make an EDNS1 multiple question query and the remote side (forwarder or authoritative server) doesn't support ENDS1? Three round trips? That doesn't seem like a reasonable upgrade path. -- David Terrell | Q. Is C an acronym? dbt@meat.net | A. Yes, it stands for ``C''. It's another Nebcorp Prime Minister | of those funky recursive acronyms. http://wwn.nebcorp.com/ | - "Infrequently asked questions in comp.lang.c" -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 20 20:53:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01886 for ; Tue, 20 Aug 2002 20:53:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hJVh-000760-00 for namedroppers-data@psg.com; Tue, 20 Aug 2002 17:38:09 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hJVZ-00075V-00 for namedroppers@ops.ietf.org; Tue, 20 Aug 2002 17:38:01 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159176; Tue, 20 Aug 2002 19:35:25 -0500 Message-ID: <3D62E0E5.3060800@ehsco.com> Date: Tue, 20 Aug 2002 19:37:57 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: David Terrell CC: namedroppers Subject: Re: qtype addr scorecard References: <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <3D627FD8.2000303@ehsco.com> <3D629F84.1040103@ehsco.com> <20020820230925.GA12023@pianosa.catch22.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/20/2002 6:09 PM David Terrell wrote: > Can you posit or demonstrate a scenario where an application doing a > lookup for AAAA and getting an A record in the extra section would be > harmful? Again, I only have to prove that it is the worst. > Assuming we're specifying new, optional behavior and that as always they > can fall back to a second A query (as is done today) Correction, will almost certainly always fallback, since even in those situations where the A RR was provided, the application won't have expected it. Heck, some resolvers may not even pass it along to the application since it wasn't part of the question. The leftover benefit is that the cache will have the data on hand to issue the next query, but this by itself does not make anything operate more efficiently. Remember, this is the scenario at peak deployment, and not just during deployment, since this is being flogged as voluntary. > ADDR query seems more harmful, as it will result in THREE round trips > in the likely case of a remote resolver not supporting it (one error, > one AAAA, one A). > What happens if you make an EDNS1 multiple question query and the > remote side (forwarder or authoritative server) doesn't support ENDS1? > Three round trips? That doesn't seem like a reasonable upgrade path. During deployment yes, at peak no. We have deployed new RRs before (MX). We are early enough into the IPv6 deployment to do this. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 21 03:45:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03238 for ; Wed, 21 Aug 2002 03:45:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hPr5-000O7l-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 00:24:39 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17hPqr-000O6A-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 00:24:28 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7L7O3l03715; Wed, 21 Aug 2002 14:24:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7L7LtW07855; Wed, 21 Aug 2002 14:21:55 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Eric A. Hall" cc: Greg Hudson , namedroppers Subject: Re: qtype addr scorecard In-Reply-To: <3D627FD8.2000303@ehsco.com> References: <3D627FD8.2000303@ehsco.com> <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Aug 2002 14:21:55 +0700 Message-ID: <7853.1029914515@munnari.OZ.AU> X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,WEIRD_PORT version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 20 Aug 2002 12:43:52 -0500 From: "Eric A. Hall" Message-ID: <3D627FD8.2000303@ehsco.com> | I only need to demonstrate that it is worse than qtype ADDR. No you don't, as they're not alternatives. We could do ADDR, if we thought it worth the effort, and still have servers supplying A when they get an AAAA query. If ADDR really took off, then there would be essentially no AAAA queries, so it wouldn't matter one way or the other. On the other hand, if clients don't bother implementing ADDR, because it means an extra RTT waiting for the NOTIMPL error, because relatively few deployed servers support it, then the AAAA+A approach can have some benefits. You can't just assume full (or close to it) deployment - there has to be an implementable path to get us there. That is, you somehow have to convince resolvers to start doing ADDR queries while few servers support the thing, otherwise they'll never appear (upgrading servers takes a long time, upgrading resolvers takes an eternity). | First is that just-include increases the overall complexity because it | puts a burden on the servers without removing a burden from the clients True, as has been stated before - but the aim of all of this is to reduce the burden on the network, not on either implementation. DNS servers and resolvers are complex beasts now, the extra complexity to add in A's is negligible (the code for it already exists, it just needs to be run in one more case). The resolver better be able to handle the answer already, even if it just means ignoring the A's. If resolver implementors start to see that A's are appearing with the AAAA replies, then they will take advantage of that. | Conversely, the qtype ADDR approach puts | complexity on servers but it removes complexity from the client. [both | analysis assume that deployment is widespread] Unless you assume universal deployment (which will not happen) the client still has to be able to deal with the one old server out there which does not implement ADDR, so it still needs the fallback logic. | Secondarily, the nature of an undocumented server-side option makes | pointing to bugs impossible. What if they include the A data but not the | delegation glue in a truncated answer. Where is it written that they would | be wrong to do this? How can we prove otherwise? If the specs say that the delegation info should be provided, then it should be. If there is available glue for that, it can be included as well, but in one of these queries, it never has to be, and in general, is completely useless anyway. That is needed in referals, it isn't otherwise. I just did an AAAA lookup for munnari.oz.au. It happens that I got an AAAA answer, and I got A records for munnari.oz.au in the additional section. (You might even imagine a server that was implemented by someone with lots of foresight, as the server there hasn't changed since well before this idea was floated...) Of course, the reason for those particular A records is that munnari.oz.au is in the NS list for itself, so the A records were part of the delegation glue. But, not all of the delegation glue A records were provided. oz.au has 4 servers, there were addresses in the answer I received for only 3 of them (I am doing this query from nowhere near munnari, so this is the kind of thing that anyone else would see). The A records in the answer don't seem to be breaking anything... (whether or not resolvers take any notice is a different issue). The lack of the glue record for the 4th server breaks nothing. For the record, here is the answer... ; <<>> DiG 8.3 <<>> munnari.oz.au. aaaa ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6 ;; QUERY SECTION: ;; munnari.oz.au, type = AAAA, class = IN ;; ANSWER SECTION: munnari.oz.au. 10M IN AAAA 2001:388:c02:4000::1:21 ;; AUTHORITY SECTION: oz.au. 1d6h49m59s IN NS mulga.cs.mu.oz.au. oz.au. 1d6h49m59s IN NS dmssyd.nsw.cmis.CSIRO.au. oz.au. 1d6h49m59s IN NS munnari.oz.au. oz.au. 1d6h49m59s IN NS ns.UU.NET. ;; ADDITIONAL SECTION: mulga.cs.mu.oz.au. 7h24m23s IN A 128.250.1.22 mulga.cs.mu.oz.au. 7h24m23s IN A 128.250.37.150 dmssyd.nsw.cmis.CSIRO.au. 5h36m14s IN A 130.155.16.1 munnari.oz.au. 1d6h49m59s IN A 128.250.1.21 munnari.oz.au. 1d6h49m59s IN A 128.250.22.2 munnari.oz.au. 10M IN AAAA 2001:388:c02:4000::1:21 ;; Total query time: 475 msec ;; FROM: delta.cs.mu.OZ.AU to SERVER: default -- 172.30.0.9 ;; WHEN: Wed Aug 21 14:13:23 2002 ;; MSG SIZE sent: 31 rcvd: 279 (and yes, this was done from deep inside a NAT'd area of the net, so the local cache has a 1918 address...) [Aside: the AAAA glue record there looks like a bug, I thought the practice of repeating answers in the additional data section had been squashed long ago...] | [Bonus] DNS is fragile already. What fragility the DNS has all comes from configuration problems (in the past some from implementation bugs, but that's less common now). Nothing here is changing anything related to how operators run their DNS servers, so nothing is likely to impact on whatever fragility you're seeing. There are two arguments that an implementor might choose to use for not bothering to implement this (aside from just "I can't be bothered" which is OK too). One is based upon Paul's comment - if you believe that caches aren't going to remember the A records, then the potential benefit drops. It doesn't vanish though - the answer (complete with additional info) will still get sent back to the requesting client. In cases where the same info is requested again, the cache won't have the A's, and will need to fetch them. The cache is less effective than it could be, but we still get just 2 queries out of the cache, for data which is apparently being required multiple times. On the other hand, if it is a one off (queries needed less frequently than the TTL of the RRs) then what the cache does is immaterial anyway, and getting the A along with the AAAA could halve the number of these queries to the remote servers. That's going to mean there's a judgment issue, and once again, implementors get to decide what they want to do (and then users get to decide which server they will deploy). The second reason why one might not bother with implementing this is more compelling though I think, but it depends upon the behaviour of resolvers. Currently, I believe, most resolvers end up doing an AAAA query, and then when that fails (no AAAA records are returned, I don't mean NXDOMAIN or similar) they retry with an A query. That means 2 RTT's to get the answer (three if they start with ADDR...). If that's what ends up being "normal" then AAAA+A looks attractive. On the other hand, resolvers could issue the AAAA and A queries more or less simultaneously (two queries one after the other, I don't mean EDNS1 here). If that's what resolvers do, so they get the answer back in 1 RTT, then AAAA+A is useless, the AAAA answer with A records would only get back at about the same time as the A answer anyway. But in any case, I have no idea why you're bothering to argue against this. Implementors will make their own decisions (probably based upon customer demand). kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 04:53:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04238 for ; Wed, 21 Aug 2002 04:53:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hR0z-0000D7-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 01:38:57 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17hR0p-0000Cs-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 01:38:47 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA30623; Wed, 21 Aug 2002 11:37:21 +0300 Date: Wed, 21 Aug 2002 11:37:21 +0300 Message-Id: <200208210837.LAA30623@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: ehall@ehsco.com, ghudson@MIT.EDU, namedroppers@ops.ietf.org In-reply-to: <7853.1029914515@munnari.OZ.AU> (message from Robert Elz on Wed, 21 Aug 2002 14:21:55 +0700) Subject: Re: qtype addr scorecard References: <3D627FD8.2000303@ehsco.com> <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <7853.1029914515@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Robert Elz > I just did an AAAA lookup for munnari.oz.au. It happens that I got > an AAAA answer, and I got A records for munnari.oz.au in the additional > section. Instead of additional section, why not my other proposal: return IPv4 addresses in AAAA query as IPv6 addresses (ipv4 mapped format). - there would be no problems with caching servers - the answer set is always complete (the same DNS server will always have both A and AAAA data for the same name) - there would be issue about what would current IPv6 implementations do, if IPv4 mapped addresses are returned for AAAA. I know mine would work just fine (as I already internally represent all IPv4 as IPv4-mapped). How about KAME? Microsoft? AAAA query is relatively new and IPv6 stacks are still in developement stage (and must be upgraded in near future anyway, becuase apparently there are several drafts or changes in the pipeline, that will become mandatory standards.. although I don't like some of them :-) Thus, the handling of AAAA query could easily be changed to cope with IPv4 mapped addressess, and to cope with existing old DNS - if host needs IPv4 address and AAAA reply didn't contain any IPv4 addresses, it could issue the normal A query too. - further optimization, there could also be some flag or signal in the reply, that would say "there are no IPv4 addresses, there is no point trying A" These are about the last moments to act on this. Very soon cell phones will have IPv6 stacks and there will be millions of nodes doing queries in some way, which will hard to change after the fact... -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 05:46:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05066 for ; Wed, 21 Aug 2002 05:46:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hRyv-00021p-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 02:40:53 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17hRyp-00021L-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 02:40:48 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7L9eLl23657; Wed, 21 Aug 2002 16:40:22 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7L9e5W08619; Wed, 21 Aug 2002 16:40:05 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: ehall@ehsco.com, ghudson@MIT.EDU, namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <200208210837.LAA30623@burp.tkv.asdf.org> References: <200208210837.LAA30623@burp.tkv.asdf.org> <3D627FD8.2000303@ehsco.com> <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <7853.1029914515@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Aug 2002 16:40:05 +0700 Message-ID: <8617.1029922805@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 21 Aug 2002 11:37:21 +0300 From: Markku Savela Message-ID: <200208210837.LAA30623@burp.tkv.asdf.org> | Instead of additional section, why not my other proposal: return IPv4 | addresses in AAAA query as IPv6 addresses (ipv4 mapped format). I think this has the same problem as all of the proposals to have server created on the fly RR data - it doesn't work at all well with dnssec. Not certain about Microsoft, but KAME doesn't much like IPv4 mapped IPv6 addresses I believe, and avoids them wherever possible... (one of the KAME people might correct that if I'm wrong). But if we really thought ... | Thus, the handling of AAAA query could easily be changed to cope with | IPv4 mapped addressess, and to cope with existing old DNS I think we would have thought the same about A6, but apparently we didn't... (even the most ardent A6 supporters had given up on the possibility of having the clients ever use it - already too late). I don't follow the cell phone industry, but are they planning to put dual stack in their phones, os just IPv6. It is such a specialised market, and such a large one, that they could do v6 alone, and force the rest of the world that cares to communicate to simply support v6. Doing v4 would require NAT, which would seem to be very ugly for mobile devices. If they're only doing v6 then they're just going to want AAAA queries, and methods to get A answers to them simply wouldn't matter. If... kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 06:26:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05577 for ; Wed, 21 Aug 2002 06:26:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hSXG-00037J-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 03:16:22 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17hSX6-00035k-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 03:16:12 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id NAA30736; Wed, 21 Aug 2002 13:14:56 +0300 Date: Wed, 21 Aug 2002 13:14:56 +0300 Message-Id: <200208211014.NAA30736@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: ehall@ehsco.com, ghudson@MIT.EDU, namedroppers@ops.ietf.org In-reply-to: <8617.1029922805@munnari.OZ.AU> (message from Robert Elz on Wed, 21 Aug 2002 16:40:05 +0700) Subject: Re: qtype addr scorecard References: <200208210837.LAA30623@burp.tkv.asdf.org> <3D627FD8.2000303@ehsco.com> <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <7853.1029914515@munnari.OZ.AU> <8617.1029922805@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Robert Elz > I don't follow the cell phone industry, but are they planning to put > dual stack in their phones, os just IPv6. It is such a specialised > market, and such a large one, that they could do v6 alone, and force the > rest of the world that cares to communicate to simply support v6. Currently there is no IPv6 in real use, but there is GPRS with iPv4. Thus support for IPv4 is required. Future plans apparently call for IPv6, thus that too must be supported. So, by default the dual stack is the way to go, it will work in both or mixed environments. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 09:37:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09856 for ; Wed, 21 Aug 2002 09:37:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hVME-0000cZ-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 06:17:10 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17hVM9-0000cO-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 06:17:06 -0700 Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g7LDFMh68734; Wed, 21 Aug 2002 09:15:24 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020821091028.031dc378@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 21 Aug 2002 09:11:13 -0400 To: gson@nominum.com (Andreas Gustafsson), =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: DNSEXT WGLC: Unknown types support Cc: namedroppers@ops.ietf.org In-Reply-To: <200208191814.g7JIEDg00375@guam.araneus.fi> References: <5.1.1.6.2.20020815093727.00bb2f60@localhost> <5.1.1.6.2.20020815093727.00bb2f60@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,FROM_AND_TO_SAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA09856 At 14:14 2002-08-19, Andreas Gustafsson wrote: >[ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > >Ólafur Guðmundsson writes: > > Extending the Domain Name System with new Resource Record types > > currently requires changes to name server software. This document > > specifies the changes necessary to allow future DNS implementations > > to handle new RR types transparently. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt > > > > This draft is slated to be published as informational, if you disagree > with > > that please state why in your response. > >I would think it needs to be standards track because it specifies >changes to a standards stack protocol (specifically, changes to the >the DNSSEC RR canonicalization rules defined in RFC2535). You are right, the document is standards track! Olafur -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 10:23:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09857 for ; Wed, 21 Aug 2002 09:37:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hVP8-0000g0-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 06:20:10 -0700 Received: from 208-59-113-50.c3-0.129-ubr2.lnh-129.md.cable.rcn.com ([208.59.113.50] helo=ogud.com) by psg.com with esmtp (Exim 3.36 #1) id 17hVP0-0000fT-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 06:20:02 -0700 Received: from ENGILL.ogud.com (mail.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.6/8.11.6) with ESMTP id g7LDIRh68740 for ; Wed, 21 Aug 2002 09:18:28 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20020821091855.01549fe0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 21 Aug 2002 09:19:26 -0400 To: namedroppers@ops.ietf.org From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Fwd: I-D ACTION:draft-vixie-dnsext-edns2-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=3.3 required=5.0 tests=EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: *** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This is of relevance. Olafur >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-vixie-dnsext-edns2-00.txt >Date: Tue, 20 Aug 2002 15:34:54 -0400 >Sender: scoya@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Extensions to DNS (EDNS2) > Author(s) : P. Vixie > Filename : draft-vixie-dnsext-edns2-00.txt > Pages : 4 > Date : 16-Aug-02 > >This document specifies a number of extensions within the Extended >DNS framework defined by [RFC2671] and [EDNS1], including several new >extended label types. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-vixie-dnsext-edns2-00.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-vixie-dnsext-edns2-00.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-vixie-dnsext-edns2-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020816131508.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-vixie-dnsext-edns2-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: From owner-namedroppers@ops.ietf.org Wed Aug 21 10:36:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11400 for ; Wed, 21 Aug 2002 10:36:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hWRW-0001lO-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 07:26:42 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17hWRR-0001kc-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 07:26:38 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EC93E1945 for ; Wed, 21 Aug 2002 10:26:05 -0400 (EDT) Date: Wed, 21 Aug 2002 10:26:05 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support In-Reply-To: <200208191814.g7JIEDg00375@guam.araneus.fi> References: <5.1.1.6.2.20020815093727.00bb2f60@localhost> <200208191814.g7JIEDg00375@guam.araneus.fi> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=X-UNKNOWN Message-Id: <20020821142605.EC93E1945@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11400 At Mon, 19 Aug 2002 11:14:13 -0700 (PDT), Andreas Gustafsson wrote: > > [ post by non-subscriber. with the massive amount of spam, it is easy to > miss and therefore delete mis-posts. so fix subscription addresses! ] > > Ólafur Guðmundsson writes: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt > > > > This draft is slated to be published as informational, if you disagree with > > that please state why in your response. > > I would think it needs to be standards track because it specifies > changes to a standards stack protocol (specifically, changes to the > the DNSSEC RR canonicalization rules defined in RFC2535). I agree with Andreas. This draft modifies the downcasing rule used when computing DNSSEC signatures, so it has to be standards track. Side question related to this point: do folks feel that the draft goes into enough detail on this point? I found it a bit terse, but failed to come up with anything useful when Andreas quite reasonably asked me to suggest better text. If I'm the only person who thinks there's an issue here, I'll drop it, since presumably this point will be addressed in the grand unified DNSSEC rewrite 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: From owner-namedroppers@ops.ietf.org Wed Aug 21 10:49:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11951 for ; Wed, 21 Aug 2002 10:49:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hWee-00021h-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 07:40:16 -0700 Received: from fort-point-station.mit.edu ([18.7.7.76]) by psg.com with esmtp (Exim 3.36 #1) id 17hWeX-00021J-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 07:40:09 -0700 Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA05123; Wed, 21 Aug 2002 10:39:43 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA09042; Wed, 21 Aug 2002 10:39:42 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA20249; Wed, 21 Aug 2002 10:39:41 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA20809; Wed, 21 Aug 2002 10:39:41 -0400 (EDT) To: Markku Savela Cc: kre@munnari.OZ.AU, ehall@ehsco.com, ghudson@MIT.EDU, namedroppers@ops.ietf.org From: Derek Atkins Subject: Re: qtype addr scorecard References: <3D627FD8.2000303@ehsco.com> <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <7853.1029914515@munnari.OZ.AU> <200208210837.LAA30623@burp.tkv.asdf.org> Date: 21 Aug 2002 10:39:40 -0400 In-Reply-To: <200208210837.LAA30623@burp.tkv.asdf.org> Message-ID: Lines: 13 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,RCVD_IN_OSIRUSOFT_COM,RCVD_IN_RELAYS_ORDB_ORG, FUDGE_RELAY_OSIRU version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Markku Savela writes: > Instead of additional section, why not my other proposal: return IPv4 > addresses in AAAA query as IPv6 addresses (ipv4 mapped format). Dynamic construction of responses: BAD. How do you sign it? -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 12:15:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14913 for ; Wed, 21 Aug 2002 12:15:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hY3M-0002ED-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 09:09:52 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17hY3H-0002De-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 09:09:47 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 5B1B028B6C for ; Wed, 21 Aug 2002 16:09:47 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: Message from Markku Savela of "Wed, 21 Aug 2002 11:37:21 +0300." <200208210837.LAA30623@burp.tkv.asdf.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 21 Aug 2002 16:09:47 +0000 Message-Id: <20020821160947.5B1B028B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Instead of additional section, why not my other proposal: return IPv4 > addresses in AAAA query as IPv6 addresses (ipv4 mapped format). Synthetic data is very touchy. Those mapped AAAA's would have to have TTL=0, for example, which would mean the whole AAAA RRset would be minimized to TTL 0. I don't think this situation calls for synthetic data. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 12:17:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14973 for ; Wed, 21 Aug 2002 12:17:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hXzo-0001Wc-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 09:06:12 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17hXzh-0001VW-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 09:06:05 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 61A1328B6C for ; Wed, 21 Aug 2002 16:06:04 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: qtype addr scorecard In-Reply-To: Message from Robert Elz of "Wed, 21 Aug 2002 14:21:55 +0700." <7853.1029914515@munnari.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 21 Aug 2002 16:06:04 +0000 Message-Id: <20020821160604.61A1328B6C@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > | I only need to demonstrate that it is worse than qtype ADDR. > > No you don't, as they're not alternatives. We could do ADDR, if we > thought it worth the effort, and still have servers supplying A when > they get an AAAA query. ... Gentlemen, you have both been heard to say that the EDNS1 ("QDCOUNT>1") solution appeared viable and would be a good generic solution to this problem. Could we do a little deeper into that topic, and let the alternatives ("just send A" and QTYPE=ADDR) drop for now? Who thinks EDNS1 isn't ready for last call? OK, state your issues -- that is, tell us all how the document should be improved. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 13:09:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17183 for ; Wed, 21 Aug 2002 13:09:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hYod-0006tk-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 09:58:43 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17hYoa-0006tY-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 09:58:40 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id E9CFD28B6C for ; Wed, 21 Aug 2002 16:58:39 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: EDNS1 In-Reply-To: Message from Paul Vixie of "Wed, 21 Aug 2002 16:06:04 GMT." <20020821160604.61A1328B6C@as.vix.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 21 Aug 2002 16:58:39 +0000 Message-Id: <20020821165839.E9CFD28B6C@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Who thinks EDNS1 isn't ready for last call? OK, state your issues -- > that is, tell us all how the document should be improved. here are some proposed changes which came to me privately: 60,62c60,62 < This document specifies a number of extensions within the Extended DNS < framework defined by [EDNS0], including several new extended label types and < the ability to ask multiple questions in a single request. --- > This document specifies an extension within the Extended DNS framework defined > by [RFC2671], providing the ability to ask multiple questions in a single > request. 88c88 < 2: |md |FM |RRD|lm | z | --- > 2: |do |FM |RRD| Z | 94c94 < both requestors and responders should set this to the highest level they --- > both initators and responders should set this to the highest level they 96c96 < requestors should be prepared to probe using lower version numbers if they --- > initiators should be prepared to probe using lower version numbers if they 104c104,105 < the response. Response FM should be ignored by requestors. --- > the response. Response FM should be set to zero by responders, and ignored > by initiators. 113c114,115 < same FM and LM settings present in the current question. --- > same FM setting present in the current question. Response RRD should > be set to zero by responders, and ignored by initiators. 144,146c146,148 < 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs < where QDCOUNT>1 if the response contains no RRs of that type but some RRs < for one of the other QTYPEs present. --- > 4.6. If request FM was not set but QDCOUNT>1, then an initiator can infer the > absence of any RRs for one of the QTYPEs if the response contains no RRs of > that type but some RRs for one of the other QTYPEs present. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 13:39:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18943 for ; Wed, 21 Aug 2002 13:39:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hZGT-000D2Z-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 10:27:29 -0700 Received: from [3ffe:501:100f:0:200:f8ff:fe01:61cf] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 17hZGQ-000D2N-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 10:27:26 -0700 Received: from localhost ([2001:4f8:3:e:e9bb:cd31:377d:fceb]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g7LHQst45782; Thu, 22 Aug 2002 02:26:54 +0900 (JST) Date: Thu, 22 Aug 2002 02:26:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: kre@munnari.OZ.AU, ehall@ehsco.com, ghudson@MIT.EDU, namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <200208210837.LAA30623@burp.tkv.asdf.org> References: <3D627FD8.2000303@ehsco.com> <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <7853.1029914515@munnari.OZ.AU> <200208210837.LAA30623@burp.tkv.asdf.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 36 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,CHARSET_FARAWAY_HEADERS version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> On Wed, 21 Aug 2002 11:37:21 +0300, >>>>> Markku Savela said: >> I just did an AAAA lookup for munnari.oz.au. It happens that I got >> an AAAA answer, and I got A records for munnari.oz.au in the additional >> section. In general, I think this idea is problematic. Some people have already presented their concerns. In addition to them: > Instead of additional section, why not my other proposal: return IPv4 > addresses in AAAA query as IPv6 addresses (ipv4 mapped format). > - there would be no problems with caching servers I'm not really sure about this. Caching servers also (may) ask AAAA RRs by themselves to follow referrals, and the answers would affect their behavior. > - there would be issue about what would current IPv6 implementations > do, if IPv4 mapped addresses are returned for AAAA. I know mine > would work just fine (as I already internally represent all IPv4 as > IPv4-mapped). How about KAME? Microsoft? I've not tested it, but according to the code, our getaddrinfo() built with normal installation procedure seems to reject AAAA RRs that specify IPv4-mapped IPv6 addresses. I don't know much about Windows, but in my understanding, (at least some previous versions of) winsock does even not have the support of IPv4-mapped addresses (as described in RFC 2553). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 14:02:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19585 for ; Wed, 21 Aug 2002 14:02:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hZgl-000Ddz-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 10:54:39 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17hZgg-000Dca-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 10:54:35 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6FC621900 for ; Wed, 21 Aug 2002 13:54:03 -0400 (EDT) Date: Wed, 21 Aug 2002 13:53:54 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <20020821160604.61A1328B6C@as.vix.com> References: <7853.1029914515@munnari.OZ.AU> <20020821160604.61A1328B6C@as.vix.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020821175403.6FC621900@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 21 Aug 2002 16:06:04 +0000, Paul Vixie wrote: > > Who thinks EDNS1 isn't ready for last call? OK, state your issues -- > that is, tell us all how the document should be improved. Apologies if this is already covered and I missed it (am a bit fuzzed out by the head cold of the month), but don't QDCOUNT values greater than one have the same general deployment problem as EDNS0 extended labels? That is, don't you have to upgrade every name server in the resolution chain at least to EDNS0 before you can stop worrying about getting back RCODE=1 ("Format Error")? So we immediately run up against the question of whether the problem we'd be solving is important enough to be worth this kind of upgrade effort. Yes I know there are other reasons (eg, IPv6, DNSSEC) why old DNS software ought to be upgraded anyway, but let's get all the issues out on the table. On the plus side, the general approach here does at least attempt to deal with the naming granularity problem directly, so I agree that it's worth discussing in some detail whether we conclude that it's the right answer or not. I think, however, that it'd be premature to last call this, because I don't think we yet have a crisp statement of the problem we're trying to solve. Backing up a bit to a more abstract level in an attempt to start down the path towards a crisp problem statement: I think that, broadly speaking, we have two choices when talking about the general issue of applications that expect to need multiple RRsets with the same owner name in quick succession: 1) We can take the approach that the application just asks for whatever specific RRset it needs, one RRset at a time, and assume that the DNS caching mechanism will do whatever it does but that optimization of the query process is not the client's problem; or 2) We can use an approach like what Paul is proposing in EDNS1 to let the client be more explict about what data it expects to need in the immediate future. It would probably be worth reviewing the archives from the last time that this draft came around; I don't know that there's anything there that's particularly relevant to this discussion, but I'd rather learn from history than loop. Last, a nit in the current EDNS1 draft: the EDNS1 draft refers to the LM flag, which is defined in the EDNS2 draft. Based on what I think I remember of Paul's theory about how the general EDNS framework should evolve, I'd guess that this is just an editing oversight rather than a deliberate cross dependency, but it would be good to confirm that. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 14:07:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19747 for ; Wed, 21 Aug 2002 14:07:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hZmv-000Doq-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 11:01:01 -0700 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by psg.com with esmtp (Exim 3.36 #1) id 17hZmj-000DoW-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 11:00:50 -0700 Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g7LI0k9C026998; Wed, 21 Aug 2002 20:00:47 +0200 To: Paul Vixie Cc: namedroppers Subject: Re: EDNS1 References: <20020821165839.E9CFD28B6C@as.vix.com> X-Hashcash: 0:020821:paul@vix.com:0725c8f64da5af88 X-Hashcash: 0:020821:namedroppers@ops.ietf.org:d5efc3acb3757431 From: Simon Josefsson Date: Wed, 21 Aug 2002 20:00:46 +0200 In-Reply-To: <20020821165839.E9CFD28B6C@as.vix.com> (Paul Vixie's message of "Wed, 21 Aug 2002 16:58:39 +0000") Message-ID: Lines: 18 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.3.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Paul Vixie writes: >> 4.6. If request FM was not set but QDCOUNT>1, then an initiator can infer the >> absence of any RRs for one of the QTYPEs if the response contains no RRs of >> that type but some RRs for one of the other QTYPEs present. This does not rime well with DNSSEC. How about the following? 4.6. If request FM was not set but QDCOUNT>1, then an initiator can infer the absence of any RRs for one of the QTYPEs if the response either contains no RRs of that type but some RRs for one of the other QTYPEs present, or contains NXT/SIG RRs that indicate the absence of RRs of the QTYPE, depending on local security policy. I don't find any discussion of how the additional field is populated by intermediate servers. Say I query for (foo.example.org, IN, MX CERT), will the intermediate add any additional A records returned for the MX query to the initial client? -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 14:34:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20781 for ; Wed, 21 Aug 2002 14:34:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17haAS-0002R4-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 11:25:20 -0700 Received: from burp.tkv.asdf.org ([212.16.99.49]) by psg.com with esmtp (Exim 3.36 #1) id 17haAJ-0002Ql-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 11:25:11 -0700 Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA31144; Wed, 21 Aug 2002 21:25:07 +0300 Date: Wed, 21 Aug 2002 21:25:07 +0300 Message-Id: <200208211825.VAA31144@burp.tkv.asdf.org> From: Markku Savela To: paul@vix.com CC: namedroppers@ops.ietf.org In-reply-to: <20020821160947.5B1B028B6C@as.vix.com> (message from Paul Vixie on Wed, 21 Aug 2002 16:09:47 +0000) Subject: Re: qtype addr scorecard References: <20020821160947.5B1B028B6C@as.vix.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > From: Paul Vixie > > Instead of additional section, why not my other proposal: return IPv4 > > addresses in AAAA query as IPv6 addresses (ipv4 mapped format). > > Synthetic data is very touchy. Those mapped AAAA's would have to have TTL=0, > for example, which would mean the whole AAAA RRset would be minimized to TTL > 0. I don't think this situation calls for synthetic data. I was not proposing "synthetic data". What I proposed, can be simulated manually using current name servers without any change as follows: - when you enter A record for address 1.2.3.4, you also enter AAAA record for ::ffff:1.2.3.4 It would be a convenience feature, if some new version of server did this implicitly. However, I did not suggest that some intermediate server should do any merging of AAAA query with A queries. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 15:34:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22620 for ; Wed, 21 Aug 2002 15:34:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hb8L-00047U-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 12:27:13 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17hb8I-00046n-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 12:27:10 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 210381900 for ; Wed, 21 Aug 2002 15:26:38 -0400 (EDT) Date: Wed, 21 Aug 2002 15:26:35 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <200208211825.VAA31144@burp.tkv.asdf.org> References: <20020821160947.5B1B028B6C@as.vix.com> <200208211825.VAA31144@burp.tkv.asdf.org> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020821192638.210381900@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 21 Aug 2002 21:25:07 +0300, Markku Savela wrote: > > I was not proposing "synthetic data". What I proposed, can be > simulated manually using current name servers without any change... Right. The difficulties I see with the mapped approach are that: a) By adding v4 addresses to the AAAA RRset, it makes the AAAA RRset bigger and leaves you with no way to say that you just want the IPv6 addresses. That is, it has a mild flavor of the subtyping problem, although I will admit that IP addresses are so close to being the same thing as IP addresses that maybe it doesn't matter. b) The case where a dual-stack machine is most likely to want the IPV4 addresess is, unfortunately, also the case that's most likely not to have bothered supplying the mapped addresses at all. That is, while you'd get some benefit from the ability to supply the mapped addresses for a host that's IPv6-aware but IPv4-only, the case on which you'd really like to get some traction is the one that's not playing here (IPv4 only and doesn't care about IPv6). Neither of these issues is necessarily a showstopper. John Klensin and I discussed something very close to this a couple of years ago and I still kind of like the idea. In the final analysis, though, what I mostly care about is coming up with the simplest set of rules that gets everybody the right answer in every case where a right answer is possible. So while I'm happy to discuss other options, I still tend towards the idea that the application should just ask for the RRsets it needs, one RRset at a time, and let the caching take care of itself. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 15:36:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22669 for ; Wed, 21 Aug 2002 15:36:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hb57-00042B-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 12:23:53 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17hb54-000420-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 12:23:50 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 09D9528B6F for ; Wed, 21 Aug 2002 19:23:50 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: Message from Rob Austein of "Wed, 21 Aug 2002 13:53:54 -0400." <20020821175403.6FC621900@thrintun.hactrn.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 21 Aug 2002 19:23:50 +0000 Message-Id: <20020821192350.09D9528B6F@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > ..., don't you have to upgrade every name server in the resolution > chain at least to EDNS0 before you can stop worrying about getting > back RCODE=1 ("Format Error")? yes. however, since we expect this to last more than our lifetimes, it is reasonable to design for (eventual) success. it's a near thing, since by the time EDNS1 would fully penetrate the installed base, A RR queries could be expected to reduce in number since there would be few non-V6 endstations and the majority of transactions will be satisfied by a AAAA result. the thing that tips the balance is the ability to ask for MX and A and AAAA all together, or some day, A and AAAA and AAAAAAAA all together. > So we immediately run up against the question of whether the problem > we'd be solving is important enough to be worth this kind of upgrade > effort. something called EDNS1 is inevitable, from a social perspective. the question is: have we found something that makes another crank-turn worth the effort, or should we wait for more things or bigger things to come along before turning this crank? here again it's a near thing, since something called EDNS2 is also inevitable, from a social perspective, and EDNS2 will be inclusive of EDNS(n<2). we could turn the crank every year and never really miss an opportunity to get more out of the protocol. > Backing up a bit to a more abstract level in an attempt to start down > the path towards a crisp problem statement: I think that, broadly > speaking, we have two choices when talking about the general issue of > applications that expect to need multiple RRsets with the same owner > name in quick succession: > > 1) We can take the approach that the application just asks for > whatever specific RRset it needs, one RRset at a time, and assume > that the DNS caching mechanism will do whatever it does but that > optimization of the query process is not the client's problem; or based on what we see at the root name servers, caching (statistically speaking) just doesn't happen. that ought to get fixed. but i'm betting that it's more wide spread -- that every authoritative zone, and not just ".", is getting pounded by repeated queries for both existing and non- existing names. if we take approach (1) then let's also embark on an internet-wide crusade to improve dns caching. > Last, a nit in the current EDNS1 draft: the EDNS1 draft refers to the > LM flag, which is defined in the EDNS2 draft. Based on what I think I > remember of Paul's theory about how the general EDNS framework should > evolve, I'd guess that this is just an editing oversight rather than a > deliberate cross dependency, but it would be good to confirm that. it was an oversight, and was corrected in this morning's published diffs, which evidently crossed your letter in the post. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 15:41:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22821 for ; Wed, 21 Aug 2002 15:41:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hbCe-0004GV-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 12:31:40 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17hbCb-0004GG-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 12:31:37 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 8997528B6C for ; Wed, 21 Aug 2002 19:31:37 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: Message from Markku Savela of "Wed, 21 Aug 2002 21:25:07 +0300." <200208211825.VAA31144@burp.tkv.asdf.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 21 Aug 2002 19:31:37 +0000 Message-Id: <20020821193137.8997528B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I was not proposing "synthetic data". What I proposed, can be > simulated manually using current name servers without any change as > follows: > > - when you enter A record for address 1.2.3.4, you also enter AAAA > record for ::ffff:1.2.3.4 > > It would be a convenience feature, if some new version of server did > this implicitly. > > However, I did not suggest that some intermediate server should do any > merging of AAAA query with A queries. i apologize for misunderstanding you. (your words were clear on this point, upon rereading.) jinmei's comments are relevant to this. getaddrinfo() does not accept ipv4-mapped addresses. so there would still be some implementation cost to this proposal, though not in the protocol itself. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 16:45:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25242 for ; Wed, 21 Aug 2002 16:45:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hcEL-0006Er-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 13:37:29 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17hcEI-0006Ee-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 13:37:26 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 414C728B6C for ; Wed, 21 Aug 2002 20:37:26 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: EDNS1 In-Reply-To: Message from Simon Josefsson of "Wed, 21 Aug 2002 20:00:46 +0200." X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 21 Aug 2002 20:37:26 +0000 Message-Id: <20020821203726.414C728B6C@as.vix.com> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This does not rime well with DNSSEC. How about the following? > > 4.6. If request FM was not set but QDCOUNT>1, then an initiator can > infer the absence of any RRs for one of the QTYPEs if the response > either contains no RRs of that type but some RRs for one of the > other QTYPEs present, or contains NXT/SIG RRs that indicate the > absence of RRs of the QTYPE, depending on local security policy. done. > I don't find any discussion of how the additional field is populated > by intermediate servers. Say I query for (foo.example.org, IN, MX > CERT), will the intermediate add any additional A records returned for > the MX query to the initial client? how about: 4.7. Negative caching and additional data processing shall be performed as if successive queries had been initiated with QDCOUNT=1 and successive QTYPEs. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 16:50:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25451 for ; Wed, 21 Aug 2002 16:50:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hcKS-0006We-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 13:43:48 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hcKJ-0006WJ-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 13:43:39 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159339; Wed, 21 Aug 2002 15:41:03 -0500 Message-ID: <3D63FB76.70604@ehsco.com> Date: Wed, 21 Aug 2002 15:43:34 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard References: <20020821192350.09D9528B6F@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/21/2002 2:23 PM Paul Vixie wrote: >>..., don't you have to upgrade every name server in the resolution >>chain at least to EDNS0 before you can stop worrying about getting >>back RCODE=1 ("Format Error")? > > yes. You can avoid this if the cache forms answers by assembling discrete components. That's how qtype ADDR avoids it. If q1 is cached but q2 is missing, only fetch q2. With that in place, apps/users only need to support the query at the local cache. Every other server on the Internet can refuse to support the query and it won't matter. There is a hole here that has to be avoided in terms of short TTLs on the discrete answer sets. If q1 has a ttl of 3 seconds but it takes 4 seconds to fetch q2, oops got to get q1 now, dang where did q2 go, etc. -- 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: From owner-namedroppers@ops.ietf.org Wed Aug 21 17:03:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25881 for ; Wed, 21 Aug 2002 17:03:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hcY2-00071k-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 13:57:50 -0700 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 17hcXx-00070n-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 13:57:45 -0700 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id g7LKwKx28665 for ; Wed, 21 Aug 2002 16:58:20 -0400 (EDT) Received: from nodnsquery(129.9.145.48) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAVVaa_3; Wed, 21 Aug 02 16:58:20 -0400 Received: from wokcdts1.is.chrysler.com (extra.daimlerchrysler.com.names.do.not.resolve.sanely.on.the.inside.is.chrysler.com [53.230.102.56]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g7LKvcs18025 for ; Wed, 21 Aug 2002 16:57:38 -0400 (EDT) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g7LKuZJ02374 for ; Wed, 21 Aug 2002 16:56:35 -0400 (EDT) Message-ID: <3D63FE83.50E9C21F@daimlerchrysler.com> Date: Wed, 21 Aug 2002 16:56:35 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support References: <5.1.1.6.2.20020815093727.00bb2f60@localhost> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by shmrspr1-pf0.shdc.chrysler.com id g7LKvcs18025 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA25881 Ólafur Guðmundsson wrote: > Extending the Domain Name System with new Resource Record types > currently requires changes to name server software. This document > specifies the changes necessary to allow future DNS implementations > to handle new RR types transparently. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt > > This draft is slated to be published as informational, if you disagree with > that please state why in your response. > > The Last call completes on August 29'th 2002. I still think there should be an exception to the ban on RDATA label compression for the specific case where the RR type is only to be used between co-operating clients and servers (e.g. through EDNS OPTION control or whatever): in this case, the client can reasonably be expected to understand the RDATA structure and there is no good reason for the benefits of label compression to be forfeited. However, no-one on the WG seems to share my opinion on this, so I only state it for the record. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 18:27:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27808 for ; Wed, 21 Aug 2002 18:27:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hdmv-0009Xn-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 15:17:17 -0700 Received: from rcwep-dhcp-47.isc.org ([204.152.189.47] helo=drugs.dv.isc.org) by psg.com with esmtp (Exim 3.36 #1) id 17hdmq-0009Xb-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 15:17:12 -0700 Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.5/8.12.5) with ESMTP id g7LMHOOj004335; Thu, 22 Aug 2002 08:17:24 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200208212217.g7LMHOOj004335@drugs.dv.isc.org> To: Kevin Darcy Cc: namedroppers@ops.ietf.org From: Mark.Andrews@isc.org Subject: Re: DNSEXT WGLC: Unknown types support In-reply-to: Your message of "Wed, 21 Aug 2002 16:56:35 -0400." <3D63FE83.50E9C21F@daimlerchrysler.com> Date: Thu, 22 Aug 2002 08:17:24 +1000 X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Ólafur Guðmundsson wrote: > > > Extending the Domain Name System with new Resource Record types > > currently requires changes to name server software. This document > > specifies the changes necessary to allow future DNS implementations > > to handle new RR types transparently. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-03.txt > > > > This draft is slated to be published as informational, if you disagree with > > that please state why in your response. > > > > The Last call completes on August 29'th 2002. > > I still think there should be an exception to the ban on RDATA label > compression for the specific case where the RR type is only to be used betwee > n > co-operating clients and servers (e.g. through EDNS OPTION control or > whatever): in this case, the client can reasonably be expected to understand > the RDATA structure and there is no good reason for the benefits of label > compression to be forfeited. > > However, no-one on the WG seems to share my opinion on this, so I only state > it for the record. > > > - Kevin Kevin there are trade offs occuring here. There is no "right" answer that will fit everyones needs. compression vs dnssec vs case preservation vs opaque data The current trade off gets you dnssec + case preservation + opaque data Mark > > > > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 21 18:51:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28384 for ; Wed, 21 Aug 2002 18:51:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17heD5-000AQ1-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 15:44:19 -0700 Received: from [2001:240:501:0:206:29ff:fe8f:b201] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17heD2-000APo-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 15:44:16 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A8AE54B23; Thu, 22 Aug 2002 07:44:05 +0900 (JST) To: Markku Savela Cc: paul@vix.com, namedroppers@ops.ietf.org In-reply-to: msa's message of Wed, 21 Aug 2002 21:25:07 +0300. <200208211825.VAA31144@burp.tkv.asdf.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: qtype addr scorecard From: itojun@iijlab.net Date: Thu, 22 Aug 2002 07:44:05 +0900 Message-Id: <20020821224405.A8AE54B23@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >I was not proposing "synthetic data". What I proposed, can be >simulated manually using current name servers without any change as >follows: > - when you enter A record for address 1.2.3.4, you also enter AAAA > record for ::ffff:1.2.3.4 >It would be a convenience feature, if some new version of server did >this implicitly. no IPv4 mapped address on wire, ever, please. i'm writing up a draft why it is harmful. it is very, very, harmful. itojun -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 22 00:50:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05858 for ; Thu, 22 Aug 2002 00:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hjmG-000MBr-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 21:41:00 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17hjmD-000MBg-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 21:40:57 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17hjmD-0000Wg-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 21:40:57 -0700 Message-Id: <200208212258.g7LMwpd13117@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3363 on Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Wed, 21 Aug 2002 15:58:51 -0700 X-Spam-Status: No, hits=2.7 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3363 Title: Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) Author(s): R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain Status: Informational Date: August 2002 Mailbox: randy@psg.com, alain.durand@sun.com, fink@es.net, ogud@ogud.com, hain@tndh.net Pages: 6 Characters: 11055 Updates: 2673, 2874 I-D Tag: draft-ietf-dnsext-ipv6-addresses-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3363.txt This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status. This document is a product of the DNS Extensions Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020821155708.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3363 --OtherAccess Content-Type: Message/External-body; name="rfc3363.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020821155708.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 22 00:52:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05897 for ; Thu, 22 Aug 2002 00:52:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hjmh-000MCv-00 for namedroppers-data@psg.com; Wed, 21 Aug 2002 21:41:27 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17hjmc-000MC7-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 21:41:22 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17hjmc-0000XO-00 for namedroppers@ops.ietf.org; Wed, 21 Aug 2002 21:41:22 -0700 Message-Id: <200208212302.g7LN2Kd14867@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3364 on Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) Cc: rfc-editor@rfc-editor.org, namedroppers@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Wed, 21 Aug 2002 16:02:20 -0700 X-Spam-Status: No, hits=2.7 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: ** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3364 Title: Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) Author(s): R. Austein Status: Informational Date: August 2002 Mailbox: sra@hactrn.net Pages: 11 Characters: 26544 Obsoletes: 2673, 2874 I-D Tag: draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3364.txt The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on. This document is a product of the DNS Extensions Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <020821160043.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3364 --OtherAccess Content-Type: Message/External-body; name="rfc3364.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <020821160043.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 22 04:46:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18752 for ; Thu, 22 Aug 2002 04:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hnJn-0003DE-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 01:27:51 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hnJj-0003D2-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 01:27:47 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159476; Thu, 22 Aug 2002 03:25:11 -0500 Message-ID: <3D64A07E.1080704@ehsco.com> Date: Thu, 22 Aug 2002 03:27:42 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Paul Vixie CC: namedroppers Subject: Re: draft-dnsext-edns1-04.txt References: <20020815012139.B84F828B6E@as.vix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [late-night comments in-line and at bottom] on 8/14/2002 8:21 PM Paul Vixie wrote: > 2 - Affected Protocol Elements > > 2.1. Multiple queries in a question section have not been supported in > DNS due the applicability of some DNS Message Header flags (such as AA) > and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. > Multiple questions per request are desirable, and some way of asking > them must be made available. Multiple questions is easy. Multiple answers is the hard part. > FM ``First match'' flag. Notable only when multiple questions are > present. If set in a request, nit, "enabled" is more accurate than "set". Flags/bits can be set on and off, but they can only be enabled or disabled. > questions will be processed in > wire order and the first question whose answer would have > NOERROR AND ANCOUNT>0 is treated as if it were the only > question in the query message. Otherwise, questions can be > processed in any order and all possible answer records will be > included in the response. Response FM should be ignored by > requestors. Is there a reason you don't say that servers MUST echo the flag setting received in the query? If so, shouldn't this say that clients MUST ignore the setting? > RRD ``Recursion really desired'' flag. Notable only when a request > is processed by an intermediate name server (``forwarder'') who > is not authoritative for the zone containing QNAME, and where > QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate > name server can only answer using unexpired cached answers > (either positive or negative) which were atomically acquired > using (a) the same QTYPE or set of QTYPEs present in the > current question and whose TTLs were each minimized to the > smallest among them when first cached, and (b) the same FM and > LM settings present in the current question. This needs clarifying. From what I read, a query for MX+A+AAAA with RRD enabled would require that the server only answer the query if each of those RRtypes had been queried distinctly. However, I don't see how this plays into the QTYPE=ANY statement. If the server queried for QTYPE=ANY and got an incomplete answer from its upstream (such as a slave forwarder asking its daddy cache), then the conditions would be satisfied, and the slave could return the same incomplete answer set. I think it might be safest to just say that RRD has no meaning in a response for QTYPE=ANY unless AA is also enabled. Also, the motivation for the synchronized TTLs "when first cached" isn't obvious to me. What do you mean by that, and can you say what you mean in such a way that I understand why? > 4.4. If iteratively processing a multiple question request using an > authority server which can only process single question requests, if any > contributing request generates a SERVFAIL response, then the final > response's RCODE should be SERVFAIL. If you can't indicate unique errors in the answers, MUST be SERVFAIL > 4.5. An authority server processing a query for which QDCOUNT>1 will > respond with a delegation or referral if any of the multiple QTYPEs > present would yield such a response when QDCOUNT==1. What does a cache do? > 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs > where QDCOUNT>1 if the response contains no RRs of that type but some > RRs for one of the other QTYPEs present. q1 may be a negative answer and q2 may not be available (RA=0). There would not be any answer data so this logic doesn't work in that scenario. I don't see a discussion on NODATA processing when it applies to ALL of the questions. No mention of RA=0 here. No mention of truncation either. If the TC bit is enabled, this rule does not apply. How does this rule apply when one of the multipart questions was for CNAME, but the only available answer is a CNAME (no recursion performed). General comments Might want to include a disclaimer that this specifically does not apply to Dynamic DNS. Nowhere do you describe the behavior of caches here. Do they always relay the query and then return the answer (or the error) to the resolver unmolested? Are they allowed to intercept errors and try to complete the query using distinct qtypes if feasible. What kind of knowledge is required for this (eg, based on existing round-trip timers, the cache would be able to fill in the holes before a timer expired)? Or should caches simply default to respond with just the cached data. I assume that RRD is meant to do something here but I can't quite figure out what caches are supposed to do about incomplete answer sets when RD and/or RRD. Or when RD and RRD are mixed, for that matter. How smart should caches try to be?, that is the unanswered question. If it were me, I would make some discussion about how resolvers need to support whatever model gets used here, too. Are there specific timer requirements, specific fallback behaviors, and so forth. Somebody has to perform fallback processing, and it will always be a resolver at some point in time. I assume your expectation is that the EDNS 0.5 mechanisms will be used here although I would make that discussion clear WRT the issues with multiple questions in particular. You don't describe TTL synchronization issues. Should all of the RRsets be treated as a superset and therefore be synchronized? What ramifications does this have for different synchronizations? For example, there might be an NS pointing to an AAAA and an MX pointing to an A, both of which have their own synchronizations. If you start tweaking superset timers then you risk triggering pollution of those synchronizations in a downstream agent. You say that SERVFAIL applies to all answers. If you are going to say that, you might as well say that any RCODE apply to all answers. SERVFAIL and NXDOMAIN are equally obvious here, it seems. Similarly, discuss CNAME processing and how it applies to multiple questions and answers. Is there something we can do with OPT (or a variant) such that negative answers are clearly identified and provided with a TTL of their own? Go ahead and discourage the use of QTYPE=ANY. No need to deprecate it, just say "QTYPE=ANY has been proven to be only useful for testing. Here is what you should use instead of QTYPE=ANY for non-testing lookups" I've said this before. I think that this should be overspecified. We can remove fluff if that is clearly unwarranted later. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 22 08:44:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23666 for ; Thu, 22 Aug 2002 08:44:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hr47-000ELS-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 05:27:55 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17hr3c-000EIf-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 05:27:25 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7MCRGl01612; Thu, 22 Aug 2002 19:27:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7MCQlW13377; Thu, 22 Aug 2002 19:26:47 +0700 (ICT) From: Robert Elz To: "Eric A. Hall" cc: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <3D63FB76.70604@ehsco.com> References: <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Aug 2002 19:26:47 +0700 Message-ID: <13375.1030019207@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 21 Aug 2002 15:43:34 -0500 From: "Eric A. Hall" Message-ID: <3D63FB76.70604@ehsco.com> | You can avoid this if the cache forms answers by assembling discrete | components. That's how qtype ADDR avoids it. As I said in a private reply to a private message, but repeat here for the list - this is optimising the wrong thing. What happens between client & cache is, in the grand scheme of things, irrelevant. None of these schemes are useful unless they work across the net, to the auth servers. That's where optimisation is useful (less traffic to the auth servers, less traffic on the congested wires). If there's a problem with a local cache, there's an easy answer - just install another one, we don't need protocol mods to improve that part of the universe. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 22 11:24:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28862 for ; Thu, 22 Aug 2002 11:24:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17htZw-000KNI-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 08:08:56 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17htZt-000KN1-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 08:08:53 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159532; Thu, 22 Aug 2002 10:06:18 -0500 Message-ID: <3D64FE81.9040300@ehsco.com> Date: Thu, 22 Aug 2002 10:08:49 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Robert Elz CC: Paul Vixie , namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard References: <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> <13375.1030019207@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/22/2002 7:26 AM Robert Elz wrote: > Date: Wed, 21 Aug 2002 15:43:34 -0500 > From: "Eric A. Hall" > Message-ID: <3D63FB76.70604@ehsco.com> > > | You can avoid this if the cache forms answers by assembling discrete > | components. That's how qtype ADDR avoids it. > > As I said in a private reply to a private message, but repeat here for > the list - this is optimising the wrong thing. > > What happens between client & cache is, in the grand scheme of things, > irrelevant. Which cache? For a query against munnari.OZ.AU, my resolver asks (1) my local forwarding cache, who asks (2) my resolving cache, who asks (3) the root, (4) the AU servers, (5) oz.au, and then (6) munnari.oz.au. The benefit isn't limited to the first-hop pair, but can kick in anywhere that one of those 6 caches doesn't support the query. The minimum requirement is for my local forwarding cache to perform this conversion (it MUST be able to handle the query, or the query won't get used anywhere). In the best case, all of the boxes can handle it. In the normal case for the next 10 years, conversion will happen somewhere in the middle. If the root servers can't handle EDNS1 messages, then it would happen whenever any resolving cache asked the root servers. If the root and OZ.AU servers can handle EDNS1 messages, then it would happen whenever any resolving cach asked munnari.oz.au for info. > None of these schemes are useful unless they work across the net, to the > auth servers. Which this does. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 22 15:02:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06850 for ; Thu, 22 Aug 2002 15:02:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hwww-0000gI-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 11:44:54 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hwwr-0000g3-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 11:44:49 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159592; Thu, 22 Aug 2002 13:42:13 -0500 Message-ID: <3D65311C.1060901@ehsco.com> Date: Thu, 22 Aug 2002 13:44:44 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 CC: Paul Vixie , namedroppers Subject: Re: draft-dnsext-edns1-04.txt References: <20020815012139.B84F828B6E@as.vix.com> <3D64A07E.1080704@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=MISSING_HEADERS version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/22/2002 3:27 AM Eric A. Hall wrote: > Nowhere do you describe the behavior of caches here. > If it were me, I would make some discussion about how resolvers need to > support whatever model gets used here, too. I think you can use section 5 from draft-hall-qtype-addr-00.txt as a start to this. Generally speaking, requesters MUST be prepared for queries with QDCOUNT>1 to be refused. When this happens, the requester either returns the error to the original agent, or it issues discrete queries for the missing data before it returns an answer. The decision should be based upon the RD and RRD flags, and the server's willingness to perform recursion. The discrete queries can be sent in parrallel (shotgun) so that cumulatively this is only 2 RTTs (one for error, one for shotgun), which is economically the same as AAAA followed by A. There is a concern here, which is that shotgun queries should not be sent to the root servers, but I'm not sure what is reasonable, or when reasonable can be determined (the query might be answerable by the delegation parent so you can't just wait until you get the authoritative NS list). This process can be used by any requester in the chain, whether this is the original resolver, a slave forwarding server, or a resolving server. Note that this process will only occur once for any query, since the first node to encounter a failure will be the last node to issue QDCOUNT>1. Note also that the first successful query will result in the cache learning about the authoritative servers for the zone. Any subsequent queries which are issued will go to those servers directly, bypassing the delegation chain. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 22 15:23:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07396 for ; Thu, 22 Aug 2002 15:23:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hxLd-0001P8-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 12:10:25 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17hxLa-0001O1-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 12:10:22 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id DF97A1945 for ; Thu, 22 Aug 2002 15:09:49 -0400 (EDT) Date: Thu, 22 Aug 2002 15:09:49 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <3D64FE81.9040300@ehsco.com> References: <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> <13375.1030019207@munnari.OZ.AU> <3D64FE81.9040300@ehsco.com> User-Agent: SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020822190949.DF97A1945@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 22 Aug 2002 10:08:49 -0500, Eric A. Hall wrote: > > Which cache? For a query against munnari.OZ.AU, my resolver asks (1) my > local forwarding cache, who asks (2) my resolving cache, who asks (3) the > root, (4) the AU servers, (5) oz.au, and then (6) munnari.oz.au. > > The benefit isn't limited to the first-hop pair, but can kick in anywhere > that one of those 6 caches doesn't support the query. Your message seems fairly confused about which functions those six entities support. I can't tell whether I'm just misreading what you wrote or you really don't understand this. If I'm just confused, please forgive the following. Let's try using the terminology that's defined in the RFCs to identify the functions that each entity in this scenario performs. (1) is the combination of a caching recursive-mode resolver and a name server. (2) is the combination of a caching iterative-mode resolver and a name server. (3), (4), and (5) are just name servers as far as this query is concerned, not resolvers at all, and thus have no caches at all. I'm quite certain that (3) does not support recursion, I'd be surprised if (4) or (5) do, and certainly none of them should. (6) is either in the same catagory as (3), (4), and (5), or is not involved at all, depending on what you mean by "a query against". So the only caches that should be relevant to this are in the resolver portions of entities (1) and (2), and at least one of us is seriously confused about the benefit you think you're seeing. Last, with all due respect, this QTYPE=ADDR thing just does not work, because it's a single QTYPE that can match more than one RRset, thus whenever the name server answering it has an associated caching resolver, the results you get back will depend on the previous query history of that resolver. This is ok for debugging, but not for operational use. Thus, while you're certainly entitled to say your piece, this approach demonstrably will not work, so I don't understand why you keep bringing it up. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 22 17:16:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11224 for ; Thu, 22 Aug 2002 17:16:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17hzBZ-0004iR-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 14:08:09 -0700 Received: from goose.ehsco.com ([207.65.203.98]) by psg.com with esmtp (Exim 3.36 #1) id 17hzBP-0004hJ-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 14:07:59 -0700 Received: from [68.52.3.151] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 3.5.7) with ESMTP-TLS id 159630; Thu, 22 Aug 2002 16:05:00 -0500 Message-ID: <3D655293.2050209@ehsco.com> Date: Thu, 22 Aug 2002 16:07:31 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Rob Austein CC: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard References: <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> <13375.1030019207@munnari.OZ.AU> <3D64FE81.9040300@ehsco.com> <20020822190949.DF97A1945@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit on 8/22/2002 2:09 PM Rob Austein wrote: > (3), (4), and (5) are just name servers as far as this query is > concerned, not resolvers at all, and thus have no caches at all. > I'm quite certain that (3) does not support recursion, I'd be > surprised if (4) or (5) do, and certainly none of them should. Let me answer this with the qualification that it is not relevant to the discussion at hand. Depending on the question, one of those servers may respond. Whether they are supposed to respond or not is a function of the data they have, their configuration, or their bugs. (3) will indeed return NS and A RRsets in the answer if this data is available through delegation knowledge or glue, even though it shouldn't. (4) or (5) might if they were also configured as secondaries or had similar bugs. I'll demonstrate this if you want, although I'll do this off-list since it's not relevant. The discussion is about where in the query chain fallback processing can happen and the cost of that processing. My point is simply that QDCOUNT>1 can be converted into atomic lookups anywhere in the path, and it can survive from resolver all the way to an authoritative server without any conversion being required, but that at a minimum the first-hop cache has to support it. Actually, upon further though, this latter point is in error, since the resolver can perform the conversion on its own (see the last message for details). > Last, with all due respect, this QTYPE=ADDR thing just does not work, > because it's a single QTYPE that can match more than one RRset, thus > whenever the name server answering it has an associated caching > resolver, the results you get back will depend on the previous query > history of that resolver. Two things. First is that I'm not flogging qtype ADDR other than to use it as an example of one method for caches to process multiple questions. Secondarily, your interpretation of its model is erroneous. I'll gladly clarify this off-list as well, if you wish. -- 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: From owner-namedroppers@ops.ietf.org Thu Aug 22 19:36:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13877 for ; Thu, 22 Aug 2002 19:36:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i1NO-0009FH-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 16:28:30 -0700 Received: from fxshpr08.extra.daimlerchrysler.com ([129.9.80.165] helo=fxshpr06.extra.daimlerchrysler.com) by psg.com with esmtp (Exim 3.36 #1) id 17i1Mq-0009CH-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 16:27:56 -0700 Received: (from uucp@localhost) by fxshpr06.extra.daimlerchrysler.com (8.11.4/8.9.0) id g7MNROi21593 for ; Thu, 22 Aug 2002 19:27:24 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fxshpr08.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAG9aalQ; Thu, 22 Aug 02 19:27:24 -0400 Received: from wokcdts1.is.chrysler.com (extra.daimlerchrysler.com.names.do.not.resolve.sanely.on.the.inside.is.chrysler.com [53.230.102.56]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g7MNQmb22003 for ; Thu, 22 Aug 2002 19:26:48 -0400 (EDT) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g7MNPdJ08220 for ; Thu, 22 Aug 2002 19:25:39 -0400 (EDT) Message-ID: <3D6572F2.750D36E8@daimlerchrysler.com> Date: Thu, 22 Aug 2002 19:25:38 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard References: <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> <13375.1030019207@munnari.OZ.AU> <3D64FE81.9040300@ehsco.com> <20020822190949.DF97A1945@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > At Thu, 22 Aug 2002 10:08:49 -0500, Eric A. Hall wrote: > > Last, with all due respect, this QTYPE=ADDR thing just does not work, > because it's a single QTYPE that can match more than one RRset, thus > whenever the name server answering it has an associated caching > resolver, the results you get back will depend on the previous query > history of that resolver. This is ok for debugging, but not for > operational use. With all due respect to _you_, Rob, read the draft. Sure, "the results you get back will depend on the previous history of that resolver", but that's true for *any* query to a caching resolver (maybe it has a cached answer, maybe it doesn't; maybe it has a negative cache entry, maybe it doesn't; maybe it has cached referral information, maybe it doesn't). The plain fact that caches have "histories" doesn't render the qtype unusable. As the draft specifies, the caching resolver will, if configured to recurse for the query, fetch whatever RRset it happens to be missing (A or AAAA), in order to answer the QTYPE=ADDR question. You seem to be assuming that QTYPE=ADDR will function identically to QTYPE=* inasmuch as it will automatically be denied recursion (who decided that QTYPE=* should automatically be denied recursion, by the way? AFAICT, nothing in the standards -- including the ambiguous query/response examples in RFC 1034 -- mandates this behavior). QTYPE=ADDR behaves differently; it's more diligent about fetching missing data than the current implementations of QTYPE=* resolution algorithms. Note to Eric: please use the "RRset" terminology in the document, and use it consistently. I found the "as an individual group" and "cumulative set of resource records" terms in the the TTL section, for instance, very confusing until I realized you were talking about separate RRsets and combined RRsets, respectively. Since you're basically echoing RFC 2181 in that section, it makes sense to adopt the same terminology used in that document. - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 22 21:41:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15826 for ; Thu, 22 Aug 2002 21:41:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i3Gf-000DAJ-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 18:29:41 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17i3GZ-000D6T-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 18:29:35 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id B594528B6C for ; Fri, 23 Aug 2002 01:28:04 +0000 (GMT) From: Paul Vixie To: namedroppers Subject: Re: draft-dnsext-edns1-04.txt In-Reply-To: Message from "Eric A. Hall" of "Thu, 22 Aug 2002 03:27:42 EST." <3D64A07E.1080704@ehsco.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 23 Aug 2002 01:28:04 +0000 Message-Id: <20020823012804.B594528B6C@as.vix.com> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > FM ``First match'' flag. Notable only when multiple questions are > > present. If set in a request, > > nit, "enabled" is more accurate than "set". Flags/bits can be set on and > off, but they can only be enabled or disabled. other dns rfc's have used set and clear, so i'll stick with that naming. > > included in the response. Response FM should be ignored by > > requestors. > > Is there a reason you don't say that servers MUST echo the flag setting > received in the query? If so, shouldn't this say that clients MUST ignore > the setting? this was fixed in the diffs sent around yesterday. > > RRD ``Recursion really desired'' flag. Notable only when a request > > is processed by an intermediate name server (``forwarder'') who > > is not authoritative for the zone containing QNAME, and where > > QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate > > name server can only answer using unexpired cached answers > > (either positive or negative) which were atomically acquired > > using (a) the same QTYPE or set of QTYPEs present in the > > current question and whose TTLs were each minimized to the > > smallest among them when first cached, and (b) the same FM and > > LM settings present in the current question. > > This needs clarifying. From what I read, a query for MX+A+AAAA with RRD > enabled would require that the server only answer the query if each of > those RRtypes had been queried distinctly. > > However, I don't see how this plays into the QTYPE=ANY statement. If the > server queried for QTYPE=ANY and got an incomplete answer from its > upstream (such as a slave forwarder asking its daddy cache), then the > conditions would be satisfied, and the slave could return the same > incomplete answer set. that's what happens in the QDCOUNT=1 case, so, we're simply specifying that that has not changed in the QDCOUNT>1 case. > I think it might be safest to just say that RRD has > no meaning in a response for QTYPE=ANY unless AA is also enabled. AA in queries isn't meaningful (even though BIND defines RES_AAONLY). > Also, the motivation for the synchronized TTLs "when first cached" isn't > obvious to me. What do you mean by that, and can you say what you mean in > such a way that I understand why? the key word is "atomically." but i agree that trying to salvage any meaning for QTYPE=ANY is probably doomed at this late date, particularly in the case where the EDNS1->!EDNS gateway must speak through a forwarder rather than to the authority servers directly. i'll remove the QTYPE=ANY wording, since it was a debugging wish rather than an operational expectation. > > 4.4. If iteratively processing a multiple question request using an > > authority server which can only process single question requests, if any > > contributing request generates a SERVFAIL response, then the final > > response's RCODE should be SERVFAIL. > > If you can't indicate unique errors in the answers, MUST be SERVFAIL fixed. > > 4.5. An authority server processing a query for which QDCOUNT>1 will > > respond with a delegation or referral if any of the multiple QTYPEs > > present would yield such a response when QDCOUNT==1. > > What does a cache do? a cache would not respond with a referral so they aren't mentioned here. > > 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs > > where QDCOUNT>1 if the response contains no RRs of that type but some > > RRs for one of the other QTYPEs present. > > q1 may be a negative answer and q2 may not be available (RA=0). There > would not be any answer data so this logic doesn't work in that scenario. > > I don't see a discussion on NODATA processing when it applies to ALL of > the questions. > > No mention of RA=0 here. if RA=0 then you should only be going to this server for authoritative answers, in which case none of this except 4.6 applies in any case. > No mention of truncation either. If the TC bit is enabled, this rule does > not apply. i do not think it's nec'y to respecify TC handling; rfc1035 does a fine job. > How does this rule apply when one of the multipart questions was for > CNAME, but the only available answer is a CNAME (no recursion performed). since it is an error for there to be any other RR present at a node if there is a CNAME present at that node, this condition cannot occur. > General comments > > Might want to include a disclaimer that this specifically does not apply > to Dynamic DNS. dynamic dns specifies its own definition for the field variable occupied by "QDCOUNT". i think i won't mention that it's unaffected by this proposal. more later. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Thu Aug 22 23:28:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17477 for ; Thu, 22 Aug 2002 23:28:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i4z4-000GlU-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 20:19:38 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17i4z0-000Gjl-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 20:19:35 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3DC2F1945 for ; Thu, 22 Aug 2002 23:18:26 -0400 (EDT) Date: Thu, 22 Aug 2002 23:18:26 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <3D6572F2.750D36E8@daimlerchrysler.com> References: <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> <13375.1030019207@munnari.OZ.AU> <3D64FE81.9040300@ehsco.com> <20020822190949.DF97A1945@thrintun.hactrn.net> <3D6572F2.750D36E8@daimlerchrysler.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020823031826.3DC2F1945@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 22 Aug 2002 19:25:38 -0400, Kevin Darcy wrote: > > With all due respect to _you_, Rob, read the draft....As the draft specifies, > the caching resolver will, if configured to recurse for the query, fetch > whatever RRset it happens to be missing (A or AAAA), in order to answer the > QTYPE=ADDR question. You seem to be assuming that QTYPE=ADDR will function > identically to QTYPE=* inasmuch as it will automatically be denied recursion Oh. You're right, I assumed that its behavior was similar to *, MAILA, and MAILB, because that's what I thought Eric had said on the list. My oops. > (who decided that QTYPE=* should automatically be denied recursion, by the > way? AFAICT, nothing in the standards -- including the ambiguous > query/response examples in RFC 1034 -- mandates this behavior). QTYPE=* doesn't disable recursion, it just stops as soon as it finds anything that matches, which is not quite the same thing. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 01:09:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18980 for ; Fri, 23 Aug 2002 01:09:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i6ab-000KH6-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 22:02:29 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17i6aY-000KGv-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 22:02:26 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17i6aY-000APt-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 22:02:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200208230237.TAA00344@spin.SFBay.Sun.COM> To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support Date: Thu, 22 Aug 2002 19:37:53 -0700 From: Scott Seligman X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Rob Austein writes: > > I agree with Andreas. This draft modifies the downcasing rule... > > Side question related to this point: do folks feel that the draft goes > into enough detail on this point? I found it a bit terse, but failed > to come up with anything useful when Andreas quite reasonably asked me > to suggest better text. While this is probably beyond the scope of the current discussion, the downcasing rule in RFC 2535 says: "all domain name letters are set to lower case". How does this work for a label that includes non-ASCII octets? The RFC uses \200.z.foo.example as an example domain name. Suppose it had used this instead: \200\167\115\199.foo.example The octet \115 in there happens to be in the range of ASCII, although from context one might guess that it may not represent the character "S". Would the above be mapped to: \200\167s\199.foo.example Although it's not clear what someone would intend with such a domain name, it's a good bet that they did not intend this. Scott Seligman Java Security, Networking, and Naming Sun Microsystems -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 03:08:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29767 for ; Fri, 23 Aug 2002 03:08:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i8Fb-000OCJ-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 23:48:55 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17i8FX-000OAB-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 23:48:52 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3F8431945 for ; Fri, 23 Aug 2002 02:48:20 -0400 (EDT) Date: Fri, 23 Aug 2002 02:48:20 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support In-Reply-To: <200208230237.TAA00344@spin.SFBay.Sun.COM> References: <200208230237.TAA00344@spin.SFBay.Sun.COM> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020823064820.3F8431945@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Thu, 22 Aug 2002 19:37:53 -0700, Scott Seligman wrote: > > While this is probably beyond the scope of the current discussion, > the downcasing rule in RFC 2535 says: "all domain name letters > are set to lower case". How does this work for a label that includes > non-ASCII octets? The rule still applies. Note: 1) The RFC2535 rule only applies to computation of the "cannonical form" of a DNS name, which is used in place of the raw DNS name when computing signatures, sorting names while inserting NXT RRs, and so forth. The RFC2535 rule shouldn't be read to imply that the original record itself has been modified in any way. 2) DNS (from RFC 883 through the present day) is case-insensitive but case-preserving for the range of octet values that correspond to the US-ASCII alphabet. Basicly, this means that DNS preserves case in DNS labels when it's convenient for an implementation to do so, but you can't assume that case has been preserved in any particular DNS name (except, maybe, for the leftmost label of a DNS name). 3) I would redirect any follow-up on point (2) to the IDN WG, except that (a) anything that anyone could possibly say on this subject has almost certainly already been said there, and (b) James and Marc would hurt me. :) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 03:08:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29782 for ; Fri, 23 Aug 2002 03:08:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i8Jy-000OLh-00 for namedroppers-data@psg.com; Thu, 22 Aug 2002 23:53:26 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17i8Jk-000OLD-00 for namedroppers@ops.ietf.org; Thu, 22 Aug 2002 23:53:16 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7N6qel13868; Fri, 23 Aug 2002 13:52:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7N6qRW21641; Fri, 23 Aug 2002 13:52:27 +0700 (ICT) From: Robert Elz To: Scott Seligman cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: Unknown types support In-Reply-To: <200208230237.TAA00344@spin.SFBay.Sun.COM> References: <200208230237.TAA00344@spin.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 13:52:27 +0700 Message-ID: <21639.1030085547@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 22 Aug 2002 19:37:53 -0700 From: Scott Seligman Message-ID: <200208230237.TAA00344@spin.SFBay.Sun.COM> | While this is probably beyond the scope of the current discussion, Yes... | The octet \115 in there happens to be in the range of ASCII, | although from context one might guess that it may not represent the | character "S". Would the above be mapped to: | | \200\167s\199.foo.example Yes, absolutely beyond doubt. The DNS does not ('*' excepted) assign any meanings to the labels in domain names - they're just sequences of octets. | Although it's not clear what someone would intend with such a | domain name, it's a good bet that they did not intend this. Then they didn't understand the DNS well enough to be assigning names in the first place. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 03:21:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29975 for ; Fri, 23 Aug 2002 03:21:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i8bw-000P3X-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 00:12:00 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17i8bt-000P2J-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 00:11:57 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8EBD21945 for ; Fri, 23 Aug 2002 03:11:25 -0400 (EDT) Date: Fri, 23 Aug 2002 03:11:25 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <20020821192350.09D9528B6F@as.vix.com> References: <20020821175403.6FC621900@thrintun.hactrn.net> <20020821192350.09D9528B6F@as.vix.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020823071125.8EBD21945@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Wed, 21 Aug 2002 19:23:50 +0000, Paul Vixie wrote: > > based on what we see at the root name servers, caching (statistically > speaking) just doesn't happen. that ought to get fixed. but i'm betting > that it's more wide spread -- that every authoritative zone, and not just > ".", is getting pounded by repeated queries for both existing and non- > existing names. if we take approach (1) then let's also embark on an > internet-wide crusade to improve dns caching. I know that: - we have hard data on the unbelievable amount of garbage that hits the root name servers; - we have theoretical work attempting to demonstrate that caching of leaf data (not delegations) is most useful (for web browsers) in the first ten or twenty minutes after being cached; and - we're pretty sure that negative caching is under-utilized; but do we really have data to suggest that caching isn't happening at all on any significant scale? If so, it's news to me, please share. :) The thing about the above breakdown is that most of the traffic either comes from bad practice (whether coding or operational) or from traffic patterns that don't cache well, so it's not clear that an optimization to the query process is going to help that much. Improving DNS caching Internet-wide sounds like a worthy goal in any case. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 03:50:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00553 for ; Fri, 23 Aug 2002 03:50:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i8xd-000PRE-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 00:34:25 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17i8xH-000PPb-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 00:34:06 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7N7W3l17760; Fri, 23 Aug 2002 14:32:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7N7VcW21681; Fri, 23 Aug 2002 14:31:38 +0700 (ICT) From: Robert Elz To: "Eric A. Hall" cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <3D655293.2050209@ehsco.com> References: <3D655293.2050209@ehsco.com> <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> <13375.1030019207@munnari.OZ.AU> <3D64FE81.9040300@ehsco.com> <20020822190949.DF97A1945@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 2002 14:31:38 +0700 Message-ID: <21679.1030087898@munnari.OZ.AU> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Thu, 22 Aug 2002 16:07:31 -0500 From: "Eric A. Hall" Message-ID: <3D655293.2050209@ehsco.com> | The discussion is about where in the query chain fallback processing can | happen and the cost of that processing. My point is simply that QDCOUNT>1 | can be converted into atomic lookups anywhere in the path, and it can | survive from resolver all the way to an authoritative server without any | conversion being required, but that at a minimum the first-hop cache has | to support it. yes, but you keep missing the point. All of this is possible, what matters is the cost, and whether it is likely to be a benefit or not over the life of the proposal. The analysis of this is completely different for ADDR and for EDNS1. ADDR is useful only while A records remain alive. That is, the net benefit from using it must outweigh the deployment costs. As I showed in another message (which may have been off list, so readers other than Eric, & maybe Greg, might not have seen it), early in its deployment, ADDR costs more than doing nothing. It can double the delay and add 50% to packet counts. If we reach a stage where most of the net supports ADDR, then it can save 50% of the packet costs (no delay savings of note). Once A vanishes, ADDR starts costing more than not having it again, though at a smaller rate that is harder to calculate (it's because negative caches time out faster than positive ones). If there was no ADDR, clients by then would be just doing AAAA as in general, all they care about is an address, very few actually want both - the dual query is a transition mechanism to find AAAA when it exists, but fall back to A when it doesn't. When A is vanishing, one presumes just about everyone will have AAAA, so the AAAA query would return an address, and no A query would be wanted. But if ADDR is being used, no-one can assume that, the cache still has to go hunting for the non-existing A records. So, we have a period of increased costs, a period of benefit, and then forever after, increased costs. The period of benefit would have to be a HUGE benefit to make this a worthwhile - and it isn't. So, can we just forget ADDR, forever, please? | First is that I'm not flogging qtype ADDR other than to use it | as an example of one method for caches to process multiple questions. A job which its special nature makes it particularly bad at. EDNS1 on the other hand doesn't have these problems - the client gets to specify the actual data wanted, and the FM flag means that the (very common) "I only need this other record if the first one doesn't exist" semantic can be processed (for the AAAA & A case, the cache only needs the AAAA records, if they exist, it never needs to bother with A records, in the common client query of "Give me AAAA if they exist, otherwise A".) We still need to evaluate the costs of EDNS1 vs its benefits. Just as ADDR, it increases delay & packets while it is being deployed. And then it can descrease packets while it is in use. But it has no end point, there's no point after which it starts costing more again. And it has more general applicability, so this one isn't as easy to just write off as useless. I appreciate Rob Austein's point - just let the cache's do the work, and if the multiple queries in EDNS1 didn't have the FM capability, but always requested all the answers, I think that would sway me. But it is real hard to do a "a or b or c" (as in MX, or AAAA, or A) query using the DNS without excessive delay, or excessive waste (the queries are either serialised, in which case you have 3 RTTs to get a useful answer, or sent in parallel, in which case you get all three answers, and in many cases, discard 2 of them - wasted work for the server, and for the network). On balance, I think EDNS1 is worth the deployment pain, and increased usage costs while that is happening. kre -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 04:08:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00876 for ; Fri, 23 Aug 2002 04:08:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17i9PH-000Puz-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 01:02:59 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17i9PB-000Puo-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 01:02:53 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 697B528B6C; Fri, 23 Aug 2002 08:02:53 +0000 (GMT) From: Paul Vixie To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: Message from Rob Austein of "Fri, 23 Aug 2002 03:11:25 -0400." <20020823071125.8EBD21945@thrintun.hactrn.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 23 Aug 2002 08:02:53 +0000 Message-Id: <20020823080253.697B528B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > but do we really have data to suggest that caching isn't happening at > all on any significant scale? If so, it's news to me, please share. :) the data at hand indicates that a great number of people do not cache referrals, either positively or negatively. i've provided several (anonymized) tcpdumps to caida over the years, so let's ask them to comment. > The thing about the above breakdown is that most of the traffic either > comes from bad practice (whether coding or operational) or from > traffic patterns that don't cache well, so it's not clear that an > optimization to the query process is going to help that much. i completely agree. > Improving DNS caching Internet-wide sounds like a worthy goal in any case. yes indeed. but it'll receive no real attention unless one of two things happens. (1) one more person comes forward with a design proposal of the form "we don't need to do that because caching will take care of it" or (2) the amount of rejected repeated useless query traffic at some root server exceeds 1 gigabit per second. (both of those things will happen within my lifetime, unless i miss my guess.) -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 11:28:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09490 for ; Fri, 23 Aug 2002 11:28:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iG2k-0008xS-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 08:08:10 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17iG2h-0008xA-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 08:08:07 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17iG2e-000AvP-00; Fri, 23 Aug 2002 08:08:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard References: <20020821175403.6FC621900@thrintun.hactrn.net> <20020821192350.09D9528B6F@as.vix.com> <20020823071125.8EBD21945@thrintun.hactrn.net> Message-Id: Date: Fri, 23 Aug 2002 08:08:04 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > but do we really have data to suggest that caching isn't happening at > all on any significant scale? If so, it's news to me, please share. :) hari's work at mit said the opposite, yes? sorry, their server is rejecting me this morning, so no url. but there was even a presentation at dnsops a bit ago. randy -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 14:33:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14002 for ; Fri, 23 Aug 2002 14:33:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iJ5Q-000EhE-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 11:23:08 -0700 Received: from fxodpr13.extra.daimlerchrysler.com ([129.9.82.74]) by psg.com with esmtp (Exim 3.36 #1) id 17iJ5F-000EgA-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 11:22:57 -0700 Received: (from uucp@localhost) by fxodpr13.extra.daimlerchrysler.com (8.11.4/8.9.0) id g7NIH8e19575 for ; Fri, 23 Aug 2002 14:17:08 -0400 (EDT) Received: from shmrspr1-pf0.shdc.chrysler.com(129.9.145.48) by fxodpr13.extra.daimlerchrysler.com via csmap (V6.0) id srcAAAD5aWoM; Fri, 23 Aug 02 14:17:08 -0400 Received: from wokcdts1.is.chrysler.com (extra.daimlerchrysler.com.names.do.not.resolve.sanely.on.the.inside.is.chrysler.com [53.230.102.56]) by shmrspr1-pf0.shdc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id g7NIMos11500 for ; Fri, 23 Aug 2002 14:22:51 -0400 (EDT) Received: from daimlerchrysler.com (wokcdts1.is.chrysler.com [53.230.102.164]) by wokcdts1.is.chrysler.com (8.11.2/8.9.1) with ESMTP id g7NILmJ12306 for ; Fri, 23 Aug 2002 14:21:48 -0400 (EDT) Message-ID: <3D667D3C.B77AC117@daimlerchrysler.com> Date: Fri, 23 Aug 2002 14:21:48 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.74 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard References: <3D63FB76.70604@ehsco.com> <20020821192350.09D9528B6F@as.vix.com> <13375.1030019207@munnari.OZ.AU> <3D64FE81.9040300@ehsco.com> <20020822190949.DF97A1945@thrintun.hactrn.net> <3D6572F2.750D36E8@daimlerchrysler.com> <20020823031826.3DC2F1945@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > At Thu, 22 Aug 2002 19:25:38 -0400, Kevin Darcy wrote: > > > > With all due respect to _you_, Rob, read the draft....As the draft specifies, > > the caching resolver will, if configured to recurse for the query, fetch > > whatever RRset it happens to be missing (A or AAAA), in order to answer the > > QTYPE=ADDR question. You seem to be assuming that QTYPE=ADDR will function > > identically to QTYPE=* inasmuch as it will automatically be denied recursion > > Oh. You're right, I assumed that its behavior was similar to *, > MAILA, and MAILB, because that's what I thought Eric had said on the > list. My oops. > > > (who decided that QTYPE=* should automatically be denied recursion, by the > > way? AFAICT, nothing in the standards -- including the ambiguous > > query/response examples in RFC 1034 -- mandates this behavior). > > QTYPE=* doesn't disable recursion, it just stops as soon as it finds > anything that matches, which is not quite the same thing. A minor semantic distinction. It *could* recurse the QTYPE=* query if it wanted to. It chooses not to. In this context, has it "disabled recursion" (perhaps "declined" would have been a better word choice) or is recursion unnecessary? It can be viewed either way. (Obviously, it would behoove any implementation that would actually consider recursing a QTYPE=* query to keep track of whether it already has an intact, no-RRsets-expired answer to a previous QTYPE=* query for the same name, since in that case it can answer from the cache just like it would for a normal QTYPE). - Kevin -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 14:34:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14059 for ; Fri, 23 Aug 2002 14:34:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iJ9P-000Epn-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 11:27:15 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17iJ9H-000EoK-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 11:27:08 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3054118E0 for ; Fri, 23 Aug 2002 14:26:36 -0400 (EDT) Date: Fri, 23 Aug 2002 14:26:36 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: References: <20020821175403.6FC621900@thrintun.hactrn.net> <20020821192350.09D9528B6F@as.vix.com> <20020823071125.8EBD21945@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020823182636.3054118E0@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 23 Aug 2002 08:08:04 -0700, Randy Bush wrote: > > hari's work at mit said the opposite, yes? sorry, their server > is rejecting me this morning, so no url. but there was even a > presentation at dnsops a bit ago. Jaeyeon Jung's slides from the DNSMEAS BOF in the proceedings from the Salt Lake IETF suggest a DNS cache hit rate of 80%-86% at MIT. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 15:10:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14916 for ; Fri, 23 Aug 2002 15:10:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iJhk-000FwS-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 12:02:44 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17iJhh-000FwF-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 12:02:41 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 8C86B28B6C for ; Fri, 23 Aug 2002 19:02:40 +0000 (GMT) From: Paul Vixie To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: Message from Rob Austein of "Fri, 23 Aug 2002 14:26:36 -0400." <20020823182636.3054118E0@thrintun.hactrn.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Fri, 23 Aug 2002 19:02:40 +0000 Message-Id: <20020823190240.8C86B28B6C@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > hari's work at mit said the opposite, yes? sorry, their server > > is rejecting me this morning, so no url. but there was even a > > presentation at dnsops a bit ago. > > Jaeyeon Jung's slides from the DNSMEAS BOF in the proceedings from the > Salt Lake IETF suggest a DNS cache hit rate of 80%-86% at MIT. that's great but we need to know the impact on authority servers not just the hit ratio of caching recursive forwarders. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 23 17:49:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18450 for ; Fri, 23 Aug 2002 17:49:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17iM7b-000Kfw-00 for namedroppers-data@psg.com; Fri, 23 Aug 2002 14:37:35 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17iM7Y-000KfY-00 for namedroppers@ops.ietf.org; Fri, 23 Aug 2002 14:37:32 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 80DEB1900 for ; Fri, 23 Aug 2002 17:37:00 -0400 (EDT) Date: Fri, 23 Aug 2002 17:37:00 -0400 From: Rob Austein To: namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: <20020823190240.8C86B28B6C@as.vix.com> References: <20020823182636.3054118E0@thrintun.hactrn.net> <20020823190240.8C86B28B6C@as.vix.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.3 (Unebigoryòmae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020823213700.80DEB1900@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At Fri, 23 Aug 2002 19:02:40 +0000, Paul Vixie wrote: > > that's great but we need to know the impact on authority servers > not just the hit ratio of caching recursive forwarders. That is indeed a different study, and as far as I know it isn't one that anybody has performed. Work to date has concentrated on the view from the client, the view from the root, and performance. If somebody with a seriously-high-traffic name server two or more levels down the tree wanted to work with some researcher who had time and funding to look into this, it might be a good thing. TLD data would also be interesting, but weirdness factors at TLD name servers, while not as high as at root name servers, might still be high enough to complicate interpretation of the data. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 26 13:54:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16258 for ; Mon, 26 Aug 2002 13:54:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jNiz-0003XC-00 for namedroppers-data@psg.com; Mon, 26 Aug 2002 10:32:25 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17jNiq-0003Wq-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 10:32:16 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7QHWDr26615; Mon, 26 Aug 2002 10:32:13 -0700 (PDT) From: Bill Manning Message-Id: <200208261732.g7QHWDr26615@boreas.isi.edu> Subject: Re: DS design questions In-Reply-To: <5.1.0.14.2.20020102224702.024262b0@localhost> from =?us-ascii?Q?=3D=3Fiso=2D8859=2D1=3FQ=3F=3DD3lafur=3F=3D=3D=3F?= =?us-ascii?Q?iso=2D8859=2D1=3FQ=3F=5FGu=3DF0mundsson=3F=3D?= at "Jan 2, 2 11:55:00 pm" To: ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?==?iso-8859-1?Q?_Gu=F0mundsson?=) Date: Mon, 26 Aug 2002 10:32:13 -0700 (PDT) Cc: namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit a couple of questions came up last week in our testing of the recent bind snapshot (9.3.0s20020722). -- how breakable is the key? e.g. ("They generated it with old package X which has these seven known bugs. Also it appears to have a kleptographic Trojan Horse.") Who has looked at the algorithm implementation for correctness? -- allowable key lengths. there is a desire to use keys larger than the 1024 at some points in the DNS heirarchy. -- are there any other signing tools than those that come with the bind distribution? --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 26 14:26:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17573 for ; Mon, 26 Aug 2002 14:26:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jORP-0005Hl-00 for namedroppers-data@psg.com; Mon, 26 Aug 2002 11:18:19 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17jORM-0005HZ-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 11:18:16 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g7QII0C14210; Mon, 26 Aug 2002 11:18:00 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Mon, 26 Aug 2002 11:17:59 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Bill Manning cc: =?iso-8859-1?Q?=D3lafur?==?iso-8859-1?Q?_Gu=F0mundsson?= , Subject: Re: DS design questions In-Reply-To: <200208261732.g7QHWDr26615@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 26 Aug 2002, Bill Manning wrote: > -- allowable key lengths. there is a desire to use keys larger than > the 1024 at some points in the DNS heirarchy. RSA is defined for up to 4096 bits in RFC 3110. I don't know of any problems using the bind-provided key generation program / signing tools with keys this large, except that performance is really bad (which is a limitation of modern hardware). The DSA algorithm is only defined to 1024 bits, so there's nothing DNSSEC can do. > -- are there any other signing tools than those that come with the > bind distribution? I don't know of any other public tools. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 26 14:29:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17714 for ; Mon, 26 Aug 2002 14:29:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jOV2-0005Q7-00 for namedroppers-data@psg.com; Mon, 26 Aug 2002 11:22:04 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17jOUw-0005Pw-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 11:21:59 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7QILq705955; Mon, 26 Aug 2002 11:21:52 -0700 (PDT) From: Bill Manning Message-Id: <200208261821.g7QILq705955@boreas.isi.edu> Subject: Re: DS design questions In-Reply-To: from Brian Wellington at "Aug 26, 2 11:17:59 am" To: Brian.Wellington@nominum.com (Brian Wellington) Date: Mon, 26 Aug 2002 11:21:52 -0700 (PDT) Cc: bmanning@ISI.EDU, ogud@ogud.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % On Mon, 26 Aug 2002, Bill Manning wrote: % % > -- allowable key lengths. there is a desire to use keys larger than % > the 1024 at some points in the DNS heirarchy. % % RSA is defined for up to 4096 bits in RFC 3110. I don't know of any % problems using the bind-provided key generation program / signing tools % with keys this large, except that performance is really bad (which is a % limitation of modern hardware). The DSA algorithm is only defined to 1024 % bits, so there's nothing DNSSEC can do. % Sigh... DSA or RSA or both? didn't we have this discussion back in the day? can we mix DSA/RSA using DS with impunity? will the resolver beable to follow a validity chain? (he asks, hoping someone else has tested this first...) -- --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 26 14:37:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18080 for ; Mon, 26 Aug 2002 14:37:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jOd1-0005m4-00 for namedroppers-data@psg.com; Mon, 26 Aug 2002 11:30:19 -0700 Received: from spratly.wl.nominum.com ([128.177.195.135] helo=spratly.nominum.com) by psg.com with esmtp (Exim 3.36 #1) id 17jOcq-0005kI-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 11:30:08 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.6/8.11.6) with ESMTP id g7QITqR14294; Mon, 26 Aug 2002 11:29:53 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Mon, 26 Aug 2002 11:29:52 -0700 (PDT) From: Brian Wellington X-X-Sender: bwelling@spratly.nominum.com To: Bill Manning cc: ogud@ogud.com, Subject: Re: DS design questions In-Reply-To: <200208261821.g7QILq705955@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Mon, 26 Aug 2002, Bill Manning wrote: > % On Mon, 26 Aug 2002, Bill Manning wrote: > % > % > -- allowable key lengths. there is a desire to use keys larger than > % > the 1024 at some points in the DNS heirarchy. > % > % RSA is defined for up to 4096 bits in RFC 3110. I don't know of any > % problems using the bind-provided key generation program / signing tools > % with keys this large, except that performance is really bad (which is a > % limitation of modern hardware). The DSA algorithm is only defined to 1024 > % bits, so there's nothing DNSSEC can do. > > Sigh... DSA or RSA or both? I don't think there's a limitation on the RSA algorithm; RFC 3110 limits DNSSEC to 4096 bits. The DSA algorithm is limited to 1024 bits. > didn't we have this discussion back in the day? Which discussion? > can we mix DSA/RSA using DS with impunity? Yes. > will the resolver beable to follow a validity chain? Yes. > (he asks, hoping someone else has tested this first...) See the bind9 dnssec test suite, which uses RSA-MD5, DSA, and RSA-SHA1 in the same tree. Brian -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 26 14:44:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18387 for ; Mon, 26 Aug 2002 14:44:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jOk4-000655-00 for namedroppers-data@psg.com; Mon, 26 Aug 2002 11:37:36 -0700 Received: from boreas.isi.edu ([128.9.160.161]) by psg.com with esmtp (Exim 3.36 #1) id 17jOju-00064D-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 11:37:26 -0700 Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7QIbKh18020; Mon, 26 Aug 2002 11:37:20 -0700 (PDT) From: Bill Manning Message-Id: <200208261837.g7QIbKh18020@boreas.isi.edu> Subject: Re: DS design questions In-Reply-To: from Brian Wellington at "Aug 26, 2 11:29:52 am" To: Brian.Wellington@nominum.com (Brian Wellington) Date: Mon, 26 Aug 2002 11:37:20 -0700 (PDT) Cc: bmanning@ISI.EDU, ogud@ogud.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % > didn't we have this discussion back in the day? % % Which discussion? % % > can we mix DSA/RSA using DS with impunity? % % Yes. % % > will the resolver beable to follow a validity chain? % % Yes. % % > (he asks, hoping someone else has tested this first...) % % See the bind9 dnssec test suite, which uses RSA-MD5, DSA, and RSA-SHA1 in % the same tree. % % Brian will look. I remember having problems with a child using RSA and the parent using DSA but that was so long ago... -- --bill -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Mon Aug 26 14:50:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18585 for ; Mon, 26 Aug 2002 14:50:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jOoM-0006KW-00 for namedroppers-data@psg.com; Mon, 26 Aug 2002 11:42:02 -0700 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 17jOoH-0006KK-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 11:41:57 -0700 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 70B18137F02; Mon, 26 Aug 2002 11:41:57 -0700 (PDT) To: Brian Wellington Cc: Bill Manning , =?iso-8859-1?Q?=D3lafur?==?iso-8859-1?Q?_Gu=F0mundsson?= , namedroppers@ops.ietf.org Subject: Re: DS design questions In-Reply-To: Message from Brian Wellington of "Mon, 26 Aug 2002 11:17:59 PDT." Date: Mon, 26 Aug 2002 11:41:57 -0700 Message-ID: <29260.1030387317@shell.nominum.com> From: Jim Reid X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk >>>>> "Brian" == Brian Wellington writes: >> On Mon, 26 Aug 2002, Bill Manning wrote: >> -- are there any other signing tools than those that come with >> the bind distribution? Brian> I don't know of any other public tools. What about the Perl stuff Olaf developed at RIPE NCC? I dunno if this implements DS yet though. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 27 02:55:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13392 for ; Tue, 27 Aug 2002 02:55:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jZy1-000FJ8-00 for namedroppers-data@psg.com; Mon, 26 Aug 2002 23:36:45 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17jZxy-000FIs-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 23:36:42 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17jZxx-0007ev-00 for namedroppers@ops.ietf.org; Mon, 26 Aug 2002 23:36:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200208270635.g7R6Zd6T022743@birch.ripe.net> In-reply-to: Your message of Mon, 26 Aug 2002 10:32:13 PDT. <200208261732.g7QHWDr26615@boreas.isi.edu> References: <200208261732.g7QHWDr26615@boreas.isi.edu> To: Bill Manning cc: ogud@ogud.com (=?iso-8859-1?Q?=D3lafur?==?iso-8859-1?Q?_Gu=F0mundsson?=), namedroppers@ops.ietf.org Subject: Re: DS design questions From: Olaf Kolkman Date: Tue, 27 Aug 2002 08:35:39 +0200 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit * -- are there any other signing tools than those that come with the * bind distribution? Net::DNS::RR::SIG (from the Net::DNS::SEC package, on www.ripe.net/disi and CPAN has a create method with which you can make signatures.) You can use that to generate signatures. To sign a zone file you need more code. Can be done but in perl it is slow. I have made a signer once, it will need to be worked on a little and I do not think it is suitable for real distribution so to speak. If you want to toy with it send me a message. --Olaf --------------------------------------------| Olaf M. Kolkman | www.ripe.net/disi -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 27 18:03:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14277 for ; Tue, 27 Aug 2002 18:03:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jo98-000IeI-00 for namedroppers-data@psg.com; Tue, 27 Aug 2002 14:45:10 -0700 Received: from dhcp64-134-81-89.hat.dca.wayport.net ([64.134.81.89] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17jo95-000Ie2-00 for namedroppers@ops.ietf.org; Tue, 27 Aug 2002 14:45:07 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17jo95-00038g-00 for namedroppers@ops.ietf.org; Tue, 27 Aug 2002 14:45:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Subject: Nomcom call for volunteers Date: Tue, 27 Aug 2002 14:44:44 -0400 X-Spam-Status: No, hits=1.1 required=5.0 tests=TO_MALFORMED version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Tue Aug 27 23:36:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22330 for ; Tue, 27 Aug 2002 23:36:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17jtPl-0009yx-00 for namedroppers-data@psg.com; Tue, 27 Aug 2002 20:22:41 -0700 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17jtPh-0009ym-00 for namedroppers@ops.ietf.org; Tue, 27 Aug 2002 20:22:38 -0700 Received: from tecotoo.www.gis.net ([216.41.28.250]) by mx03.gis.net; Tue, 27 Aug 2002 23:22:36 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id xa028259 for ; Tue, 27 Aug 2002 21:54:02 -0400 Message-Id: <4.3.1.2.20020827214554.00e5fed0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 27 Aug 2002 21:53:52 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Markku Savela From: Danny Mayer Subject: Re: qtype addr scorecard Cc: kre@munnari.OZ.AU, ehall@ehsco.com, ghudson@MIT.EDU, namedroppers@ops.ietf.org In-Reply-To: References: <200208210837.LAA30623@burp.tkv.asdf.org> <3D627FD8.2000303@ehsco.com> <3D6136D6.4050104@ehsco.com> <3D610D8F.6020002@ehsco.com> <3D592E51.2090906@ehsco.com> <26664.1029775278@munnari.OZ.AU> <29368.1029850278@munnari.OZ.AU> <3D6255B8.10203@ehsco.com> <1029862504.1283.243.camel@error-messages.mit.edu> <7853.1029914515@munnari.OZ.AU> <200208210837.LAA30623@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 01:26 PM 8/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >I don't know much about Windows, but in my understanding, (at least >some previous versions of) winsock does even not have the support of >IPv4-mapped addresses (as described in RFC 2553). According to the documentation that I have Windows XP and later supports 4 types of compatibility addresses: ISATAP, 6to4 (RFC 3056), 6over4 (RFC 2529) and IPv4 compatible ( ::w.x.y.z). The supported getaddrinfo() is only available on XP and later. I don't expect any of this to be available on WNT, W2K or any of the Win9x O/S's even with MSR's IPv6 stack or the Win2K Technology Preview, though I could be wrong. Maybe one of the Microsoft people could comment. Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 28 08:10:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26154 for ; Wed, 28 Aug 2002 08:10:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17k1RR-0008kx-00 for namedroppers-data@psg.com; Wed, 28 Aug 2002 04:56:57 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17k1RK-0008kc-00 for namedroppers@ops.ietf.org; Wed, 28 Aug 2002 04:56:50 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24447; Wed, 28 Aug 2002 07:55:19 -0400 (EDT) Message-Id: <200208281155.HAA24447@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-mdns-12.txt Date: Wed, 28 Aug 2002 07:55:19 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,DOUBLE_CAPSWORD,EXCUSE_6 version=2.31 X-Spam-Level: **** Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-12.txt Pages : 20 Date : 2002-8-27 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-12.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-12.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-12.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: <2002-8-27144408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-mdns-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-mdns-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144408.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 28 08:36:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27197 for ; Wed, 28 Aug 2002 08:36:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17k1vT-000AGX-00 for namedroppers-data@psg.com; Wed, 28 Aug 2002 05:27:59 -0700 Received: from wireless207.east.isi.edu ([65.123.202.207] helo=snout.autonomica.net) by psg.com with esmtp (Exim 3.36 #1) id 17k1vP-000AGF-00 for namedroppers@ops.ietf.org; Wed, 28 Aug 2002 05:27:56 -0700 Received: by snout.autonomica.net (Postfix, from userid 1211) id 15FC3FA8; Tue, 27 Aug 2002 21:05:57 +0200 (CEST) To: Brian Wellington Cc: Bill Manning , ogud@ogud.com, Subject: Re: DS design questions References: From: Johan Ihren Date: 27 Aug 2002 21:05:57 +0200 In-Reply-To: Message-ID: <2cadn8nmui.fsf@snout.autonomica.net> Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_12_24 version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Brian Wellington writes: > > % bits, so there's nothing DNSSEC can do. > > > > Sigh... DSA or RSA or both? > > I don't think there's a limitation on the RSA algorithm; RFC 3110 limits > DNSSEC to 4096 bits. > > The DSA algorithm is limited to 1024 bits. > > > didn't we have this discussion back in the day? > > Which discussion? San Diego, December 2000... ;-) Johan -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 28 13:27:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10362 for ; Wed, 28 Aug 2002 13:27:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17k6NZ-000Ox1-00 for namedroppers-data@psg.com; Wed, 28 Aug 2002 10:13:17 -0700 Received: from mx05.gis.net ([208.218.130.13] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17k6NW-000Owq-00 for namedroppers@ops.ietf.org; Wed, 28 Aug 2002 10:13:14 -0700 Received: from tecotoo.www.gis.net ([216.41.72.37]) by mx05.gis.net; Wed, 28 Aug 2002 13:13:12 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id pa028277 for ; Wed, 28 Aug 2002 13:13:09 -0400 Message-Id: <4.3.1.2.20020828131051.04ba5330@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 28 Aug 2002 13:12:56 -0400 To: Paul Vixie , Rob Austein From: Danny Mayer Subject: Re: qtype addr scorecard Cc: namedroppers@ops.ietf.org In-Reply-To: <20020823080253.697B528B6C@as.vix.com> References: <20020823071125.8EBD21945@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 04:02 AM 8/23/02, Paul Vixie wrote: > (2) the amount of rejected repeated useless query traffic at some root >server exceeds 1 gigabit per second. (both of those things will happen >within my lifetime, unless i miss my guess.) Out of curiosity, what is the current amount of query traffic on F? And what is the percentage of useless query traffic out of the total traffic? Danny -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 28 14:09:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12347 for ; Wed, 28 Aug 2002 14:09:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17k75B-0001S1-00 for namedroppers-data@psg.com; Wed, 28 Aug 2002 10:58:21 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17k756-0001Rq-00 for namedroppers@ops.ietf.org; Wed, 28 Aug 2002 10:58:16 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id ADFA128B6B; Wed, 28 Aug 2002 17:58:14 +0000 (GMT) From: Paul Vixie To: Danny Mayer Cc: Rob Austein , namedroppers@ops.ietf.org Subject: Re: qtype addr scorecard In-Reply-To: Message from Danny Mayer of "Wed, 28 Aug 2002 13:12:56 -0400." <4.3.1.2.20020828131051.04ba5330@pop.gis.net> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 28 Aug 2002 17:58:14 +0000 Message-Id: <20020828175814.ADFA128B6B@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > (2) the amount of rejected repeated useless query traffic at some root > >server exceeds 1 gigabit per second. (both of those things will happen > >within my lifetime, unless i miss my guess.) > > Out of curiosity, what is the current amount of query traffic on F? And > what is the percentage of useless query traffic out of the total traffic? we get about 6Meg of traffic of which about half is garbage. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Wed Aug 28 17:06:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19131 for ; Wed, 28 Aug 2002 17:06:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17k9sF-000AvD-00 for namedroppers-data@psg.com; Wed, 28 Aug 2002 13:57:11 -0700 Received: from wireless239.east.isi.edu ([65.123.202.239] helo=lapdancer.antd.nist.gov.) by psg.com with esmtp (Exim 3.36 #1) id 17k9s7-000AtV-00 for namedroppers@ops.ietf.org; Wed, 28 Aug 2002 13:57:04 -0700 Received: from antd.nist.gov (localhost.localdomain [127.0.0.1]) by lapdancer.antd.nist.gov. (8.11.2/8.11.2) with ESMTP id g7SKvjr02541 for ; Wed, 28 Aug 2002 16:57:49 -0400 Message-ID: <3D6D3948.AB40B90E@antd.nist.gov> Date: Wed, 28 Aug 2002 16:57:44 -0400 From: Scott Rose Organization: NIST X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Return value for DS query to a child zone Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A new subject that has been raised at the DNSSEC workshop today: Scenario: A authoritative-only server (non-cache) that is DNSSEC aware and follows the DS model of zone signing: foo.bar. A client queries this server (foo.bar authoritative server) for: foo.bar. IN DS Now: what is returned? foo.bar. does not have the DS record. "foo.bar. IN DS" is stored in .bar. with the rest of the glue records for the foo.bar. delegation. bar. is authoritative (and signs) the DS record for foo.bar. possible responses: 1. NXDOMAIN with the foo.bar. NXT RR showing that the DS record is not in the foo.bar. zone. Should the AA bit be set in this response? foo.bar is claiming that foo.bar. DS does not exist (and it is authoritative). 2. A referral to root (upwards referral) to direct the client to query root - hoping that eventually the client will reach .bar and get the DS record for foo.bar. However, this may result in a loop in the client (upward referral does not naturally occur in DNS). This might end with any caching server marking the foo.bar. server as lame. 3. Some new error code? (IDUNNO - "The data might exist, I just don't know where it is, even though I am technically authoritative for that name...") 4 something else? Disclaimer - it is hoped that this situation would never happen. Following the DNS with DNSSEC model, this should not happen. One possible example would be a non-DNSSEC aware parent and a DNSSEC aware child that believes its parent is DNSSEC aware. -OR- when a DNSSEC aware application tries to use a non-DNSSEC aware caching resolver to service recursive queries (the non-aware resolver would assume DS for foo.bar. would be in foo.bar. - naturally). 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: From owner-namedroppers@ops.ietf.org Fri Aug 30 18:57:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08486 for ; Fri, 30 Aug 2002 18:57:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17kuMU-000Je1-00 for namedroppers-data@psg.com; Fri, 30 Aug 2002 15:35:30 -0700 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 17kuMR-000Jdq-00 for namedroppers@ops.ietf.org; Fri, 30 Aug 2002 15:35:27 -0700 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 15:35:26 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Aug 2002 15:35:29 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 30 Aug 2002 15:35:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 30 Aug 2002 15:35:25 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Fri, 30 Aug 2002 15:35:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6728.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: qtype addr scorecard Date: Fri, 30 Aug 2002 15:35:15 -0700 Message-ID: Thread-Topic: qtype addr scorecard Thread-Index: AcJOt/HGOy/f5+hqQ6CkvfUGpjuNywBvXeWQ From: "Christian Huitema" To: "Danny Mayer" , "JINMEI Tatuya / ????" , "Markku Savela" Cc: , , , X-OriginalArrivalTime: 30 Aug 2002 22:35:23.0621 (UTC) FILETIME=[879A0950:01C25075] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA08486 > According to the documentation that I have Windows XP and later supports > 4 types of compatibility addresses: ISATAP, 6to4 (RFC 3056), 6over4 > (RFC 2529) and IPv4 compatible ( ::w.x.y.z). The supported getaddrinfo() > is only available on XP and later. I don't expect any of this to be > available > on WNT, W2K or any of the Win9x O/S's even with MSR's IPv6 stack or > the Win2K Technology Preview, though I could be wrong. > > Maybe one of the Microsoft people could comment. The documentation is available at http://www.microsoft.com/ipv6/ -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-namedroppers@ops.ietf.org Fri Aug 30 21:43:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11528 for ; Fri, 30 Aug 2002 21:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17kx9t-000Ply-00 for namedroppers-data@psg.com; Fri, 30 Aug 2002 18:34:41 -0700 Received: from mx03.gis.net ([208.218.130.11] helo=gis.net) by psg.com with esmtp (Exim 3.36 #1) id 17kx9n-000Pku-00 for namedroppers@ops.ietf.org; Fri, 30 Aug 2002 18:34:35 -0700 Received: from tecotoo.www.gis.net ([63.209.226.82]) by mx03.gis.net; Fri, 30 Aug 2002 21:34:30 -0400 Received: from localhost (localhost [127.0.0.1]) by tecotoo.www.gis.net (NTMail 3.02.13) with ESMTP id ya028312 for ; Fri, 30 Aug 2002 21:34:43 -0400 Message-Id: <4.3.1.2.20020830212317.00e6deb0@pop.gis.net> X-Sender: mayer@pop.gis.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 30 Aug 2002 21:34:27 -0400 To: "Christian Huitema" , "JINMEI Tatuya / ????" , "Markku Savela" From: Danny Mayer Subject: RE: qtype addr scorecard Cc: , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Info: NTMail 3.02 Server on TECOTOO X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 06:35 PM 8/30/02, Christian Huitema wrote: > > According to the documentation that I have Windows XP and later >supports > > 4 types of compatibility addresses: ISATAP, 6to4 (RFC 3056), 6over4 > > (RFC 2529) and IPv4 compatible ( ::w.x.y.z). The supported >getaddrinfo() > > is only available on XP and later. I don't expect any of this to be > > available > > on WNT, W2K or any of the Win9x O/S's even with MSR's IPv6 stack or > > the Win2K Technology Preview, though I could be wrong. > > > > Maybe one of the Microsoft people could comment. > >The documentation is available at http://www.microsoft.com/ipv6/ Christian, it would have helped if you had answered the question asked. That URL does not answer the question as you would have know had you read that page. You would be better off pointing to the Ipv6/IPv4 migration document. Danny P.S. My email address is NOT m@psg.com. I don't know where you got that one. -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: