> On 1 Oct 2024, at 04:36, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > >> This message starts a Call for Adoption for "Greasing Protocol >> Extension Points in the DNS" (see >> [1]https://datatracker.ietf.org/doc/draft-huque-dnsop-grease/) > > There is quite a bit I find confusing in this draft. > > For example, Table 1 shows that are 16 opcodes. But if I send a request > with a different opcode then my original request will not go out. Does > the draft want me to send an additional request? A similar issue exists if > the Qtype is changed.
Yes, you send multiple queries. For QTYPE I would do this after I have got the response so one can set the correct expectation for the rcode, (NOERROR vs NXDOMAIN). For opcode one is looking for NOTIMP. > Then the DNS Header Flags. We have one flag left. What will happen if > DNS software is putting random values in this unused flag and at a later > time we want to actually use that bit for something? You have time limited testing built into the code and controls to turn the tests off. Recursive servers need accurate clocks to validate responses. https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9544 > To me it seems better if the authors would write an implementation and > give a clear algorithm how grease should be applied. Otherwise there may > be quite a bit of work for the working group to sort it all out. We have been doing this sort of testing for nearly a decade now see: https://ednscomp.isc.org Expected behaviour is already specified. > If I dismiss the DNS Header Flags, the Resource Record Type and the Opcode > as hard to grease, then what is left is various EDNS code points. EDNS version negotiation. Sending unknown EDNS options. There is also checking TSIG behaviour. Using a well known TSIG would protect UDP responses from fragmentation attacks. > I'm a bit worried there that it might make EDNS harder to use. Some > experiement might be in order to see how much would break in the current > internet. Only if the server has a broken EDNS implementation. If you look at the time series https://ednscomp.isc.org you will see that broken servers are going away. Deploying DNS COOKIE has cleaned out a lot of broken servers. Having recursive servers do this testing will flag broken servers deeper in the tree than we regularly test. > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
