If you managed to make it through twelve years of primary education and four years of college without learning how to spell 'shiny', just how valuable do you think you're going to be to anyone, degree or not?
Yeah, most of the time so-called "reverse lookups" are done by doing a normal query of a PTR RR. But there is also, an obscure DNS query called an iquery, where the answer is prefilled in with the IP address and any name. If the query type is IQUERY, then the server (if it supports it) is supposed to lookup the name that corresponds with the IP address.
Not quite. IQUERY, to the extent that it was ever actually used, was explicitly defined as an inappropriate method for obtaining A RRs corresponding to a given address. An inverse query is an answer, and the queried server is supposed to respond with the set of *questions* that would result in the queried answer being returned, if they were asked of the server. One of those questions might be an A record for a FQDN whose right hand side is the IP address queried for in the inverse query, but only if the queried server has such a record locally.
It's an unfortunate byproduct of the near-equivalence in everyday English of 'inverse' and 'reverse' that people confuse the two when talking about the DNS.
I don't think any publicly released, non-experimental name server implementations ever actually implementd IQUERY. I'd love to be proved wrong, though.
Is it just me, or is this a description of a reverse lookup? How does that qualify as unnecessary?
I believe that reverse lookups are identified by an "inverse" status flag in the request header. One can only assume that the authors were not counting this sort of valid query, and were only focusing on the "standard" queries that contained IP addresses. Those certainly would, I think, be rather pointless.
Ummm, no. "inverse" does not in any way shape or forme identify a request for the hostname associated with an IP address.
And the lookups being described are not reverse loops, either. A 'reverse lookup' for 1.2.3.4 is a query for the PTR RR associated with 4.3.2.1.in-addr.arpa. The queries being described are for the A RR associated with the FQDN 1.2.3.4. There is no such TLD as '4.'
If the authors actually thought how the DNS works they would realise the reason for this. A DNS server that gets a request for.com will consult the root the first time and then cache the result. So even though the server might then get a million hits in.com it won't ask the root again.
Well, that's the theory. In practice, however, there are millions of servers out there that do not cache NXDOMAIN at all, and just keep querying, over and over and over again, for TLDs that they've already been told don't exist. Microsoft's name server has been known to do this.
At one point, f.gtld-servers.net was seeing millions of repeated queries per hour from the same two.mil servers asking the same question and refusing to accept the NXDOMAIN. For long periods, these two servers were asking the same question multiple times per click of F's timer. That's.. ummm.. Bad.
I suggest that you read the actual CAIDA paper, and the other papers on the subject that Evi Nemeth and others at CAIDA have produced. They *have* thought about how the DNS actually works in practice. You've only thought about how it would work if every implementation worked perfectly, according to your expectations.
Third, he also made a point of running into the senior engineer a number of times. Getting hit by one of those things is no worse then getting hit by someone who weighs 75
pounds more then you do.
Uhh huh, right. You ready to have that junior engineer run into your grandmother with this thing? How about your six year old daughter? These things are a menace on the sidewalk, period.
Re:Perhaps this is yet more proof
on
Brian West Update
·
· Score: 2, Insightful
Good *god*, how long is it going to be before people stop believing this argument? This isn't like someone "noticing that you left your car doors unlocked and pointing it out to you". It's like someone noticing your car doors are unlocked, climbing in, popping the trunk, having a good look around in there, rifling your glove box, stealing the paper you left there with the access code for your home security code on it, and grabbing a copy of the business plan and customer list you had in the back seat.
"The most interesting thing about Saturday's games... was thenew league's efforts to use technology..."
How sad is this? I mean, really, Jon. Did you *see* the players? Did you *see* the cheerleaders? The most interesting thing about the XFL is the babes on the field and on the sidelines, not the helmetcam.
OTOH, the most interesting thing about the Las Vegas game may have been how the XFL managed to get 45 guys under 30 in a group, and only 3 were named Jason.
Slashdot Mirror
If you managed to make it through twelve years of primary education and four years of college without learning how to spell 'shiny', just how valuable do you think you're going to be to anyone, degree or not?
Not quite. IQUERY, to the extent that it was ever actually used, was explicitly defined as an inappropriate method for obtaining A RRs corresponding to a given address. An inverse query is an answer, and the queried server is supposed to respond with the set of *questions* that would result in the queried answer being returned, if they were asked of the server. One of those questions might be an A record for a FQDN whose right hand side is the IP address queried for in the inverse query, but only if the queried server has such a record locally.
It's an unfortunate byproduct of the near-equivalence in everyday English of 'inverse' and 'reverse' that people confuse the two when talking about the DNS.
I don't think any publicly released, non-experimental name server implementations ever actually implementd IQUERY. I'd love to be proved wrong, though.
I believe that reverse lookups are identified by an "inverse" status flag in the request header. One can only assume that the authors were not counting this sort of valid query, and were only focusing on the "standard" queries that contained IP addresses. Those certainly would, I think, be rather pointless.
Ummm, no. "inverse" does not in any way shape or forme identify a request for the hostname associated with an IP address.
And the lookups being described are not reverse loops, either. A 'reverse lookup' for 1.2.3.4 is a query for the PTR RR associated with 4.3.2.1.in-addr.arpa. The queries being described are for the A RR associated with the FQDN 1.2.3.4. There is no such TLD as '4.'
Well, that's the theory. In practice, however, there are millions of servers out there that do not cache NXDOMAIN at all, and just keep querying, over and over and over again, for TLDs that they've already been told don't exist. Microsoft's name server has been known to do this.
At one point, f.gtld-servers.net was seeing millions of repeated queries per hour from the same two .mil servers asking the same question and refusing to accept the NXDOMAIN. For long periods, these two servers were asking the same question multiple times per click of F's timer. That's.. ummm.. Bad.
I suggest that you read the actual CAIDA paper, and the other papers on the subject that Evi Nemeth and others at CAIDA have produced. They *have* thought about how the DNS actually works in practice. You've only thought about how it would work if every implementation worked perfectly, according to your expectations.
OK, I'm really sorry, but for god's sake. The whole question of the ethics and economics of diamonds pales in comparison to this:
What kind of girl would marry a guy who would come to *SLASHDOT* for advice about an engagement ring?
Good lord, man. Have some freaking dignity.
is "The Register has also covered this story in an easier to read fashion."
Heaven forbid someone should actually have to spend more than thirty seconds reading about significant issues of the day.
The Register: When USA Today is just too complicated for you.
Uhh huh, right. You ready to have that junior engineer run into your grandmother with this thing? How about your six year old daughter? These things are a menace on the sidewalk, period.
Know how to tell when an EMC sales rep is lying?
His lips are moving.
Good *god*, how long is it going to be before people stop believing this argument? This isn't like someone "noticing that you left your car doors unlocked and pointing it out to you". It's like someone noticing your car doors are unlocked, climbing in, popping the trunk, having a good look around in there, rifling your glove box, stealing the paper you left there with the access code for your home security code on it, and grabbing a copy of the business plan and customer list you had in the back seat.
"The most interesting thing about Saturday's games ... was thenew league's efforts to use technology..."
How sad is this? I mean, really, Jon. Did you *see* the players? Did you *see* the cheerleaders? The most interesting thing about the XFL is the babes on the field and on the sidelines, not the helmetcam.
OTOH, the most interesting thing about the Las Vegas game may have been how the XFL managed to get 45 guys under 30 in a group, and only 3 were named Jason.