Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

[John R Levine <[e-mail]>]

We are clearly talking past each other here.  Let's see what the rest of 
the WG thinks.

I think we need to think harder about "what is required for the DNS 
protocol to work" vs "what do I think might be a nice idea."

R's,
John

On Wed, 28 Jul 2021, Shumon Huque wrote:

> On Wed, Jul 28, 2021 at 12:20 PM John R Levine <[e-mail]> 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.
>

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly