bind 9.11, cookes by default

[Mark Andrews]

In message <1479332234.30976.34.camel at ns.five-ten-sg.com>, Carl Byington writes
:
> On Thu, 2016-11-17 at 07:47 +1100, Mark Andrews wrote:
> > I know you think doing this collectively is a service but having
> > individuals discover and complain to the site operators that their
> > DNS is broken is the only way there will be enough presure brought
> > to bear for some of these companies to fix their server
> > configurations.
> 
> > It requires noise for them to act.  Collectively hiding broken
> > servers doesn't generate the noise.
> 
> I agree that having individuals complain is the way to bring enough
> pressure to get things fixed. But recording the results of the discovery
> process can be centralized.
> 
> 
> > https://ednscomp.isc.org/ has lists of servers with broken EDNS
> > support some of which stops / slows DNS resolution in BIND.
> 
> I am only interested (for now) in the names that are fully broken
> without "send-cookie no". It seems more important to get those fixed,
> than to fix those that (only) slow down resolution.
> 
> I propose adding /etc/named.broken.servers to track those that cannot
> handle cookies, but that file won't be included in the default
> /etc/named.conf configuration. It will include for each server the dig
> tests that can verify that the server is still broken, and should
> include contact information so the bind administrator can send a note
> asking that it be fixed.
> 
> For example, something like:
> 
> // adobe servers that don't understand edns options
> //
> // please send a note asking hostmaster at adobe.com to fix those servers.
> //
> // dig wip4.adobe.com ns
> // dig airdownload.wip4.adobe.com @192.150.16.247   +cookie ==> nxdomain
> // dig airdownload.wip4.adobe.com @192.150.16.247 +nocookie ==> noerror
> server 192.150.16.247   { send-cookie no; };
> server 192.150.19.247   { send-cookie no; };
> server 193.104.215.247  { send-cookie no; };
> 
> 
> 
> Note that "dig wip4.adobe.com soa" shows hostmaster at sj1gtm001.adobe.com
> for that zone, but sj1gtm001.adobe.com has no MX record, and the A
> record target does not answer port 25 connections.

Adobe has been told multiple times that their servers are misconfigured.
The even half fixed them once.  Their DNS administrators are just
plain incompentent.  They can fix this in less than 5 minutes by
adding a single period (.) to the end of "sl-download.adobe.com.edgekey.net"
in the fallback zone which is used when the a cookie option is
present.  It should be "sl-download.adobe.com.edgekey.net." which has a
period at the end.

Without a cookie option you get:
airdownload.wip4.adobe.com. 300	IN	CNAME	ssl-download.adobe.com.edgekey.net.

With a cookie option you get:
airdownload.wip4.adobe.com. 300	IN	CNAME	ssl-download.adobe.com.edgekey.net.wip4.adobe.com.

They just refuse to act.

Mark
 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEAREKAAYFAlgs0WkACgkQL6j7milTFsFF5gCfdguqebQ8OAlClMDJMbFQH06h
> LtQAn16TQQaG/zgAL0Sx/mrFCdSvnFwJ
> =O049
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org