Maybe DNS authority server software could auto-generate TXT records for what would otherwise be ENTs, or zone administrators could add them manually,
E.g. ent.example.com TXT "This object intentionally left blank." This avoids the ENT issue. I can't think of any way that would break anything. The issue with ENTs is that they have children, which are not changed or harmed. Preventing the erroneous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be returned. Brian Sent from my iPhone > On Feb 9, 2017, at 11:57 AM, Mark Andrews <ma...@isc.org> wrote: > > > In message <20170209163123.56hdbzaluekmv...@nic.fr>, Stephane Bortzmeyer > writes > : >> On Wed, Feb 08, 2017 at 12:36:23PM -0800, >> Brian Dickson <brian.peter.dick...@gmail.com> wrote >> a message of 258 lines which said: >> >>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=1. >>> - cache the response, and as appropriate, re-query periodically. >>> - If a query for <anything>.onion is received, reply with the authenticated >>> denial of existence from the root (cached in step 2) >> >> Note that, if you implement RFC 7816 and RFC 8020, you already have >> this behavior. No work for us :-) > > Only if you are willing to break lookups for names where there are > missing delegations in parent zone and the parent and child zones > share the same nameservers or the nameserver just misimplements ENT > or the nameserver implements RFC 2535 NXDOMAIN (ENT don't exist > with RFC 2535). All of these result in NXDOMAIN for ENT. > > RFC7816 > > A problem can also appear when a name server does not react properly > to ENTs (Empty Non-Terminals). If ent.example.com has no resource > records but foobar.ent.example.com does, then ent.example.com is an > ENT. Whatever the QTYPE, a query for ent.example.com must return > NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly > return NXDOMAIN for ENTs. If a resolver queries only > foobar.ent.example.com, everything will be OK, but if it implements > QNAME minimisation, it may query ent.example.com and get an NXDOMAIN. > See also Section 3 of [DNS-Res-Improve] for the other bad > consequences of this bad behaviour. > > 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
