On 2021-02-04 7:25 a.m., Per Jessen wrote:

...

DNS is a UDP protocol not a TCP protocol. <nitpick> both actually </nitpick>

Well PHOO to you too, buster! The 'long delayed response' issue that I was addressing is a UDP phenomena.

To the OP - what does this mean:

...

requests continue on the sites that I visited and that long after my last connection. Do you mean you can see active connections, e.g. with 'ss' ?

With UDP there are not 'connections'. With UDP there are only (possible) responses at some time in the future. A 'response' is not a 'connection'. A connection reeds a setup handshake and positive response to each individual packet sent. That the difference between UDP and and TCP. Yes you can run DNS as TCP, but that way the connection gets terminated so the 'long delayed response' you can get with UDP isn't there. A 'persistent response' because the response was cached is quite another matter. If you want to discuss 'secure DNS', then fine, but please what the $SUBJ. Locally, I use DNSmasq which offers a great deal of simplicity of set up compared to BIND9, much easier DHCP integration, and a lot of controllability IF AND ONLY IF you need it. For the most part I don't. DNSMASQ(8) NAME dnsmasq - A lightweight DHCP and caching DNS server. SYNOPSIS dnsmasq [OPTION]... DESCRIPTION dnsmasq is a lightweight DNS, TFTP, PXE, router advertisement and DHCP server. It is intended to provide coupled DNS and DHCP service to a LAN. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg

Thank you, for your answers, I looked and apriori on fedora it does it too (in virtualization), but on the site which I gave, it speaks about bug or even risky behavior. See the link, I launch a translate to answer you. https://translate.google.fr/translate?hl=&sl=ru&tl=en&u=https%3A%2F%2Fwww.linux.org.ru%2Fforum%2Fgeneral%2F15622136&sandbox=1 Le jeudi 04 février 2021 à 15:29 +0100, Per Jessen a écrit :

Anton Aylward wrote:

...

On 2021-02-04 7:25 a.m., Per Jessen wrote:

...

...

DNS is a UDP protocol not a TCP protocol. <nitpick> both actually </nitpick>

Well PHOO to you too, buster!

The 'long delayed response' issue that I was addressing is a UDP phenomena.

Perhaps so, but how is that relevant here?

...

...

To the OP - what does this mean:

...

requests continue on the sites that I visited and that long after my last connection. Do you mean you can see active connections, e.g. with 'ss' ?

With UDP there are not 'connections'.

Anton, please stop with the lecturing. The OP spoke about his Firefox browser and "requests that continue on the sites that I visited" - that sounds like he is talking about TCP.

On 2021/02/04 11:53, Anton Aylward wrote:

On 2021-02-04 11:35 a.m., passiongnulinux@gmail.com wrote:

...

See the link, I launch a translate to answer you.

It says "Translating ...." And still says it 20 minutes later with no further detail.

While I can get to the original URL at: http://www.linux.org.ru/forum/general/15622136 Google translate turns it into an inaccessible URL that it says cannot be found. However, cut+paste of the text works, though I still have no clue what they are talking about: On openSUSE, Tumbleweed launched Wireshark. All is clear. I launch YaST Software, close it. There is no yast, zypper or package * in the processes, but Wireshark shows that someone (possibly NM) continues to send DNS queries to the SUSE mirrors. Moreover, it seems that the intensity of these requests depends on the activity of the network. It seems that everything has already calmed down, you ping 1.1.1.1 from the terminal and after a while DNS queries were sent again on the mirror sus. These are DNS queries, not TCP / UDP. They are not on a freshly booted system until you start YaST. Then there are not so many of them, but they are sent periodically. I thought it wasn't just Yast (Susi's mirrors) that had such an echo. Launched Firefox 74, there are, of course, tons of requests at once, despite tuning about: config and disabling unnecessary things (Firefox has long been a Trojan). But that's okay. I close Firefox (it also knocks when I close it, by the way). I think now DNS queries will go to Mozilla's servers. But no. Silence after closing. Someone sends DNS queries to Susi's mirrors. Who and why? The processes are silent, all update checks are disabled. Clarification: In /etc/NetworkManager/NetworkManager.conf commented out the line conncheck.opensuse.org, otherwise NM branding openSUSE is constantly hammering there (I wonder how much this DDOS costs?). Also deleted the contents of the / var / lib / zypp / AnonymousUniqueId file so that YaST does not send the ID when upgrading and installing packages. But all this is not particularly relevant, he just clarified, maybe someone did not know. ....

