Hi,
I have also difficulties finding any benefit of such feature. Shall it
help lowering bandwidth usage for authoritatives or for recursives? I'd
say that for authoritatives in general, legitimate traffic is the
minority, so reducing that would not help much.
I'd oppose the idea of having the "noting has changed" signal insecure.
It should be carefully discussed why it would be not a big problem.
One idea that came to my mind is to utilize ZONEMD: the recursive could
re-query just ZONEMD (+its RRSIG), assume that nothing else in the zone
has changed (SOA, DNSKEYs, any RRSIGs....), and re-set their TTLs to
original. It could just cause problems if TTL of ZONEMD is greater than
TTL of DNSKEY, in case of some key roll-overs, so one would probably
require the TTL of ZONEMD be the minimum of zone's TTLs (currently it's
RECOMMENDED to equal SOA TTL).
Libor
Dne 04. 08. 23 v 13:07 jab...@strandkip.nl napsal(a):
Hi Petr,
On Aug 4, 2023, at 05:21, Petr Menšík <pemen...@redhat.com> wrote:
Again, this proposal is not targeted to gigabit+ links connectivity. This is
not indented to fight DDoS in data centers. It would be links, where data are
still counted in kilobytes or megabytes. Satellite links or long range radios
might be example. Low-power IoT devices battery operated devices as well.
I still have my doubts about the usefulness of shaving a relatively small
number of bytes off a transaction that is already pretty light on the wire. Any
device for which a significant proportion of its available capacity is consumed
by DNS in normal operation is presumably not doing very much else. But...
I would recommend checking the paper I have referenced about CoAP. It explains
well constrained environment with limited connectivity and low maximal MTU.
... that is a very reasonable request, and I will do so.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
