In message <0394528c-99cd-41d4-9ab6-844d13182...@gmail.com>, Brian Dickson writ
es:
> 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 t=
> hat they have children, which are not changed or harmed. Preventing the erro=
> neous NXDOMAIN by a hack is still preventing an NXDOMAIN which should not be=
> returned.
>
> Brian
Brian.
There is only one time you can trust a NXDOMAIN to mean
there is no data under it. That is when it validates as secure.
At the moment we have Ted saying that if you want privacy you MUST
also turn on DNSSEC validation and implement QNAME minimisation and
implement agressive negative caching (still a I-D). This is all
because of ungrounded fears of people using DNS as a way to do a
opt-in experimental naming in .alt where we intend to have experimental
opt-in naming services. Add to that it is suggested that we create
yet another TLD (.lcl) where such services would be allowed.
Mind boggling inconsistancy.
Mark
> Sent from my iPhone
>
> > On Feb 9, 2017, at 11:57 AM, Mark Andrews <ma...@isc.org> wrote:
> >=20
> >=20
> > In message <20170209163123.56hdbzaluekmv...@nic.fr>, Stephane Bortzmeyer w=
> rites
> > :
> >> On Wed, Feb 08, 2017 at 12:36:23PM -0800,
> >> Brian Dickson <brian.peter.dick...@gmail.com> wrote=20
> >> a message of 258 lines which said:
> >>=20
> >>> - upon startup, do a query for "onion" (the non-existent TLD), with DO=3D
> =
> 1.
> >>> - cache the response, and as appropriate, re-query periodically.
> >>> - If a query for <anything>.onion is received, reply with the authentica=
> ted
> >>> denial of existence from the root (cached in step 2)
> >>=20
> >> Note that, if you implement RFC 7816 and RFC 8020, you already have
> >> this behavior. No work for us :-)
> >=20
> > 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.
> >=20
> > RFC7816
> >=20
> > 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.
> >=20
> > Mark
> >=20
> > --=20
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.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
https://www.ietf.org/mailman/listinfo/dnsop
