On 8/4/23 10:46, Joe Abley wrote:
My proposal allows unsigned response stating nothing have changed, yes. Of course there is nothing demanding server to provide this refresh support. That is why I have suggested top limit, after which it would have to do regular refresh. Also validating resolver should do full query when RRSIG is about to expire.On 4 Aug 2023, at 10:12, Peter Thomassen <pe...@desec.io> wrote:A hash over the RRset in question might work, assuming some canonical form is used (e.g. as used for RRSIG calculation).In fact, if the requirement is for a hash whose authenticity can be proven by a relying party (which seems important in order to avoid a rogue assertion that nothing has changed from being an attack vector), exactly an RRSIG response seems conveniently ideal. The only bit missing is the ability to retrieve the RRSIG independently of the signed RRSet.
I may have not pointed at this enough. This is directed to devices communicating over slow or expensive links, where gigabytes transferred are not for free. This proposal does not help too much in data center machine connected to 10GE link. It might help there to keep DNSKEYs checked more often, without using more expensive TCP retries. Because keys do not change often anyway, this allows just checking whether new one is needed.However, I think there is a more fundamental problem with the applicability of this kind of thing, which is that I don't think it achieves anything that anybody needs. DNS servers that serve small amounts of traffic don't tend to have traffic volume problems in a world where you have to be at least 10GE high to get people to bother replying to requests for a PNI.
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.DNS servers that serve large amounts of traffic tend to be attack magnets (or non-complicit attack vectors) and consequently the available capacity for responses is significantly overprovisioned from steady-state traffic demands; the savings in traffic are then at best limited to a fraction of a fraction which makes it hard to think that the extra complexity is worth it.
The metrics that count in the minds of a lot of people concern the time taken to complete a transaction. A query to check whether answers have changed takes the same amount of time as a query that asks the same question again, and twice as long if the answer is "yes, something has changed". Again, it's hard to see the real-world benefit. Joe
I would recommend checking the paper I have referenced about CoAP. It explains well constrained environment with limited connectivity and low maximal MTU. Think about bluetooth connectivity as an high-speed example. Yes, it takes the same time as a normal query. No, if something has changed, it responds full reply on the response, with addition of TTL=0 in cache-refresh option or the option missing. It does not answer first yes, it has changed, then a new query fetches the actual content. So query count stays the same, yes. It only reduces transmitted bytes and may avoid TCP retry. And potentially unneeded re-validation of unmodified records.
Petr -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
