Re: [DNSOP] Should root-servers.net be signed

"George Barwood" <george.barwood@blueyonder.co.uk> Fri, 19 March 2010 19:01 UTC

Return-Path: <george.barwood@blueyonder.co.uk>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1713A67A1 for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 12:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.865
X-Spam-Level: ***
X-Spam-Status: No, score=3.865 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxXo-uW4mSAA for <dnsop@core3.amsl.com>; Fri, 19 Mar 2010 12:01:28 -0700 (PDT)
Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 6B7B23A68FA for <dnsop@ietf.org>; Fri, 19 Mar 2010 12:01:22 -0700 (PDT)
Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1NshRs-0003GS-6W; Fri, 19 Mar 2010 19:01:32 +0000
Received: from [92.238.99.235] (helo=GeorgeLaptop) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1NshRr-0004O5-KM; Fri, 19 Mar 2010 19:01:31 +0000
Message-ID: <662061674DB34DB395F519F52B0C4C35@localhost>
From: George Barwood <george.barwood@blueyonder.co.uk>
To: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
References: <2AA0F45200E147D1ADC86A4B373C3D46@localhost><0E169711-92DC-4AEA-AA81-718F298D1645@hopcount.ca><alpine.LSU.2.00.1003081614480.1897@hermes-2.csi.cam.ac.uk><A2D7C5EE-9937-4529-A28F-23296485A8B2@hopcount.ca><43FC3F50679F458A869F99D72ECD1237@localhost><20100309151726.GC5108@dul1mcmlarson-l1-2.local> <6C56581E-D4F4-4A49-A3B4-CB7F1CF42E29@icsi.berkeley.edu> <183BEF785A9844F186558A87848A6698@localhost> <061F30F4-E0EE-40E6-A54D-246D9E9A9D77@ICSI.Berkeley.EDU> <6D6F580F8CFB4DB5AB32566FB608088D@localhost> <57BC5F21-B1EE-4D06-BB1B-3DC8582D0D87@ICSI.Berkeley.EDU> <03CF4A3B5B374C4C858DEEB2D66C0702@localhost> <AA116C2A-CCFC-4177-A43A-B3AA066B3C3C@ICSI.Berkeley.EDU> <7F872C0CAA544F9480BF49438AAFA3BF@localhost> <68584293-648A-4F4E-8731-785E8F4D38B7@ICSI.Berkeley.EDU>
Date: Fri, 19 Mar 2010 19:01:25 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: dnsop@ietf.org, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: Re: [DNSOP] Should root-servers.net be signed
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Mar 2010 19:01:29 -0000

> Hmm, you're right, IF the A records are accepted in the additional section, true, A records could be added to the RRSET for some of the names.  
> But frankly speaking, thats "ADDITIONAL", and shouldn't really be accepted at all, and if the resolver DOES cache it, I'd personally call it a bug.

It may be a bug, but I suspect many existing resolvers will use it.

For the priming query, a resolver has to accept glue, it's the purpose of the query ( and a special case ).

It might be considered a bug for glue to be sent with a response that is not a referral, except for the priming query.

The main (only?) reason for sending the NS RRset in an Authoritative response
( other than as a direct answer to the question ) is in case the client has not yet
discovered the zone ( because it's a child zone is hosted on the same server ),
and in this case, glue is not required, let alone signed glue.

However it could be considered a valid optimization, and it's what most existing implementations seem to do.

Anyway, do we yet agree that 1450 is the best default for max-udp-size, and that higher values are dangerous?