hpr-knowledge-base/hpr_transcripts/hpr0588.txt

Episode: 588
Title: HPR0588: Klaatu interviews Brian Smith from dns.com
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0588/hpr0588.mp3
Transcribed: 2025-10-07 23:34:43

---

Hi everyone, this is Klaatu and I am at Southeast Linux Fest 2010, this is the second annual
Southeast Linux Fest and I have met Brian Smith from dns.com and I decided to talk to
Brian, so you're here with dns.com, so let's start from the really, really basics.
Okay, so let me tell you what I know about dns. I make a request to a website. There's a box somewhere
that has names and IP addresses sort of related to each other. It looks up the IP address so that it knows what
website to direct me to. So is that a fair assessment? That's pretty accurate. DNS, you can also look at as a key value
source, so you have a list of zones as they're called. That would be like example.com or www.example.com.
And if you're requesting for a webpage, typically you're going to be asking for a record or an IP address.
You can get all kinds of different responses back, C names, which are just canonical names, like another www.example.com.
Knowing that now, so what do you guys offer at dns.com doing? Like what kind of services do you guys offer?
We offer general authoritative DNS services, so we're not like open DNS or Google public DNS word.
Anybody can come to us and start asking for resolution. But if you do have DNS services that you do need for a large scale website,
we can manage that for you. You just come to us, point your zones at us, and we have I think around 15 servers right now that are geographically dispersed
on a dual DNS network. So we have a 5-9 SLA, and we are basically competing with like ultra DNS and 9-DNS.
And we have dynamic DNS services. We were the first to come out with a really rich API, RCC and base, so it's very easy for people to integrate with.
We kind of have nicheed ourselves in the geographic realm of things where we have geodirectional resolution down to a city level.
So with 98% accuracy, we can state that a query coming from a server is in, say, Chicago, Illinois and give a specific response back to that,
or to that specific request door. And people will want that.
Is that good or evil? It's contextual. Somebody could use it for evil. Somebody can also use it for very good. Say if you're an advertiser, which you can argue, good or bad.
But at the same time, do you want to, if you go to hotdogs.com, do you want to know about a hotdog shack in South Beach, California, or one that's in your neighborhood?
So in that, it's really useful. If you are a CDN network, conscious delivery network, do you want to send a user to a server that's on the other side of the country or caught in a way?
Or do you want to send them to one that's closest to you so that they have the best response? That's really where it comes into play.
And it can be very functional. A lot of the DNS community, the old school guys, they hate what we do, because they think we're breaking DNS as a standard data, because you're supposed to, whatever you've handed to the resolver, they're supposed to hand to all of their clients.
So that knowledge is supposed to be shared universally, but we're doing our best to try and make sure that we are upholding the course of DNS and still satisfying this niche that is out there that people do want that service.
Okay, yeah, that, I mean, it does sound really cool. So who are your, what's the customer base? And is it primarily companies that have a website, people are going to it, and they want to show me, here's my local results or whatever?
Or are there people who use it for, like, I don't know, what would it be? Well, like dynamic DNS kind of services or...
Even though we do have these dynamic DNS, we, you don't have a whole lot of play in the geographic welcome up there.
But what we do have is, or a lot of our customers are like, say, councils of cities, they want to send, if you live in France or something, if you had a france.com, you could send everybody who's in France to your local chapter,
and then everybody else, you could send somewhere else. For them that might be useful, but mostly we see a lot of use from CDNs, and then also just advertise if you are looking to try and get the most relevant response.
Now, as far as what's on the website, we don't have a whole lot of play and what is ended up presented in the HTML.
And that's generally done with, say, a Max-Mind API, which was that somebody might have on their own or any other GOIP that's available.
So now, in terms of having more security in us, because I know that, I mean, like, obviously, Dan Kaminsky, and well-known names like that, they kind of are, I guess, exposing a lot of stuff in the DNS realm.
Would there be a security advantage, do you think, with using something like your service for a business?
We like to think so. Our system is not based off bind or any of the other traditional softwares. We've kind of developed our stuff in-house.
We've been very careful to always do as much testing as much penetration as we can against it, to make sure that we are always sick, because the last thing we need is, you know, it's for no to go down or to be hacked.
But make security advantage compared to, say, open DNS or now Norton's Dines Partnership and Google Public is that we're not an open resolver.
And that's where really a lot of the vulnerabilities came from, with cash points. Where we don't do any kind of resolutions. There's not really any cash for somebody to actually play.
The cash that we have in our system, we know about, we don't ask any other resolvers that are out in the world what data to request.
So there's no possibility for there to be a cash poisoning on it.
You know, I mean, I know I've heard of cash poisoning, but honestly, I've no earthly clue about what that is. Could you maybe enlighten me a little bit?
Yeah, we can go over that one of the more famous ones, the Kaminsky attack. Basically, what you would do is you have an open resolver, or not even an open resolver, just a resolver.
And you initiate a request for, say, Microsoft.com. You know that you're asking for an A record. And so what you would do from that point is then bombard that system with as many queries as you came with all the query IDs to try and match the same query ID that it sends the request to Microsoft.
And you're trying to basically feed it to the Microsoft response and you're going to add additional data to the additional record section of your response that you're sending that you're poisoning with.
And that might contain data for say www.microsoft.com or windows update.microsoft.com. And you're putting in poison data that would send users who got that response to your server.
And when, say, the servers do accept receive the response of these resolvers, they're going to see this additional data. And they're going to reference that inside their own cash and say, this is more recent data.
So I should override my cash with what this data says. And by doing so, you have them poison their cash for anybody who comes by request www.microsoft.com or windows update. And then you're sending that traffic to your servers for the remainder of the TTL.
Wow, that is really crazy. It's really cool. But happily, if people are using your service DNS.com, that's not really something that happens because you don't keep your own. There's no cash to poison is what you said, right?
That would be correct.
Okay. Thanks a lot for the info.
Oh, no problem. Thank you.
Thanks.
Thank you.
That's the audio.
Thank you for listening to H.P.R. sponsored by tarot.net. So head on over to C.A.R.O.N.T. for all of us in need.
Thank you.