> Date: Sunday, August 26, 2018 21:10:48 -0400 > From: TE Dukes <tdukes at palmettoshopper.com> > >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> Richard Sent: Sunday, August 26, 2018 8:31 PM >> >> > Date: Sunday, August 26, 2018 16:25:14 -0400 >> > From: TE Dukes <tdukes at palmettoshopper.com> >> > >> >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> >> Alexander Dalloz >> >> Sent: Sunday, August 26, 2018 3:46 PM >> >> >> >> Am 26.08.2018 um 20:48 schrieb TE Dukes: >> >> >> You see a basic error message "Could not connect to >> >> >> localhost:143". So test that without using additional >> >> >> software. Foremost consult the maillog, in this case the log >> >> >> content produced by dovecot. And test connectivity on the >> >> >> lowest level. >> >> >> >> >> >> echo QUIT | openssl s_client -connect localhost:143 -starttls >> >> >> imap >> >> > I'm getting what appears to be help file with various options >> >> > when trying to run the above commad >> >> >> >> Can we guess that you don't offer TLS for IMAP connections? >> >> >> > I added this to /etc/postfix/main.cf from >> > https://access.redhat.com/solutions/120383 >> > >> > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 >> > smtpd_tls_protocols = !SSLv2, !SSLv3 >> > smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 >> > smtp_tls_protocols = !SSLv2, !SSLv3 >> > >> >> Randomly adding lines to a config file isn't going to help things. >> Those lines, which you added to the postfix config (which will have >> no impact on dovecot), are -- as the RH documentation indicates -- >> to turn off weak protocols, they don't turn anything on, other >> directives are used for that. >> >> > >> >> >> That must be successful first. You can too test "lsof -i >> >> >> :143" or "ss -tulpen | grep 143". And tail your maillog. >> >> >> >> >> > Running lsof -i :143, I get: >> >> > >> >> > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> >> > dovecot 1576 root 37u IPv4 32014 0t0 TCP *:imap >> >> > (LISTEN) dovecot 1576 root 38u IPv6 32015 0t0 TCP >> >> > *:imap (LISTEN) >> >> > >> >> > Running ss -tulpen | grep 143 : >> >> > >> >> > tcp LISTEN 0 100 *:143 *:* >> >> > users:(("dovecot",pid=1576,fd=37)) ino:32014 >> >> > sk:ffff913e953e2e80 <-> tcp LISTEN 0 100 >> >> > :::143 >> >> > :::* users:(("dovecot",pid=1576,fd=38)) ino:32015 >> >> > sk:ffff913b2e90a100v6only:1 >> >> > <-> >> >> >> >> So port 143 is listening. Are we back to the point that your DNS >> >> or NSS is broken so that even >> > >> > I think so. Everything else work, I don't get it. >> >> >> >> telnet localhost 143 >> >> >> >> fails while >> >> >> >> telnet 127.0.0.1 143 >> >> >> >> is successful? >> >> >> > >> > Yes, that is correct localhost fails but 127.0.0.1 responds. >> > >> >> In your pastebin: >> >> <https://paste.fedoraproject.org/paste/MMNEJmqIrEzK-A4N3MR0ZA> >> >> you show three nameservers: >> >> nameserver 166.102.165.13 >> nameserver 207.91.5.20 >> nameserver 127.0.0.1 >> > > The first two nameservers belong to my ISP. Should I move 127.0.0.1 > to the top? > > >> I can't tell if that's what you still have in place, but note that >> your dns queries will query those DNS servers in that order. Based >> on that order, the "localhost" (127.0.0.1) server is the last one >> that will be queried. Unless explicitly queried (e.g., with an >> @<nameserver> syntax) it will only be queried if the other two >> fail. >> >> Could you confirm the current order (and perhaps list) the >> nameservers in your /etc/resolv.conf file - so we are aware of any >> changes. > > They are still in that order. > >> >> I did a "localhost" query against the first two and they respond >> correctly, e.g., >> >> ;; QUESTION SECTION: >> ;localhost. IN A >> >> ;; ANSWER SECTION: >> localhost. 86400 IN A 127.0.0.1 >> >> ;; Query time: 100 msec >> ;; SERVER: 166.102.165.13#53(166.102.165.13) >> >> Somewhat related to the: >> >> > telnet localhost 143 >> > >> > fails [while it works when you try 127.0.0.1] >> > > Not sure what I have done, but telnet localhost 143 now works but > telnet 127.0.0.1 143 fails. > > >> In an earlier message (from Sunday, August 26, 2018 14:37:57) you >> state: >> >> > I have all the files shipped with CentOS. I created 2 zone >> > files >> >> could you please enumerate the "named.*" files that you have under >> your defined directory. Note, if you've chrooted named that's a >> different location than in a non-chrooted setup. >> > > total 28 > -rw-r--r-- 1 root named 391 Aug 26 17:44 192.168.1.zone > drwxrwx--- 2 named named 127 Aug 26 03:46 data/ > drwxrwx--- 2 named named 31 Aug 26 16:28 dynamic/ > -rw-r--r-- 1 root root 0 Aug 26 20:54 named > -rw-r----- 1 root named 2281 May 22 2017 named.ca > -rw-r----- 1 root named 152 Dec 15 2009 named.empty > -rw-r----- 1 root named 152 Jun 21 2007 named.localhost > -rw-r----- 1 root named 168 Dec 15 2009 named.loopback > -rw-r--r-- 1 root named 793 Aug 26 17:44 palmettodomains.zone > -rw-r--r-- 1 root root 1001 Aug 26 13:29 > palmettodomains.zone.082618 drwxrwx--- 2 named named 6 Apr 12 > 14:48 slaves/ > >> Then there's this: >> >> > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @localhost localhost >> > +short >> > ; (1 server found) >> > ;; global options: +cmd >> > ;; connection timed out; no servers could be reached >> >> do you *really* have a name server running on your local machine? >> Just thought I'd ask. >> > root 600 0.0 0.0 112704 968 tty2 S+ 21:02 0:00 > grep --color=auto named > named 21096 0.0 0.3 391636 60160 ? Ssl 17:45 0:00 > /usr/sbin/named -u named -c /etc/named.conf > >> While you are at it, could you show the current state of your >> /etc/hosts file (as well as its ownerships and permissions). >> > 127.0.0.1 localhost localhost.localdomain localhost4 > localhost4.localdomain4 ># 127.0.0.1 localhost.localdomain localhost > 192.168.1.110 ts130.palmettodomains.com ts130 > 192.168.1.110 mail.palmettodomains.com mail > > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 ># ::1 localhost6.localdomain6 localhost6 > 192.168.1.102 edukes1.palmettodomains.com edukes1 > 192.168.1.105 hp8200.palmettodomains.com hp8200 > ::1 localhost localhost.localdomain localhost6 > localhost6.localdomain6 > > -rw-r--r-- 1 root root 509 Aug 26 14:02 hostsSince your: dig @localhost localhost failed, try: dig @127.0.0.1 localhost a (in this context, i like the longer output as it reveals more). If that fails, then there is, at minimum, a problem with your local dns server. If that works, try: dig @localhost4 localhost a This will explicitly use the ipv4 127. entry in your /etc/hosts, while "localhost" could use either. [by the way, you appear to have redundant ipv6 "localhost" entries in your /etc/hosts file. mostly to have things clean, i'd get rid of the bottom one.]
> -----Original Message----- > From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of Richard > Sent: Sunday, August 26, 2018 10:25 PM > To: CentOS mailing list > Subject: Re: [CentOS] Mail has quit working > > > > > Date: Sunday, August 26, 2018 21:10:48 -0400 > > From: TE Dukes <tdukes at palmettoshopper.com> > > > >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of > >> Richard Sent: Sunday, August 26, 2018 8:31 PM > >> > >> > Date: Sunday, August 26, 2018 16:25:14 -0400 > >> > From: TE Dukes <tdukes at palmettoshopper.com> > >> > > >> >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of > >> >> Alexander Dalloz > >> >> Sent: Sunday, August 26, 2018 3:46 PM > >> >> > >> >> Am 26.08.2018 um 20:48 schrieb TE Dukes: > >> >> >> You see a basic error message "Could not connect to > >> >> >> localhost:143". So test that without using additional > >> >> >> software. Foremost consult the maillog, in this case the log > >> >> >> content produced by dovecot. And test connectivity on the > >> >> >> lowest level. > >> >> >> > >> >> >> echo QUIT | openssl s_client -connect localhost:143 -starttls > >> >> >> imap > >> >> > I'm getting what appears to be help file with various options > >> >> > when trying to run the above commad > >> >> > >> >> Can we guess that you don't offer TLS for IMAP connections? > >> >> > >> > I added this to /etc/postfix/main.cf from > >> > https://access.redhat.com/solutions/120383 > >> > > >> > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 > >> > smtpd_tls_protocols = !SSLv2, !SSLv3 > >> > smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 > >> > smtp_tls_protocols = !SSLv2, !SSLv3 > >> > > >> > >> Randomly adding lines to a config file isn't going to help things. > >> Those lines, which you added to the postfix config (which will have > >> no impact on dovecot), are -- as the RH documentation indicates -- > >> to turn off weak protocols, they don't turn anything on, other > >> directives are used for that. > >> > >> > > >> >> >> That must be successful first. You can too test "lsof -i > >> >> >> :143" or "ss -tulpen | grep 143". And tail your maillog. > >> >> >> > >> >> > Running lsof -i :143, I get: > >> >> > > >> >> > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > >> >> > dovecot 1576 root 37u IPv4 32014 0t0 TCP *:imap > >> >> > (LISTEN) dovecot 1576 root 38u IPv6 32015 0t0 TCP > >> >> > *:imap (LISTEN) > >> >> > > >> >> > Running ss -tulpen | grep 143 : > >> >> > > >> >> > tcp LISTEN 0 100 *:143 *:* > >> >> > users:(("dovecot",pid=1576,fd=37)) ino:32014 > >> >> > sk:ffff913e953e2e80 <-> tcp LISTEN 0 100 > >> >> > :::143 > >> >> > :::* users:(("dovecot",pid=1576,fd=38)) ino:32015 > >> >> > sk:ffff913b2e90a100v6only:1 > >> >> > <-> > >> >> > >> >> So port 143 is listening. Are we back to the point that your DNS > >> >> or NSS is broken so that even > >> > > >> > I think so. Everything else work, I don't get it. > >> >> > >> >> telnet localhost 143 > >> >> > >> >> fails while > >> >> > >> >> telnet 127.0.0.1 143 > >> >> > >> >> is successful? > >> >> > >> > > >> > Yes, that is correct localhost fails but 127.0.0.1 responds. > >> > > >> > >> In your pastebin: > >> > >> <https://paste.fedoraproject.org/paste/MMNEJmqIrEzK-A4N3MR0ZA> > >> > >> you show three nameservers: > >> > >> nameserver 166.102.165.13 > >> nameserver 207.91.5.20 > >> nameserver 127.0.0.1 > >> > > > > The first two nameservers belong to my ISP. Should I move 127.0.0.1 > > to the top? > > > > > >> I can't tell if that's what you still have in place, but note that > >> your dns queries will query those DNS servers in that order. Based > >> on that order, the "localhost" (127.0.0.1) server is the last one > >> that will be queried. Unless explicitly queried (e.g., with an > >> @<nameserver> syntax) it will only be queried if the other two > >> fail. > >> > >> Could you confirm the current order (and perhaps list) the > >> nameservers in your /etc/resolv.conf file - so we are aware of any > >> changes. > > > > They are still in that order. > > > >> > >> I did a "localhost" query against the first two and they respond > >> correctly, e.g., > >> > >> ;; QUESTION SECTION: > >> ;localhost. IN A > >> > >> ;; ANSWER SECTION: > >> localhost. 86400 IN A 127.0.0.1 > >> > >> ;; Query time: 100 msec > >> ;; SERVER: 166.102.165.13#53(166.102.165.13) > >> > >> Somewhat related to the: > >> > >> > telnet localhost 143 > >> > > >> > fails [while it works when you try 127.0.0.1] > >> > > > > Not sure what I have done, but telnet localhost 143 now works but > > telnet 127.0.0.1 143 fails. > > > > > >> In an earlier message (from Sunday, August 26, 2018 14:37:57) you > >> state: > >> > >> > I have all the files shipped with CentOS. I created 2 zone > >> > files > >> > >> could you please enumerate the "named.*" files that you have under > >> your defined directory. Note, if you've chrooted named that's a > >> different location than in a non-chrooted setup. > >> > > > > total 28 > > -rw-r--r-- 1 root named 391 Aug 26 17:44 192.168.1.zone > > drwxrwx--- 2 named named 127 Aug 26 03:46 data/ > > drwxrwx--- 2 named named 31 Aug 26 16:28 dynamic/ > > -rw-r--r-- 1 root root 0 Aug 26 20:54 named > > -rw-r----- 1 root named 2281 May 22 2017 named.ca > > -rw-r----- 1 root named 152 Dec 15 2009 named.empty > > -rw-r----- 1 root named 152 Jun 21 2007 named.localhost > > -rw-r----- 1 root named 168 Dec 15 2009 named.loopback > > -rw-r--r-- 1 root named 793 Aug 26 17:44 palmettodomains.zone > > -rw-r--r-- 1 root root 1001 Aug 26 13:29 > > palmettodomains.zone.082618 drwxrwx--- 2 named named 6 Apr 12 > > 14:48 slaves/ > > > >> Then there's this: > >> > >> > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @localhost localhost > >> > +short > >> > ; (1 server found) > >> > ;; global options: +cmd > >> > ;; connection timed out; no servers could be reached > >> > >> do you *really* have a name server running on your local machine? > >> Just thought I'd ask. > >> > > root 600 0.0 0.0 112704 968 tty2 S+ 21:02 0:00 > > grep --color=auto named > > named 21096 0.0 0.3 391636 60160 ? Ssl 17:45 0:00 > > /usr/sbin/named -u named -c /etc/named.conf > > > >> While you are at it, could you show the current state of your > >> /etc/hosts file (as well as its ownerships and permissions). > >> > > 127.0.0.1 localhost localhost.localdomain localhost4 > > localhost4.localdomain4 > ># 127.0.0.1 localhost.localdomain localhost > > 192.168.1.110 ts130.palmettodomains.com ts130 > > 192.168.1.110 mail.palmettodomains.com mail > > > > ::1 localhost localhost.localdomain localhost6 > > localhost6.localdomain6 > ># ::1 localhost6.localdomain6 localhost6 > > 192.168.1.102 edukes1.palmettodomains.com edukes1 > > 192.168.1.105 hp8200.palmettodomains.com hp8200 > > ::1 localhost localhost.localdomain localhost6 > > localhost6.localdomain6 > > > > -rw-r--r-- 1 root root 509 Aug 26 14:02 hosts > > Since your: > > dig @localhost localhost > > failed, try: > > dig @127.0.0.1 localhost a > > (in this context, i like the longer output as it reveals more).>From dig @127.0.0.1 localhost a; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @127.0.0.1 localhost a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36452 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;localhost. IN A ;; ANSWER SECTION: localhost. 86400 IN A 127.0.0.1 ;; AUTHORITY SECTION: localhost. 86400 IN NS localhost. ;; ADDITIONAL SECTION: localhost. 86400 IN AAAA ::1 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Aug 26 22:29:21 EDT 2018 ;; MSG SIZE rcvd: 96> > If that fails, then there is, at minimum, a problem with your local > dns server. If that works, try: > > dig @localhost4 localhost a>From dig @localhost4 localhost a; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @localhost4 localhost a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39351 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;localhost. IN A ;; ANSWER SECTION: localhost. 86400 IN A 127.0.0.1 ;; AUTHORITY SECTION: localhost. 86400 IN NS localhost. ;; ADDITIONAL SECTION: localhost. 86400 IN AAAA ::1 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Aug 26 22:30:35 EDT 2018 ;; MSG SIZE rcvd: 96> > This will explicitly use the ipv4 127. entry in your /etc/hosts, > while "localhost" could use either. > > [by the way, you appear to have redundant ipv6 "localhost" entries in > your /etc/hosts file. mostly to have things clean, i'd get rid of the > bottom one.]Thanks! Not sure where that came from but its been removed. Thank!!
> Date: Sunday, August 26, 2018 22:37:55 -0400 > From: TE Dukes <tdukes at palmettoshopper.com> > >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> Richard Sent: Sunday, August 26, 2018 10:25 PM >> >> >> > Date: Sunday, August 26, 2018 21:10:48 -0400 >> > From: TE Dukes <tdukes at palmettoshopper.com> >> > >> >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> >> Richard Sent: Sunday, August 26, 2018 8:31 PM >> >> >> >> > Date: Sunday, August 26, 2018 16:25:14 -0400 >> >> > From: TE Dukes <tdukes at palmettoshopper.com> >> >> > >> >> >> From: CentOS [mailto:centos-bounces at centos.org] On Behalf Of >> >> >> Alexander Dalloz >> >> >> Sent: Sunday, August 26, 2018 3:46 PM >> >> >> >> >> >> Am 26.08.2018 um 20:48 schrieb TE Dukes: >> >> >> >> You see a basic error message "Could not connect to >> >> >> >> localhost:143". So test that without using additional >> >> >> >> software. Foremost consult the maillog, in this case the >> >> >> >> log content produced by dovecot. And test connectivity on >> >> >> >> the lowest level. >> >> >> >>>> >> >> >> >> >> So port 143 is listening. Are we back to the point that your >> >> >> DNS or NSS is broken so that even >> >> > >> >> > I think so. Everything else work, I don't get it. >> >> >> >> >> >> telnet localhost 143 >> >> >> >> >> >> fails while >> >> >> >> >> >> telnet 127.0.0.1 143 >> >> >> >> >> >> is successful? >> >> >> >> >> > >> >> > Yes, that is correct localhost fails but 127.0.0.1 responds. >> >> > >> >> >> >> In your pastebin: >> >> >> >> <https://paste.fedoraproject.org/paste/MMNEJmqIrEzK-A4N3MR0ZA> >> >> >> >> you show three nameservers: >> >> >> >> nameserver 166.102.165.13 >> >> nameserver 207.91.5.20 >> >> nameserver 127.0.0.1 >> >> >> > >> > The first two nameservers belong to my ISP. Should I move >> > 127.0.0.1 to the top? >> > >> > >> >> I can't tell if that's what you still have in place, but note >> >> that your dns queries will query those DNS servers in that >> >> order. Based on that order, the "localhost" (127.0.0.1) server >> >> is the last one that will be queried. Unless explicitly queried >> >> (e.g., with an @<nameserver> syntax) it will only be queried if >> >> the other two fail. >> >> >> >> Could you confirm the current order (and perhaps list) the >> >> nameservers in your /etc/resolv.conf file - so we are aware of >> >> any changes. >> > >> > They are still in that order. >> > >> >> >> >> I did a "localhost" query against the first two and they respond >> >> correctly, e.g., >> >> >> >> ;; QUESTION SECTION: >> >> ;localhost. IN A >> >> >> >> ;; ANSWER SECTION: >> >> localhost. 86400 IN A 127.0.0.1 >> >> >> >> ;; Query time: 100 msec >> >> ;; SERVER: 166.102.165.13#53(166.102.165.13) >> >> >> >> Somewhat related to the: >> >> >> >> > telnet localhost 143 >> >> > >> >> > fails [while it works when you try 127.0.0.1] >> >> >> > >> > Not sure what I have done, but telnet localhost 143 now works but >> > telnet 127.0.0.1 143 fails. >> > >> >>> >> >> > 127.0.0.1 localhost localhost.localdomain localhost4 >> > localhost4.localdomain4 >> ># 127.0.0.1 localhost.localdomain localhost >> > 192.168.1.110 ts130.palmettodomains.com ts130 >> > 192.168.1.110 mail.palmettodomains.com mail >> > >> > ::1 localhost localhost.localdomain localhost6 >> > localhost6.localdomain6 >> ># ::1 localhost6.localdomain6 localhost6 >> > 192.168.1.102 edukes1.palmettodomains.com edukes1 >> > 192.168.1.105 hp8200.palmettodomains.com hp8200 >> > ::1 localhost localhost.localdomain localhost6 >> > localhost6.localdomain6 >> > >> > -rw-r--r-- 1 root root 509 Aug 26 14:02 hosts >> >> Since your: >> >> dig @localhost localhost >> >> failed, try: >> >> dig @127.0.0.1 localhost a >> >> (in this context, i like the longer output as it reveals more). > > From dig @127.0.0.1 localhost a > > > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @127.0.0.1 localhost a > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36452 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, > ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;localhost. IN A > > ;; ANSWER SECTION: > localhost. 86400 IN A 127.0.0.1 > > ;; AUTHORITY SECTION: > localhost. 86400 IN NS localhost. > > ;; ADDITIONAL SECTION: > localhost. 86400 IN AAAA ::1 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Aug 26 22:29:21 EDT 2018 > ;; MSG SIZE rcvd: 96 > >> >> If that fails, then there is, at minimum, a problem with your local >> dns server. If that works, try: >> >> dig @localhost4 localhost a > > From dig @localhost4 localhost a > > ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @localhost4 localhost a > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39351 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, > ADDITIONAL: 2 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;localhost. IN A > > ;; ANSWER SECTION: > localhost. 86400 IN A 127.0.0.1 > > ;; AUTHORITY SECTION: > localhost. 86400 IN NS localhost. > > ;; ADDITIONAL SECTION: > localhost. 86400 IN AAAA ::1 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Aug 26 22:30:35 EDT 2018 > ;; MSG SIZE rcvd: 96 > >> >> This will explicitly use the ipv4 127. entry in your /etc/hosts, >> while "localhost" could use either. >>Since the localhost4 approach worked, commend out the ipv6 localhost entries in your /etc/hosts file, then try: dig @localhost localhost a again. If that works try: telnet localhost 143 once again. If those work, it would seem that your ipv6 is messed up and your system is trying it first and not falling back to ipv4. Regarding your nameserver list in /etc/resolv.conf. If you have a working 127.0.0.1 nameserver you generally don't include external nameservers in that list. So, if non-ipv6 things seem to work, I'd remove the two non-127 nameservers from that list.