On Wed, Jul 28, 2021 at 12:20 PM John R Levine <jo...@taugh.com> wrote:
> On Wed, 28 Jul 2021, Shumon Huque wrote: > > Sibling glue was already covered in RFC 1034 (even though there was no > term > > for it). ... > > Sure, but we've been cleaning up the ambiguities and errors in 1034 for 30 > years. A straightforward reading of that paragraph also gives you the > Kaminsky attack. > The Kaminsky attack can redirect in-bailiwick nameserver names just as easily as out-of-bailiwick. The defenses against it are (1) make it harder (source port randomization etc), or (2) deploy DNSSEC. Glue is unauthenticated anyway, so the only real defense against misdirection is DNSSEC and a secure referral to the child. Also, sibling glue is easier to accept for a paranoid resolver. It may not be in-bailiwick (i.e. a subdomain) of the "delegated zone", but it is in- bailiwick of the "delegating zone". If a paranoid resolver, ignores and re-queries for the sibling names, it ends up requerying the same authority and then getting a response with in-bailiwick glue. So, it just did a bunch of additional work for not much benefit in my opinion. But this is an interesting topic. What do resolver implementations do when presented with sibling glue? Can implementers comment? I think this can help inform what we recommend in the draft. "MUST" in RFC-ese means you have to do something in order to interoperate. > I think we all agree that the DNS will operate fine without sibling glue, > other than NS loops which I personally don't care about. That makes it at > most a MAY, and I agree with Geoff's reasons to take it out completely. > I don't agree we should take it out, since as I pointed out, RFC 1034 explicitly covers this type of glue (without giving it a name), and the algorithm will include it if it is there. If there is a compelling security or other reason to remove that, someone should make that case (I haven't heard it yet). But it seems we will not get consensus on truncating if sibling glue doesn't fit, so I'm okay with relaxing that requirement. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
