In message <1479332234.30976.34.ca...@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 hostmas...@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 hostmas...@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@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: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users