problem resolving ardownload.adobe.com --enable-sit harmful?

[Mark Andrews]

I suggest that you log a complaint with Adobe requesting that they
contact their nameserver vendor for a fix.  This bug is similar in
nature to that of http://www.kb.cert.org/vuls/id/714121 (NXDOMAIN
incorrectly returned to a AAAA query).  Unknown EDNS options are
supposed to be ignored by the nameserver, RFC 6891, though that
wasn't clear in RFC 2671.  NXDOMAIN however is a idiotic response
to a unknown EDNS option.

	dig ardownload.wip4.adobe.com @da1gtm001.adobe.com +nsid

will also demonstate this bug and doesn't involve using experimental
EDNS opcodes that +sit does.

At least the server returns BADVERS to EDNS(1) queries.  

There are a number of nameservers that fail to respond correctly
to unknown EDNS options to EDNS(1) queries.  Dig can demonstrate the
server failing.

	dig name @server +edns=1
	dig name @server +nsid
	dig name @server +sit		      (BIND 9.10.0 compiled with
							 --enable-sit)
	dig name @server +ednsopt=#[:payload] (BIND 9.11.0 or later)

Each domain I have seen failing has had different failure signatures.

It looks like nameserver vendors are not doing even rudimentry
checks like those above.  DiG has thos options so that we could
perform checks like these.

Until Adobe fix their broken servers you can use a server clause to
disable sending SIT requests to them.  Obviously this does not scale.

	 server <address> { request-sit no; };

Mark

In message <1404418984.5134.52.camel at ns.five-ten-sg.com>, Carl Byington writes:
> I re-ran the dig to localhost (running bind 9.10.0-P2), and grabbed the
> packets with tcpdump.
> 
> dig ardownload.adobe.com. @localhost
> 
> That sent a query to 192.150.19.247 with flags = 0, edns size = 512, and
> got an NXDOMAIN answer. So I tried to reproduce that query with dig:
> 
> dig ardownload.wip4.adobe.com a @192.150.19.247 +dnssec +norecur
> +noadflag +bufsize=512
> 
> According to tcpdump, that sent the same query, but it got the cname
> answer.
> 
> The outgoing query from the local bind-9.10.0-P2 contains an extra 12
> bytes of data in the OPT record, after the Z field containing the DO
> bit. This version of bind was compiled with --enable-sit
> 
> It seems that the adobe servers choke on that.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEARECAAYFAlO1u5wACgkQL6j7milTFsH2IACfVK7hgK/L4XprzUWpJ7PGeXQV
> 938AmwcrygxiD7pZD3qYVtaL37idfHWp
> =Ah7c
> -----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