Re: BIND Patch hands Verisign another weapon

> 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.

Verisign only has glue. Glue is not an answer. Failure
to supply the referral would be a violation of the DNS
protocol. They should be working towards only returning
glue in the additional section to being the server into
compliance with RFC 2181. BIND 8 has the same issues.

What Verisign has done to date has not been in violation of the
DNS protocol. I don't expect them to break the DNS protocol.

What they have done is violate the trust placed in them to
mange the COM and NET zones reasonably. Adding the wildcard
violated peoples expectations of what is reasonable.

> (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.
>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org