[nycbug-talk] dns abuse
carton at Ivy.NET
Thu Jan 22 08:58:09 EST 2009
>>>>> "y" == Yarema <yds at CoolRat.org> writes:
y> When DNSSEC becomes a serious requirement djbdns will either
y> have to offer a solution or fall by the wayside.
good plan. Make obstructionist criticisms during the standards
process. Ignore the result and let others do the implementation work.
Call the result bloated and confusing.
successful, but not very foreward-thinking or neighborly.
won't support dns-sd if it can't write to LDAP.
y> I don't know if it's a BIND "bug" rather it seems like a
y> byproduct of having the authoritative server and caching
y> resolver be part of the same app.
you can turn off the caching resolver with a config option that many
people use, so if it's not completely off when you turn it off, then
that's a bug.
But when the caching resolver is off, if you ask BIND anything it will
reply telling you to go back and ask the root nameservers. This is
its way of refusing to answer. so in that sense it's a corner case.
In general, simply ignoring a query can have bad consequences, like in
my recent thread about facebook ignoring queries for AAAA records, in
combination with their gratuitously short load balancer timeouts,
making the site almost unuseable for anyone who has IPv6 and a browser
set to prefer it.
Ignoring might be the best thing to do in this case. I'm just
pointing out that there IS an argument on the other side, for giving
replies of some kind to bad queries---recursive resolvers are designed
to use DNS's redundancy and can answer queries much more quickly if
they don't have to wait on timeouts when servers are pissed at them.
y> If the attacker sends queries to which my server
y> replies because it is authoritative for that zone -- then only
y> my servers will be "flooding" the spoofed address.
yes you have to send different queries to each amplifier instead of
sending the same one everywhere. This makes the attack tool harder to
write, but certainly not impossible, hence ``security through
y> djbdns was written mostly in response to BIND 4.x.x. The fact
y> that it's still useful and secure today speaks to the fact
y> that he did something right.
yeah that sounds fair to me.
And I do feel lukewarm about these wippersnappers and their modern
bloatware. (including LDAP :' )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 304 bytes
Desc: not available
Url : http://lists.nycbug.org/pipermail/talk/attachments/20090122/eef9efe7/attachment.bin
More information about the talk