Re: [DNG] Weird network issue - slow to resolve IPs
Le 14/10/2018 à 04:38, goli...@dyne.org a écrit : On 2018-10-13 20:59, Hendrik Boom wrote: On Sat, Oct 13, 2018 at 05:30:56PM -0500, goli...@dyne.org wrote: On 2018-10-13 09:05, Steve Litt wrote: > On Fri, 12 Oct 2018 14:21:19 -0500 > goli...@dyne.org wrote: > > > Greetings everyone, > > > > Something funny is going on with my networking. It's taking a very > > long time to resolve host IPs across all browsers. It's been > > happening for a week or two but I'm just now getting annoyed enough > > to troubleshoot. > > Me too. I just noticed it about a month ago when I installed my own > Unbound resolver instead of just sending all queries to 8.8.8.8. > > Somebody later in this thread mentions that you shouldn't judge > resolution time by what the browser says. A few tests with dig and > nslookup tell me that with most domains I've never hit before (or which > have expired since I hit them), resolution usually takes less than a > second. > > In my case, I'm temporarily assuming that before installing my own > resolver I never noticed how much of slow browser loading was due to > browser's inefficient dns operations. > > SteveT > I have some food for thought to share but first an update. A technician came out today to check the line and setup. Line was clear and strong. Switched the modem and now getting 256 down. But . . . internet is still very slow to connect as verified by several of you. Once it gets to where it's going, it is really fast. So here's my conclusion . . . I think we are finally seeing the effects of the demise of Net Neutrality. Corporations are raking in a lot of money streaming videos to every imaginable device and the tech sites that I/we frequent are a low priority. So we are being bumped to the slow lane. Aaron Swartz and others saw this coming and it has finally arrived. Will be interesting to see just how bad it's going to get . . . Have you tried timing connection time to sites that likely *are* in the fast lane? Do we even now what they are? -- hendrik Well, I picked a few names at random. netflix pops up as soon as I hit enter. Ditto Microsoft, outlook, Apple, twitter, instagram, reddit, snapchat and facebook. Redhat is in a slower lane as is the Linux Foundation. Even Ubuntu takes a while. But I don't get out much so maybe some of you know some popular destinations that I missed. It is incredibly annoying to be connected to a rather fast pipe yet have to travel on what feels like 56k connection to get to where I can benefit from it. golinux Hi Golinux. Did you try to list your favorite sites in /etc/hosts ? This is a primitive and oldfashioned, but very simple, way to see if you hit a DNS issue or are routed to a slow lane. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On 2018-10-14 01:52, Rick Moen wrote: Quoting goli...@dyne.org (goli...@dyne.org): Well, I picked a few names at random. netflix pops up as soon as I hit enter. Ditto Microsoft, outlook, Apple, twitter, instagram, reddit, snapchat and facebook. Redhat is in a slower lane as is the Linux Foundation. Even Ubuntu takes a while. But I don't get out much so maybe some of you know some popular destinations that I missed. Thanks for taking the time to do this. When I digest it, just maybe my issue will be solved. I assume you mean using a Web browser. I would suggest starting your checks using 'dig'. Yes. But first, a brief interlude about _where_ your nameservice is coming from: If you look in /etc/resolv.conf, you'll see one or more 'nameserver' lines. Mine on my server is like this: $ cat /etc/resolv.conf search linuxmafia.com deirdre.org unixmercenary.net nameserver 127.0.0.1 nameserver 198.144.192.2 nameserver 198.144.192.4 #nameserver 198.144.195.186 $ (If you are getting your IP address using DHCP, you are extremely likely to be getting passed nameserver IP addresses with your IP address lease, resulting in the DHCP client software overwriting /etc/resolv.conf with, among other things, 'nameserver nnn.nnn.nnn.nnn' information. wicd finds a connection automatically. I think it uses DHCP. All these years I have managed to avoid the fine points of networking because it's always "just worked". Anyway, /etc/resolv.conf is one of the primary configuration files of a Linux system's DNS client software, part of glibc. The 'resolver library' in glibc uses as its sources of DNS resolution information the IP addresses in those 'nameserver nnn.nnn.nnn.nnn' lines. The resolver tries each one in turn, starting with the top line and moving down, until it finds the first one that answers DNS questions. Anyhow, it can be vital to know _what_ server is answering (well or otherwise) your system's DNS questions by default. Looking at /etc/resolv.cofn should answer that question. I don't have anything in /etc/resolvconf except an avahi-daemon in /update-libc.d/ Maybe I should start by putting 8.8.8.8 in /etc/resolvconf? And OT do I even need avahi installed at all? That's as much as I can digest atm - the rest of this looks "challenging". I really need some sleep. To be continued . . . In the case of _my_ /etc/resolv.conf, notice that the first address is the localhost IP addres, 127.0.0.1, which means 'resolve DNS questions locally'. This is because my server runs its own recursive nameserver daemon. Your first 'nameserver nnn.nnn.nnn.nnn' line will surely not be that, and will probably be an ISP-operated recursive nameserver reachable on the far end of your house's uplink. Following me so far? Now, we'll turn to basic use of 'dig'. The optional '@' parameter is where you can put which nameserver (specified by either fully qualified domain name = FQDN or IP address) this query should be sent to. In the example below, we will direct a query to out of the Google Public DNS recursive nameservers that Google offers for public benefit. $ dig ns1.linuxmafia.com @8.8.8.8 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55874 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: ns1.linuxmafia.com. 21599 IN A 198.144.195.186 $ 'dig' is using the default UDP-type datagram transport, and it got answer '198.144.195.186'. You can test exactly how long the question and answer cycle took by using the 'time' command as a wrapper: $ time dig ns1.linuxmafia.com @8.8.8.8 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: ns1.linuxmafia.com. 21519 IN A 198.144.195.186 real0m0.092s user0m0.008s sys 0m0.012s $ 'dig' can be badgered into using specifically TCP (instead of UDP) transport using a flag (+tcp) to that effect, or it can be told to use speciflcally only IPv4 or specifically only IPv6 using options to that effect (-4 and -6). It's the most versatile and reliable tool around for testing DNS functionality -- which in turn is useful to be able to test separately from the separate task of actually making connections for services after resolving DNS names to find where to reach them. I hope that helps. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On 2018-10-14 01:52, Rick Moen wrote: Anyhow, it can be vital to know _what_ server is answering (well or otherwise) your system's DNS questions by default. Looking at /etc/resolv.conf should answer that question. I don't have anything in /etc/resolvconf except an avahi-daemon in /update-libc.d/ Maybe I should start by putting 8.8.8.8 in /etc/resolvconf? And OT do I even need avahi installed at all? === OK. I am a complete idiot and ignored the dot in the filename so didn't even see the resolv.conf file. This is what's in it: domain austin.rr.com search austin.rr.com nameserver 209.18.47.62 nameserver 209.18.47.61 I would really like to change the DNS service. And those RR search pages are really annoying and useless. === Apologies for the confusion. Bedtime for me . . . ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
Quoting goli...@dyne.org (goli...@dyne.org): > I don't have anything in /etc/resolvconf except an avahi-daemon in > /update-libc.d/ Maybe I should start by putting 8.8.8.8 in > /etc/resolvconf? I didn't say _/etc/resolvconf_ (which is a directory). I said _/etc/resolv.conf_ (which is a regular file). /etc/resolv.conf is an ancient, primordial Unix feature, from the earliest days of TCP/IP, probably invented about a day or so after someone thought of the concept of DNS. /etc/resolvconf is a directory containing configuration files for a network-management framework called Resolvconf, so called because it's a set of tools for managing the contents of the /etc/resolv.conf file. (The naming of Resolvconf is at best unfortunate, as the namespace collision causes all sorts of problems.) Anyway, pretty much every TCP/IP-enabled Unix host has always had /etc/resolv.conf, along with /etc/hosts and /etc/nsswitch.conf. Those three IIRC are the configuration files for the built-in system DNS resolver facility built into glibc. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to build your own distro
Hi Arnt, El 14/10/18 a las 03:01, Arnt Karlsen escribió: ..why the 2 different web servers??? The configuration of Nginx requires granted permissions. At the same, granted permissions in the cloud requires a dedicated server, more expensive than a shared one. Not all the people can afford it. Apache, instead, can be configured using a local .htaccess file. One of them should do, and I'd say the proper way to number them, would be "1A." and "1B.", rather than "1." and "2." for apache and nginx. 1.i) 1.ii) 1.iii) 1.iv) ... I'm not a lawyer! ;-) If one of them is much easier or significantly better etc than the other, then the best one should be numbered "1." just like you did, and the other(s) should be thrown into an "alternative webserver setups" section in an appendix. Personally, i prefer nginx over apache, but i use a shared hosting for gnuinos; so, i'm using apache. On the other hand, the configuration suggested by KatolaZ: http://pkgmaster.devuan.org/devuan_mirror_walkthrough.txt that is: RewriteEngine on RewriteRule /devuan/merged/pool/DEVUAN/(.*) /devuan/pool/$1 RewriteRule /devuan/merged/pool/DEBIAN-SECURITY/(.*) /debian-security/pool/$1 RewriteRule /devuan/merged/pool/DEBIAN/(.*) /debian/pool/$1 didn't work for me. I just shared the one which worked in my server, using Redirect 302. Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to build your own distro
On Sun, Oct 14, 2018 at 11:05:20AM +0200, aitor_czr wrote: [cut] > On the other hand, the configuration suggested by KatolaZ: > > http://pkgmaster.devuan.org/devuan_mirror_walkthrough.txt > > that is: > > RewriteEngine on > RewriteRule /devuan/merged/pool/DEVUAN/(.*) /devuan/pool/$1 > RewriteRule /devuan/merged/pool/DEBIAN-SECURITY/(.*) /debian-security/pool/$1 > RewriteRule /devuan/merged/pool/DEBIAN/(.*) /debian/pool/$1 > > didn't work for me. I just shared the one which worked in my server, using > Redirect 302. > Dear Aitor, could you please elaborate on that? Many Devuan mirrors are using apache and they have used the same walkthrough. If there is anything we should change/improve in the walkthrough, it would be good to know. Please also consider that those instruction above are to be used in the context set by the walkthrough (See Section 0 and Section 4 therein), so quoting them verbatim without including the context is quite misleading. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to build your own distro
On 14-10-18 11:17, KatolaZ wrote: > On Sun, Oct 14, 2018 at 11:05:20AM +0200, aitor_czr wrote: > > [cut] > >> On the other hand, the configuration suggested by KatolaZ: >> >> http://pkgmaster.devuan.org/devuan_mirror_walkthrough.txt >> >> that is: >> >> RewriteEngine on >> RewriteRule /devuan/merged/pool/DEVUAN/(.*) /devuan/pool/$1 >> RewriteRule /devuan/merged/pool/DEBIAN-SECURITY/(.*) /debian-security/pool/$1 >> RewriteRule /devuan/merged/pool/DEBIAN/(.*) /debian/pool/$1 >> >> didn't work for me. I just shared the one which worked in my server, using >> Redirect 302. >> > Dear Aitor, > > could you please elaborate on that? Many Devuan mirrors are using > apache and they have used the same walkthrough. If there is anything > we should change/improve in the walkthrough, it would be good to know. > > Please also consider that those instruction above are to be used in > the context set by the walkthrough (See Section 0 and Section 4 > therein), so quoting them verbatim without including the context is > quite misleading. > > HND > > KatolaZ > Hi Katolaz, For people not used to apache2 we maybe should add a configuration file for the local mirror to your walk through. Without a correctly configured local mirror the rewrite rules will not work. I can add the .conf file for mirror.smallinnovations.nl if that is helpful. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to build your own distro
On Sun, Oct 14, 2018 at 11:17:20AM +0200, KatolaZ wrote: > On Sun, Oct 14, 2018 at 11:05:20AM +0200, aitor_czr wrote: > > [cut] > > > On the other hand, the configuration suggested by KatolaZ: > > > > http://pkgmaster.devuan.org/devuan_mirror_walkthrough.txt > > > > that is: > > > > RewriteEngine on > > RewriteRule /devuan/merged/pool/DEVUAN/(.*) /devuan/pool/$1 > > RewriteRule /devuan/merged/pool/DEBIAN-SECURITY/(.*) > > /debian-security/pool/$1 > > RewriteRule /devuan/merged/pool/DEBIAN/(.*) /debian/pool/$1 > > > > didn't work for me. I just shared the one which worked in my server, using > > Redirect 302. > > > > Dear Aitor, > > could you please elaborate on that? Many Devuan mirrors are using > apache and they have used the same walkthrough. If there is anything > we should change/improve in the walkthrough, it would be good to know. nginx or apache? There are others. This may be moot because I don't have the resources for a Devuan mirror anyway (just a home DSL line), but I use lighttpd. Do I guess correctly that every web server would have to be configured completely differently and that it's a mug's game to try and handle all these possibilities in one document? The rumour mill for the past few years suggests that apache is overcomplicated and thus vulnerable. Is this an issue? Or are the complications actually needed for something like setting up a distro? And is this also true for nginx? I haven't heard much about that one. -- hendrik. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On Sat, Oct 13, 2018 at 11:52:34PM -0700, Rick Moen wrote: > Quoting goli...@dyne.org (goli...@dyne.org): > > > Well, I picked a few names at random. netflix pops up as soon as I > > hit enter. Ditto Microsoft, outlook, Apple, twitter, instagram, > > reddit, snapchat and facebook. Redhat is in a slower lane as is the > > Linux Foundation. Even Ubuntu takes a while. But I don't get out > > much so maybe some of you know some popular destinations that I > > missed. > > I assume you mean using a Web browser. I would suggest starting your > checks using 'dig'. > > But first, a brief interlude about _where_ your nameservice is coming > from: > > If you look in /etc/resolv.conf, you'll see one or more 'nameserver' > lines. Mine on my server is like this: > > $ cat /etc/resolv.conf > search linuxmafia.com deirdre.org unixmercenary.net > nameserver 127.0.0.1 > nameserver 198.144.192.2 > nameserver 198.144.192.4 > #nameserver 198.144.195.186 > $ > > (If you are getting your IP address using DHCP, you are extremely likely > to be getting passed nameserver IP addresses with your IP address lease, > resulting in the DHCP client software overwriting /etc/resolv.conf with, > among other things, 'nameserver nnn.nnn.nnn.nnn' information. Is there any practical way of suppressing this overwriting? Or is it essential for the usual coffee-shop mode? Is the coffee-shop's DNS service is how my http: requests are hijacked to give me an advertising and agree-to-not-show-nudity page without which they cut me off? And whih causes my browser to cut me off if it's https:? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On Sun, Oct 14, 2018 at 02:45:07AM -0500, goli...@dyne.org wrote: ... > > And OT do I even need avahi installed at all? What is it needed for? > > OK. I am a complete idiot and ignored the dot in the filename so didn't > even see the resolv.conf file. This is what's in it: > > domain austin.rr.com Is this the fully qualified domain name for the machine this file resides in, or the domain name that something has to be prefixed to to get that fqdn? > search austin.rr.com Is this what gets prefixed to every non-qualified domain name in the search attempt so as to allow abbreviated short names? Is it possibe to just say search . to disallow abbreviated names? > nameserver 209.18.47.62 > nameserver 209.18.47.61 -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
On Sun, 14 Oct 2018 08:23:09 -0400 Hendrik Boom wrote: > On Sun, Oct 14, 2018 at 02:45:07AM -0500, goli...@dyne.org wrote: > ... > > > > And OT do I even need avahi installed at all? > > What is it needed for? I do not really know, if you have DNS set up correctly, it isn't required and guess who wrote it ? > > > > > OK. I am a complete idiot and ignored the dot in the filename so > > didn't even see the resolv.conf file. This is what's in it: > > > > domain austin.rr.com > > Is this the fully qualified domain name for the machine this file > resides in, or the domain name that something has to be prefixed to > to get that fqdn? > > > search austin.rr.com > > Is this what gets prefixed to every non-qualified domain name in the > search attempt so as to allow abbreviated short names? It is the dns domain to search for the domain records and you do not need both, in fact, which ever is second will be used, so for most people, you only need the 'search' line. > Is it possibe to just say > search . > to disallow abbreviated names? Not from my experience. Rowland ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to build your own distro
On Sun, Oct 14, 2018 at 07:54:25AM -0400, Hendrik Boom wrote: > On Sun, Oct 14, 2018 at 11:17:20AM +0200, KatolaZ wrote: > > On Sun, Oct 14, 2018 at 11:05:20AM +0200, aitor_czr wrote: > > > > [cut] > > > > > On the other hand, the configuration suggested by KatolaZ: > > > > > > http://pkgmaster.devuan.org/devuan_mirror_walkthrough.txt > > > > > > that is: > > > > > > RewriteEngine on > > > RewriteRule /devuan/merged/pool/DEVUAN/(.*) /devuan/pool/$1 > > > RewriteRule /devuan/merged/pool/DEBIAN-SECURITY/(.*) > > > /debian-security/pool/$1 > > > RewriteRule /devuan/merged/pool/DEBIAN/(.*) /debian/pool/$1 > > > > > > didn't work for me. I just shared the one which worked in my server, > > > using Redirect 302. > > > > > > > Dear Aitor, > > > > could you please elaborate on that? Many Devuan mirrors are using > > apache and they have used the same walkthrough. If there is anything > > we should change/improve in the walkthrough, it would be good to know. > > nginx or apache? > > There are others. This may be moot because I don't have the resources > for a Devuan mirror anyway (just a home DSL line), but I use lighttpd. > There are package mirrors using lighttpd as well, and they work just fine. > Do I guess correctly that every web server would have to be configured > completely differently and that it's a mug's game to try and handle all > these possibilities in one document? > rewrite rules are server-specific. There is no way around that. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
Le 14/10/2018 à 09:45, goli...@dyne.org a écrit : I don't have anything in /etc/resolvconf except an avahi-daemon in /update-libc.d/ Maybe I should start by putting 8.8.8.8 in /etc/resolvconf? And OT do I even need avahi installed at all? Avahi daemon is the Linux dnssd service. dnssd is a protocol for service discovery on LAN (formerly known as Apple "Bonjour"). The essential utility for me is to allow to discover CUPS servers on the LAN, because recent versions of CUPS advertise their presence by the dnssd protocol instead of the former ad hoc protocol. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
Am 2018-10-14 14:23, schrieb Hendrik Boom: And OT do I even need avahi installed at all? What is it needed for? try "aptitude why avahi-daemon" to see why it was installed. Your normally don't need it. Maybe it was installed as a recommend. Avahi is a zeroconf tool like Apples Bonjour to detect network devices on your lan by sending broadcasts. It's for automagically detecting printers, scanners and so on. You can live without that. Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
Rick Moen wrote: > It's the most versatile and reliable tool around for testing DNS > functionality -- which in turn is useful to be able to test separately > from the separate task of actually making connections for services after > resolving DNS names to find where to reach them. +1 for that - it's my "go to" tool for anything that could be even remotely DNS related, and for many non-DNS related issues as well. And I'll add wget or curl (according to preference) to actually download a web page rather than your browser. It a) tells you what it's doing, b) doesn't cache the results to cause confusion, and c) it doesn't (unless you tell it to) download all the linked files. So dig can tell you where the server is, wget or curl will tell you how a web server is performing. Oh yes, looking at the list presented earlier, one thought that went through my mind was "aren't those well performing ones all using a CDN ?" Hendrik Boom wrote: >> search austin.rr.com > Is this what gets prefixed to every non-qualified domain name in the search > attempt so as to allow abbreviated short names? My first thought was that it's been put there by the ISP to direct all short names to a search engine type of page that they provide - eg if someone puts just "Microsoft" into the broaser address bar, the browser will then go to microsoft.austin.rr.com and they'll present a search page of possible destinations the user might have wanted. However I see no A records, and this seems to be broken - so I wonder if this is perhaps an element in the problem. Rowland Penny wrote: >>> And OT do I even need avahi installed at all? >> What is it needed for? > I do not really know, if you have DNS set up correctly, it isn't required and > guess who wrote it ? I disagree with that. Firstly it can be very useful - eg it's easier for most people to simply send their print job to (eg) "lj1320.local." than to find out how to statically configure the printer and directly use it's IP address. It's even more work to statically configure the printer (or the DHCP server to give it a static assignment) AND set up the local DNS so you can print to (eg) "lj1320.mydomain.com". And of course, mdns will also automagically use IPv6 if both devices properly support it. There's definitely an advantage to not exposing most users to IPv6 addresses. As to who wrote it, even given the reason for the existence of Devuan it's getting a bit paranoid to reject something just for that reason. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
Quoting Hendrik Boom (hend...@topoi.pooq.com):
> On Sat, Oct 13, 2018 at 11:52:34PM -0700, Rick Moen wrote:
> >
> > If you look in /etc/resolv.conf, you'll see one or more 'nameserver'
> > lines. Mine on my server is like this:
> >
> > $ cat /etc/resolv.conf
> > search linuxmafia.com deirdre.org unixmercenary.net
> > nameserver 127.0.0.1
> > nameserver 198.144.192.2
> > nameserver 198.144.192.4
> > #nameserver 198.144.195.186
> > $
> >
> > (If you are getting your IP address using DHCP, you are extremely likely
> > to be getting passed nameserver IP addresses with your IP address lease,
> > resulting in the DHCP client software overwriting /etc/resolv.conf with,
> > among other things, 'nameserver nnn.nnn.nnn.nnn' information.
>
> Is there any practical way of suppressing this overwriting?
Yes, absolutely. (Not a complaint, but there was recent discussion of
that matter on Dng.) Write-up here:
http://linuxmafia.com/faq/Network_Other/resolvconf.html (Note, in
particular, item #3, 'Tweaking Your DHCP Client's Operation without
Resolvconf.'
> Or is it essential for the usual coffee-shop mode? Is the
> coffee-shop's DNS service is how my http: requests are hijacked to give
> me an advertising and agree-to-not-show-nudity page without which they
> cut me off?
{sigh} This is where things _sometimes_ become a little complex.
Many coffee-shop (and hotel, and similar) wifi networks rely on
something called a 'captive portal' to direct and force users to visit
a specific Web page immediately and either prove entitlement/payment or
formally consent to terms of service or both. In the cases I have in
mind, the WAP sends a DHCP lease with nameserver IP information that it
requests the client overwrite to /etc/resolv.conf . The initial purpose
of that nameserver is to categorically resolve any FQDN to the portal
Web site IP, pending customer authentication.
If you are travelling with a laptop and, say, object to /etc/resolv.conf
being overwritten every time there's a DHCP lease and take steps to
prevent that happening (as detailed in my write-up), you would silently
fail to reach the hotel (etc.) sign-in Web site and wonder why you're
neither seeing it nor any other remote destination, until you figure it
out and say to yourself 'Oh, right, I need to use _their_ cursed and
peculiar nameserver for the first two minutes so I can enter my Marriott
Rewards number, then I can switch back to nameservers I prefer.'
> And whih causes my browser to cut me off if it's https:?
I'm guessing: A nosy company that with a gateway designed to deny
privacy?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Weird network issue - slow to resolve IPs
Quoting Didier Kryn (k...@in2p3.fr): > Avahi daemon is the Linux dnssd service. dnssd is a protocol > for service discovery on LAN (formerly known as Apple "Bonjour"). > The essential utility for me is to allow to discover CUPS servers on > the LAN, because recent versions of CUPS advertise their presence by > the dnssd protocol instead of the former ad hoc protocol. dnssd is the most annoyingly and pointlessly chatty network protocol since Appletalk. If like me you don't want that crud junking up your network, edit the line 'BrowseRemoteProtocols dnssd cups' in cupsd.conf to 'BrowseRemoteProtocols none' and restart cupsd. Blessed silence will ensue. This of course requires determining a target printer's IP address and supported network transports, when configuring printing, rather than having it be automagical. (Quelle horreur!) (Check the authors of Avahi, and you'll see a familiar name.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
