[lug] Suspicous: "host"/"DNS" Showing Odd Results (Fedora)

[stimits at comcast.net]

I don't believe I have any control over how response goes via the resolv.conf, but that does bring up a good point. The resolv.conf has multiple DNS servers listed (supposedly in case one times out). Perhaps the different results are from different resolv.conf entries. Don't know. It would still be a bug for comcast to provide multiple DNS entries where the different entries gave different replies to the same query at the same host at the same time.
 
So far (today and most of yesterday) it isn't doing it anymore, so I'm not going to worry about it since I know it isn't a compromised system and whatever is going on seems to be fading into history. I'm assuming this is because the query isn't changing instantly between the two tabs. As soon as it does this will probably happen again, but I know how to work with it now. One thing contributing seems to be that if firefox had crashed, then it tries to restore the previous session and again uses the previous bad state.
 
FYI, I do believe it is a race condition. This only happened with rapidly opening multiple tabs and starting multiple SSL login pages simultaneously when two of the tabs receive a different ptr. Allowing a login to complete before starting another did help when this was happening. Still, when I see a segfault in SSL and I'm seeing two names for the same address, it raises an eyebrow. Especially since I had been testing alternate resolv.conf (and the open DNS has terrible performance). My testing had been finished days before, so it made me very curious how DNS could be doing this (and it turns out it wasn't related). This is why I had to know and didn't chalk it up to a bug.
 
----- Original Message -----From: Lee Woodworth <blug-mail at duboulder.com>To: lug at lug.boulder.co.usSent: Tue, 04 Sep 2018 16:28:50 -0000 (UTC)Subject: Re: [lug] Suspicous: "host"/"DNS" Showing Odd Results (Fedora)

Does your /etc/resolv.conf have settings for forcing a sort ondns query results? This would only help if firefox uses the systemdns resolver.

Even if the crash is in openssl it is possible firefox cannot handlea single ip with multiple PTRs and varying query result order. If thingswork when you open the login pages with a time delay between them then Iwould wonder about race conditions in ff.

On 09/03/2018 05:24 PM, stimits at comcast.net wrote:> Btw, it is SSL which doesn't like the name changing for a single dotted-decimal address. Firefox is just using the SSL. The issue shows up from rapidly opening multiple SSL login pages simultaneously.> > ----- Original Message -----From: Zan Lynx <zlynx at acm.org>To: lug at lug.boulder.co.usSent: Mon, 03 Sep 2018 23:12:06 -0000 (UTC)Subject: Re: [lug] Suspicous: "host"/"DNS" Showing Odd Results (Fedora)> > On 9/3/2018 5:08 PM, stimits at comcast.net wrote:> I wouldn't believe it either but I've verified my firefox and watched in > the stack frame what is causing the lock. When the name switches mid > stream it locks. Fedora 27. Note that when the name shows up constant > (regardless of what it shows up as), then there is no lockup. This > occurs only if multiple queries running simultaneously use different > names for the same IP.> > Did you build this yourself? Or are you running weird addons?> > My Firefox doesn't make any reverse DNS lookups._______________________________________________Web Page: http://lug.boulder.co.usMailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lugJoin us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety> > > > _______________________________________________> Web Page: http://lug.boulder.co.us> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety> 

_______________________________________________Web Page: http://lug.boulder.co.usMailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lugJoin us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20180904/6d2f54f8/attachment.html>