[Dnssec-trigger] dnssec trigger 0.3 experimental

Wed Sep 21 06:25:33 UTC 2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

On 09/20/2011 08:11 PM, Paul Wouters wrote:
> On Tue, 20 Sep 2011, W.C.A. Wijngaards wrote:
> 
>> Well, does https work with some website? (like nlnetlabs, selfsigned)?
> 
> Depends on the state/timing when you break my dns :)
> After portal login, all 80/443 works fine.
> 
> Turns out the test I tend to do works:
> 
> dig +dnssec dnskey xelerance.com @193.110.157.136

Oh, so even UDP may work.

> But what I had not noticed:
> 
> ;; WARNING: Messages has 169 extra bytes at end
> 
> So something very fishy happening.....

Interesting.

>> - - after sign-in you can Reprobe (tray menu) perhaps it works then.
> 
> The difference before auth and after login to the portal is that queries
> to auth nameservers do work. Does dnssec-trigger do any exponential backof
> attempt at probing when the user put it in "insecure mode"?

Not yet, it is a feature on my TODO.  So, retry after 10 seconds and
exponential backoff after that, in Insecure mode.

>> - - perhaps dnssec-over-tcp80 and tcp443 works, can you try these digs?
> 
>> dig @213.154.224.42 -p 80 +vc +dnssec . DNSKEY
> 
> Timeout before login. There is a 302 redirect on port 80 to port 443, see
> below.  Works after login
> 
>> dig @213.154.224.42 -p 443 +vc +dnssec . DNSKEY
> 
> Before login: ;; communications error to 213.154.224.42#443: end of file
> This is the secure login page capturing ANY port 443 for login
> Works after login
> 
>> dig @213.154.224.42 -p 80 +vc +dnssec se. DS
> 
> Time out before login.
> Works after login
> 
>> dig @213.154.224.42 -p 443 +vc +dnssec se. DS
> 
> same error as above on port 443 before login
> works after login
> 
> Note that before login, port 80 traffic does reconnect me to port 443
> Not sure why dig does not report an error for that at all.

This is very nice, but I get the idea that perhaps normal UDP to
authority servers may work after signon on this portal.

> [paul at thinkpad ~]$ telnet 1.2.3.4 80
> Trying 1.2.3.4...
> Connected to 1.2.3.4.
> Escape character is '^]'.
> lkfdfkhdf
> HTTP/1.1 400 Page not found
> Server: GoAhead-Webs
> Date: Tue, 20 Sep 2011 17:39:15 GMT
> Pragma: no-cache
> Cache-Control: no-cache
> Content-Type: text/html
> 
> <html><head><title>Document Error: Page not found</title></head>
>         <body><h2>Access Error: Page not found</h2>
>         <p>Bad request type</p></body></html>
> 
> Connection closed by foreign host.
> 
> [paul at thinkpad ~]$ telnet 1.2.3.4 80
> Trying 1.2.3.4...
> Connected to 1.2.3.4.
> Escape character is '^]'.
> GET / /
> 
> HTTP/1.0 302 Redirect
> Server: GoAhead-Webs
> Date: Tue, 20 Sep 2011 17:39:24 GMT
> Pragma: no-cache
> Cache-control: no-cache
> Content-Type: text/html
> Location:
> https://secure.boldstreet.com/SecondCup/Intercept.aspx?UI=00-03-52-EB-8C-E0&MA=00-21-5C-54-4F-E5&UIP=206.108.148.92&CIP=192.168.101.39&SSID=hotspot_Rogers&OS=http://www.google.ca/sd
> 
> 
> [...]
> 
> 
> After relogin, I did a reprobe. Tray icon still shows "!"
> 
> results from probe at 2011-09-20 13:32:38
> 
> authority 199.7.83.42: error cannot disassemble reply: additional
> section incomplete
> cache 192.168.101.1: error timeout
> 
> DNS queries are sent to INSECURE servers.
> Please, be careful out there.

Okay, so it cannot use UDP, but TCP may work in the port80/443 fallback.
 So it seems that feature could be worthwhile to implement.

