Subject: [DNSOP] Call for Adoption: draft-andrews-dnsop-glue-is-not-optional

From: Tim Wicinski <[email-masked]>
Date: Mon, 18 May 2020 13:49:04 -0400

All,

As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.
We are looking for *explicit* support for adoption.

This starts a Call for Adoption for draft-andrews-dnsop-glue-is-not-optional

The draft is available here:
https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 1 June 2020

Thanks,
tim wicinski
DNSOP co-chair

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 May 2020 11:30:35 -0700

> Please also indicate if you are willing to contribute text, review, etc.
I support adoption by the WG, believe it is suitable, and am willing to
review and contribute text.

Brian

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 May 2020 14:39:41 -0400

In favour of adoption but like to see text from both AUTH and recursive behaviour.

Not convinced the situation should be this black and white - eg perhaps partial glue would be enough not to require TC=1 or behaviour for resolvers could be a little more advanced to try with partial before going to TCP.

If my request seem stupid, the draft needs clarification for stupid people like me :)

Paul

Sent from my iPhone

> On May 18, 2020, at 14:30, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> 
>> The draft is available here: https://datatracker.ietf.org/doc/draft-andrews-dnsop-glue-is-not-optional/
>> 
> I support adoption by the WG, believe it is suitable, and am willing to review and contribute text.
> 
> Brian
> 
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 May 2020 23:41:28 +0000

On Monday, 18 May 2020 17:49:04 UTC Tim Wicinski wrote:
> ...

+1. long overdue after false starts by me and others.

> This call for adoption ends: 1 June 2020

i'm willing to review.

-- 
Paul

---

From: "John Levine" <[email-masked]>
Date: 18 May 2020 20:37:00 -0400

In article <[email-masked]> you write:
>Not convinced the situation should be this black and white - eg perhaps partial glue would be enough
>not to require TC=1 or behaviour for resolvers could be a little more advanced to try with partial
>before going to TCP.
>

The draft, which I hope we adopt, could use clarification if that
seems like a good idea.

Imagine you have foo.example with two nameservers, ns1.foo.example and
ns2.foo.example. Client looks up something.foo.example, server returns
a referral with two NS records but only has room for one A record for
ns1. The Internet is having a bad day and ns1 is unreachable while ns2
is fine. Since there's no TC=1 the client has no idea that requerying
would return the A record for ns2, so it wrongly assumes ns2 has no A
record and the domain is kaput. It can't separately requery for ns2,
since who would it ask?

It's fine to return a partial result with TC=1, that's always been the case.

R's,
John

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 May 2020 07:41:20 -0700

> We are looking for *explicit* support for adoption.

Yes please!
-- 
Wes Hardaker
USC/ISI

---

From: Daniel Migault <[email-masked]>
Date: Thu, 21 May 2020 12:02:42 -0400

I am supporting adoption.
Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 May 2020 12:09:52 -0400

> This call for adoption ends: 1 June 2020

I've read the draft. It's a useful clarification to the spec, so I support
adoption and will review etc.

I have one question for the Mark A though:

Since you specifically cite the example of the GOV servers, did you ask
Verisign about this behavior, and if so, what was their response? Maybe
this is just a bug, rather than a "widespread misbelief" about additional
data & truncation that you more generally attribute as the cause for this.

Shumon

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 May 2020 09:31:34 +0900

> by DNSOP, and comments to the list, clearly stating your view.

While I'm not against the clarification, the draft should mention
that rfc1034 already states:

    To fix this problem, a zone contains "glue" RRs which are not
    part of the authoritative data, and are address RRs for the servers.
    These RRs are only necessary if the name server's name is "below" the
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    cut, and are only used as part of a referral response.
                 ^^^^^^^^^

which means the glue RRs are necessary for a referral response.
Though not very obvious, it logically means that they MUST be
included as part of a referral response, because it is the only
reason to make them necessary.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 May 2020 01:35:58 +0000

>     These RRs are only necessary if the name server's name is "below" the

i agree. this is why later versions of BIND would return referrals rather than 
answers when queried for these names, which were in-bailiwick but below-zone. 
by implication, they can only be retrieved from the delegating server as part 
of a referral, and they will be in the additional section not the answer 
section even though they do match the qname. this distinction is also 
necessary in the assignment of credibility levels in the downstream cache.

-- 
Paul