[Dnssec-trigger] dnssec trigger 0.3 experimental

W.C.A. Wijngaards wouter at NLnetLabs.nl
Wed Sep 21 06:25:33 UTC 2011

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 @

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


>> - - 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 @ -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 @ -p 443 +vc +dnssec . DNSKEY
> Before login: ;; communications error to end of file
> This is the secure login page capturing ANY port 443 for login
> Works after login
>> dig @ -p 80 +vc +dnssec se. DS
> Time out before login.
> Works after login
>> dig @ -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 80
> Trying
> Connected to
> 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 80
> Trying
> Connected to
> 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=
> [...]
> After relogin, I did a reprobe. Tray icon still shows "!"
> results from probe at 2011-09-20 13:32:38
> authority error cannot disassemble reply: additional
> section incomplete
> cache 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
> [root at thinkpad paul]# unbound-control forward
> 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 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 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,
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/


More information about the dnssec-trigger mailing list