Subject: [DNSOP] A mention of draft-fujiwara-dnsop-resolver-update and draft-weaver-dnsext-comprehensive-resolver

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 5 Dec 2016 18:24:21 +0100

https://blog.cloudflare.com/tld-glue-sticks-around-too-long/

"In this article, I explained what DNS glue is, and why I believe that
DNS TLD glue TTL values hardcoded at 48 hours are not helping with
DDoS mitigation. I hope this article will serve as a call to action
for relevant TLD operators. I believe the ability to adjust DNS glue
TTLs is a simple yet effective way to make DNS infrastructure more
reliable."

With my TLD operator hat: not convinced.

---

From: David Conrad <[email-masked]>
Date: Mon, 5 Dec 2016 13:44:29 -0800

Stephane,

> On Dec 5, 2016, at 9:24 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

It might be more helpful if you perhaps could explain why you're not convinced?

Regards,
-drc
(speaking only for myself)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Dec 2016 18:36:20 +0100

On Mon, Dec 05, 2016 at 01:44:29PM -0800,
 David Conrad <[email-masked]> wrote 

> It might be more helpful if you perhaps could explain why you're not convinced?

1) Glue is only for in-child nameservers. The majority of delegations
don't use glue. So, glue is only a part of the problem.

2) The proper behaviour is for the child NS TTL to be used because it
is authoritative. This is what resolvers like Unbound do. If all
resolvers don't do it, we should change that, instead of allowing to
change the TTL in the parent.

2bis) Section 2.1 of draft-vixie-dnsext-resimprove seems the way to go
(with the provisions of its section 2.2, to avoid ghost domains.)

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 6 Dec 2016 14:52:25 -0500

> don't use glue. So, glue is only a part of the problem.

I can easily believe that most delegation NS RRsets don't directly
require glue address records. But it stands to reason that all glueless
delegations must ultimately rely on other delegations with address glue
in order to be resolved.

> change the TTL in the parent.

Sure, Unbound implements the trustworthiness ranking in RFC 2181 §5.4.1,
like other implementations, so for a given zone the apex NS RRset will
overwrite the delegation NS RRset. But it doesn't go out of its way to
fetch authoritative data from the child to replace cached glue address
records. (Unless you turn on Unbound's "harden-referral-path" option.)

> (with the provisions of its section 2.2, to avoid ghost domains.)

If I understand the complaint in the blog post you linked, the other
issue that they want to avoid (which isn't mentioned at all AFAICS) is
avoiding any extra RTTs to fill in glue records from the child. But if
you don't mind possible extra RTTs there is the obvious solution of
providing customers with nameserver names whose address records are not
also glue address records.

-- 
Robert Edmonds