[dnssec-deployment] test.mx. online signing
paul at vix.com
Mon May 7 15:31:13 EDT 2007
> > in a hotel, you've gotta vpn your dns traffic back to a server you trust.
> That would be the dnssec-enabled caching recursive nameserver running
> on 127.0.0.1?
won't help. udp/53 is trapped by the hotel and sent to NAT purgatory.
doesn't matter whether you're using EDNS or not, TSIG or not, DNSSEC or
not, large packets, small packets, IPv4, IPv6. they want to be able to
send you a fake response indicating that the A RR of wherever you were
going is actually some RFC 1918 proxy that they control. often, if you
don't ask an A RR question, they don't even send you an answer.
if you want DNS to work, you have to protect your hotel-originated udp/53
traffic by putting it into a secure tunnel of some kind. generally hotels
do not interfere with TCP/443 (SSL HTTP) since they fear reprisals from
the fortune 1000 who generate nontrivial revenue that way, and whose
employees use it while travelling in order to reach corporate MS/Exchange
servers. SSL isn't something hotels can intercept unless they send their
own certificate using somebody else's domain names, which i've seen done
outside the US but not anywhere that FTC holds sway. so when i'm travelling
i'm prepared with various unixy tools that open ip tunnels inside TCP/443
with normal SSL covering. my dns traffic is never seen. ymmv.
More information about the Dnssec-deployment