[Dnssec-trigger] dnssec trigger 0.3 experimental

Tue Sep 20 18:11:03 UTC 2011

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

But what I had not noticed:

;; WARNING: Messages has 169 extra bytes at end

So something very fishy happening.....

> - - 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"?

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

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

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"?

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:

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

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

Paul