broken DNS proxying at public wireless hotspots
Right now, I'm on a swisscom eurospot wifi connection at Paris airport, and this - yet again - has a DNS proxy setup so that the first few queries for a host will return some nonsense value like 1.2.3.4, or will return the records for com instead. Some 4 or 5 minutes later, the dns server might actually return the right dns record. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25634 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 11 ;; QUESTION SECTION: ;www.kcircle.com. IN A ;; AUTHORITY SECTION: com. 172573 IN NS j.gtld-servers.net. com. 172573 IN NS k.gtld-servers.net. [etc] ;; Query time: 1032 msec ;; SERVER: 192.168.48.1#53(192.168.48.1) ;; WHEN: Sat Feb 3 11:33:07 2007 ;; MSG SIZE rcvd: 433 They're not the first provider I've seen doing this, and the obvious workarounds (setting another NS in resolv.conf, or running a local dns caching resolver) dont work either as all dns traffic is proxied. Sure I could route dns queries out through a ssh tunnel but the latency makes this kind of thing unusable at times. I'm then reduced to hardwiring some critical work server IPs into /etc/hosts What do nanogers usually do when caught in a situation like this? thanks srs -- Suresh Ramasubramanian (ops.lists@gmail.com)
One thing I have noticed to be unfortunately more common that I would like is routers that misunderstand IPv6 AAAA requests and return an A record of 0.0.0.1 So if you are using (for the most part) anything other than windows, or Windows Vista, this may be related to what you are seeing. Cheers, Trent On Sat, Feb 03, 2007 at 11:38:26AM +0530, Suresh Ramasubramanian wrote:
Right now, I'm on a swisscom eurospot wifi connection at Paris airport, and this - yet again - has a DNS proxy setup so that the first few queries for a host will return some nonsense value like 1.2.3.4, or will return the records for com instead. Some 4 or 5 minutes later, the dns server might actually return the right dns record.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25634 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 11 ;; QUESTION SECTION: ;www.kcircle.com. IN A ;; AUTHORITY SECTION: com. 172573 IN NS j.gtld-servers.net. com. 172573 IN NS k.gtld-servers.net.
[etc] ;; Query time: 1032 msec ;; SERVER: 192.168.48.1#53(192.168.48.1) ;; WHEN: Sat Feb 3 11:33:07 2007 ;; MSG SIZE rcvd: 433
They're not the first provider I've seen doing this, and the obvious workarounds (setting another NS in resolv.conf, or running a local dns caching resolver) dont work either as all dns traffic is proxied. Sure I could route dns queries out through a ssh tunnel but the latency makes this kind of thing unusable at times. I'm then reduced to hardwiring some critical work server IPs into /etc/hosts
What do nanogers usually do when caught in a situation like this?
thanks srs
-- Suresh Ramasubramanian (ops.lists@gmail.com)
Thus spake "Trent Lloyd" <lathiat@bur.st>
One thing I have noticed to be unfortunately more common that I would like is routers that misunderstand IPv6 AAAA requests and return an A record of 0.0.0.1
So if you are using (for the most part) anything other than windows, or Windows Vista, this may be related to what you are seeing.
The same is true if you've enabled IPv6 on XP. Unfortunately, it's hard to find a hotel network these days that _doesn't_ break when presented with AAAA queries. I'm hoping that the flood of support calls from Vista users will pressure them to get their systems fixed, but I'm not holding my breath. They'll probably just make "disable IPv6" part of their standard troubleshooting routine, just like telling you to reboot your PC. After all, nobody uses it, right? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Sat, Feb 03, 2007 at 01:00:29AM -0600, Stephen Sprunk wrote:
Thus spake "Trent Lloyd" <lathiat@bur.st>
One thing I have noticed to be unfortunately more common that I would like is routers that misunderstand IPv6 AAAA requests and return an A record of 0.0.0.1
So if you are using (for the most part) anything other than windows, or Windows Vista, this may be related to what you are seeing.
The same is true if you've enabled IPv6 on XP. Unfortunately, it's hard to find a hotel network these days that _doesn't_ break when presented with AAAA queries.
I'm hoping that the flood of support calls from Vista users will pressure them to get their systems fixed, but I'm not holding my breath. They'll probably just make "disable IPv6" part of their standard troubleshooting routine, just like telling you to reboot your PC. After all, nobody uses it, right?
Unfortunately this is something I'm afraid of, currently there is a long running bug[1] in the Ubuntu bug tracker on why they should disable IPv6 by default, which makes me sad, but I can understand why they would think that because to them it provides no advantage (yet), yet when disabled, it works for them. I have considered if some kind of "workaround" to the resolver which would ignore returns of 0.0.0.1 (possibly if there are other addresses, or only if AAAA is requested, etc) Is anyone aware of other "weird" things some routers return? Personally I have only seen 0.0.0.1 coming back. Cheers, Trent [1] https://launchpad.net/ubuntu/+source/netcfg/+bug/24828
S
Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Sat, 3 Feb 2007, Suresh Ramasubramanian wrote:
What do nanogers usually do when caught in a situation like this?
Important question: if memory serves, and you are in the "Paris Charles de Gaulle International Airport", wireless costs money. This is after paying, right? I had this problem in a more annoying location. On a connexxion wireless on a flight to NYC. What I do if there are no alternatives is very simply... kick back and listen to some music (unless you have some cellular 3G connectivity). Gadi.
On 2/3/07, Gadi Evron <ge@linuxbox.org> wrote:
On Sat, 3 Feb 2007, Suresh Ramasubramanian wrote:
What do nanogers usually do when caught in a situation like this?
Important question: if memory serves, and you are in the "Paris Charles de Gaulle International Airport", wireless costs money.
Yes - at a hilton there. Only - its a swisscom hotspot. And trying to explain things to tier 1 tech support might not be the most useful thing to do .. I'm going to be already jetlagged and catching up on work before my next flight.
I had this problem in a more annoying location. On a connexxion wireless on a flight to NYC.
Funny. During its all too brief life, Connexion By Boeing never gave me this sort of problem, I used to use it all the time on lufthansa flights.
What I do if there are no alternatives is very simply... kick back and listen to some music (unless you have some cellular 3G connectivity).
Yeah, and then go catch up on all the work that's piled up after 18++ hours flying from the US to India. Fun. Thread's gone way OT now - I'll close it here. -- Suresh Ramasubramanian (ops.lists@gmail.com)
I am running djbdns and my own root-server (tinydns) on my laptop. To axfr the root and some other zones, I use port 3001 (Cesidian Root). With cloned (not actually slaved) zones I have no problem at all but others might still get me. I have seen the Mac can use things like nameserver 192.168.208.228:3001 in his /etc/resolv.conf, linux cannot. That is why I have not tried. Anyhow there are not many open resolvers on port 3001. You can run bind on your laptop (even with windows). I dont know if you can tell it to use other ports than 53 for the forwarders - but you have the source. Dig can do it. In case you need ip-addresses for djbdns, try ifconfig lo:1 127.0.1.16 netmask 255.255.255.0 ifconfig lo:1 127.0.2.16 netmask 255.255.255.0 Now you have enough ip-addresses to run dnscache, tinydns and axfrdns on one and the same laptop, even when your ip-address to the wlan is constantly changeing. Cheers Peter and Karin Suresh Ramasubramanian wrote:
Right now, I'm on a swisscom eurospot wifi connection at Paris airport, and this - yet again - has a DNS proxy setup so that the first few queries for a host will return some nonsense value like 1.2.3.4, or will return the records for com instead. Some 4 or 5 minutes later, the dns server might actually return the right dns record.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25634 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 11 ;; QUESTION SECTION: ;www.kcircle.com. IN A ;; AUTHORITY SECTION: com. 172573 IN NS j.gtld-servers.net. com. 172573 IN NS k.gtld-servers.net.
[etc] ;; Query time: 1032 msec ;; SERVER: 192.168.48.1#53(192.168.48.1) ;; WHEN: Sat Feb 3 11:33:07 2007 ;; MSG SIZE rcvd: 433
They're not the first provider I've seen doing this, and the obvious workarounds (setting another NS in resolv.conf, or running a local dns caching resolver) dont work either as all dns traffic is proxied. Sure I could route dns queries out through a ssh tunnel but the latency makes this kind of thing unusable at times. I'm then reduced to hardwiring some critical work server IPs into /etc/hosts
What do nanogers usually do when caught in a situation like this?
thanks srs
-- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher-Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.serveftp.com http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
Sure I could route dns queries out through a ssh tunnel but the latency makes this kind of thing unusable at times.
instead of an ssh tunnel, how about simple port forwarding? /etc/resolv.conf nameserver 127.0.0.1 And then whatever it takes to forward 127.0.0.1:53 to a dns that is listing on some other port? hmm, I think running a local caching dns was mentioned, but the parts that may have been un-verified: man named -p port Listen for queries on port port. If not specified, the default is port 53. man named.conf everywhere there is an address, there is also the option to specify port: ( ipv4_address | * ) [ port ( integer | * ) ] Carl K
On Sat, 03 Feb 2007 13:29:13 -0600 Carl Karsten <carl@personnelware.com> wrote:
Sure I could route dns queries out through a ssh tunnel but the latency makes this kind of thing unusable at times. instead of an ssh tunnel, how about simple port forwarding?
/etc/resolv.conf nameserver 127.0.0.1
And then whatever it takes to forward 127.0.0.1:53 to a dns that is listing on some other port?
hmm, I think running a local caching dns was mentioned, but the parts that may have been un-verified:
man named
-p port Listen for queries on port port. If not specified, the default is port 53.
man named.conf everywhere there is an address, there is also the option to specify port: ( ipv4_address | * ) [ port ( integer | * ) ]
Right, plus 'forward only' in the config file. --Steve Bellovin, http://www.cs.columbia.edu/~smb
participants (7)
-
Carl Karsten -
Gadi Evron -
Peter Dambier -
Stephen Sprunk -
Steven M. Bellovin -
Suresh Ramasubramanian -
Trent Lloyd