Hello the family ;) It's me again, I have a person who told me about a dns cache problem, or something like that, in short, I have indeed since noticed that well after closing the Firefox browser, requests continue on the sites that I visited and that long after my last connection. What about, bug or not? https://translate.google.fr/translate?hl=&sl=ru&tl=en&u=https%3A%2F%2Fwww.linux.org.ru%2Fforum%2Fgeneral%2F15622136&sandbox=1 the link speaks about it too. Cordialy.
On 2021-02-03 8:39 a.m., passiongnulinux@gmail.com wrote:
Hello the family ;)
It's me again, I have a person who told me about a dns cache problem, or something like that, in short, I have indeed since noticed that well after closing the Firefox browser, requests continue on the sites that I visited and that long after my last connection.
What about, bug or not? https://translate.google.fr/translate?hl=&sl=ru&tl=en&u=https%3A%2F%2Fwww.linux.org.ru%2Fforum%2Fgeneral%2F15622136&sandbox=1 the link speaks about it too.
DNS is a UDP protocol not a TCP protocol. Think of it this way. Your DNS mechanism asks for a resolution. What gets sent out amounts to a UDP shotgun blast. UDP is asynchronous. You don't know if a reply will come back to a specific request or when it will come back. Once sent, you can't cancel it. What you are getting amounts to a "long delayed echo" in radiophonics parlance. You send UDP requests to [A .. Z], get a reply from F and act on it. Meanwhile [A..T] might or might not reply and go into your cache. You finish and shut the application down. Then replies from [U..z} might or might not come in. Big Deal, that's the way it works. Its UDP after all. One the other hand, I have my firefox running day after day, so I never see this issue and even if I did i wouldn't see it as a problem, cost that's the way DNS works in a rich environment where there are many responders. You have to remember that DNS was designed some decades ago, in very sparse environment with unreliable connections and unreliable facilities. It solved the problems that existed then. The ones that exist now have to do with authenticity and integrity, not availability which are the problems that it faces now. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
Anton Aylward wrote:
On 2021-02-03 8:39 a.m., passiongnulinux@gmail.com wrote:
Hello the family ;)
It's me again, I have a person who told me about a dns cache problem, or something like that, in short, I have indeed since noticed that well after closing the Firefox browser, requests continue on the sites that I visited and that long after my last connection.
What about, bug or not?
the link speaks about it too.
DNS is a UDP protocol not a TCP protocol.
<nitpick> both actually </nitpick> 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' ? -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland.
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
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. -- Per Jessen, Zürich (9.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
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: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. Perhaps there is a CVE/big-number you can give us for this. -- “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 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 05/02/2021 00.03, L A Walsh wrote:
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.
Works for me instantly.
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:
The translation is not perfect, but it was sufficiently for me to read it all. The culprit was found to be nscd. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
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
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 -- Per Jessen, Zürich (5.2°C)
On Fri, 05 Feb 2021 08:57:55 +0100 Per Jessen <per@computer.org> 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 05/02/2021 11.56, Dave Howorth wrote:
On Fri, 05 Feb 2021 08:57:55 +0100 Per Jessen <per@computer.org> 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? ;-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Fri, 5 Feb 2021 13:29:15 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 05/02/2021 11.56, Dave Howorth wrote:
On Fri, 05 Feb 2021 08:57:55 +0100 Per Jessen <per@computer.org> 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 :)
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 <per@computer.org> 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 ;-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
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 <per@computer.org> 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 ;-)
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. -- Per Jessen, Zürich (8.6°C)
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.
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. Brendan On 05/02/2021 18:32, passiongnulinux@gmail.com wrote:
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)
Le vendredi 05 février 2021 à 19:28 +0000, Brendan McKenna a écrit :
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.
Brendan
On 05/02/2021 18:32, passiongnulinux@gmail.com wrote:
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.
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.
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)
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 :
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.l inux.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.
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.
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 2021-02-06 2:24 p.m., Stakanov wrote:
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.
That's a valid point. If you look at /usr/lib/systemd/system/nscd.service you'll see that a number of services are (re)started. So RTFM and see that nscd provides caching for accesses of the passwd(5), group(5), hosts(5) services(5) Try 'nscd --help' And check what's in /etc/nscd.conf Some of that is useful, some is not. Recall that things like 'ls' will want to know the GID->GroupName mapping. There's a similar reasoning for 'services', if and when. But in a single user system what about the rest? There's no need to cache passwords; I'm not sure there is a need in a multi user system. And as you say, if you're using DNSMasq with a reasonable setup then it's doing its own caching and monitoring changes of key files. So no, for single user workstations, I'm not sure nscd offers a tangible benefit. # systemctl disable nscd -- “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 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 04/02/2021 17.35, passiongnulinux@gmail.com wrote:
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.
Says there it is nscd. -- 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
Anton Aylward wrote:
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.
I see no mention of anything like that in his original post, are we talking about the same thing? -- Per Jessen, Zürich (7.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
participants (9)
-
Anton Aylward -
Brendan McKenna -
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
L A Walsh -
passiongnulinux＠gmail.com -
Per Jessen -
Stakanov