> resolv.conf matches that:
> 
> [paul at thinkpad ~]$ cat /etc/resolv.conf
> # Generated by dnssec-trigger 0.3
> nameserver 192.168.101.1
> 
> [root at thinkpad paul]# unbound-control forward
> 127.0.0.127
> 
> and unbound blackholed (not sure why, as no one is asking it anything,
> why not leave it in "auth mode"?

Yes, because the user is using the insecure servers, but unbound could
have some 'leftover' queries in its task list.  If it tries to connect
outside, it gets timeouts and this messes up the time detection of DNS
hosts.  Thus setting 127.0.0.127 stops unbound from sending queries,
because its entries are leftover and useless anyway, and it cannot
succeed either.  At worst, it may timeout lots of times, on a root
server perhaps, and put that server on the 'do not query it again it is
offline' list.

> I then put unbound in regular auth mode:
> 
> [root at thinkpad paul]# unbound-control flush all
> ok
> [root at thinkpad paul]# unbound-control forward off
> ok
> 
> which seems to work:
> 
> ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-9.P4.fc14 <<>> +dnssec dnskey com
> @localhost
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17249
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> that worked, but the se DS set indeed is still borken:

You are querying the cache in unbound, but unbound cannot query to the
network.   tcp80 and tcp443 features are not implemented on dnssec-trigger.

With 1.4.13, you could do:
unbound-control forward 213.154.224.42 at 443
unbound-control set_option tcp-upstream: yes

That makes unbound do TCP to port 443 (with open resolver NLnet Labs).

And that is what dnssec-trigger can try to do.  But it would be nice to
know if that is useful.  Your coffee network looks like it may be: UDP
DNS looks like it is borked, even after signon (right?!) and
TCP-intheclear-DNS-port443 works?

> [root at thinkpad paul]# dig +dnssec se. DS @localhost
> 
> ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-9.P4.fc14 <<>> +dnssec se. DS @localhost
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> and a dig for www.xelerance.com also failed
> 
> then I noticed this is unbound 1.4.11. Repeated the test and got
> the same results for 1.4.13rc1 with EDNS patch.
> 
> Note also that once you put yourself in "insecure" mode, you can never put
> yourself via the GUI back in "disconnected cache only mode" until you
> switch
> networks.....

Yes, you can reprobe.  If it then detects that it is secure, it switches
to secure without a dialog (icon stops !).  There is simply no need for
a dialog here as the user need not click on 'Yes I am secure' or something.

But perhaps this needs to change, if you have to go to the 'portal page'
via the portal-page DNS somehow.  So temporarily go insecure, and then
go secure again (With dialog: Are you done with signon?)...

> I also see these:
> (<unknown>:30388): Gdk-CRITICAL **: IA__gdk_window_get_root_coords:
> assertion `GDK_IS_WINDOW (window)' failed

This is a bug in GTK to do with trayicons.  When you mouseover them.  I
think we can ignore it, although a fix in GTK could be good of course.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOeYNdAAoJEJ9vHC1+BF+NIQIP/3nzMykKA7FDZGiG8sF+NNhY
pat2uFyEBBiaKUaWurQlaKzGUQQTYoPIlOwF6H/cUnfljmGUV4Dbhb2aKpvKqvsH
5OyBX5uh3nkE2+pYVca6g8WlrnOVauFeStzsRfXs4txjt9UUVv+nCK4wi0t3J1m0
Mp1YmFs3/WDFzje+TpIE0+QFGGGduYT9y4xhuhTrNdY83XLpvs1CocEWZF1ZGxdm
L871ZE8pLUpR0rOSS56uAZa50twCp411tE6aX9uisppzC5IlFt7kMBY2bQ01YZAU
N0K2VAAEMd5RUdT8RQq8E6Sjih1sps+zkE3nzs3aYUU3M6tdJ2z22N2OeMgmSJgy
Xaa5kPtnthOuatiQXp0715wYmTUCNR6muA97bZLmZuCmXt4eMijrfrlGsIN55fc+
Oh8IEtDVtSebRgxR6XdcbN0WzmmAMyfu7A0M8DczB496VycGa8JxCOiV0PxHm7kP
wrLqxKJWnp0rPqtDBLbYwZoPJulb3S29cZAl4bXrja35EovhCbT39WWeMnTFrdo0
PayvGoRdN/vIs9gXUo4lW2g9N1+GM1OD+pEHOW4Ge3OifHMf9WtfXnn2e/3mn2le
KFYmvEpwCYPP5fMfcEcr6VRqAXlRZfgkpDGNF+k7Ar7C30bla7dgDn20h56Zyt1P
N4uNrjgA11+FFPN2Pj1D
=iwyc
-----END PGP SIGNATURE-----