[MaraDNS] I no longer have time to fix recursive resolution bugs

--===============1856585963==
Content-Type: multipart/alternative; boundary=001a1143eedc220f42053839f51f

--001a1143eedc220f42053839f51f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Deadwood's recursive resolution is not bug-for-bug identical to BIND's
recursive resolution; I have, ever since the beginning of 2015, have not
had time to fix these issues. This in mind, if using root_servers, a small
number of misconfigured domains which resolve in BIND anyway do not resolve
in Deadwood. These are the known issues:

   - MaraDNS does not resolve RFC-violating CNAME records combined with
   other records the way BIND does. Discussion:
   http://samiam.org/blog/2015-02-11.html
   - MaraDNS does not handle out-of-bailiwick glue records for CNAME
   records the way BIND does. Discussion:
   http://samiam.org/blog/2016-07-21.html#MaraDNS_Not_chasing_moving_goalpo=
sts
   - MaraDNS does not handle out-of-bailiwick glue records for NS referrals
   the way BIND does.

The first issue is caused because CNAME records with other records
downright violate the RFCs, so there=E2=80=99s no standardized behavior for
handling them. The second and third issue are caused because older versions
of BIND handled them differently than newer versions of BIND; MaraDNS'
recursive algorithm was designed in 2001 to emulated BIND's older behavior,
and the 2010 recursive rewrite used the same algorithm.
If I were to win the lottery, allowing me to retire early, I would have
time to fix these issues -- but right now I do not.

--001a1143eedc220f42053839f51f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Deadwood&#39;s recursive resolution is not bug-for-bug =
identical to=20
BIND&#39;s recursive resolution; I have, ever since the beginning of 2015,=
=20
have not had time to fix these issues. This in mind, if using=20
root_servers, a small number of misconfigured domains which resolve in=20
BIND anyway do not resolve in Deadwood. These are the known issues:</p>

<ul><li>MaraDNS does not resolve RFC-violating CNAME records combined with =
other records the way BIND does. Discussion: <a href=3D"http://samiam.org/b=
log/2015-02-11.html">http://samiam.org/blog/2015-02-11.html</a>
</li><li>MaraDNS does not handle out-of-bailiwick glue records for CNAME re=
cords the way BIND does. Discussion: <a href=3D"http://samiam.org/blog/2016=
-07-21.html#MaraDNS_Not_chasing_moving_goalposts">http://samiam.org/blog/20=
16-07-21.html#MaraDNS_Not_chasing_moving_goalposts</a>
</li><li>MaraDNS does not handle out-of-bailiwick glue records for NS refer=
rals the way BIND does.</li></ul>

<p>The first issue is caused because CNAME records with other records=20
downright violate the RFCs, so there=E2=80=99s no standardized behavior for=
=20
handling them. The second and third issue are caused because older=20
versions of BIND handled them differently than newer versions of BIND;=20
MaraDNS&#39; recursive algorithm was designed in 2001 to emulated BIND&#39;=
s=20
older behavior, and the 2010 recursive rewrite used the same algorithm.</p>

If I were to win the lottery, allowing me to retire early, I would have tim=
e to fix these issues -- but right now I do not. </div>

--001a1143eedc220f42053839f51f--

--===============1856585963==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
List mailing list
[email protected]
https://postbox.samiam.org/mailman/cgi-bin/listinfo/list

--===============1856585963==--