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

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

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

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] Bug #24828 “IPv6 should be disabled by default” : Bugs : netcfg package : Ubuntu

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.

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:

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

Right, plus 'forward only' in the config file.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

checked >SSH doesn't do UDP port forwarding?

At the risk of stating the obvious ...

Whats wrong with using an OpenVPN tunnel with appropriate acls ?
(It works for me !)

1) SSH out, by IP, to a known-useful host.
2) Resolve all IPs required there / use it as a proxy if feasible.

Depends on what you're trying to do over a public wlan, of course.

VPN solutions are indeed obvious, and are the other work around.

Suprised noones mentioned yet...

I hope the wireless you're using is free!!! If not, well, I wouldn't be paying for an obviously broken service. (And would be making all appropriate noises to the provider).

I would imagine the average NANOGer is going to be quite capable to get around the problem, as long as theres the ability to go out via known-IP (assuming no more strict filtering than that..). But obviously some people are going to struggle, and frankly, service providers who provide 'broken' services (and still charge for it) really get on my nerves....

Mark.

> 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.