Skip to main content
The 2024 Developer Survey results are live! See the results

What are you trying to accomplish? My guess is you're trying to do something and you think "monitoring DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

  4. Multiple egress points. Though less common now, it used to be very common for ISPs to proxy requests out and at times a single subscriber might get rotated on egress points (what you'd see as their IP) in even a single session. AOL used to do this a lot, and as they've dropped in popularity, I've seen other tools (mobile Opera) use proxies as well.

  5. DNS forwarding does not work this way. If someone tries to look up a hostname in your site, the vast majority of the time they'll wind up asking either google's 8.8.8.8 server or their ISP's recursive DNS server. In either case, the IP address that queries your DNS server for a hostname will not be the same as the source IP address of the web browser that comes looking a moment later.

In short, you can't get there from here. IP addresses are not (not they ever have been) unique 1-1 identifiers for a user. You'd break HTTP. You're stuck looking at the HTTP stream and parsing. Make sure your proxy supports Keep-Alive and you'd lessen the hit a bit.

What are you trying to accomplish? My guess is you're trying to do something and you think "monitoring DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

  4. Multiple egress points. Though less common now, it used to be very common for ISPs to proxy requests out and at times a single subscriber might get rotated on egress points (what you'd see as their IP) in even a single session. AOL used to do this a lot, and as they've dropped in popularity, I've seen other tools (mobile Opera) use proxies as well.

In short, you can't get there from here. IP addresses are not (not they ever have been) unique 1-1 identifiers for a user. You'd break HTTP. You're stuck looking at the HTTP stream and parsing. Make sure your proxy supports Keep-Alive and you'd lessen the hit a bit.

What are you trying to accomplish? My guess is you're trying to do something and you think "monitoring DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

  4. Multiple egress points. Though less common now, it used to be very common for ISPs to proxy requests out and at times a single subscriber might get rotated on egress points (what you'd see as their IP) in even a single session. AOL used to do this a lot, and as they've dropped in popularity, I've seen other tools (mobile Opera) use proxies as well.

  5. DNS forwarding does not work this way. If someone tries to look up a hostname in your site, the vast majority of the time they'll wind up asking either google's 8.8.8.8 server or their ISP's recursive DNS server. In either case, the IP address that queries your DNS server for a hostname will not be the same as the source IP address of the web browser that comes looking a moment later.

In short, you can't get there from here. IP addresses are not (not they ever have been) unique 1-1 identifiers for a user. You'd break HTTP. You're stuck looking at the HTTP stream and parsing. Make sure your proxy supports Keep-Alive and you'd lessen the hit a bit.

added 524 characters in body
Source Link
Rich Homolka
  • 31.7k
  • 7
  • 55
  • 80

What are you trying to accomplish? My guess is you're trying to do something and yuoyou think "DNS"monitoring DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

  4. Multiple egress points. Though less common now, it used to be very common for ISPs to proxy requests out and at times a single subscriber might get rotated on egress points (what you'd see as their IP) in even a single session. AOL used to do this a lot, and as they've dropped in popularity, I've seen other tools (mobile Opera) use proxies as well.

In short, you can't get there from here. IP addresses are not (not they ever have been) unique 1-1 identifiers for a user. You'd break HTTP. You're stuck looking at the HTTP stream and parsing. Make sure your proxy supports Keep-Alive and you'd lessen the hit a bit.

What are you trying to accomplish? My guess is you're trying to do something and yuo think "DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

In short, you can't get there from here. You'd break HTTP. You're stuck looking at the HTTP stream and parsing.

What are you trying to accomplish? My guess is you're trying to do something and you think "monitoring DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

  4. Multiple egress points. Though less common now, it used to be very common for ISPs to proxy requests out and at times a single subscriber might get rotated on egress points (what you'd see as their IP) in even a single session. AOL used to do this a lot, and as they've dropped in popularity, I've seen other tools (mobile Opera) use proxies as well.

In short, you can't get there from here. IP addresses are not (not they ever have been) unique 1-1 identifiers for a user. You'd break HTTP. You're stuck looking at the HTTP stream and parsing. Make sure your proxy supports Keep-Alive and you'd lessen the hit a bit.

added 1120 characters in body
Source Link
Rich Homolka
  • 31.7k
  • 7
  • 55
  • 80

What are you trying to accomplish? My guess is you're trying to do something and yuo think "DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

In short, you can't get there from here. You'd break HTTP. You're stuck looking at the HTTP stream and parsing.

What are you trying to accomplish? My guess is you're trying to do something and yuo think "DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

What are you trying to accomplish? My guess is you're trying to do something and yuo think "DNS is the answer" when it won't work.

If you're looking to see a hit from a client IP on every DNS request, that will never happen. DNS is layered, and clients are configured to hit a local DNS server, which will then eventually hit your DNS server.

If you're looking to see a request (from someone) on every DNS request, you can try to tune your TTL to something small, like a second. You'd then see a hit from someone, somewhere. This may not be 100% - it depends on everyone respecting your TTL, which isn't a given.

UPDATE

If I read correctly, you're trying to associate a DNS request to a future HTTP request. This will fail for several reasons.

  1. Caching. DNS - IP mappings are very cacheable, and therefore they are cached heavily. Even setting TTL won't help all that much, since some ISPs ignore TTL and cache for an hour/a day or so no matter the setting. Browsers also have their own DNS cache. There are too many levels for you to control all.

  2. Multiple users - one IP address. Between NAT (and Carrier Grade NAT is on the horizon) and normal multiple users per machine, you can't map an IP to a browser anymore (not that you really ever could). Even multiple browsers per user or multiple tabs could throw this system off.

  3. People may use DNS for other reasons. What if someone just does an nslookup on one domain, but then hits another (with the IP in cache). You'd forward the wrong site.

In short, you can't get there from here. You'd break HTTP. You're stuck looking at the HTTP stream and parsing.

Source Link
Rich Homolka
  • 31.7k
  • 7
  • 55
  • 80
Loading