Let me again rephrase…
As a white-hat attempting to find problems to address through legitimate means, how
do you …
Owen
Once upon a time, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> said:
Now explain how you find a recursive nameserver that isn't listed in an NS
entry and *hasn't* been publicized someplace that Google can find it.The same way you find open mail relays, SSH hosts with weak
user/password combos, bad WordPress installs, etc. - scan for them. If
it is open to the Internet, it will be found (or probably already has
been).Let me rephrase the question� How do you find an open IPv6 recursive name server
that isn't listed in an NS entry and hasn't been publicized someplace that Google can
find it?That question was already answered ... ask the bots what their resolving name servers are, then check to see if they are open. As IPv6 deployment increases, the answers will increasingly include IPv6 open resolvers.
Doug
Let me again rephrase�
As a white-hat attempting to find problems to address through legitimate means, how
do you �
passive DNS collection , e.g. many people lave large lists of resolvers that have connected to their authoritative nameservers.
What mobile devices do you support that don't acquire a suitable local DNS resolver using DHCP or PPP?
Pretty much all devices are *able* to acquire a DNS resolver via DHCP.
Honest question. I presume you wouldn't bring it up if it wasn't a real problem.
The problem starts when you don't *trust* DHCP to hand you a pointer to
a *working* DNS resolver (anybody who's had a hotel net hand them a DNS
that's either busted or MITMs your queries knows what I mean, and I hope
I don't have to explain about the fun involved in using wireless anywhere
near a DefCon or Black Hat conference).
And yes, unless you turn on DNSSEC you don't have much defense against
a hotel net or rogue net that decides to spoof replies to your queries
to your home DNS server
Now in day-to-day production, it's *mostly* a non-issue, because many/most of
the people who hard-code our DNS into their mobile configs will also fire up a
VPN to our campus. Unfortunately, that leaves us a lot of interesting to
diagnose corner cases involving DNS lookups that happen between when they boot
the device and when they launch the VPN (for instance, coding a DNS name
rather than an IP for the VPN endpoint 
Thanks 
Well,
As a white-hat attempting to find problems to address through legitimate means, how
do you �
You make friends with people with busy authoritative servers and see
who's querying them.
I suppose you could justify one probe per client and see if they appear to be open.
R's,
John
I'm confused. Don't most authoritative servers have to
answer to just about anyone in order to be useful?
Matt
Authoritative DNS servers need to implement rate limiting. (a client
shouldn't query you twice for the same thing within its TTL).
If you give the same answer 15x to the same person in a few seconds one can possibly infer they aren't a caching resolver or are broken. Either way you can think about ignoring them for a few with dampening or similar.
OK, but we started this discussion about open recursive resolvers,
right? Securing your recursive resolvers is a very different problem
space from trying to come up with rate limits for your authoritative
nameservers.
In terms of impacts people are feeling today, is most of the pain
coming from open recursive servers being abused by miscreants,
or from miscreants doing spoofed queries against authoritative
nameservers?
The concern Valdis raised about securing recursives while still
being able to issue static nameserver IPs to mobile devices
is an orthogonal problem to Owen putting rate limiters on
the authoritative servers for he.net. If we're all lighting up
pitchforks and raising torches, I'd kinda like to know at which
castle we're going to go throw pitchforks.
Matt
So what you're saying is that a decade after Duane Wessels presented
at NANOG saying that 98% of the traffic hitting the root nameservers
was total bull, we're not doing much better?
Open Recursive DNS Resolvers.
The need to start seriously addressing this issue is kind of dire. The
problem with DNS Amplification attacks is getting worse, not better.
Oh yeah... and BCP38, too.
They both kind of go hand-in-hand.
- ferg
BCP38. As you can see from the wandering conversation, there are many attack vectors that hinge on the ability to spoof the source address, and thereby misdirect responses to your DDoS target. BCP38 filtering stops them all. Or, we can ignore BCP38 for several more years, go on a couple years crusade against open recursive resolvers, then against non-rate-limited authoratative servers, default public RO SNMP communities, etc.
You are assuming that there is a recursive server making the queries
and that there are not multiple recursive server behind a NAT.
Neither of these assumptions in true in practice and with the
deployment of CGNs these will become less true.
I have two recursive server at home behind a NAT today. Both do
DNSSEC.
Mark
And I don't plan on being around doing this sort of work in another
10+ years, so let's stop farting around. :-p
- ferg
Both. And BCP-38 as well. Lots of effort is needed in this space.
Jared Mauch
Both are currently being abused.
Rate limiting itself causes operational problems for legitimate
users of authoritative servers and will only have a limited effect
for a limited time. It is a stop gap measure.
Mark
As a white-hat attempting to find problems to address through legitimate means, how
do you �You make friends with people with busy authoritative servers and see
who's querying them.I'm confused. Don't most authoritative servers have to
answer to just about anyone in order to be useful?
yes, and that's why they're useful for tracking who has a resolver.
Yes. And that list will contain lots of recursive servers.
Cheers,
-- jra
I'm struggling to understand why it's necessary to hard-code dns servers
into the ip networking configuration of a portable device. By definition,
these devices will already have dhcp enabled.
Nick