Versign wildcards in TLD domains

  • Thread starter Thread starter Kenneth Porter
  • Start date Start date
KP> This will affect those using DNS for anti-spam measures,
KP> and is a raging topic on the anti-spam mailing lists.

It will affect more than that. It also affects the likes of you
and me, here in these fora.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-coup.html#Consequences>

It has already become a raging topic on the discussion fora for
ISC's BIND and Dan Bernstein's "djbdns", where some people are
promoting some very bad ideas. (Most ironically, users of
Microsoft's DNS are fortunate here, in that the closed source
nature of the software prevents these bad ideas from taking hold
as quickly. I'm dreading Microsoft beinging out a "hotfix"
incorporating these bad ideas, though.)
 
Yep, the monopoly...

--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
 
coup.html#Consequences>

Nice summary.
It has already become a raging topic on the discussion fora for
ISC's BIND and Dan Bernstein's "djbdns", where some people are
promoting some very bad ideas. (Most ironically, users of
Microsoft's DNS are fortunate here, in that the closed source
nature of the software prevents these bad ideas from taking hold
as quickly. I'm dreading Microsoft beinging out a "hotfix"
incorporating these bad ideas, though.)

Note that the flaws in these initial attempts were quickly identified and
ISC's official patch to BIND is a bit more intelligent. It doesn't block
the specific IP address that Verisign selected (which almost everyone
agrees is a bad solution). Instead, it introduces the idea of a
"delegation-only" zone. In such a zone, only the SOA and NS record are
accepted from authoritative servers. Other records (particularly the
wildcard A) are rejected and the client is presented with a NXDOMAIN
answer. This solution can easily be applied to the country-code TLD's that
have already been doing this for some time.

http://www.isc.org/products/BIND/delegation-only.html

The open source alternatives to MS can quickly test different solutions
while those of us with more conservative tendencies can site back and wait
for others to get the bloody knuckles. We can then move forward and adopt
the wrung-out solution.
 
JdeBP> <URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/verisign-internet-coup.html>

KP> Note that the flaws in these initial attempts were quickly
KP> identified [...]

They were by me, certainly. I had the web page up detailing the
flaws that same day. They weren't by a lot of other people, though,
and still aren't by some.

KP> [...] ISC's official patch to BIND is a bit more intelligent.

Not really. ISC's patch doesn't fix the problem, either. I
analysed it yesterday and found a flaw that allows Verisign to
specifically target those users of the "delegation-only" mechanism
with denials of service, should it wish to. I decided to write up
the flaw for "comp.protocols.dns.bind" before writing it up for the
web page. I wrote it up for "comp.protocols.dns.bind" yesterday,
and I'm writing it up for the web page today.

KP> We can then move forward and adopt the wrung-out solution.

The wrung-out solution is, ironically, the first one that most
people thought of: Revoking Verisign's authority. This is an
administrative problem with a talking-to-human-beings fix, not a
technical problem with a software fix. Someone to whom we have
delegated authority has breached our trust. Our remedy is to
revoke (or, at least, to threaten to revoke) that authority.

Alas! All of the flawed software patches and worthless petitions
appear to be distracting people from doing what they really should
be doing, which is contacting the root server organizations and
telling them to contact Verisign and tell it to revert to toeing the
line again (with the threat that they will stop delegating authority
for "com." and "net." to it if it doesn't), threatening to stop
delegating our authority to the root server organizations themselves
if they don't do this. (As I've said elsewhere, Microsoft, as a DNS
server software vendor, can swing considerable weight in this area,
given that many users of its software unquestioningly accept its
recommendation of root server organization.)
 
I think this is easy for Verisign to get around too. All they have to do is
add NS records in the zone pointing to a server that contains the wildcard
records, so bind will still think it was talking to an authoritive server -
ask for the A record and get the A record produced from the wildcard. I
think if I read that right anyway.
 
If you matched the wildcard IP to that of the A record reply, you would know
its the wildcard trick and return nxdomain even if they had NS delegations.
 
Back
Top