On 2021-02-04 6:03 p.m., L A Walsh wrote:

However, cut+paste of the text works, though I still have no clue what they are talking about:

Indeed. How can you have a RFC compliant DNS query that isn't 't either UPD or TCP? -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg

On Fri, 05 Feb 2021 08:57:55 +0100 Per Jessen wrote:

Anton Aylward wrote:

...

On 2021-02-04 6:03 p.m., L A Walsh wrote:

...

However, cut+paste of the text works, though I still have no clue what they are talking about:

Indeed. How can you have a RFC compliant DNS query that isn't 't either UPD or TCP?

DoH is becoming popular. (which does involve TCP of course). RFC8484

The latest router upgrade I got supports DoT instead. I think I prefer DoH.

On Fri, 5 Feb 2021 13:29:15 +0100 "Carlos E. R." wrote:

On 05/02/2021 11.56, Dave Howorth wrote:

...

On Fri, 05 Feb 2021 08:57:55 +0100 Per Jessen wrote:

...

Anton Aylward wrote:

...

On 2021-02-04 6:03 p.m., L A Walsh wrote:

...

However, cut+paste of the text works, though I still have no clue what they are talking about:

Indeed. How can you have a RFC compliant DNS query that isn't 't either UPD or TCP?

DoH is becoming popular. (which does involve TCP of course). RFC8484

The latest router upgrade I got supports DoT instead. I think I prefer DoH.

Could you point to some explanation for dummies? ;-)

google dot doh dummies and take your pick (ignore the dog things, they're probably not relevant :)

Good evening, Thank you for continuing to understand, on my side I'm quite lost and I ask if it's suddenly a bug or a function? Should we make a bug report on our bugzilla or not? And since for my part, I do not understand this story for the masses, which nevertheless seems to be simple for you, and moreover, since I translate from Russian into a language which is not mine and which so far i can't say if it's a good translation, i'm not the ideal guy to point this bug (if it really is) on the buzilla. Cordially. Le vendredi 05 février 2021 à 16:51 +0100, Carlos E. R. a écrit :

On 05/02/2021 16.36, Dave Howorth wrote:

...

On Fri, 5 Feb 2021 13:29:15 +0100 "Carlos E. R." <> wrote:

...

On 05/02/2021 11.56, Dave Howorth wrote:

...

On Fri, 05 Feb 2021 08:57:55 +0100 Per Jessen wrote:

...

Anton Aylward wrote:

...

On 2021-02-04 6:03 p.m., L A Walsh wrote: > > However, cut+paste of the text works, though I still have > no clue what they are talking about:

Indeed. How can you have a RFC compliant DNS query that isn't 't either UPD or TCP?

DoH is becoming popular. (which does involve TCP of course). RFC8484

The latest router upgrade I got supports DoT instead. I think I prefer DoH.

Could you point to some explanation for dummies? ;-)

google dot doh dummies and take your pick (ignore the dog things, they're probably not relevant :)

Thanks :-)

My google foo lacks somewhat ;-)

I will open a request on bugzilla by giving the link of this discussion. Thank you very much for your help. Le vendredi 05 février 2021 à 19:21 +0100, Per Jessen a écrit :

passiongnulinux@gmail.com wrote:

...

Good evening,

Thank you for continuing to understand, on my side I'm quite lost and I ask if it's suddenly a bug or a function? Should we make a bug report on our bugzilla or not?

If you believe the situation is a problem or a security issue, a bug report is a good idea.

On 05/02/2021 20.28, Brendan McKenna wrote:

