Return-Path: 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 BE7A03A68A0 for ; Sat, 17 Oct 2009 01:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.18 X-Spam-Level: X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] 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 lAv1vB2r2Lot for ; Sat, 17 Oct 2009 01:14:11 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 16ED33A67E6 for ; Sat, 17 Oct 2009 01:14:10 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=D0yZFR7QpVapMUo8wAqSyQrsoCUPyLXvevrzJddVLT91nKF6WTnAi2bz qXv7JQQtah9YGGMhnGupkEXKzj5SIeqOra6GPEPE6t1HZJuOOhQ9RbB1I 86iDyfL1Gd1poGG; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1255767256; x=1287303256; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[DNSO P]=20Fw:=20New=20Version=20Notification=0D=0A=20fordraft- bellis-dns-recursive-discovery-00|Date:=20Sat,=2017=20Oct =202009=2009:14:13=20+0100|Message-ID:=20|To:=20"George=20Barwood"=20|Cc:=20dnsop@ietf.org,=0D=0A=09Alex=20Bligh=20|MIME-Version:=201.0|In-Reply-To:=20|References:=20=20; bh=qMOwmJMbf6EthrV+UDa8uQx3T+RhqREJOkqn8sbTLOo=; b=jTfc5IKrUYUYwJiTwm7PJrMrrNaNSU3kwshMdgGBCGnEvq/8Tv4wBZ5C B42j1nKzxU4+Jv1gkq/w2a9f6tV8DVM+xvFjQYyjcn8BBh2DJ1YE3lXmH DqK9sDA3rQAHEya; X-IronPort-AV: E=Sophos;i="4.44,577,1249254000"; d="scan'208";a="18666549" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 17 Oct 2009 09:14:14 +0100 In-Reply-To: References: To: "George Barwood" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Sat, 17 Oct 2009 09:14:13 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 17/10/2009 09:14:13 AM, Serialize complete at 17/10/2009 09:14:13 AM Content-Type: multipart/alternative; boundary="=_alternative 002D3F4580257652_=" Cc: dnsop@ietf.org, Alex Bligh Subject: Re: [DNSOP] Fw: New Version Notification fordraft-bellis-dns-recursive-discovery-00 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 08:14:12 -0000 This is a multipart message in MIME format. --=_alternative 002D3F4580257652_= Content-Type: text/plain; charset="US-ASCII" > I have read the draft, found no problems other than the missing > security considerations ( I don't see any particular security > considerations ), and fully support it. Thanks - and that's why the Security Considerations is "TODO" - we're not sure what they are yet. The only significant risk we can think of is someone spoofing that initial seeding query, and thereafter intercepting all DNS requests. > Did you consider a "referral" model using NS records? > > LOCAL.ARPA. 9000 NS A.LOCAL.ARPA. > LOCAL.ARPA. 9000 NS B.LOCAL.ARPA. > > A.LOCAL.ARPA. 9000 A 1.2.3.4 > B.LOCAL.ARPA. 9000 A 2.3.4.5 > > I think this may be cleaner, it allows multi-homed servers to be > properly distinguished ( you shouldn't try an alternate address > until other servers have been tried ), and seems closer to the > normal DNS representation of name servers. Resolvers require a list of A (or AAAA) records to send queries to. Hence we use the RR type which represents just such a list. > A simplistic client can still just save all the A records, and > ignore the names. That would be harder to implement than simply asking for A records in the first place. > This may be significant if the glue types are extended in future > to supply other link-local parameters, for example the DNS transport > protocols supported... At this point any other transports are (with all due respect) entirely hypothetical so they are not considered here. > I also note that using LOCALHOST, or a sub-domain of LOCALHOST, > would avoid non-local queries being sent by servers that are not > aware of LOCAL.ARPA See RFC 2606: The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. Ray --=_alternative 002D3F4580257652_= Content-Type: text/html; charset="US-ASCII" > I have read the draft, found no problems other than the missing > security considerations ( I don't see any particular security
> considerations ), and fully support it.

Thanks - and that's why the Security Considerations is "TODO" - we're not sure what they are yet. The only significant risk we can think of is someone spoofing that initial seeding query, and thereafter intercepting all DNS requests.

> Did you consider a "referral" model using NS records?
>
> LOCAL.ARPA. 9000 NS A.LOCAL.ARPA.
> LOCAL.ARPA. 9000 NS B.LOCAL.ARPA.
>
> A.LOCAL.ARPA. 9000 A 1.2.3.4
> B.LOCAL.ARPA. 9000 A 2.3.4.5
>
> I think this may be cleaner, it allows multi-homed servers to be > properly distinguished ( you shouldn't try an alternate address
> until other servers have been tried ), and seems closer to the
> normal DNS representation of name servers.

Resolvers require a list of A (or AAAA) records to send queries to. Hence we use the RR type which represents just such a list.

> A simplistic client can still just save all the A records, and > ignore the names.

That would be harder to implement than simply asking for A records in the first place.

> This may be significant if the glue types are extended in future
> to supply other link-local parameters, for example the DNS transport
> protocols supported...

At this point any other transports are (with all due respect) entirely hypothetical so they are not considered here.

> I also note that using LOCALHOST, or a sub-domain of LOCALHOST,
> would avoid non-local queries being sent by servers that are not
> aware of LOCAL.ARPA

See RFC 2606:

The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
Ray

--=_alternative 002D3F4580257652_=--