Not answering queries has effects on OTHER servers. Because there are servers out there that don't answer EDNS queries or only answer the first EDNS query resolvers have to ASSUME that no answer to a EDNS quere means "NO EDNS". They then make a plain DNS query and get a answer. Those servers then get marked for a while as not supporting EDNS. This isn't a big issue until those servers are serving a signed zone. Once that server serves a signed zone you have real issues as DNSSEC responses rely on EDNS queries and you stop getting EDNS queries. The client then doesn't get the RRSIGs and can't validate.
PMTUD from the server to the client has a similar loss pattern to drop on EDNS, answer on DNS. Do you see the problems caused to others by deciding to drop packets in a query / response protocol. The same thing happens with servers that don't answer EDNS options. The recursive server has to decide is this the EDNS option or EDNS or just packloss. Add in servers that don't like particular options (yes there are servers that don't answer NSID queries but do answer other EDNS options) and the problem for the recursive servers becomes bigger for the recursive server. We already have DNS zones that will not work with BIND 9.10.x and BIND 9.11.x because the servers for those zones drop queries with EDNS options present and the zones are signed. The CORRECT behaviour for a recursive server is to retry the SAME query. No answer means PACKET LOSS, usually for load but sometimes for corruption. It does NOT mean that I don't like the query. We have a rcode for that: REFUSED. When named drops packet (too many queries for the same question) the expected behaviour from the client is to timeout and retry. Its load shedding the same way as a link sheds load by dropping packets. It also isn't based on a EDNS option, EDNS flag, EDNS version, QTYPE, QCLASS, DNS flag, opcode or similar. It purely load based. For completeness named can also be configured to drop queries based on address but is drops all queries so it behaves like a dead server to that client. A nameserver / firewall should not be looking at query content and deciding not to answer based on that content. If you don't want to implement a EDNS than don't implement it. If you don't want to use a EDNS option with some client then just ignore the option. Similarly for EDNS flags. The client is expecting that unsupported options and flags will be ignored not used to decide to drop a query. Mark -- 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 https://www.ietf.org/mailman/listinfo/dnsop
