From willem at nlnetlabs.nl  Thu Mar  5 08:33:34 2026
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 5 Mar 2026 09:33:34 +0100
Subject: IEPG @ IETF 125 - Shenzhen
In-Reply-To: <CAHw9_iJWq_RZqWFm=DbtVQSYpw7RH3+GEe4uZRF+kvgU=A5h-A@mail.gmail.com>
References: <CAHw9_iJWq_RZqWFm=DbtVQSYpw7RH3+GEe4uZRF+kvgU=A5h-A@mail.gmail.com>
Message-ID: <137bb91b-7ad0-4b94-bdf8-b96b5c788e75@nlnetlabs.nl>

Hi Warren,

I had a student (Ilyas Rahimi) doing a research project: "local root 
serving by default: quantifying the traffic trade-off between root 
queries and root zone distribution" [1], in which he has measured the 
impact on traffic with BIND, Unbound and Knot Resolver configured 
following example configurations from RFC 8806 Appendix B [2]. I think 
it raises interesting questions and showed show fun results. For example 
the different perspective w.r.t. timing values. Should resolvers 
primarily follow the TTL of the records in the root (2 days for the 
non-authoritative and 1 day for the authoritative delegation 
information) as those are meant for resolvers anyway and fetch the root 
once a day (what Knot Resolver does by default), or actually try to act 
as a real secondary?, which (fun fact) for Unbound currently means it 
will fetch the full root zone every 30 minutes (refresh timer in the 
SOA) when it is configured to fetch the root over http(s) only (because 
it cannot do the SOA query over http(s)).

Besides what is already in his report, we've also created a 
incrementally signed "shadow" of all the root zones since 21st of 
December 2025 here: https://github.com/willem-ietf125/incremental-root 
This repo also includes the IXFRs from version to version (with the 
size) when incrementally signed properly (i.e. no signature will be 
older than 6 days, so that in the worst case the SOA expire timer goes 
off before signatures start to expire)

Would this be interesting to have in the IEPG session? and if so, do you 
still have a spot?

Cheers,

-- Willem

[1] 
https://nlnetlabs.nl/downloads/publications/DNS_Local_ROOT_ResearchProject2.pdf

[2] https://www.rfc-editor.org/rfc/rfc8806#name-example-configurations-of-c

On 2/20/26 17:21, Warren Kumari wrote:
> Hi all,
>
> The IEPG is an informal gathering that meets on theSunday prior to 
> IETF meetings. The intended theme of these meetings is essentially one 
> of operational relevance in some form or fashion.
>
> We still have some open agenda time for the IEPG session at IETF 125?
>
> These presentations / discussions are generally around things like 
> problems discovered when deploying various protocols, interesting 
> operational issues or deployments, interesting measurement results, 
> fun things discovered while building networks, etc. It is much more 
> operationally focused than an IETF Working Group meeting, and is not a 
> place to just present your shiny new Internet Draft (that's HotRFC and 
> / or the relevant WG).
>
> So, things like: "If you have a chain of CNAME records, and one of 
> them is at the apex of a DNS zone, the 3 largest resolver 
> implementations?all do different?things. This allows you to 
> fingerprint resolvers - here are some results?.", or "We implemented 
> BGP?Flowspec?to allow fast response to DDoS events? and then we pushed 
> out a rule which blocked access to the controller. This is what 
> happened after that?" are all great IEPG presentations.
> But? "Here is my draft. It adds the Foo extension to the Bar protocol. 
> The format of the Foo extension looks like this?. If a router using 
> Bar sees this extension, it should increment the Baz counter. The YANG 
> model for Foo looks like this? " is not ? that should be discussed in 
> the Bar WG, or HotRFC,? or Dispatch, or similar?
>
>
> Previous presentations are here:http://www.iepg.org/
>
> More info on the IEPG: RFC 1690 -https://tools.ietf.org/html/rfc1690
> We will have remote participation through MeetEcho.
>
> If you have some sort of operationally relevant topic which you'd be 
> willing to present, please let Jen Linkova <furry13 at gmail.com> or me know.
>
> Thanks,
> W
>
>
> _______________________________________________
> Iepg mailing list
> Iepg at lists.isc.org
> https://lists.isc.org/mailman/listinfo/iepg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/iepg/attachments/20260305/8eb90b46/attachment.htm>