Hi,

    What's happening is that nscd (the Name Service Caching Daemon) is updating its cache entries.  When you visit a web site, it makes a DNS request to look up the site.  The response has a time-to-live value associated with it.  When that exipres, nscd re-issues the request to update its cache, on the assumption that you will (eventually) make the same request again at some point in the future.

    So, if you want to eliminate the repeated requests, just shut nscd down and/or don't start it in the future.  That way, the only time(s) you will see DNS requests being made is when you are actually browsing to a site, and not later.

    Even with nscd running, it will (eventually) stop refreshing the cache entries -- the size of the cache is finite, so if you make enough DNS requests, eventually the "older" ones will be removed from the cache to make room for information pertaining to more recently-requested information.

Or just tell nscd to not cache external names. But that may make your browsing slower. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 06/02/2021 17.55, passiongnulinux@gmail.com wrote:

Le vendredi 05 février 2021 à 19:28 +0000, Brendan McKenna a écrit :

...

Hi,

Hello,

Please try to explain, it's already clearer, so it's not a bug but a function.

...

No bugzilla.

I told you yesterday, that the comments at the end of that link say that the /culprit/ was *nscd*. It is a "feature", that is how it works.

ok so i'm not doing anything, thanks.

It is simple. The people on the link you posted: https://translate.google.fr/translate?hl=&sl=ru&tl=en&u=https%3A%2F%2Fwww.linux.org.ru%2Fforum%2Fgeneral%2F15622136&sandbox=1 clearly say that the symptoms stop when stopping nscd service. The manual page explains what it is: nscd - name service cache daemon And it does its job. There is a configured time during which it will store that name to address conversion, which means it has to query upstream when upstream says it is time out. It is doing its job. If you don't like it, you can stop it permanently, but then internet (and other things) will be slower. Your choice. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 06/02/2021 20.24, Stakanov wrote:

In data sabato 6 febbraio 2021 20:18:13 CET, Carlos E.R. ha scritto:

...

On 06/02/2021 17.55, passiongnulinux@gmail.com wrote:

...

Le vendredi 05 février 2021 à 19:28 +0000, Brendan McKenna a écrit :

...

...

The manual page explains what it is:

nscd - name service cache daemon

And it does its job. There is a configured time during which it will store that name to address conversion, which means it has to query upstream when upstream says it is time out. It is doing its job.

If you don't like it, you can stop it permanently, but then internet (and other things) will be slower. Your choice.

Is nscd actually useful at all if he would use a caching server like unbound or dnsmasq? My understanding is that it would be only the case if he is using normal resolf.conf, am I mistaken? So he could in this case use a workaround to install / use such setup and stop nscd. Maybe not correct, please educate me if I am mistaken. Thanks.

I have never seen a canonical document that answers that question, or a post from somebody that actually knows. I don't know. However, the proper method to disable it is to disable the internet name cache part of dnsmaq, because it has others. /etc/nscd.conf enable-cache hosts no When enabled, queries to google.es take sometimes about 50 mS, and other times about 20 mS. When disabled, it is once 50, then seems always 20 (I have dnsmasq running). -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 05/02/2021 19.18, passiongnulinux@gmail.com wrote:

Good evening,

Thank you for continuing to understand, on my side I'm quite lost and I ask if it's suddenly a bug or a function? Should we make a bug report on our bugzilla or not?

And since for my part, I do not understand this story for the masses, which nevertheless seems to be simple for you, and moreover, since I translate from Russian into a language which is not mine and which so far i can't say if it's a good translation, i'm not the ideal guy to point this bug (if it really is) on the buzilla.

Cordially.

No bugzilla. I told you yesterday, that the comments at the end of that link say that the /culprit/ was *nscd*. It is a "feature", that is how it works. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 2021-02-04 9:29 a.m., Per Jessen wrote:

Anton Aylward wrote:

...

On 2021-02-04 7:25 a.m., Per Jessen wrote:

...

...

DNS is a UDP protocol not a TCP protocol. <nitpick> both actually </nitpick>

Well PHOO to you too, buster!

The 'long delayed response' issue that I was addressing is a UDP phenomena.

Perhaps so, but how is that relevant here?

It is relevant because the OP remarked about DNS responses continuing to come in after the application finished. That constitutes a long delayed response. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg