Re: resolver question
On 12/24/13 22:08, Andres Perera wrote: i think further investigation is due on OP's part OK. I first removed the domain keyword out of the /etc/resolv.conf and updated /etc/resolv.conf.tail. Then I stuck search centroid.eu in there instead so that it looked like this: # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 search centroid.eu lookup file bind family inet6 inet4 I turned up logs on the immediate nameserver (192.168.34.1) and watched them a bit. Here is what I then read: Dec 26 11:17:31 uranus named[12220]: client 192.168.34.4#22419: query: www.spiegel.de.centroid.eu IN + so the leak I described earlier was happening here too. Then I adjusted the search keyword to only do search . and that stopped the leak, however it still created 2 queries where one would suffice: # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 search . lookup file bind family inet6 inet4 queries were: Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#38177: query: www.spiegel.de IN + Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#24662: query: www.spiegel.de IN + So reasonable, just as I want them. Too bad there is 2 of the same, so it's not exactly perfect. I'm wondering if this hint can be included into the resolv.conf manpage somehow, something like: search . stops leaking quad-A queries to the domain's nameserver. But I'm looking for proper wording and place to put it into the manpage. Thanks, -peter
Re: resolver question
On Thu, Dec 26, 2013 at 6:09 AM, Peter J. Philipp p...@centroid.eu wrote: On 12/24/13 22:08, Andres Perera wrote: i think further investigation is due on OP's part OK. I first removed the domain keyword out of the /etc/resolv.conf and updated /etc/resolv.conf.tail. Then I stuck search centroid.eu in there instead so that it looked like this: # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 search centroid.eu lookup file bind family inet6 inet4 I turned up logs on the immediate nameserver (192.168.34.1) and watched them a bit. Here is what I then read: Dec 26 11:17:31 uranus named[12220]: client 192.168.34.4#22419: query: www.spiegel.de.centroid.eu IN + so the leak I described earlier was happening here too. it would be easier if you work on isolating why is this happening; don't worry about interim servers and other variables, just configure a machine with a nameserver running on localhost while trying to sort this out Then I adjusted the search keyword to only do search . and that stopped the leak, however it still created 2 queries where one would suffice: # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 search . lookup file bind family inet6 inet4 queries were: Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#38177: query: www.spiegel.de IN + Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#24662: query: www.spiegel.de IN + So reasonable, just as I want them. Too bad there is 2 of the same, so it's not exactly perfect. what browser are you using? how is it calling resolver(3) routines? it seems strange that the cache would allow for two identical queries in such a short time span (both on the same second, 11:27:54) I'm wondering if this hint can be included into the resolv.conf manpage somehow, something like: search . stops leaking quad-A queries to the domain's nameserver. But I'm looking for proper wording and place to put it into the manpage. Thanks, -peter
Re: resolver question
On 12/26/13 20:34, Andres Perera wrote: OK. I first removed the domain keyword out of the /etc/resolv.conf and updated /etc/resolv.conf.tail. Then I stuck search centroid.eu in there instead so that it looked like this: # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 search centroid.eu lookup file bind family inet6 inet4 I turned up logs on the immediate nameserver (192.168.34.1) and watched them a bit. Here is what I then read: Dec 26 11:17:31 uranus named[12220]: client 192.168.34.4#22419: query: www.spiegel.de.centroid.eu IN + so the leak I described earlier was happening here too. it would be easier if you work on isolating why is this happening; don't worry about interim servers and other variables, just configure a machine with a nameserver running on localhost while trying to sort this out As I'm just about done with work today, and working tomorrow my time is limited. I'll try that on a virtual machine on my mac with vmware fusion, if you think that's ok. Then I adjusted the search keyword to only do search . and that stopped the leak, however it still created 2 queries where one would suffice: # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 search . lookup file bind family inet6 inet4 queries were: Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#38177: query: www.spiegel.de IN + Dec 26 11:27:54 uranus named[12220]: client 192.168.34.4#24662: query: www.spiegel.de IN + So reasonable, just as I want them. Too bad there is 2 of the same, so it's not exactly perfect. what browser are you using? how is it calling resolver(3) routines? it seems strange that the cache would allow for two identical queries in such a short time span (both on the same second, 11:27:54) The particular log from named above was traffic from Thunderbird which gets RSS feeds from spiegel.de on a regular basis. I'm not sure how I can debug this other than looking at the source and using gdb with breakpoints which possibly requires a recompile of thunderbird. This will probably take more time. Stay tuned then..happy holidays, -peter
Re: resolver question
On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: I'm trying to track down the code in the libasr that causes this behaviour: Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain like a search. So with logging turned on, on my nameserver I get this: pjp@americas$ grep canoe.ca.centroid.eu /var/log/all Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 interface em0 from 212.114.242.132 (ttl=54, region=255) for chealth.canoe.ca.centroid.eu. type=(28) class=1, answering NXDOMAIN The problem is that my nameservers are in china and latin america and I'M sorta worried about these leaks. This particular log came from my nameserver in panama and the packet passes miami. I'm not clear on what the leak you are worried about is. Ken My resolv.conf file looks like this on the workstation here in germany: jupiter$ more /etc/resolv.conf # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 domain centroid.eu lookup file bind family inet6 inet4 The leak only happens with queries, like said. Any hints on tracking this down and squelching it? Regards, -peter
Re: resolver question
On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: I'm trying to track down the code in the libasr that causes this behaviour: Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain like a search. So with logging turned on, on my nameserver I get this: pjp@americas$ grep canoe.ca.centroid.eu /var/log/all Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 interface em0 from 212.114.242.132 (ttl=54, region=255) for chealth.canoe.ca.centroid.eu. type=(28) class=1, answering NXDOMAIN The problem is that my nameservers are in china and latin america and I'M sorta worried about these leaks. This particular log came from my nameserver in panama and the packet passes miami. I'm not clear on what the leak you are worried about is. Ken Hi Ken, Merry Christmas! I was browsing http://chealth.canoe.ca when I saw the above log. I'm supposing the resolver looks up chealth.canoe.ca, and then eventually does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in resolv.conf by means of DHCP. I'm wondering why it does that though? Someone in the US, like the NSA, can then sit back and see my browsing habits, which I call a leak. I'm hoping on finding the knob that turns this off. The leak wouldn't happen if my centroid.eu nameservers were just in .de but then you can just replace NSA with BND the german intelligence sniffers (s/NSA/BND). I'd really just rather replace the function that allows chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should exit is a lookup for just chealth.canoe.ca, which takes a different lookup path in the Internet. Regards, -peter My resolv.conf file looks like this on the workstation here in germany: jupiter$ more /etc/resolv.conf # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 domain centroid.eu lookup file bind family inet6 inet4 The leak only happens with queries, like said. Any hints on tracking this down and squelching it? Regards, -peter
Re: resolver question
Peter, From the resolv.conf man page: http://www.openbsd.org/cgi-bin/man.cgi?query=resolv.confsektion=5 The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance will override. I believe what is happening is the search keyword is sticking centroid.euto probably everything. This isn't a issue with the code, its a miss-configuration. Of course I could be horribly wrong and someone might come over and kick my dog to teach me a lesson ~Jeff On Tue, Dec 24, 2013 at 9:33 AM, Peter J. Philipp p...@centroid.eu wrote: On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: I'm trying to track down the code in the libasr that causes this behaviour: Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain like a search. So with logging turned on, on my nameserver I get this: pjp@americas$ grep canoe.ca.centroid.eu /var/log/all Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 interface em0 from 212.114.242.132 (ttl=54, region=255) for chealth.canoe.ca.centroid.eu. type=(28) class=1, answering NXDOMAIN The problem is that my nameservers are in china and latin america and I'M sorta worried about these leaks. This particular log came from my nameserver in panama and the packet passes miami. I'm not clear on what the leak you are worried about is. Ken Hi Ken, Merry Christmas! I was browsing http://chealth.canoe.ca when I saw the above log. I'm supposing the resolver looks up chealth.canoe.ca, and then eventually does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in resolv.conf by means of DHCP. I'm wondering why it does that though? Someone in the US, like the NSA, can then sit back and see my browsing habits, which I call a leak. I'm hoping on finding the knob that turns this off. The leak wouldn't happen if my centroid.eu nameservers were just in .de but then you can just replace NSA with BND the german intelligence sniffers (s/NSA/BND). I'd really just rather replace the function that allows chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should exit is a lookup for just chealth.canoe.ca, which takes a different lookup path in the Internet. Regards, -peter My resolv.conf file looks like this on the workstation here in germany: jupiter$ more /etc/resolv.conf # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 domain centroid.eu lookup file bind family inet6 inet4 The leak only happens with queries, like said. Any hints on tracking this down and squelching it? Regards, -peter
Re: resolver question
On Tue, Dec 24, 2013 at 17:33, Peter J. Philipp wrote: I was browsing http://chealth.canoe.ca when I saw the above log. I'm supposing the resolver looks up chealth.canoe.ca, and then eventually does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in resolv.conf by means of DHCP. I think you have this backwards. It looks up chealth.canoe.ca.centroid.eu first. Your browser apparently doesn't think chealth.canoe.ca is a full domain, and so it starts creating a full name and resolving that. (or not the browser, but the local dns cache. you're not clear what server you're machine is contacting.) fwiw, I only see queries to chealth.canoe.ca and not any local domain extended variants, using both both ping and firefox. on the other hand, if I ping apple, there are lookup requests for apple.home.tedunangst.com, apple.tedunangst.com, and apple.
Re: resolver question
Thus said Peter J. Philipp on Tue, 24 Dec 2013 17:33:10 +: I was browsing http://chealth.canoe.ca when I saw the above log. I'm supposing the resolver looks up chealth.canoe.ca, and then eventually does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in resolv.conf by means of DHCP. You have a some options: 1) Change your habits to use a fully qualified domain name; e.g., a domain name that ends with a final/trailing dot. chealth.cano.ca is ambiguous (perhaps not in your brain, but to a computer, it doesn't know that you really mean chealth.canoe.ca. which is absolute). So use http://chealth.canoe.ca./ (note the trailing dot). 2) Don't configure a search option in /etc/resolv.conf as each domain listed in the search is appended to the query in order. E.g., if you have centroid.eu and google.com in your search, then your DNS resolver will take chealth.canoe.ca and append centroid.eu., attempt to resolve it but fail. Then it will take chealth.canoe.ca and append google.com., attempt to resolve it but fail, and then finally it will try chealth.canoe.ca., attempt to resolve it and receive a successful response. Andy -- TAI64 timestamp: 400052b9ecb0
Re: resolver question
On Tue, Dec 24, 2013 at 1:03 PM, Peter J. Philipp p...@centroid.eu wrote: On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote: On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote: I'm trying to track down the code in the libasr that causes this behaviour: Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain like a search. So with logging turned on, on my nameserver I get this: pjp@americas$ grep canoe.ca.centroid.eu /var/log/all Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17 interface em0 from 212.114.242.132 (ttl=54, region=255) for chealth.canoe.ca.centroid.eu. type=(28) class=1, answering NXDOMAIN The problem is that my nameservers are in china and latin america and I'M sorta worried about these leaks. This particular log came from my nameserver in panama and the packet passes miami. I'm not clear on what the leak you are worried about is. Ken Hi Ken, Merry Christmas! I was browsing http://chealth.canoe.ca when I saw the above log. I'm supposing the resolver looks up chealth.canoe.ca, and then eventually does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in resolv.conf by means of DHCP. a FQDN ends with a period this tells a correctly functioning dns subsystem--correctly being subject to your willingness to abide a collection of rfcs, all the way from local binaries to remote hosts[0]--that you wish to resolve that name sans transformations the ``search'' keyword in resolv.conf is a suffix that may be appended to unqualified domain names prior resolving them to ip addresses 1. check if you are really configuring the appropiate settings. some programs, eg dig, willfully ignore the search keyword by default. some browsers use their own resolvers 2. clear the ``search`` keyword: $ echo 'search .' /etc/resolv.conf.tail # dhclient $INTERFACE I'm wondering why it does that though? Someone in the US, like the NSA, can then sit back and see my browsing habits, which I call a leak. I'm hoping on finding the knob that turns this off. The leak wouldn't happen if my centroid.eu nameservers were just in .de but then you can just replace NSA with BND the german intelligence sniffers (s/NSA/BND). I'd really just rather replace the function that allows chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should exit is a lookup for just chealth.canoe.ca, which takes a different lookup path in the Internet. Regards, -peter My resolv.conf file looks like this on the workstation here in germany: jupiter$ more /etc/resolv.conf # Generated by re0 dhclient search centroid.eu nameserver 192.168.34.1 domain centroid.eu lookup file bind family inet6 inet4 The leak only happens with queries, like said. Any hints on tracking this down and squelching it? Regards, -peter
Re: resolver question
On Tue, Dec 24, 2013 at 12:09:18PM -0800, Jeff O'Neal wrote:
Peter,
From the resolv.conf man page:
http://www.openbsd.org/cgi-bin/man.cgi?query=resolv.confsektion=5
The domain and search keywords are mutually exclusive. If more than one
instance of these keywords is present, the last instance will
override.
I believe what is happening is the search keyword is sticking
centroid.euto probably everything. This isn't a issue with the code,
its a
miss-configuration.
Jeff,
Maybe you're on to something, but the last instance is the domain keyword, not
the search. I'll take that out of my resolv.conf.tail file where I believe
it is and watch the logs if I see any behaviour like this. Give me a few
days...
Cheers,
-peter
Of course I could be horribly wrong and someone might come over and kick my
dog to teach me a lesson
~Jeff
On Tue, Dec 24, 2013 at 9:33 AM, Peter J. Philipp p...@centroid.eu wrote:
On Tue, Dec 24, 2013 at 10:25:06AM -0500, Kenneth R Westerback wrote:
On Mon, Dec 23, 2013 at 02:37:47PM +0100, Peter J. Philipp wrote:
I'm trying to track down the code in the libasr that causes this
behaviour:
Whenever I go to a IPv4 site and IPv6 query is made for domain+mydomain
like a search. So with logging turned on, on my nameserver I get this:
pjp@americas$ grep canoe.ca.centroid.eu /var/log/all
Dec 20 17:00:37 americas wildcarddnsd[29850]: request on descriptor 17
interface em0 from 212.114.242.132 (ttl=54, region=255) for
chealth.canoe.ca.centroid.eu. type=(28) class=1, answering
NXDOMAIN
The problem is that my nameservers are in china and latin america and
I'M sorta worried about these leaks. This particular log came from my
nameserver in panama and the packet passes miami.
I'm not clear on what the leak you are worried about is.
Ken
Hi Ken, Merry Christmas!
I was browsing http://chealth.canoe.ca when I saw the above log. I'm
supposing
the resolver looks up chealth.canoe.ca, and then eventually does a lookup
for
chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in
resolv.conf by means of DHCP.
I'm wondering why it does that though? Someone in the US, like the NSA,
can
then sit back and see my browsing habits, which I call a leak. I'm hoping
on
finding the knob that turns this off. The leak wouldn't happen if my
centroid.eu nameservers were just in .de but then you can just replace NSA
with BND the german intelligence sniffers (s/NSA/BND).
I'd really just rather replace the function that allows
chealth.canoe.ca.centroid.eu lookup to exit my DSL as all that should
exit is
a lookup for just chealth.canoe.ca, which takes a different lookup path
in the
Internet.
Regards,
-peter
My resolv.conf file looks like this on the workstation here in germany:
jupiter$ more /etc/resolv.conf
# Generated by re0 dhclient
search centroid.eu
nameserver 192.168.34.1
domain centroid.eu
lookup file bind
family inet6 inet4
The leak only happens with queries, like said. Any hints on
tracking this down and squelching it?
Regards,
-peter
Re: resolver question
On Tue, Dec 24, 2013 at 3:50 PM, Andy Bradford amb-open...@bradfords.org wrote: Thus said Peter J. Philipp on Tue, 24 Dec 2013 17:33:10 +: I was browsing http://chealth.canoe.ca when I saw the above log. I'm supposing the resolver looks up chealth.canoe.ca, and then eventually does a lookup for chealth.canoe.ca.centroid.eu. centroid.eu is the domain I configured in resolv.conf by means of DHCP. You have a some options: 1) Change your habits to use a fully qualified domain name; e.g., a domain name that ends with a final/trailing dot. chealth.cano.ca is ambiguous (perhaps not in your brain, but to a computer, it doesn't know that you really mean chealth.canoe.ca. which is absolute). So use http://chealth.canoe.ca./ (note the trailing dot). 2) Don't configure a search option in /etc/resolv.conf as each domain listed in the search is appended to the query in order. E.g., if you have centroid.eu and google.com in your search, then your DNS resolver will take chealth.canoe.ca and append centroid.eu., attempt to resolve it but fail. Then it will take chealth.canoe.ca and append google.com., attempt to resolve it but fail, and then finally it will try chealth.canoe.ca., attempt to resolve it and receive a successful response. the suffix list may still be initialized from the ``domain'' keyword, which is very likely in a dhcp scenario, and more than that, present in the OP dhcp-fed resolv.conf thus setting ``search .'' is the way of insuring that no suffixes be appended, even when ``domain'' is present, or when ``domain'' is absent and it's consequently deduced from the system hostname what's interesting is that the query has more than the default ndots i think further investigation is due on OP's part Andy -- TAI64 timestamp: 400052b9ecb0
