Date: Mon, 23 Sep 2002 15:01:25 +1000 From: Mark.Andrews@isc.org To: itojun@iijlab.net Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>, Lista <freebsd-net@FreeBSD.ORG>, "(Lista) bind9-users@isc.org" <bind9-users@isc.org> Subject: Re: RES_INSECURE and CHECK_SRVR_ADDR in resolver functions (IPv6 anycast response problem) Message-ID: <200209230501.g8N51PB5078220@drugs.dv.isc.org> In-Reply-To: Your message of "Mon, 23 Sep 2002 12:50:03 %2B0900." <20020923035004.F1D0A4B24@coconut.itojun.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Yes, and I know why the restriction is in RFC 1884 and it > > is a reasonable restriction. > > I don't think so, Are you saying we should source packets from the anycast address? If not you should quote better. > IP source address is easy to forge and it does not > add any meaning protection. DNSSEC is the only way if you want trusted > responsees. therefore, i agree with enabling RES_INSECURE1 by default. > > itojun Source addresses can be used to seperate multiple queries with the same query id. While the stub resolver rarely needs to do this a nameserver will to this all the time. Enabling RES_INSECURE1 just hides the real problem that IPv6 anycast is broken, encourages broken nameserver implementations and leaves you with the situation where the tools using stub resolver "work" but the nameserver doesn't. 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 mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209230501.g8N51PB5078220>