BIND Patch hands Verisign another weapon

[Jonathan de Boyne Pollard]

JW> I hope this patch does not filter out glue records for 
JW> nameserver hosts?!

PV> if you query for glue directly you should be 
PV> receiving delegations, so, no.

If one queries for "glue" directly, Verisign's servers return complete
answers, not referrals.

   [C:\]dnsqry /server:m.gtld-servers.net. a ns1.pingmagic.com. | tail /9
   [192.55.83.30:0035] -> [0.0.0.0:0000] 126
   Header: 0001 1+1+2+2, R, , query, no_error
   Question: ns1.pingmagic.com. IN A
   Answer: ns1.pingmagic.com. IN A 172800 202.140.169.216
   Authority: pingmagic.com. IN NS 172800 ns1.pingmagic.com.
   Authority: pingmagic.com. IN NS 172800 ns2.monitor724.com.
   Additional: ns1.pingmagic.com. IN A 172800 202.140.169.216
   Additional: ns2.monitor724.com. IN A 172800 143.89.51.48

   [C:\]

The only reason that this happens to work with the new 
"delegation-only" feature is the presence of the resource record
sets in the "authority" section, allowing the answer domain name 
to be recognized as being under an actual registered subdomain 
of "com.", thereby skipping the "delegation-only" processing.  

But Verisign can simply turn off the addition of such resource 
records, leaving just the bare answer resource record set.  This, 
according to the rules for "delegation-only", would force BIND to 
turn the response into a "no such name" answer for 
"ns1.pingmagic.com.".  Without "delegation-only", in contrast, the 
response would be used as it stood.  Thus, by this patch, Verisign 
is handed a weapon for causing explicit queries for "glue" to yield 
wrong answers _only_ to those people employing "delegation-only", and 
thereby for causing denials of service specifically for the people 
who are trying to disregard its wildcards with this mechanism.  

(Alas!  Using "www.example.com." as the intermediate domain name for 
an "example.com." content DNS server, and similar unwise practices, 
are not entirely unheard of.  So one cannot assert that if Verisign 
chose to mount such an attack it would have little effect becase
explicit queries for the intermediate domain names would be 
unlikely to be issued.  There's also the common occurrence of lookups
for intermediate domain names such as "m.root-servers.net." to take 
into account.)

All of the patches, for all of the DNS server softwares, published 
thus far have handed Verisign a new weapon.  This one is simply 
subtler than most.  If one is taking the view that Verisign has 
gone rogue, handing it further powers to do more damage (as these 
various mechanisms all do) is not the way to proceed.