> On 10 Nov 2021, at 09:35, libor.peltan <libor.pel...@nic.cz> wrote: > > Hi Roy, > >> Change 2) There was an observation by developers that some authoritative >> servers do not parse (unknown) EDNS0 options correctly, leading to an >> additional roundtrip by the resolver. It was suggested that authoritative >> servers could return the new EDNS0 option “unsolicited”. This is already the >> case for Extended DNS errors. We have adopted this suggestion. It was also >> pointed out that this kind of unsolicited behaviour can be surveyed. We >> believe that one such effort is underway. > > Let me express my personal opinion here.
Thanks! I really appreciate feedback on this! Keep it coming! > While sending unsolicited EDE seems fine for me as it's just few bytes, the > error-reporting address might be usually roughly 100 bytes long, Why would that be 100 bytes long? An error-reporting domain should be kept rather short. > so sending it with very every response may lead to perceptible increase in > traffic, including increase in TCP fallbacks. Would it help to require the authoritative server to only add this option when there is space to do so? > This may be tolerable, if there were some better reason for it. But I don't > like argumenting with broken implementations. Always dodging broken > implementation only leads to more broken implementations (see DNS Flag Day > etc). In ideal case, we should aim for the state where broken implementation > are failing constantly. This is not that! If we were sending new EDNS0 options to authoritative servers, it will lead to additional round-trips to dodge broken servers. This is the way of “dodging broken implementations”. It won’t get these implementations fixed, and this additional resolver code to route around brokenness in the field will eventually end up at flag-day. Consider the current method of returning unsolicited new options in responses: A resolver may not handle unsolicited new EDNS0 options. They will either be fixed or not be used. This is not a negotiation, unless the resolver falls back to send a query without EDNS0. I have been told by developers that there are more broken authoritative server software out there than broken resolver software. Field tests are taking place to measure impact. Hope this helps! Warmly, Roy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
