hi list,
so my bind config has apparently not worked despite my dig'ing.
an external config checker says it finds no valid IP' for linuxlighthouse.com, i am failing http challenge.
see link at
https://check-your-website.server-daten.de/?q=linuxlighthouse.com
and certbot failure has, ...
2021-04-15 10:43:03,646:DEBUG:acme.client:Storing nonce: 0004HnTzBUlghQdQEzv_wTvwyO48A34nYnSNpZ8AAM3Jp8o 2021-04-15 10:43:03,647:WARNING:certbot._internal.auth_handler:Challenge failed for domain linuxlighthouse.com 2021-04-15 10:43:03,647:INFO:certbot._internal.auth_handler:http-01 challenge for linuxlighthouse.com 2021-04-15 10:43:03,648:DEBUG:certbot._internal.reporter:Reporting to user: The following errors were reported by the server:
Domain: linuxlighthouse.com Type: dns Detail: No valid IP addresses found for linuxlighthouse.com 2021-04-15 10:43:03,649:DEBUG:certbot._internal.error_handler:Encountered exception: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 91, in handle_authorizations self._poll_authorizations(authzrs, max_retries, best_effort) File "/usr/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 180, in _poll_authorizations raise errors.AuthorizationError('Some challenges have failed.') certbot.errors.AuthorizationError: Some challenges have failed.
dig 108.220.213.121 linuxlighthouse.com soa NOERROR DNS Query completed successfully
dig localhost linuxlighthouse.com soa NOERROR DNS Query completed successfully
dig 8.8.8.8 linuxlighthouse.com soa NOERROR DNS Query completed successfully
suggestions??
----- On Apr 15, 2021, at 9:00 PM, Jack Craig jack.craig.aptos@gmail.com wrote:
hi list,
so my bind config has apparently not worked despite my dig'ing.
an external config checker says it finds no valid IP' for linuxlighthouse.com, i am failing http challenge.
see link at
https://check-your-website.server-daten.de/?q=linuxlighthouse.com
and certbot failure has, ...
2021-04-15 10:43:03,646:DEBUG:acme.client:Storing nonce: 0004HnTzBUlghQdQEzv_wTvwyO48A34nYnSNpZ8AAM3Jp8o 2021-04-15 10:43:03,647:WARNING:certbot._internal.auth_handler:Challenge failed for domain linuxlighthouse.com 2021-04-15 10:43:03,647:INFO:certbot._internal.auth_handler:http-01 challenge for linuxlighthouse.com 2021-04-15 10:43:03,648:DEBUG:certbot._internal.reporter:Reporting to user: The following errors were reported by the server:
Domain: linuxlighthouse.com Type: dns Detail: No valid IP addresses found for linuxlighthouse.com 2021-04-15 10:43:03,649:DEBUG:certbot._internal.error_handler:Encountered exception: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 91, in handle_authorizations self._poll_authorizations(authzrs, max_retries, best_effort) File "/usr/lib/python3.8/site-packages/certbot/_internal/auth_handler.py", line 180, in _poll_authorizations raise errors.AuthorizationError('Some challenges have failed.') certbot.errors.AuthorizationError: Some challenges have failed.
dig 108.220.213.121 linuxlighthouse.com soa NOERROR DNS Query completed successfully
dig localhost linuxlighthouse.com soa NOERROR DNS Query completed successfully
dig 8.8.8.8 linuxlighthouse.com soa NOERROR DNS Query completed successfully
suggestions??
No one know about your domain linuxlighthouse.com. Fix this.
$ dig linuxlighthouse.com +short $ dig linuxlighthouse.com +short @8.8.8.8
Shows nothing...
And
$ dig -x 108.220.213.121 +short ws.linuxlighthouse.com. $ dig -x 108.220.213.121 +short @8.8.8.8 ws.linuxlighthouse.com.
On 16/04/2021 03:00, Subscriber wrote:
No one know about your domain linuxlighthouse.com. Fix this.
$ dig linuxlighthouse.com +short $ dig linuxlighthouse.com +short @8.8.8.8
Shows nothing...
And
$ dig -x 108.220.213.121 +short ws.linuxlighthouse.com. $ dig -x 108.220.213.121 +short @8.8.8.8 ws.linuxlighthouse.com.
Yes. Oddly, it was working a day or two ago. I didn't save the output but that is why I commented in the previous thread.
IPv6 address fe80::15ef:5535 is not a routeable IPv6 address. It is akin to setting 10.0.0.101 as your public IPv4 address.
As this was an address for ws.linuxlighthouse.com.
[egreshko@meimei ~]$ dig @8.8.8.8 +nssearch linuxlighthouse.com [egreshko@meimei ~]$
No results.
[egreshko@meimei ~]$ dig -x 108.220.213.121 121.213.220.108.in-addr.arpa. 1177 IN PTR ws.linuxlighthouse.com.
Is OK, but that zone is may not be delegated to the OP.
Jack Craig writes:
hi list,
so my bind config has apparently not worked despite my dig'ing.
an external config checker says it finds no valid IP' for URL:http://linuxlighthouse.comlinuxlighthouse.com, i am failing http challenge.
Correct. The DNS is broken. You need to get basic DNS working, first.
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> linuxlighthouse.com a ;; global options: +cmd ;; Got answer: ;; →>HEADER<← opcode: QUERY, status: SERVFAIL, id: 18762
Digging into DNS further:
linuxlighthouse.com. 172800 IN NS ns3.attdns.com. linuxlighthouse.com. 172800 IN NS ws.linuxlighthouse.com.
ns3.attdns.com. 172800 IN A 144.160.20.47 ws.linuxlighthouse.com. 172800 IN A 108.220.213.121
Attempting to poke either IP address comes back with REFUSED.
Your DNS service is not working.
On Thu, 2021-04-15 at 11:00 -0700, Jack Craig wrote:
so my bind config has apparently not worked despite my dig'ing.
an external config checker says it finds no valid IP' for linuxlighthouse.com, i am failing http challenge.
The DNS records need to be fixed before all else. They need to be held on a public DNS server that propagates them to the other DNS servers. Holding them on an isolated server won't do you any good, and referencing that isolated server within the unavailable record is compounding the problem.
When I registered my domain name the records were published in the registrant's DNS servers. While I may set the IPs that are pointing to my domain name to find my website, and the MX ones for my mail server, I leave the nameserver (NS) records pointing to the registrant's DNS servers.
This is the usual way of doing things.
Later on, after changing hosting provider, I transferred the DNS records to *their* domain servers, too. Again, my www and MX records point to *my* hosting servers, and the NS records point to the *hosts* DNS servers.
Usually, the hard work is done for you. When setting up the website, their system gets you to tell you what name server holds the records, and their system programs their name server with the data it needs to hold. Sometimes they screw up, and you have to contact your host and get them to manually fix things. I've had to do that a few times.
DNS records are like a family tree, they're researched to find your records, all the records have to be held on public servers. Boiling this down to a simplistic example - if I want to browse a site like www.example.com, my system tries to find the IP for it, if it doesn't already know the answer (*). The approach is to ask the .com root DNS server *which* DNS server holds records for example.com, then query that DNS server for the IP for www.example.com.
* If, at some stage, your system has looked up a DNS record, it will cache it for a while (an so can intermediate DNS servers and caching proxies). If the records change, such as you experimenting, there's a propagation delay before the changes are noticed elsewhere. This can be confusing for debugging.
If your plan is for you to run your webserver on your own computer and for people to connect to it, you have to find out if that's actually possible with your ISP. Many will forbid it, or their network structure makes it nearly impossible. And you'll need to be able to handle all the attacks you'll be under. There probably isn't a website on the planet that someone isn't trying to exploit.
But you'll need to get your DNS records sorted before you can worry about trying to get SSL to work, and they'll need to be hosted outside of your computer.
On Thu, Apr 15, 2021 at 6:38 PM Tim via users users@lists.fedoraproject.org wrote:
On Thu, 2021-04-15 at 11:00 -0700, Jack Craig wrote:
so my bind config has apparently not worked despite my dig'ing.
an external config checker says it finds no valid IP' for linuxlighthouse.com, i am failing http challenge.
The DNS records need to be fixed before all else. They need to be held on a public DNS server that propagates them to the other DNS servers. Holding them on an isolated server won't do you any good, and referencing that isolated server within the unavailable record is compounding the problem.
First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through.
Second this used to work. I get my static IP from AT&T in a block of actually eight addresses only the first of which do they agree to pass through so I have been using DNS via name HTTP HTTPS for some time and only since I've upgraded to fedora 30 to have I had this dns battle .
In times past I have managed the system and I thought I had a good handle on it but now clearly I am the problem so I'm gonna have to back up and take another run at it because something is not adding up.
When I registered my domain name the records were published in the
registrant's DNS servers. While I may set the IPs that are pointing to my domain name to find my website, and the MX ones for my mail server, I leave the nameserver (NS) records pointing to the registrant's DNS servers.
Networksolutions is my registrar, they provide to the world my domain name my primary and secondary DNS servers so I guess that's the external place where you were referring to?
So AT&T provides the internet road, networksolutions provides the signage along the road to my place .
isn't it the way it supposed to work?
This is the usual way of doing things.
Later on, after changing hosting provider, I transferred the DNS records to *their* domain servers, too. Again, my www and MX records point to *my* hosting servers, and the NS records point to the *hosts* DNS servers.
Usually, the hard work is done for you. When setting up the website, their system gets you to tell you what name server holds the records, and their system programs their name server with the data it needs to hold. Sometimes they screw up, and you have to contact your host and get them to manually fix things. I've had to do that a few times.
DNS records are like a family tree, they're researched to find your records, all the records have to be held on public servers. Boiling this down to a simplistic example - if I want to browse a site like www.example.com, my system tries to find the IP for it, if it doesn't already know the answer (*). The approach is to ask the .com root DNS server *which* DNS server holds records for example.com, then query that DNS server for the IP for www.example.com.
- If, at some stage, your system has looked up a DNS record, it will
cache it for a while (an so can intermediate DNS servers and caching proxies). If the records change, such as you experimenting, there's a propagation delay before the changes are noticed elsewhere. This can be confusing for debugging.
If your plan is for you to run your webserver on your own computer and for people to connect to it, you have to find out if that's actually possible with your ISP. Many will forbid it, or their network structure makes it nearly impossible. And you'll need to be able to handle all the attacks you'll be under. There probably isn't a website on the planet that someone isn't trying to exploit.
I was hoping that wireguard would provide that kind of coverage via vpn.. I have two routers in my access path the first one is the AT&T router and its firewall is set to forward packets only from ports 53 for 43 and 80 those packets alone are forwarded to my internal server internal router which in turn contacts in my server on my 10.0.0 net
I thought that having two firewalls between me in the world would be a larger advantage but it sounds like what you're saying is that people can penetrate that no matter what. that's depressing.
But you'll need to get your DNS records sorted before you can worry about trying to get SSL to work, and they'll need to be hosted outside of your computer.
My goal was simply to serve files from my server HTTPS to the world that doesn't seem like such a unreasonable goal.
comments?
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Tim:
The DNS records need to be fixed before all else. They need to be held on a public DNS server that propagates them to the other DNS servers.
Jack Craig:
First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through.
Second this used to work. I get my static IP from AT&T in a block of actually eight addresses only the first of which do they agree to pass through so I have been using DNS via name HTTP HTTPS for some time and only since I've upgraded to fedora 30 to have I had this dns battle .
Sounds ok. One test would be to see if an outsider can ping your public IP that's supposed to allow traffic through. Though, that will only work if your system responds to pings. The other test is for someone to try and browse your webserver at your public IP.
Your public IP has to route through to your own server. You will probably have to explain your network topology to us. Which I've seen you do, in general, further below.
But is your public IP in a range of "customer" addresses, or public IPs? If it's within the range allocated to an ISPs clients, other networks around the world will consider your IP to be risky. You'd find doing mail a problem, at least.
Networksolutions is my registrar, they provide to the world my domain name my primary and secondary DNS servers so I guess that's the external place where you were referring to?
Yes.
So AT&T provides the internet road, networksolutions provides the signage along the road to my place .
isn't it the way it supposed to work?
Yes.
By the look of things you need to reconfigure your DNS records. Point the A record for your domain, and the www. subdomain at your webserver's IP. Point your MX record at whoever handles mail to your domain name. Point the NS record at the name servers for your domain.
If your plan is for you to run your webserver on your own computer and for people to connect to it, you have to find out if that's actually possible with your ISP. Many will forbid it, or their network structure makes it nearly impossible. And you'll need to be able to handle all the attacks you'll be under. There probably isn't a website on the planet that someone isn't trying to exploit.
I was hoping that wireguard would provide that kind of coverage via vpn.. I have two routers in my access path the first one is the AT&T router and its firewall is set to forward packets only from ports 53 for 43 and 80 those packets alone are forwarded to my internal server internal router which in turn contacts in my server on my 10.0.0 net
If you're also doing HTTPS, there will need to be port "443" passed through, too. I'm guessing "43" was a typo. Both routers and your computer will have to allow through the ports. I see no point in trying to be your own DNS server, though.
HTTPS *could* be a curly one to solve in your situation. Certificates can tied to an IP address. While an outsider will be connecting to your public IP forwarded through, your webserver will be using its local IP, and the cert wouldn't match. *If* the cert has to match your public IP, you'd need to set your computer's IP to be your public one.
But that may not be the case with you. Solve the DNS problem first.
I thought that having two firewalls between me in the world would be a larger advantage but it sounds like what you're saying is that people can penetrate that no matter what. that's depressing.
While firewalls can prevent unwanted connections through a network, they don't protect you from things that are done through the allowed connections. Your webserver will have to be able to handle people trying to exploit it.
On my public website, the error logs are full of people trying to connect to known exploits in wordpress and various other software suites that people run on webservers. I don't run those things, so they just get errors.
You'll also need to be able to handle the legitimate traffic. You'll have multiple crawlers from search engines, including many you've never heard of, as well as actual people browsing it.
That's why I don't run my public website on my own system.
On 16/04/2021 10:35, Jack Craig wrote:
First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through.
BTW, if you are hosting the DNS server and if your DNS server has the IP address of 108.220.213.121 then this could be a problem.
Running nmap against that IP
PORT STATE SERVICE VERSION 53/udp closed domain 53/tcp closed domain
On Thu, Apr 15, 2021, at 11:00 AM, Jack Craig wrote:
hi list,
so my bind config has apparently not worked despite my dig'ing.
an external config checker says it finds no valid IP' for linuxlighthouse.com, i am failing http challenge.
Others have given good answers, but let me show you how I parse it...
whois linuxlighthouse.com | grep ^Name
Name Server: WS.LINUXLIGHTHOUSE.COM Name Server: NS3.ATTDNS.COM
First one is not useful since it lives inside the domain. See: https://ns1.com/blog/glue-records-and-dedicated-dns
So I check the other one:
dig @NS3.ATTDNS.COM linuxlighthouse.com any
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @NS3.ATTDNS.COM linuxlighthouse.com any ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 19251 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;linuxlighthouse.com. IN ANY
;; Query time: 110 msec ;; SERVER: 2001:1890:1c00:5323::c:3#53(2001:1890:1c00:5323::c:3) ;; WHEN: Fri Apr 16 07:59:10 PDT 2021 ;; MSG SIZE rcvd: 48
Note the part "WARNING: recursion requested but not available", so it is saying that it is not authoritative for that domain.
So I check to see that it is the auth for its own domain:
dig @NS3.ATTDNS.COM ATTDNS.COM any
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @NS3.ATTDNS.COM ATTDNS.COM any ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62918 ;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 9 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ATTDNS.COM. IN ANY
;; ANSWER SECTION: ATTDNS.COM. 28800 IN SOA ns0.ATTDNS.COM. eiss-dns.att.COM. 2021033001 3600 1800 2592000 300 ATTDNS.COM. 28800 IN NS ns1.ATTDNS.COM. ATTDNS.COM. 28800 IN NS ns3.ATTDNS.COM. ATTDNS.COM. 28800 IN NS ns4.ATTDNS.COM. ATTDNS.COM. 28800 IN NS ns2.ATTDNS.COM. ATTDNS.COM. 600 IN MX 10 mx0b-00191d01.pphosted.COM. ATTDNS.COM. 600 IN MX 10 mx0a-00191d01.pphosted.COM.
;; ADDITIONAL SECTION: ns1.ATTDNS.COM. 28800 IN AAAA 2001:1890:1286:320::c:2 ns2.ATTDNS.COM. 28800 IN AAAA 2001:1890:1c00:3320::c:3 ns3.ATTDNS.COM. 28800 IN AAAA 2001:1890:1c00:5323::c:3 ns4.ATTDNS.COM. 28800 IN AAAA 2001:1890:1c00:6320::c:6 ns1.ATTDNS.COM. 28800 IN A 144.160.112.22 ns2.ATTDNS.COM. 28800 IN A 144.160.128.140 ns3.ATTDNS.COM. 28800 IN A 144.160.20.47 ns4.ATTDNS.COM. 28800 IN A 144.160.229.11
;; Query time: 97 msec ;; SERVER: 2001:1890:1c00:5323::c:3#53(2001:1890:1c00:5323::c:3) ;; WHEN: Fri Apr 16 08:00:15 PDT 2021 ;; MSG SIZE rcvd: 409
Yup, good there. So you have two name servers listed. We need that glue record to figure out where one is and the other claims to not know who you are.
On 16/04/2021 17:19, Ed Greshko wrote:
On 16/04/2021 10:35, Jack Craig wrote:
First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through.
BTW, if you are hosting the DNS server and if your DNS server has the IP address of 108.220.213.121 then this could be a problem.
Running nmap against that IP
PORT STATE SERVICE VERSION 53/udp closed domain 53/tcp closed domain
You should also check the output from here.....
https://intodns.com/linuxlighthouse.com
ok, now we are getting somewhere!
So of the two servers that are listed the primary one, mine, does not respond
the secondary from AT&T is not responsive
finally as you'll see below pinging t
Internal DNS is being returned as the external DNS number, that's a third thing I need to fix up.
So I need to find out what's the correct AT&T DNS reference that I should be using and second I need to fix my own DNS so that I return the external not the internal IP
Retest with improved DNS parsing method, thx again..
ping -c 3 108.220.213.121 PING 108.220.213.121 (108.220.213.121) 56(84) bytes of data. 64 bytes from 108.220.213.121: icmp_seq=1 ttl=64 time=1.51 ms 64 bytes from 108.220.213.121: icmp_seq=2 ttl=64 time=0.850 ms 64 bytes from 108.220.213.121: icmp_seq=3 ttl=64 time=1.35 ms
--- 108.220.213.121 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.850/1.236/1.513/0.281 ms [jackc@ws ~ $ ping -c 3 ns3.attdns.com PING ns3.attdns.com (144.160.20.47) 56(84) bytes of data.
--- ns3.attdns.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2038ms
*[jackc@ws ~ $ ping -c 3 ws.linuxlighthouse.com http://ws.linuxlighthouse.comPING ws (10.0.0.101) 56(84) bytes of data.64 bytes from ws (10.0.0.101): icmp_seq=1 ttl=64 time=0.083 ms64 bytes from ws (10.0.0.101): icmp_seq=2 ttl=64 time=0.062 ms64 bytes from ws (10.0.0.101): icmp_seq=3 ttl=64 time=0.067 ms*
*wrong!! let me clean these up and see how far that gets me *
*thanks again for all your help *
*I am getting there slow but sure*
--- ws ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2038ms rtt min/avg/max/mdev = 0.062/0.070/0.083/0.009 ms
On Fri, Apr 16, 2021 at 8:25 AM Doug H. fedoraproject.org@wombatz.com wrote:
On Thu, Apr 15, 2021, at 11:00 AM, Jack Craig wrote:
hi list,
so my bind config has apparently not worked despite my dig'ing.
an external config checker says it finds no valid IP' for linuxlighthouse.com, i am failing http challenge.
Others have given good answers, but let me show you how I parse it...
whois linuxlighthouse.com | grep ^Name
Name Server: WS.LINUXLIGHTHOUSE.COM Name Server: NS3.ATTDNS.COM
First one is not useful since it lives inside the domain. See: https://ns1.com/blog/glue-records-and-dedicated-dns
So I check the other one:
dig @NS3.ATTDNS.COM linuxlighthouse.com any
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @NS3.ATTDNS.COM linuxlighthouse.com any ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 19251 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;linuxlighthouse.com. IN ANY
;; Query time: 110 msec ;; SERVER: 2001:1890:1c00:5323::c:3#53(2001:1890:1c00:5323::c:3) ;; WHEN: Fri Apr 16 07:59:10 PDT 2021 ;; MSG SIZE rcvd: 48
Note the part "WARNING: recursion requested but not available", so it is saying that it is not authoritative for that domain.
So I check to see that it is the auth for its own domain:
dig @NS3.ATTDNS.COM ATTDNS.COM any
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @NS3.ATTDNS.COM ATTDNS.COM any ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62918 ;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 9 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ATTDNS.COM. IN ANY
;; ANSWER SECTION: ATTDNS.COM. 28800 IN SOA ns0.ATTDNS.COM. eiss-dns.att.COM. 2021033001 3600 1800 2592000 300 ATTDNS.COM. 28800 IN NS ns1.ATTDNS.COM. ATTDNS.COM. 28800 IN NS ns3.ATTDNS.COM. ATTDNS.COM. 28800 IN NS ns4.ATTDNS.COM. ATTDNS.COM. 28800 IN NS ns2.ATTDNS.COM. ATTDNS.COM. 600 IN MX 10 mx0b-00191d01.pphosted.COM. ATTDNS.COM. 600 IN MX 10 mx0a-00191d01.pphosted.COM.
;; ADDITIONAL SECTION: ns1.ATTDNS.COM. 28800 IN AAAA 2001:1890:1286:320::c:2 ns2.ATTDNS.COM. 28800 IN AAAA 2001:1890:1c00:3320::c:3 ns3.ATTDNS.COM. 28800 IN AAAA 2001:1890:1c00:5323::c:3 ns4.ATTDNS.COM. 28800 IN AAAA 2001:1890:1c00:6320::c:6 ns1.ATTDNS.COM. 28800 IN A 144.160.112.22 ns2.ATTDNS.COM. 28800 IN A 144.160.128.140 ns3.ATTDNS.COM. 28800 IN A 144.160.20.47 ns4.ATTDNS.COM. 28800 IN A 144.160.229.11
;; Query time: 97 msec ;; SERVER: 2001:1890:1c00:5323::c:3#53(2001:1890:1c00:5323::c:3) ;; WHEN: Fri Apr 16 08:00:15 PDT 2021 ;; MSG SIZE rcvd: 409
Yup, good there. So you have two name servers listed. We need that glue record to figure out where one is and the other claims to not know who you are.
-- Doug Herr fedoraproject.org@wombatz.com _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote:
On 16/04/2021 17:19, Ed Greshko wrote:
On 16/04/2021 10:35, Jack Craig wrote:
First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through.
BTW, if you are hosting the DNS server and if your DNS server has the IP address of 108.220.213.121 then this could be a problem.
Running nmap against that IP
PORT STATE SERVICE VERSION 53/udp closed domain 53/tcp closed domain
You should also check the output from here.....
Nice. That shows that the "glue" record *is* there after all. The results from that site got me to realize that this will give the IP:
dig @b.gtld-servers.net ws.linuxlighthouse.com
[snip] ;; ADDITIONAL SECTION: ns3.attdns.com. 172800 IN A 144.160.20.47 ws.linuxlighthouse.com. 172800 IN A 108.220.213.121 [snip]
On 17/04/2021 02:12, Jack Craig wrote:
[jackc@ws ~ $ ping -c 3 ws.linuxlighthouse.com http://ws.linuxlighthouse.com PING ws (10.0.0.101) 56(84) bytes of data. 64 bytes from ws (10.0.0.101): icmp_seq=1 ttl=64 time=0.083 ms 64 bytes from ws (10.0.0.101): icmp_seq=2 ttl=64 time=0.062 ms 64 bytes from ws (10.0.0.101): icmp_seq=3 ttl=64 time=0.067 ms*
*wrong!! let me clean these up and see how far that gets me
*thanks again for all your help
*I am getting there slow but sure*
Why is that "wrong"? I thought ws.linuxlighthouse.com had an internal ip adderss of 10.0.0.101 and an external one of 108.220.213.121. You bash prompt appears to be on that host. So, you are "internal".
Much meimei below which is internal to my network.
[egreshko@meimei ~]$ host meimei meimei.greshko.com has address 192.168.1.18 meimei.greshko.com has IPv6 address 2001:b030:112f::140e
[egreshko@meimei ~]$ ping -4 meimei PING (192.168.1.18) 56(84) bytes of data. 64 bytes from meimei.greshko.com (192.168.1.18): icmp_seq=1 ttl=64 time=0.063 ms 64 bytes from meimei.greshko.com (192.168.1.18): icmp_seq=2 ttl=64 time=0.086 ms 64 bytes from meimei.greshko.com (192.168.1.18): icmp_seq=3 ttl=64 time=0.056 ms
But, when viewed from outside of my network.
[egreshko@acer ~]$ host meimei meimei.greshko.com has address 211.75.128.214 meimei.greshko.com has IPv6 address 2001:b030:112f::140e
[egreshko@acer ~]$ ping -4 meimei PING (211.75.128.214) 56(84) bytes of data. 64 bytes from 211-75-128-214.HINET-IP.hinet.net (211.75.128.214): icmp_seq=1 ttl=64 time=0.575 ms 64 bytes from 211-75-128-214.HINET-IP.hinet.net (211.75.128.214): icmp_seq=2 ttl=64 time=0.598 ms 64 bytes from 211-75-128-214.HINET-IP.hinet.net (211.75.128.214): icmp_seq=3 ttl=64 time=0.477 ms
On 17/04/2021 03:51, Doug H. wrote:
Nice. That shows that the "glue" record*is* there after all. The results from that site got me to realize that this will give the IP:
dig @b.gtld-servers.net ws.linuxlighthouse.com
[snip] ;; ADDITIONAL SECTION: ns3.attdns.com. 172800 IN A 144.160.20.47 ws.linuxlighthouse.com. 172800 IN A 108.220.213.121
Yet, no matter what he does, if his NameServer is 108.220.213.121 then having this
PORT STATE SERVICE VERSION 53/udp closed domain 53/tcp closed domain
is still a problem.
On Fri, Apr 16, 2021 at 12:52 PM Doug H. fedoraproject.org@wombatz.com wrote:
On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote:
On 16/04/2021 17:19, Ed Greshko wrote:
On 16/04/2021 10:35, Jack Craig wrote:
First I get my static IP from AT&T actually a block of eight
addresses of which only the first do they agree to pass through.
BTW, if you are hosting the DNS server and if your DNS server has the
IP address of 108.220.213.121 then
this could be a problem.
*would you expand on this comment? i think this is an issue,... thx..*
*i seem to have NS access problems, but much is working *
[snip] ;; ADDITIONAL SECTION: ns3.attdns.com. 172800 IN A 144.160.20.47 ws.linuxlighthouse.com. 172800 IN A 108.220.213.121 [snip]
On 19/04/2021 03:18, Jack Craig wrote:
On Fri, Apr 16, 2021 at 12:52 PM Doug H. <fedoraproject.org@wombatz.com mailto:fedoraproject.org@wombatz.com> wrote:
On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > On 16/04/2021 17:19, Ed Greshko wrote: > > On 16/04/2021 10:35, Jack Craig wrote: > >> First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through. > >> > > > > BTW, if you are hosting the DNS server and if your DNS server has the IP address of 108.220.213.121 then > > this could be a problem.
*would you expand on this comment? i think this is an issue,... thx..*
You removed the most important part of my comment. Which was....
PORT STATE SERVICE VERSION 53/udp closed domain 53/tcp closed domain
This mean you don't have a DNS server (bind, I assume) listening on the standard port 53 on the 108.220.213.121 interface. That means that no system outside of your internals (10.0.0.x) can query your DNS server.
If I "telnet" to port 53 (tcp) to my ISP's name server...
[egreshko@meimei ~]$ telnet 168.95.1.1 53 Trying 168.95.1.1... Connected to 168.95.1.1. Escape character is '^]'. ^] telnet> close Connection closed.
Yours?
[egreshko@meimei ~]$ telnet 108.220.213.121 53 Trying 108.220.213.121... telnet: connect to address 108.220.213.121: Connection refused
Also note, that if I run "nmap -A -T4 -p53 168.95.1.1 53" I get
PORT STATE SERVICE VERSION 53/tcp open domain (generic dns response: NOTIMP) | fingerprint-strings: | DNSVersionBindReqTCP: | version |_ bind
Or if I run "nmap -A -T4 -p53 -sU 168.95.1.1" a UDP scan
PORT STATE SERVICE VERSION 53/udp open domain (generic dns response: NOTIMP) |_dns-recursion: Recursion appears to be enabled | fingerprint-strings: | DNSVersionBindReq: | version | bind | NBTStat: | CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA |_ root-servers
These nmap command need to be run from the outside. I think there are websites which allow you to run nmap against your own systems.
On 19/04/2021 03:18, Jack Craig wrote:
On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > On 16/04/2021 17:19, Ed Greshko wrote: > > On 16/04/2021 10:35, Jack Craig wrote: > >> First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through. > >> > > > > BTW, if you are hosting the DNS server and if your DNS server has the IP address of 108.220.213.121 then > > this could be a problem.
*would you expand on this comment? i think this is an issue,... thx..*
I should have mentioned you should check your named.conf. By default it contains
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; };
meaning it only is listening on the loopback interface.
On Mon, Apr 19, 2021 at 3:11 PM Ed Greshko ed.greshko@greshko.com wrote:
On 19/04/2021 03:18, Jack Craig wrote:
On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > On 16/04/2021 17:19, Ed Greshko wrote: > > On 16/04/2021 10:35, Jack Craig wrote: > >> First I get my static IP from AT&T actually a block of eightaddresses of which only the first do they agree to pass through.
> >> > > > > BTW, if you are hosting the DNS server and if your DNS serverhas the IP address of 108.220.213.121 then
> > this could be a problem.
*would you expand on this comment? i think this is an issue,... thx..*
I should have mentioned you should check your named.conf. By default it contains
options { listen-on port 53 { 127.0.0.1; };
i had listen to localhost & external ip, trimmed to just localhost
listen-on-v6 port 53 { ::1; };
meaning it only is listening on the loopback interface.
i have uncovered some ns info issues with my ip provider, att, dns config issues... working them out; you guys are a god-and tho! ;) thx!!!
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 20/04/2021 07:31, Jack Craig wrote:
On Mon, Apr 19, 2021 at 3:11 PM Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
On 19/04/2021 03:18, Jack Craig wrote: > > On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > > On 16/04/2021 17:19, Ed Greshko wrote: > > > On 16/04/2021 10:35, Jack Craig wrote: > > >> First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through. > > >> > > > > > > BTW, if you are hosting the DNS server and if your DNS server has the IP address of 108.220.213.121 then > > > this could be a problem. > > * > * > *would you expand on this comment? i think this is an issue,... thx..* I should have mentioned you should check your named.conf. By default it contains options { listen-on port 53 { 127.0.0.1; };i had listen to localhost & external ip, trimmed to just localhost
listen-on-v6 port 53 { ::1; }; meaning it only is listening on the loopback interface.i have uncovered some ns info issues with my ip provider, att, dns config issues... working them out; you guys are a god-and tho! ;) thx!!!
Maybe you're not yet up and running, but FWIW, port 53 continues to show as closed for both TCP and UDP at 108.220.213.121.
Also, FWIW, I just installed bind on a F33 test VM and changed named.conf to contain
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { 2001:b030:112f:2::53; ::1; };
The VM is accessible via IPv6 but not IPv4. And then running nmap from an external system.
PORT STATE SERVICE VERSION 53/tcp open domain (generic dns response: NOTIMP) | fingerprint-strings: | DNSVersionBindReqTCP: | version |_ bind
On Mon, Apr 19, 2021 at 5:27 PM Ed Greshko ed.greshko@greshko.com wrote:
On 20/04/2021 07:31, Jack Craig wrote:
On Mon, Apr 19, 2021 at 3:11 PM Ed Greshko <ed.greshko@greshko.com
mailto:ed.greshko@greshko.com> wrote:
On 19/04/2021 03:18, Jack Craig wrote: > > On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > > On 16/04/2021 17:19, Ed Greshko wrote: > > > On 16/04/2021 10:35, Jack Craig wrote: > > >> First I get my static IP from AT&T actually a block ofeight addresses of which only the first do they agree to pass through.
> > >> > > > > > > BTW, if you are hosting the DNS server and if your DNSserver has the IP address of 108.220.213.121 then
> > > this could be a problem. > > * > * > *would you expand on this comment? i think this is an issue,...thx..*
I should have mentioned you should check your named.conf. By defaultit contains
options { listen-on port 53 { 127.0.0.1; };
I had the external IP number listed here as well and was listening on both localhost and public IP so I've changed the content to be as you've indicated here listening only on local host
i had listen to localhost & external ip, trimmed to just localhost
listen-on-v6 port 53 { ::1; };
I had this turned off but I might as well get it up and running now as the IP4 stuff starting to come together
ultimately we want to have both covered
meaning it only is listening on the loopback interface.i have uncovered some ns info issues with my ip provider, att, dns
config issues...
working them out; you guys are a god-and tho! ;) thx!!!
Maybe you're not yet up and running, but FWIW, port 53 continues to show as closed for both TCP and UDP at 108.220.213.121.
*curious, may i ask how you reach that observation?* *i see, ...*
*netstat -tapnl | grep namedtcp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* LISTEN 1088294/named tcp 0 0 127.0.0.1:953 http://127.0.0.1:953 0.0.0.0:* LISTEN 1088294/named *
Also, FWIW, I just installed bind on a F33 test VM and changed named.conf to contain
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { 2001:b030:112f:2::53; ::1; };
The VM is accessible via IPv6 but not IPv4. And then running nmap from an external system.
PORT STATE SERVICE VERSION 53/tcp open domain (generic dns response: NOTIMP) | fingerprint-strings: | DNSVersionBindReqTCP: | version |_ bind
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
on the other hand, ... ;O
nmap -sS 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-19 18:26 PDT Nmap scan report for ws (108.220.213.121) Host is up (0.0014s latency). Not shown: 994 closed ports PORT STATE SERVICE 80/tcp open http 443/tcp open https 631/tcp open ipp 5000/tcp open upnp 8200/tcp open trivnet1 20005/tcp open btx
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
On Mon, Apr 19, 2021 at 5:27 PM Ed Greshko ed.greshko@greshko.com wrote:
On 20/04/2021 07:31, Jack Craig wrote:
On Mon, Apr 19, 2021 at 3:11 PM Ed Greshko <ed.greshko@greshko.com
mailto:ed.greshko@greshko.com> wrote:
On 19/04/2021 03:18, Jack Craig wrote: > > On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > > On 16/04/2021 17:19, Ed Greshko wrote: > > > On 16/04/2021 10:35, Jack Craig wrote: > > >> First I get my static IP from AT&T actually a block ofeight addresses of which only the first do they agree to pass through.
> > >> > > > > > > BTW, if you are hosting the DNS server and if your DNSserver has the IP address of 108.220.213.121 then
> > > this could be a problem. > > * > * > *would you expand on this comment? i think this is an issue,...thx..*
I should have mentioned you should check your named.conf. By defaultit contains
options { listen-on port 53 { 127.0.0.1; };i had listen to localhost & external ip, trimmed to just localhost
listen-on-v6 port 53 { ::1; }; meaning it only is listening on the loopback interface.i have uncovered some ns info issues with my ip provider, att, dns
config issues...
working them out; you guys are a god-and tho! ;) thx!!!
Maybe you're not yet up and running, but FWIW, port 53 continues to show as closed for both TCP and UDP at 108.220.213.121.
Also, FWIW, I just installed bind on a F33 test VM and changed named.conf to contain
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { 2001:b030:112f:2::53; ::1; };
The VM is accessible via IPv6 but not IPv4. And then running nmap from an external system.
PORT STATE SERVICE VERSION 53/tcp open domain (generic dns response: NOTIMP) | fingerprint-strings: | DNSVersionBindReqTCP: | version |_ bind
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 20/04/2021 09:25, Jack Craig wrote:
On Mon, Apr 19, 2021 at 5:27 PM Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
On 20/04/2021 07:31, Jack Craig wrote: > > > On Mon, Apr 19, 2021 at 3:11 PM Ed Greshko <ed.greshko@greshko.com <mailto:ed.greshko@greshko.com> <mailto:ed.greshko@greshko.com <mailto:ed.greshko@greshko.com>>> wrote: > > On 19/04/2021 03:18, Jack Craig wrote: > > > > On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > > > On 16/04/2021 17:19, Ed Greshko wrote: > > > > On 16/04/2021 10:35, Jack Craig wrote: > > > >> First I get my static IP from AT&T actually a block of eight addresses of which only the first do they agree to pass through. > > > >> > > > > > > > > BTW, if you are hosting the DNS server and if your DNS server has the IP address of 108.220.213.121 then > > > > this could be a problem. > > > > * > > * > > *would you expand on this comment? i think this is an issue,... thx..* > > I should have mentioned you should check your named.conf. By default it contains > > options { > listen-on port 53 { 127.0.0.1; };I had the external IP number listed here as well and was listening on both localhost and public IP so I've changed the content to be as you've indicated here listening only on local host
?????? Why would you want to listen only on localhost? I never indicated that that would be a go idea. I said it was the "default".
I think you'd be best served having
listen-on port 53 { 127.0.0.1; 10.0.0.1; 108.220.213.121; };
Here I am assuming your "internal" IP address is 10.0.0.1.
> > > i had listen to localhost & external ip, trimmed to just localhost > > listen-on-v6 port 53 { ::1; };I had this turned off but I might as well get it up and running now as the IP4 stuff starting to come together
ultimately we want to have both covered
Well, you only have to be concerned with IPv6 if you've been assigned IPv6 addresses.
> > meaning it only is listening on the loopback interface. > > > i have uncovered some ns info issues with my ip provider, att, dns config issues... > working them out; you guys are a god-and tho! ;) thx!!! > Maybe you're not yet up and running, but FWIW, port 53 continues to show as closed for both TCP and UDP at 108.220.213.121.*curious, may i ask how you reach that observation?* *i see, ...*
*netstat -tapnl | grep named tcp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* LISTEN 1088294/named tcp 0 0 127.0.0.1:953 http://127.0.0.1:953 0.0.0.0:* LISTEN 1088294/named *
That indicates named/bind is *ONLY* listening on the loopback/localhost IP address!!
That will result in a "closed" status for the port from External systems.
I run.....
nmap -A -T4 -p53 108.220.213.121 and/or nmap -A -T4 -sU -p53 108.220.213.121
from here....a system *external* to you.
I've bold-ed another important part of *my* configuration that *doesn't *apply to yours, below.
Also, FWIW, I just installed bind on a F33 test VM and changed named.conf to contain options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { 2001:b030:112f:2::53; ::1; }; *The VM is accessible via IPv6 but not IPv4.* And then running nmap from an external system. PORT STATE SERVICE VERSION 53/tcp open domain (generic dns response: NOTIMP) | fingerprint-strings: | DNSVersionBindReqTCP: | version |_ bind
On 20/04/2021 09:27, Jack Craig wrote:
on the other hand, ... ;O
nmap -sS 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org https://nmap.org ) at 2021-04-19 18:26 PDT Nmap scan report for ws (108.220.213.121) Host is up (0.0014s latency). Not shown: 994 closed ports PORT STATE SERVICE 80/tcp open http 443/tcp open https 631/tcp open ipp 5000/tcp open upnp 8200/tcp open trivnet1 20005/tcp open btx
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
So, port 53 is shown as closed since you don't have that in your list of IP to listen on.
Sorry it's been a long day on the phone with AT&T only to find out I got nowhere yeah I'm tired I made a few mistakes today my apologies
thanks for your corrections now that's what's really important is what's the right thing to do so again thanks for your help
On Mon, Apr 19, 2021 at 6:57 PM Ed Greshko ed.greshko@greshko.com wrote:
On 20/04/2021 09:27, Jack Craig wrote:
on the other hand, ... ;O
nmap -sS 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org https://nmap.org ) at
2021-04-19 18:26 PDT
Nmap scan report for ws (108.220.213.121) Host is up (0.0014s latency). Not shown: 994 closed ports PORT STATE SERVICE 80/tcp open http 443/tcp open https 631/tcp open ipp 5000/tcp open upnp 8200/tcp open trivnet1 20005/tcp open btx
Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
So, port 53 is shown as closed since you don't have that in your list of IP to listen on.
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 20/04/2021 10:02, Jack Craig wrote:
Sorry it's been a long day on the phone with AT&T only to find out I got nowhere yeah I'm tired I made a few mistakes today my apologies
OK.
Well let us know when you think you have thinks working. I see you've not yet configured it at 12:50GMT+8.
[root@meimei ~]# nmap -sS -sU 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-20 12:48 CST Nmap scan report for ws.linuxlighthouse.com (108.220.213.121) Host is up (0.17s latency). Not shown: 997 filtered ports, 997 open|filtered ports PORT STATE SERVICE 53/tcp closed domain 80/tcp open http 443/tcp open https 53/udp closed domain 80/udp closed http 443/udp closed https
Well as of tomorrow morning I will be down to two problems
the first problem is my primary DNS server is not listening / connecting g/conneenin on external IP
the second problem is the secondary IP as identified by AT&T to be my secondary refusing to reply is refusing to provide answers
below I have the various dig results look up come out
<<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> @ws.linuxlighthouse.com linuxlighthouse.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ----------------------------------------------------secondary dns server at ns3.attdns.com
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> @ns3.attdns.com linuxlighthouse.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5707 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;linuxlighthouse.com. IN A
;; Query time: 77 msec ;; SERVER: 144.160.20.47#53(144.160.20.47) ;; WHEN: Mon Apr 19 22:15:55 PDT 2021 ;; MSG SIZE rcvd: 48
----------------------------------------------------linuxlighthouse.com (localhost)
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> @localhost linuxlighthouse.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31545 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: e4d1b15c0873f8deb643f78e607e638c89be685db5022cf2 (good) ;; QUESTION SECTION: ;linuxlighthouse.com. IN A
;; ANSWER SECTION: linuxlighthouse.com. 86400 IN A 108.220.213.121
;; AUTHORITY SECTION: linuxlighthouse.com. 86400 IN NS ws.linuxlighthouse.com.
;; ADDITIONAL SECTION: ws.linuxlighthouse.com. 86400 IN A 108.220.213.121
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Apr 19 22:15:56 PDT 2021 ;; MSG SIZE rcvd: 125
On Mon, Apr 19, 2021 at 9:50 PM Ed Greshko ed.greshko@greshko.com wrote:
On 20/04/2021 10:02, Jack Craig wrote:
Sorry it's been a long day on the phone with AT&T only to find out I got
nowhere
yeah I'm tired I made a few mistakes today my apologies
OK.
Well let us know when you think you have thinks working. I see you've not yet configured it at 12:50GMT+8.
[root@meimei ~]# nmap -sS -sU 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-20 12:48 CST Nmap scan report for ws.linuxlighthouse.com (108.220.213.121) Host is up (0.17s latency). Not shown: 997 filtered ports, 997 open|filtered ports PORT STATE SERVICE 53/tcp closed domain 80/tcp open http 443/tcp open https 53/udp closed domain 80/udp closed http 443/udp closed https
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 20/04/2021 13:32, Jack Craig wrote:
Well as of tomorrow morning I will be down to two problems
the first problem is my primary DNS server is not listening / connecting g/conneenin on external IP
As port 53 is still closed you may want to post your named.conf
On 20/04/2021 13:32, Jack Craig wrote:
the second problem is the secondary IP as identified by AT&T to be my secondary refusing to reply is refusing to provide answers
BTW, this may have been answered but I can't find it in the 2 threads.
Who is your registrar?
attached named.conf
registrar = network solutions where they reference => ns3.attdns.com & ws.llinuxlighthouse.com
On Tue, Apr 20, 2021 at 12:02 AM Ed Greshko ed.greshko@greshko.com wrote:
On 20/04/2021 13:32, Jack Craig wrote:
the second problem is the secondary IP as identified by AT&T to be my
secondary refusing to
reply is refusing to provide answers
BTW, this may have been answered but I can't find it in the 2 threads.
Who is your registrar?
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 20/04/2021 18:09, Jack Craig wrote:
attached named.conf
Well a quick look and it doesn't seem too bad. First a couple of questions.
1. Why did you use "acl" statements and then not refer to them?
2. Did you mean this?
/* allow-recursion { 10.0.0.0/24; }; allow-recursion { any; }; */
Resulting in that being ignored.
Could you modify the listen lines to....
// listen-on port 53 { 127.0.0.1; 10.0.0.1; 108.220.213.121; }; // listen-on-v6 port 53 { any; };
This means "any" for both
Then stop/start the service and do
netstat -nap | grep named
registrar = network solutions where they reference => ns3.attdns.com http://ns3.attdns.com & ws.llinuxlighthouse.com http://ws.llinuxlighthouse.com
On Tue, 2021-04-20 at 03:09 -0700, Jack Craig wrote:
attached named.conf
It has the following lines in it:
listen-on port 53 { 127.0.0.1; 10.0.0.1; 108.220.213.121; }; allow-query { localhost; 10.0.0.1; 108.220.213.121; };
Does your computer actually recognise one of its WAN ports as being that IP?
Changing those lines to listen and allow from "any" might make a difference if your computer hasn't assigned 108.220.213.121 to one of its interfaces. At this time, since you're behind two routers, your DNS server shouldn't be facing unwanted connections from anywhere else to worry about.
The listen-on clause would be the interfaces it listens on, so your computer's network has to have a port with that IP address.
I'm not sure if the allow-query is the same. Whether it's allowing queries coming in through that address, or allowing queries from that address (i.e. the remote end making the query) and the remote end is whatever *their* address is.
At the end you have:
view "wan-view" { zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-update { none; }; };
and so on...
But the supplied named.conf hasn't defined a "wan-view" acl, you've only done "internals" and "slaves".
registrar = network solutions where they reference => ns3.attdns.com & ws.llinuxlighthouse.com
I can see reasons to be your own webserver (e.g. not having to pay more for someone else to do it, you can configure your server any that way you like, etc). But when you register a domain name, you're already paying for someone to host your DNS records, and you don't have to do anything extra.
On 20/04/2021 20:47, Tim via users wrote:
I can see reasons to be your own webserver (e.g. not having to pay more for someone else to do it, you can configure your server any that way you like, etc). But when you register a domain name, you're already paying for someone to host your DNS records, and you don't have to do anything extra.
Yes, that is the question that I forgot to ask.
While I use a different registrar they have great tools to maintain your domain. I can't imagine Network Solutions being any different.
Not only are all the tools there to make it easy to maintain one's domain you're running on their servers and should someone decide they don't like you it won't be your DNS server being the target of a DoS attack. :-)
I still run a local DNS server, for internal use only, for all my unroutable VM's IPs.
On 20/04/2021 20:47, Tim via users wrote:
I can see reasons to be your own webserver (e.g. not having to pay more for someone else to do it, you can configure your server any that way you like, etc). But when you register a domain name, you're already paying for someone to host your DNS records, and you don't have to do anything extra.
Yes, that is the question that I forgot to ask.
While I use a different registrar they have great tools to maintain your domain. I can't imagine Network Solutions being any different.
Not only are all the tools there to make it easy to maintain one's domain you're running on their servers and should someone decide they don't like you it won't be your DNS server being the target of a DoS attack. :-)
I still run a local DNS server, for internal use only, for all my unroutable VM's IPs.
On Tue, Apr 20, 2021 at 4:30 AM Ed Greshko ed.greshko@greshko.com wrote:
On 20/04/2021 18:09, Jack Craig wrote:
attached named.conf
Well a quick look and it doesn't seem too bad. First a couple of questions.
- Why did you use "acl" statements and then not refer to them?
This file has been the side of a lot of work in progress tons of work not a lot of progress
one of the earlier iterations i thought to use acl's
Did you mean this?
/* allow-recursion { 10.0.0.0/24; }; allow-recursion { any; }; */Resulting in that being ignored.
Same as number one
Could you modify the listen lines to....
// listen-on port 53 { 127.0.0.1; 10.0.0.1; 108.220.213.121; }; // listen-on-v6 port 53 { any; };
This means "any" for both
Then stop/start the service and do
netstat -nap | grep named
before
netstat -nap | grep named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1090819/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 1090819/named udp 0 0 127.0.0.1:53 0.0.0.0:* 1090819/named unix 2 [ ] DGRAM 3212045 1090819/named
unix 2 [ ] STREAM CONNECTED 3212051 1090819/named
after
nap | grep named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1258277/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 1258277/named udp 0 0 127.0.0.1:53 0.0.0.0:* 1258277/named unix 3 [ ] STREAM CONNECTED 3645705 1258277/named
unix 2 [ ] DGRAM 3645697 1258277/named
registrar = network solutions where they reference => ns3.attdns.com http://ns3.attdns.com &
ws.llinuxlighthouse.com http://ws.llinuxlighthouse.com
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Apr 20, 2021 at 6:24 AM Ed Greshko ed.greshko@greshko.com wrote:
On 20/04/2021 20:47, Tim via users wrote:
I can see reasons to be your own webserver (e.g. not having to pay more for someone else to do it, you can configure your server any that way you like, etc). But when you register a domain name, you're already paying for someone to host your DNS records, and you don't have to do anything extra.
Yes, that is the question that I forgot to ask.
While I use a different registrar they have great tools to maintain your domain. I can't imagine Network Solutions being any different.
Not only are all the tools there to make it easy to maintain one's domain you're running on their servers and should someone decide they don't like you it won't be your DNS server being the target of a DoS attack. :-)
The last time I did this for myself was a long time ago back then I don't record as being so difficult to set up and maintain still my motivation in this case was to again just have control over my own world
what's been screwing me up is how things have changed
you're right network solutions does have convenient tools to maintain DNS registration
I still run a local DNS server, for internal use only, for all my unroutable VM's IPs.
Clearly a superior approach ! ;)
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Apr 20, 2021 at 5:47 AM Tim via users users@lists.fedoraproject.org wrote:
On Tue, 2021-04-20 at 03:09 -0700, Jack Craig wrote:
attached named.conf
It has the following lines in it:
listen-on port 53 { 127.0.0.1; 10.0.0.1; 108.220.213.121; }; allow-query { localhost; 10.0.0.1; 108.220.213.121; };
Does your computer actually recognise one of its WAN ports as being that IP?
Apparently not
I can do a telnet connect to IP for port 53 from 10.0.0.1 & localhost
10 .0.0.101 and the external IP do not connect
As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53.
t my external visible interfaces include only these
Changing those lines to listen and allow from "any" might make a difference if your computer hasn't assigned 108.220.213.121 to one of its interfaces. At this time, since you're behind two routers, your DNS server shouldn't be facing unwanted connections from anywhere else to worry about.
The listen-on clause would be the interfaces it listens on, so your computer's network has to have a port with that IP address.
I'm not sure if the allow-query is the same. Whether it's allowing queries coming in through that address, or allowing queries from that address (i.e. the remote end making the query) and the remote end is whatever *their* address is.
At the end you have:
view "wan-view" { zone "linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-update { none; }; };
and so on...
But the supplied named.conf hasn't defined a "wan-view" acl, you've only done "internals" and "slaves".
registrar = network solutions where they reference => ns3.attdns.com & ws.llinuxlighthouse.com
I can see reasons to be your own webserver (e.g. not having to pay more for someone else to do it, you can configure your server any that way you like, etc). But when you register a domain name, you're already paying for someone to host your DNS records, and you don't have to do anything extra.
Given these ACL's not employed and questionable listen commands how should I properly have configured this interface to provide external IP processing for primary dns service?
As you see , my guessing how to configure and make it work from looking at other configurations just isn't cutting it
Time to call in the '*pros from Dover' (obscure movie reference)*
visible interfaces
ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 50:65:f3:4a:ec:e5 brd ff:ff:ff:ff:ff:ff altname enp0s31f6 inet 10.0.0.101/24 brd 10.0.0.255 scope global noprefixroute eno1 valid_lft forever preferred_lft forever inet6 fe80::15ef:5535:377f:e73f/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff
tia,...
--
uname -rsvp Linux 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Apr 8 19:51:47 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 21/04/2021 03:36, Jack Craig wrote:
netstat -nap | grep named
tcp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* LISTEN 1090819/named tcp 0 0 127.0.0.1:953 http://127.0.0.1:953 0.0.0.0:* LISTEN 1090819/named udp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* 1090819/named unix 2 [ ] DGRAM 3212045 1090819/named unix 2 [ ] STREAM CONNECTED 3212051 1090819/named
after
nap | grep named
tcp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* LISTEN 1258277/named tcp 0 0 127.0.0.1:953 http://127.0.0.1:953 0.0.0.0:* LISTEN 1258277/named udp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* 1258277/named unix 3 [ ] STREAM CONNECTED 3645705 1258277/named unix 2 [ ] DGRAM 3645697 1258277/named
Are you using "named.service" or "named-chroot.service" when you use systemctl to start it?
It almost sounds as if you're not using the named.conf you think you're using.
ps -eaf | grep named output?
That being said. You supplied the output of "ip a" in another response. So, with those 2 lines commented out it should be listening on 127.0.0.1, 10.0.0.101, and 192.168.122.1 IPv4 addresses both tcp and udp. And it should be listening on tcp6 and udp6 :::53
Also, in your response to Tim you said......
"As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53 http://10.0.0.101:53."
Oh, so you don't have a"truly" public system. So, 108.220.213.121 is actually the IP address of your router.
On Tue, Apr 20, 2021 at 4:16 PM Ed Greshko ed.greshko@greshko.com wrote:
On 21/04/2021 03:36, Jack Craig wrote:
netstat -nap | grep named
tcp 0 0 127.0.0.1:53 http://127.0.0.1:53
0.0.0.0:* LISTEN 1090819/named
tcp 0 0 127.0.0.1:953 http://127.0.0.1:953
0.0.0.0:* LISTEN 1090819/named
udp 0 0 127.0.0.1:53 http://127.0.0.1:53
0.0.0.0:* 1090819/named
unix 2 [ ] DGRAM 3212045 1090819/named unix 2 [ ] STREAM CONNECTED 3212051 1090819/named
after
nap | grep named
tcp 0 0 127.0.0.1:53 http://127.0.0.1:53
0.0.0.0:* LISTEN 1258277/named
tcp 0 0 127.0.0.1:953 http://127.0.0.1:953
0.0.0.0:* LISTEN 1258277/named
udp 0 0 127.0.0.1:53 http://127.0.0.1:53
0.0.0.0:* 1258277/named
unix 3 [ ] STREAM CONNECTED 3645705 1258277/named unix 2 [ ] DGRAM 3645697 1258277/named
Are you using "named.service" or "named-chroot.service" when you use systemctl to start
named.service
it?
ps -eaf | grep named named 1263562 1 0 13:59 ? 00:00:05 /usr/sbin/named -u named -c /etc/named.conf -4 root 1280487 311233 0 19:09 pts/0 00:00:00 grep --color=auto named
It almost sounds as if you're not using the named.conf you think you're using.
ps -eaf | grep named output?
That being said. You supplied the output of "ip a" in another response. So, with those 2 lines commented out it should be listening on 127.0.0.1, 10.0.0.101, and 192.168.122.1 IPv4 addresses both tcp and udp. And it should be listening on tcp6 and udp6 :::53
Also, in your response to Tim you said......
"As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53 < http://10.0.0.101:53%3E."
what i wanted to mean was all 108.220.213.121:53 go through router pair and are mapped into 10.0.0.101:53 ports 80, 443, & 53 are port forwarded to 10.0.0.101
Oh, so you don't have a"truly" public system. So, 108.220.213.121 is actually the IP address of your router.
no, my router has its own ip
does the following 'ping path' help me explain??
10.0.0.101 ws server (me) 2 packets transmitted, 2 received, 0% packet loss, time 1027ms 10.0.0.1 netgear gw 2 packets transmitted, 2 received, 0% packet loss, time 1002ms 192.168.1.254 router att 2 packets transmitted, 2 received, 0% packet loss, time 1001ms 108.220.213.126 att gw 2 packets transmitted, 2 received, 0% packet loss, time 1002ms
108.90.204.76 att subnet (local) 2 packets transmitted, 2 received, 0% packet loss, time 1002ms 108.90.204.1 att subnet (remote) 2 packets transmitted, 2 received, 0% packet loss, time 1002ms 68.94.156.8 att dns (pri) 2 packets transmitted, 2 received, 0% packet loss, time 1002ms 68.94.157.8 att dns (sec) 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 21/04/2021 10:27, Jack Craig wrote:
named.service
it? ps -eaf | grep named named 1263562 1 0 13:59 ? 00:00:05 /usr/sbin/named -u named -c /etc/named.conf -4 root 1280487 311233 0 19:09 pts/0 00:00:00 grep --color=auto named It almost sounds as if you're not using the named.conf you think you're using. ps -eaf | grep named output?
How about just trying a caching name server just as a test to see if it works and binds to all interfaces.
I've attached named.conf-caching. How about replacing your config file with it and see if it binds correctly?
i'll do it first thing in the am and report results. THANKS!!!
On Tue, Apr 20, 2021 at 8:02 PM Ed Greshko ed.greshko@greshko.com wrote:
On 21/04/2021 10:27, Jack Craig wrote:
named.service
it? ps -eaf | grep named named 1263562 1 0 13:59 ? 00:00:05 /usr/sbin/named-u named -c /etc/named.conf -4
root 1280487 311233 0 19:09 pts/0 00:00:00 grep--color=auto named
It almost sounds as if you're not using the named.conf you thinkyou're using.
ps -eaf | grep named output?How about just trying a caching name server just as a test to see if it works and binds to all interfaces.
I've attached named.conf-caching. How about replacing your config file with it and see if it binds correctly?
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Tim:
Does your computer actually recognise one of its WAN ports as being that IP? (108.220.213.121)
Jack Craig:
Apparently not
I can do a telnet connect to IP for port 53 from 10.0.0.1 & localhost
10.0.0.101 and the external IP do not connect
As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53.
Okay, as Ed's said, 108.220.213.121 isn't an address of your computer, it's assigned to your public facing side of your first router. So, BIND cannot listen on it. I'd go along with Ed's example:
Run a named server that listens to all interfaces, and allows queries from any address. Likewise with the webserver.
If you were doing something tricky with your webserver, it not actually having that public IP might be an issue, too. Things can get in a confused circle if they try to resolve an IP to a name, that name back to an IP, and it's different.
But the supplied named.conf hasn't defined a "wan-view" acl, you've only done "internals" and "slaves".
Given these ACL's not employed and questionable listen commands how should I properly have configured this interface to provide external IP processing for primary dns service?
For the time being, let your named server answer all queries for your domain name with the public addresses. See if it, then, works as expected.
Once you've dealt with that, you can consider whether you really want to do split DNS (answering outside queries with your public IPs, and internal queries with your internal IPs), or whether you let your register handle all outside queries (I would), or whether you use different domain names for inside and outside (that's my approach in my network).
Since you only appear to have one real interface, it's going to be harder to configure BIND to distinguish between what's inside and outside. After all, the external queries are going to come from a local address (your router), you're probably going to have use the router's specific internal address as the definition for outside queries.
If you only have one PC, as you've previously outlined, running BIND is serious overkill. You can do all you need with the /etc/hosts file.
ACLs have some predefined terms:
"any" matches any and every IP address,
"localhost" matches any IP used by the computer it's running on,
"localnets" matches any IP on any network the computer is on,
"none" matches nothing.
When those definitions are not useful enough, you start using actual IP addresses or IP ranges (e.g. 192.168.0.0./24 is the entire range 192.168.0.0 through to 192.168.0.255).
Try Ed's sample named.conf. Then if you really want to try doing split DNS, I think you'll have to go down this route, using rules something like these *within* the config file:
listen-on port 53 { any; };
listen-on-v6 port 53 { any;};
allow-queries { any; };
acl wan { type in the internal IP of your router your PC is directly plugged into; };
acl lan { 127.0.0.1; };
view wan { match-clients { wan; }; zone "wan-linuxlighthouse" { type master; file "wan-linuxlighthouse.zone"; }; };
view lan { match-clients { lan; }; zone "lan-linuxlighthouse" { type master; file "lan-linuxlighthouse.zone"; }; }
With the associated wan- and lan- zone files only containing IPs applicable to themselves (the wan zone only has public addresses, the lan zone only has local addresses).
Match the special outside rule first, then fall back to the internal rules.
NB: While the defaults for various options are often any/all if you haven't set any contradicting rules, I don't know if alternative defaults have been complied in for Fedora's BIND. So I play safe and define the things explicitly.
visible interfaces
ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
That's your localhost with IPv4 and IPv6 addresses. Localhost is how the computer refers to itself. It's like you looking in the mirror and thinking "me."
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 50:65:f3:4a:ec:e5 brd ff:ff:ff:ff:ff:ff altname enp0s31f6 inet 10.0.0.101/24 brd 10.0.0.255 scope global noprefixroute eno1 valid_lft forever preferred_lft forever inet6 fe80::15ef:5535:377f:e73f/64 scope link noprefixroute valid_lft forever preferred_lft forever
That's your ethernet interface within your network, between your computer and routers, and any other devices.
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff
These are virtual bridges, which you don't appear to be using (a bridge between real interfaces, as in the prior paragraph, and emulated ones used by virtual installations). For what it's worth, my computer had the same kind of thing set up by default. But since I don't use virtual computers on my hardware, I removed them.
From what I can gather of this tangled thread is that your network is something like:
ISP --- router --- another router --- your computer
Each router will have a different IP address at their inside and outside interfaces (that diagram has outside WAN on the left, inside LAN on the right).
Your ISP allocates you a bunch of IPs. You either need to configure your router to be all of those IPs and route them through to where you want (doing some complex NAT). Or configure you router to be one of those IPs, and route the others through to where you want, and configure the destination(s) to be the other IPs (configuring your routers as gateways). Domestic routers may not be configurable enough.
ed,
would you resend that caching cfg file; i cant find that email any where!! :(
sorry,...
On Wed, Apr 21, 2021 at 12:48 AM Tim via users < users@lists.fedoraproject.org> wrote:
Tim:
Does your computer actually recognise one of its WAN ports as being that IP? (108.220.213.121)
Jack Craig:
Apparently not
I can do a telnet connect to IP for port 53 from 10.0.0.1 & localhost
10.0.0.101 and the external IP do not connect
As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53.
Okay, as Ed's said, 108.220.213.121 isn't an address of your computer, it's assigned to your public facing side of your first router. So, BIND cannot listen on it. I'd go along with Ed's example:
Run a named server that listens to all interfaces, and allows queries from any address. Likewise with the webserver.
If you were doing something tricky with your webserver, it not actually having that public IP might be an issue, too. Things can get in a confused circle if they try to resolve an IP to a name, that name back to an IP, and it's different.
But the supplied named.conf hasn't defined a "wan-view" acl, you've only done "internals" and "slaves".
Given these ACL's not employed and questionable listen commands how should I properly have configured this interface to provide external IP processing for primary dns service?
For the time being, let your named server answer all queries for your domain name with the public addresses. See if it, then, works as expected.
Once you've dealt with that, you can consider whether you really want to do split DNS (answering outside queries with your public IPs, and internal queries with your internal IPs), or whether you let your register handle all outside queries (I would), or whether you use different domain names for inside and outside (that's my approach in my network).
Since you only appear to have one real interface, it's going to be harder to configure BIND to distinguish between what's inside and outside. After all, the external queries are going to come from a local address (your router), you're probably going to have use the router's specific internal address as the definition for outside queries.
If you only have one PC, as you've previously outlined, running BIND is serious overkill. You can do all you need with the /etc/hosts file.
ACLs have some predefined terms:
"any" matches any and every IP address,
"localhost" matches any IP used by the computer it's running on,
"localnets" matches any IP on any network the computer is on,
"none" matches nothing.
When those definitions are not useful enough, you start using actual IP addresses or IP ranges (e.g. 192.168.0.0./24 is the entire range 192.168.0.0 through to 192.168.0.255).
Try Ed's sample named.conf. Then if you really want to try doing split DNS, I think you'll have to go down this route, using rules something like these *within* the config file:
listen-on port 53 { any; }; listen-on-v6 port 53 { any;}; allow-queries { any; }; acl wan { type in the internal IP of your router your PC isdirectly plugged into; };
acl lan { 127.0.0.1; }; view wan { match-clients { wan; }; zone "wan-linuxlighthouse" { type master; file "wan-linuxlighthouse.zone"; }; }; view lan { match-clients { lan; }; zone "lan-linuxlighthouse" { type master; file "lan-linuxlighthouse.zone"; }; }With the associated wan- and lan- zone files only containing IPs applicable to themselves (the wan zone only has public addresses, the lan zone only has local addresses).
Match the special outside rule first, then fall back to the internal rules.
NB: While the defaults for various options are often any/all if you haven't set any contradicting rules, I don't know if alternative defaults have been complied in for Fedora's BIND. So I play safe and define the things explicitly.
visible interfaces
ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
That's your localhost with IPv4 and IPv6 addresses. Localhost is how the computer refers to itself. It's like you looking in the mirror and thinking "me."
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 50:65:f3:4a:ec:e5 brd ff:ff:ff:ff:ff:ff altname enp0s31f6 inet 10.0.0.101/24 brd 10.0.0.255 scope global noprefixroute eno1 valid_lft forever preferred_lft forever inet6 fe80::15ef:5535:377f:e73f/64 scope link noprefixroute valid_lft forever preferred_lft forever
That's your ethernet interface within your network, between your computer and routers, and any other devices.
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff
These are virtual bridges, which you don't appear to be using (a bridge between real interfaces, as in the prior paragraph, and emulated ones used by virtual installations). For what it's worth, my computer had the same kind of thing set up by default. But since I don't use virtual computers on my hardware, I removed them.
From what I can gather of this tangled thread is that your network is something like:
ISP --- router --- another router --- your computer
Each router will have a different IP address at their inside and outside interfaces (that diagram has outside WAN on the left, inside LAN on the right).
Your ISP allocates you a bunch of IPs. You either need to configure your router to be all of those IPs and route them through to where you want (doing some complex NAT). Or configure you router to be one of those IPs, and route the others through to where you want, and configure the destination(s) to be the other IPs (configuring your routers as gateways). Domestic routers may not be configurable enough.
--
uname -rsvp Linux 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Apr 8 19:51:47 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Apr 21, 2021 at 12:48 AM Tim via users < users@lists.fedoraproject.org> wrote:
Tim:
Does your computer actually recognise one of its WAN ports as being that IP? (108.220.213.121)
Jack Craig:
Apparently not
I can do a telnet connect to IP for port 53 from 10.0.0.1 & localhost
10.0.0.101 and the external IP do not connect
As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53.
Okay, as Ed's said, 108.220.213.121 isn't an address of your computer, it's assigned to your public facing side of your first router. So, BIND cannot listen on it. I'd go along with Ed's example:
Run a named server that listens to all interfaces, and allows queries from any address. Likewise with the webserver.
If you were doing something tricky with your webserver, it not actually having that public IP might be an issue, too. Things can get in a confused circle if they try to resolve an IP to a name, that name back to an IP, and it's different.
But the supplied named.conf hasn't defined a "wan-view" acl, you've only done "internals" and "slaves".
Given these ACL's not employed and questionable listen commands how should I properly have configured this interface to provide external IP processing for primary dns service?
For the time being, let your named server answer all queries for your domain name with the public addresses. See if it, then, works as expected.
Once you've dealt with that, you can consider whether you really want to do split DNS (answering outside queries with your public IPs, and internal queries with your internal IPs), or whether you let your register handle all outside queries (I would), or whether you use different domain names for inside and outside (that's my approach in my network).
i wasnt aware of this option/configuration. sounds perfect, then i am able refresh my cert.
after ed's caching test, perhap you guys can guide me to this KISS approach,...
ed, i found the caching file test, results shortly,...
On Wed, Apr 21, 2021 at 11:21 AM Jack Craig jack.craig.aptos@gmail.com wrote:
On Wed, Apr 21, 2021 at 12:48 AM Tim via users < users@lists.fedoraproject.org> wrote:
Tim:
Does your computer actually recognise one of its WAN ports as being that IP? (108.220.213.121)
Jack Craig:
Apparently not
I can do a telnet connect to IP for port 53 from 10.0.0.1 & localhost
10.0.0.101 and the external IP do not connect
As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53.
Okay, as Ed's said, 108.220.213.121 isn't an address of your computer, it's assigned to your public facing side of your first router. So, BIND cannot listen on it. I'd go along with Ed's example:
Run a named server that listens to all interfaces, and allows queries from any address. Likewise with the webserver.
If you were doing something tricky with your webserver, it not actually having that public IP might be an issue, too. Things can get in a confused circle if they try to resolve an IP to a name, that name back to an IP, and it's different.
But the supplied named.conf hasn't defined a "wan-view" acl, you've only done "internals" and "slaves".
Given these ACL's not employed and questionable listen commands how should I properly have configured this interface to provide external IP processing for primary dns service?
For the time being, let your named server answer all queries for your domain name with the public addresses. See if it, then, works as expected.
Once you've dealt with that, you can consider whether you really want to do split DNS (answering outside queries with your public IPs, and internal queries with your internal IPs), or whether you let your register handle all outside queries (I would), or whether you use different domain names for inside and outside (that's my approach in my network).
i wasnt aware of this option/configuration. sounds perfect, then i am able refresh my cert.
after ed's caching test, perhap you guys can guide me to this KISS approach,...
-- A start job for unit named.service has begun execution.
the results of the caching test aren't too encouraging, the error msg doesnt tell me much, recommended next step is?
perhaps in the meantime you could outline how to configure my setup for your simler, /etc/hosts approach?
tia, jackc...
On Wed, Apr 21, 2021 at 11:21 AM Jack Craig jack.craig.aptos@gmail.com wrote:
On Wed, Apr 21, 2021 at 12:48 AM Tim via users < users@lists.fedoraproject.org> wrote:
Tim:
Does your computer actually recognise one of its WAN ports as being that IP? (108.220.213.121)
Jack Craig:
Apparently not
I can do a telnet connect to IP for port 53 from 10.0.0.1 & localhost
10.0.0.101 and the external IP do not connect
As my external IP is being supported by port mapping by router, all port 53 connects are routed to the internal address of 10.0.0.101:53.
Okay, as Ed's said, 108.220.213.121 isn't an address of your computer, it's assigned to your public facing side of your first router. So, BIND cannot listen on it. I'd go along with Ed's example:
Run a named server that listens to all interfaces, and allows queries from any address. Likewise with the webserver.
If you were doing something tricky with your webserver, it not actually having that public IP might be an issue, too. Things can get in a confused circle if they try to resolve an IP to a name, that name back to an IP, and it's different.
But the supplied named.conf hasn't defined a "wan-view" acl, you've only done "internals" and "slaves".
Given these ACL's not employed and questionable listen commands how should I properly have configured this interface to provide external IP processing for primary dns service?
For the time being, let your named server answer all queries for your domain name with the public addresses. See if it, then, works as expected.
Once you've dealt with that, you can consider whether you really want to do split DNS (answering outside queries with your public IPs, and internal queries with your internal IPs), or whether you let your register handle all outside queries (I would), or whether you use different domain names for inside and outside (that's my approach in my network).
i wasnt aware of this option/configuration. sounds perfect, then i am able refresh my cert.
after ed's caching test, perhap you guys can guide me to this KISS approach,...
Tim:
Once you've dealt with that, you can consider whether you really want to do split DNS (answering outside queries with your public IPs, and internal queries with your internal IPs), or whether you let your register handle all outside queries (I would), or whether you use different domain names for inside and outside (that's my approach in my network).
On Wed, 2021-04-21 at 11:21 -0700, Jack Craig wrote:
i wasnt aware of this option/configuration. sounds perfect, then i am able refresh my cert.
I'm not aware of which option you're responding to.
after ed's caching test, perhap you guys can guide me to this KISS approach,...
My "simple" method would be to configure your public DNS records on your registrar, and let them serve them to the publid. Configure your LAN addresses on your own name server, and only use your DNS server within your own network.
On Wed, 2021-04-21 at 11:39 -0700, Jack Craig wrote:
-- A start job for unit named.service has begun execution.
-- The job identifier is 28649. Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone localhost.localdomain/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone localhost.localdomain/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone localhost.localdomain/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: _default/localhost.localdomain/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone localhost/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone localhost/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone localhost/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: _default/localhost/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: _default/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: _default/1.0.0.127.in-addr.arpa/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com bash[1451129]: zone 0.in-addr.arpa/IN: loaded serial 0 Apr 21 11:36:07 ws.linuxlighthouse.com systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
i just swapped the provided file to /etc/named.conf and restarted, thoughts?
My immediate thoughts are:
Ed's named.conf file listed a bunch of files, chances are that yours have different names and/or filepaths.
Or your files do have formatting errors.
On Wed, 2021-04-21 at 11:47 -0700, Jack Craig wrote:
perhaps in the meantime you could outline how to configure my setup for your simler, /etc/hosts approach?
I suppose that before going into masses of technicalities, what does your system actually *need* to do?
a) We know you're intending to serve pages from a webserver from your computer, that doesn't require any of the DNS server malarkey you've been trying to handle. But will require passing HTTP and HTTPS connections through from the outside world to your webserver.
b) You have a public domain name. Your registrar can handle public queries for its data, and doesn't need to know anything about your internal LAN addresses. Your local network can either use its own DNS server, or you can use the hosts file, and it doesn't really need to know anything about your public addresses. Since you said you only had one computer, then the hosts file is more than adequate for local addressing queries on the same machine.
My /etc/hosts file has just these two lines in it:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
They handle the localhost numerical IP and named addresses, and various other aliases that some people expect to be used, but I've never seen. The format is each line begins with a numerical IP address, the associated hostname, then any extra aliases. Any queries for the numerical IP for any of those aliases will return the IP at the start of the line. Any queries for what name belongs to an IP will return the first name in the list.
It could also include other local IPs and name:
e.g. 192.168.1.1 mycomputer mycomputer.example.com 192.168.1.254 myrouter router.example.com
You don't have to do that, but if you want to simply associate hostnames and IP addresses for other things on your LAN, you can do it like that.
c) I don't know what you're doing with letsencrypt, to tell what it's requirements will be.
On 4/21/21 12:56 PM, Tim via users wrote:
My "simple" method would be to configure your public DNS records on your registrar, and let them serve them to the publid.
This will work fine, if and only if you have a static IP. If not, you can use a public dynamic DNS service such as DNSEXit.com (https://www.dnsexit.com/)to give your LAN a properly resolvable name.
On 22/04/2021 02:39, Jack Craig wrote:
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone localhost.localdomain/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone localhost.localdomain/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone localhost.localdomain/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: _default/localhost.localdomain/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone localhost/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone localhost/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone localhost/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: _default/localhost/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: _default/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has 0 SOA records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has no NS records Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: not loaded due to errors. Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: _default/1.0.0.127.in-addr.arpa/IN: bad zone Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 0.in-addr.arpa/IN: loaded serial 0 Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel https://lists.freedesktop.org/mailman/listinfo/systemd-devel
i just swapped the provided file to /etc/named.conf and restarted, thoughts?
None of this makes any sense.
I ran the named.conf file on 2 systems after just doing "dnf install bind". No problems.
Lets's confirm a few things.
1. What version of Fedora are you running? I'm testing on F33. 2. What version of bind? I'm at bind-9.11.28-1.fc33.x86_64 3. Have you changed the files in /var/named? named.ca named.empty named.localhost named.loopback Those are the config files that should be loaded.
And finally. the output of
systemctl status named
On Wed, Apr 21, 2021 at 12:31 PM Tim via users < users@lists.fedoraproject.org> wrote:
On Wed, 2021-04-21 at 11:47 -0700, Jack Craig wrote:
perhaps in the meantime you could outline how to configure my setup for your simler, /etc/hosts approach?
I suppose that before going into masses of technicalities, what does your system actually *need* to do?
really, just serve http,https, and dns as necessary.
a) We know you're intending to serve pages from a webserver from your computer, that doesn't require any of the DNS server malarkey you've been trying to handle. But will require passing HTTP and HTTPS connections through from the outside world to your webserver.
i have probly been making a mountain out of an ant hill, ...
b) You have a public domain name. Your registrar can handle public queries for its data, and doesn't need to know anything about your internal LAN addresses. Your local network can either use its own DNS server, or you can use the hosts file, and it doesn't really need to know anything about your public addresses. Since you said you only had one computer, then the hosts file is more than adequate for local addressing queries on the same machine.
this simplistic option was unknown to me.
My /etc/hosts file has just these two lines in it:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
They handle the localhost numerical IP and named addresses, and various other aliases that some people expect to be used, but I've never seen. The format is each line begins with a numerical IP address, the associated hostname, then any extra aliases. Any queries for the numerical IP for any of those aliases will return the IP at the start of the line. Any queries for what name belongs to an IP will return the first name in the list.
It could also include other local IPs and name:
e.g. 192.168.1.1 mycomputer mycomputer.example.com 192.168.1.254 myrouter router.example.com
You don't have to do that, but if you want to simply associate hostnames and IP addresses for other things on your LAN, you can do it like that.
c) I don't know what you're doing with letsencrypt, to tell what it's requirements will be.
i can renew my letsencrypt cert as soon as my dns is coherent(it was choking on an address lookup for my domain).
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Apr 21, 2021 at 1:06 PM Ed Greshko ed.greshko@greshko.com wrote:
On 22/04/2021 02:39, Jack Craig wrote:
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone localhost.localdomain/IN: has 0 SOA records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone localhost.localdomain/IN: has no NS records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone localhost.localdomain/IN: not loaded due to errors.
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: _default/localhost.localdomain/IN: bad zone
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone localhost/IN: has 0 SOA records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone localhost/IN: has no NS records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone localhost/IN: not loaded due to errors.
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: _default/localhost/IN: bad zone
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: has 0 SOA records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: has no NS records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: not loaded due to errors.
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: _default/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: bad zone
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has 0 SOA records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has no NS records
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: not loaded due to errors.
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: _default/1.0.0.127.in-addr.arpa/IN: bad zone
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
bash[1451129]: zone 0.in-addr.arpa/IN: loaded serial 0
Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE
i'll look harder at this, but in the meantime, ..
-- Subject: Unit process exited
-- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
<https://lists.freedesktop.org/mailman/listinfo/systemd-devel
i just swapped the provided file to /etc/named.conf and restarted,
thoughts?
None of this makes any sense.
I ran the named.conf file on 2 systems after just doing "dnf install bind". No problems.
Lets's confirm a few things. 9.11.28-1.fc32
- What version of Fedora are you running? I'm testing on F33.
*F32* *bind 9.11.28-1.fc32 *
3. Have you changed the files in /var/named? named.ca named.empty
named.localhost named.loopback Those are the config files that should be loaded.
all but named.empty are empty.
cat
*named.empty$TTL 3H@ IN SOA @ rname.invalid. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum NS @ A 127.0.0.1 AAAA ::1*
i have zone files for llh & reverse zone
And finally. the output of
systemctl status named
- systemctl status named● named.service - Berkeley Internet Name Domain
(DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2021-04-21 11:36:07 PDT; 2h 9min ago Process: 1451128 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE) CPU: 6msApr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: not loaded due to errors.Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: _default/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: bad zoneApr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has 0 SOA recordsApr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: has no NS recordsApr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 1.0.0.127.in-addr.arpa/IN: not loaded due to errors.Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: _default/1.0.0.127.in-addr.arpa/IN: bad zoneApr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com bash[1451129]: zone 0.in-addr.arpa/IN: loaded serial 0Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com systemd[1]: named.service: Control process exited, code=exited, status=1/FAILUREApr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com systemd[1]: named.service: Failed with result 'exit-code'.Apr 21 11:36:07 ws.linuxlighthouse.com http://ws.linuxlighthouse.com systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).* -- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 4/21/21 1:37 PM, Jack Craig wrote:
On Wed, Apr 21, 2021 at 12:31 PM Tim via users < users@lists.fedoraproject.org> wrote:
On Wed, 2021-04-21 at 11:47 -0700, Jack Craig wrote: b) You have a public domain name. Your registrar can handle public queries for its data, and doesn't need to know anything about your internal LAN addresses. Your local network can either use its own DNS server, or you can use the hosts file, and it doesn't really need to know anything about your public addresses. Since you said you only had one computer, then the hosts file is more than adequate for local addressing queries on the same machine.
Hi Jack,
Tim is giving you really good advice. The internet runs on DNS. Break it and the internet breaks. Try to run a mail server with broken DNS and you WILL learn immediately what a "Spit Storm" is. I'm pretty sure I misspelled Spit.
Wild West day are gone. Unless you are doing this for academic purposes, perhaps to try to figure how this all works, you are wasting your time. Your registrar has fatter pipes than you can ever imagine and faster than you could ever buy.
20 plus years ago I went your route (still Wild West back then) and learned that you cannot compete in an asynchronous world where downhill is FAST and uphill is SSLLOOWW. If you are running a server for public consumption you want to serve FASTER than FAST and that is not possible in an asynchronous world.
I had an AT&T /29 and had to deal with quints of quads for only $5US extra per month. They raised that premium to $15US per month and I realized that I could rent a pair of DigitalOcean servers for less than I was paying AT&T and am sitting on monster pipes that are on the RIGHT side of the asynchronous internet. You can't tell my service apart from the big boys (girls too). And the world is NOT beating a path to my HOME's front door. I'm back to being just another one of the world's nameless users
Let Verizon publish your domain name. After all, it is just a name. And anybody who has ever watched their dynamic IPs change and had to figure out how to deal with that learns quickly that that is not the right route. Good DNS lets you mix and match names and IPs on a whim and lets you experiment where it DOESN'T come with serious repercussions.
2¢ worth of advice that is a bargain at half that.
Enjoy your voyage, you only get one ride on this trolley.
Mike Wright
On 22/04/2021 04:47, Jack Craig wrote:
all but named.empty are empty.
cat *named.empty $TTL 3H @ IN SOA @ rname.invalid. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum NS @ A 127.0.0.1 AAAA ::1*
i have zone files for llh & reverse zone
Well, there is "this" problem. I think you've made changes from the original install.
[root@f32k named]# ll named* -rw-r-----. 1 root named 2253 Feb 20 03:46 named.ca -rw-r-----. 1 root named 152 Feb 20 03:46 named.empty -rw-r-----. 1 root named 152 Feb 20 03:46 named.localhost -rw-r-----. 1 root named 168 Feb 20 03:46 named.loopback
You could reinstall bind or you can get this file
https://drive.google.com/file/d/1NLFAeqUSSPC-0CiCppGwbuF6kkaoY-zO/view?usp=s...
which is named.configs.tar to fix this issue.
If you look at the named.conf I supplied you'll see it has
zone "." IN { type hint; file "named.ca"; };
include "/etc/named.rfc1912.zones";
This loads those based on the contents of "/etc/named.rfc1912.zones"
On 22/04/2021 04:47, Jack Craig wrote:
i have zone files for llh & reverse zone
Oh, BTW, there is very little point in defining
zone "213.220.108.in-addr.arpa" { type master;
You only have been assigned 8 IP addresses (6 usable + network + broadcast) within the zone out of 255. I've not heard of any ISP delegating a portion of an in-addr.arpa zone to clients when they are that small.
Especially a Master, for that is certainly wrong.
It seems you've already told AT&T about 108.220.213.121 and they have entered that into their zone maps.
[root@meimei ~]# host 108.220.213.121 121.213.220.108.in-addr.arpa domain name pointer ws.linuxlighthouse.com.
Also, in the event I wasn't clear, the sample named.conf was to just run a caching name server to verify that binding will happen to all available interfaces as it should.
Once that is accomplished you can go about making changes to that file to service your zones.
I would do that step by step and not make wholesale changes.
FWIW, I agree with others (and that is what I do) in the the best thing to do is have Network Solutions handle your public DNS and just have a DNS setup for internal use. I go even a step further at home since my home isn't "complex". My NAS has a built-in DNS server with a web interface making it a snap to administer.
Why spend time on something you're probably not going to touch? And why expose services to the world that are open to attack if you can have them hosted elsewhere?
On 22/04/2021 03:42, Joe Zeff wrote:
On 4/21/21 12:56 PM, Tim via users wrote:
My "simple" method would be to configure your public DNS records on your registrar, and let them serve them to the publid.
This will work fine, if and only if you have a static IP. If not, you can use a public dynamic DNS service such as DNSEXit.com (https://www.dnsexit.com/)to give your LAN a properly resolvable name.
No need for that if you're using a good registrar.
My registrar supports Dynamic DNS Records.
FWIW, the OP has indicated early on that he has 6 usable static IP addresses.
On Thu, 2021-04-22 at 12:23 +0800, Ed Greshko wrote:
No need for that if you're using a good registrar.
My registrar supports Dynamic DNS Records.
FWIW, the OP has indicated early on that he has 6 usable static IP addresses.
Even with support for DDNS, I wouldn't use it for a real webserver. Anytime your IP changed, you'd lose traffic until the rest of the world caught up with the changes. And the next person who got your old address gets assailed with all the traffic that used to be heading in your direction.
On Thu, 2021-04-22 at 10:08 +0800, Ed Greshko wrote:
And why expose services to the world that are open to attack if you can have them hosted elsewhere?
I suppose we should explicitly point out: All servers can be attacked, and that includes DNS servers. So if you run your own, you need to know how to deal with that.
On 22/04/2021 13:30, Tim via users wrote:
On Thu, 2021-04-22 at 12:23 +0800, Ed Greshko wrote:
No need for that if you're using a good registrar.
My registrar supports Dynamic DNS Records.
FWIW, the OP has indicated early on that he has 6 usable static IP addresses.
Even with support for DDNS, I wouldn't use it for a real webserver. Anytime your IP changed, you'd lose traffic until the rest of the world caught up with the changes. And the next person who got your old address gets assailed with all the traffic that used to be heading in your direction.
Yes, totally agree.
On 22/04/2021 13:33, Tim via users wrote:
On Thu, 2021-04-22 at 10:08 +0800, Ed Greshko wrote:
And why expose services to the world that are open to attack if you can have them hosted elsewhere?
I suppose we should explicitly point out: All servers can be attacked, and that includes DNS servers. So if you run your own, you need to know how to deal with that.
Yes, that needs to be repeated. I think, it has been a long thread, I did mention DoS attacks against DNS servers. Even the "big boys" can struggle dealing with those from time to time.
On 22/04/2021 13:50, Ed Greshko wrote:
On 22/04/2021 13:30, Tim via users wrote:
On Thu, 2021-04-22 at 12:23 +0800, Ed Greshko wrote:
No need for that if you're using a good registrar.
My registrar supports Dynamic DNS Records.
FWIW, the OP has indicated early on that he has 6 usable static IP addresses.
Even with support for DDNS, I wouldn't use it for a real webserver. Anytime your IP changed, you'd lose traffic until the rest of the world caught up with the changes. And the next person who got your old address gets assailed with all the traffic that used to be heading in your direction.
Yes, totally agree.
I should have mentioned, not talking about other places, but here in Taiwan it seems the TTL on dynamic IP's is rather long. My nephew, while he doesn't run a web server, has told me he gets the same IP address even if his notebook has been off for a day or more.
On Thu, 2021-04-22 at 14:32 +0800, Ed Greshko wrote:
I should have mentioned, not talking about other places, but here in Taiwan it seems the TTL on dynamic IP's is rather long. My nephew, while he doesn't run a web server, has told me he gets the same IP address even if his notebook has been off for a day or more.
It only seems to be around 10 minutes, here. I sometimes wonder if ISPs do that on purpose, so that if your connection screws up and you do the ridiculous turn off and wait 15 minutes (as if your equipment were steam-powered), you might end up going through a different route.
I remember some Windows dill trying to tell me that DHCP leases could only last a few hours, and you'd have to reboot to be able to keep using your computer. That may well have been some shortcoming of the dire software he was using, but it certainly wasn't to do with DHCP.
On Wed, Apr 21, 2021 at 7:08 PM Ed Greshko ed.greshko@greshko.com wrote:
On 22/04/2021 04:47, Jack Craig wrote:
i have zone files for llh & reverse zone
Oh, BTW, there is very little point in defining
zone "213.220.108.in-addr.arpa" { type master;You only have been assigned 8 IP addresses (6 usable + network + broadcast) within the zone out of 255. I've not heard of any ISP delegating a portion of an in-addr.arpa zone to clients when they are that small.
Especially a Master, for that is certainly wrong.
It seems you've already told AT&T about 108.220.213.121 and they have entered that into their zone maps.
[root@meimei ~]# host 108.220.213.121 121.213.220.108.in-addr.arpa domain name pointer ws.linuxlighthouse.com.
Also, in the event I wasn't clear, the sample named.conf was to just run a caching name server to verify that binding will happen to all available interfaces as it should.
named now comes up just fine.
how do i verify the correct binding by interface has been done?
Once that is accomplished you can go about making changes to that file to service your zones.
I would do that step by step and not make wholesale changes.
i totally agree. what steps should they be?
FWIW, I agree with others (and that is what I do) in the the best thing to do is have Network Solutions handle your public DNS and just have a DNS setup for internal use. I go even a step further at home since my home isn't "complex". My NAS has a built-in DNS server with a web interface making it a snap to administer.
Why spend time on something you're probably not going to touch? And why expose services to the world that are open to attack if you can have them hosted elsewhere?
you guys are, as usual, right!!! ;) Thx!!
after these steps i should be able to renew my cert, Yeah!!
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 24/04/2021 02:49, Jack Craig wrote:
named now comes up just fine.
how do i verify the correct binding by interface has been done?
The output of
sudo netstat -nap | grep named
Also, please provide the output of
systemctl --no-pager -l status named
netstat -nap | grep named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 1815795/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 1815795/named tcp6 0 0 ::1:53 :::* LISTEN 1815795/named tcp6 0 0 ::1:953 :::* LISTEN 1815795/named udp 0 0 127.0.0.1:53 0.0.0.0:* 1815795/named udp6 0 0 ::1:53 :::* 1815795/named unix 2 [ ] STREAM CONNECTED 4864955 1815795/named
unix 2 [ ] DGRAM 4864952 1815795/named
[root@ws named$ [root@ws named$ systemctl --no-pager -l status named ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-04-23 11:36:55 PDT; 4h 2min ago Process: 1815792 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Process: 1815794 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 1815795 (named) Tasks: 11 (limit: 38336) Memory: 132.7M CPU: 6.664s CGroup: /system.slice/named.service └─1815795 /usr/sbin/named -u named -c /etc/named.conf
Apr 23 15:38:19 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'ns-1799.awsdns-32.co.uk/A/IN': 2600:9000:5305:e300::1#53 Apr 23 15:38:19 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'ns-1799.awsdns-32.co.uk/AAAA/IN': 2600:9000:5305:e300::1#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/AAAA/IN': 2001:4860:4802:36::a#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/A/IN': 2001:4860:4802:36::a#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/AAAA/IN': 2001:4860:4802:34::a#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/A/IN': 2001:4860:4802:34::a#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/AAAA/IN': 2001:4860:4802:38::a#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/A/IN': 2001:4860:4802:38::a#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/AAAA/IN': 2001:4860:4802:32::a#53 Apr 23 15:38:36 ws.linuxlighthouse.com named[1815795]: network unreachable resolving 'www.gstatic.com/A/IN': 2001:4860:4802:32::a#53
On Fri, Apr 23, 2021 at 2:41 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 02:49, Jack Craig wrote:
named now comes up just fine.
how do i verify the correct binding by interface has been done?
The output of
sudo netstat -nap | grep named
Also, please provide the output of
systemctl --no-pager -l status named
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 24/04/2021 06:40, Jack Craig wrote:
netstat -nap | grep named tcp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* LISTEN 1815795/named tcp 0 0 127.0.0.1:953 http://127.0.0.1:953 0.0.0.0:* LISTEN 1815795/named tcp6 0 0 ::1:53 :::* LISTEN 1815795/named tcp6 0 0 ::1:953 :::* LISTEN 1815795/named udp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* 1815795/named udp6 0 0 ::1:53 :::* 1815795/named unix 2 [ ] STREAM CONNECTED 4864955 1815795/named unix 2 [ ] DGRAM 4864952 1815795/named
Nope. Only listening on loopback addresses.
The systemctl command doesn't show the actual options. So, what does
ps -ax | grep named
return?
Also, if you do (make sure I'm using the correct IP address)
ncat -l 10.0.0.101 53
Does it bind as it should? It will appear to hang when working correctly. Ctrl-C to quit, of course
On 24/04/2021 07:13, Ed Greshko wrote:
On 24/04/2021 06:40, Jack Craig wrote:
netstat -nap | grep named tcp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* LISTEN 1815795/named tcp 0 0 127.0.0.1:953 http://127.0.0.1:953 0.0.0.0:* LISTEN 1815795/named tcp6 0 0 ::1:53 :::* LISTEN 1815795/named tcp6 0 0 ::1:953 :::* LISTEN 1815795/named udp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:* 1815795/named udp6 0 0 ::1:53 :::* 1815795/named unix 2 [ ] STREAM CONNECTED 4864955 1815795/named unix 2 [ ] DGRAM 4864952 1815795/named
Nope. Only listening on loopback addresses.
The systemctl command doesn't show the actual options. So, what does
ps -ax | grep named
return?
Also, if you do (make sure I'm using the correct IP address)
ncat -l 10.0.0.101 53
Does it bind as it should? It will appear to hang when working correctly. Ctrl-C to quit, of course
Also....
journalctl -b 0 | grep -i listen | grep named
maybe helpful.
ps -ax | grep named 1814955 pts/4 S+ 0:00 sudo vi /etc/named.conf 1814962 pts/4 S+ 0:00 /usr/bin/vim /etc/named.conf 1815795 ? Ssl 0:09 /usr/sbin/named -u named -c /etc/named.conf 1825164 pts/0 S+ 0:00 grep --color=auto named [root@ws named$ [root@ws named$ ncat -l 10.0.0.101 53
it does 'hang' journalctl -b 0 | grep -i listen | grep named Apr 13 22:42:48 ws.linuxlighthouse.com named[905]: using 7 UDP listeners per interface Apr 13 22:42:48 ws.linuxlighthouse.com named[905]: listening on IPv6 interfaces, port 53 Apr 13 22:42:48 ws.linuxlighthouse.com named[905]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 13 22:42:48 ws.linuxlighthouse.com named[905]: command channel listening on 127.0.0.1#953 Apr 13 22:42:53 ws.linuxlighthouse.com named[905]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 13 22:42:54 ws.linuxlighthouse.com named[905]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 15 07:55:08 ws.linuxlighthouse.com named[905]: client @0x7f50600e6060 89.39.107.167#39720 (mailgate.listen.com): view external-wan-view: query: mailgate.listen.com IN A +T (10.0.0.101) Apr 15 09:24:02 ws.linuxlighthouse.com named[905]: client @0x7f505c0ef630 91.191.209.122#44020 (mx.foodamentalisten.de): view external-wan-view: query: mx.foodamentalisten.de IN A +T (10.0.0.101) Apr 15 11:29:22 ws.linuxlighthouse.com named[905]: no longer listening on ::#53 Apr 15 11:29:22 ws.linuxlighthouse.com named[905]: no longer listening on 127.0.0.1#53 Apr 15 11:29:22 ws.linuxlighthouse.com named[905]: no longer listening on 10.0.0.101#53 Apr 15 11:29:22 ws.linuxlighthouse.com named[905]: no longer listening on 192.168.122.1#53 Apr 15 11:29:22 ws.linuxlighthouse.com named[309193]: using 7 UDP listeners per interface Apr 15 11:29:22 ws.linuxlighthouse.com named[309193]: listening on IPv6 interfaces, port 53 Apr 15 11:29:22 ws.linuxlighthouse.com named[309193]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 15 11:29:22 ws.linuxlighthouse.com named[309193]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 15 11:29:22 ws.linuxlighthouse.com named[309193]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 15 11:29:22 ws.linuxlighthouse.com named[309193]: command channel listening on 127.0.0.1#953 Apr 15 12:57:26 ws.linuxlighthouse.com named[309193]: no longer listening on ::#53 Apr 15 12:57:26 ws.linuxlighthouse.com named[309193]: no longer listening on 127.0.0.1#53 Apr 15 12:57:26 ws.linuxlighthouse.com named[309193]: no longer listening on 10.0.0.101#53 Apr 15 12:57:26 ws.linuxlighthouse.com named[309193]: no longer listening on 192.168.122.1#53 Apr 15 12:57:26 ws.linuxlighthouse.com named[313097]: using 7 UDP listeners per interface Apr 15 12:57:26 ws.linuxlighthouse.com named[313097]: listening on IPv6 interfaces, port 53 Apr 15 12:57:26 ws.linuxlighthouse.com named[313097]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 15 12:57:26 ws.linuxlighthouse.com named[313097]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 15 12:57:26 ws.linuxlighthouse.com named[313097]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 15 12:57:26 ws.linuxlighthouse.com named[313097]: command channel listening on 127.0.0.1#953 Apr 15 18:03:10 ws.linuxlighthouse.com named[313097]: no longer listening on ::#53 Apr 15 18:03:10 ws.linuxlighthouse.com named[313097]: no longer listening on 127.0.0.1#53 Apr 15 18:03:10 ws.linuxlighthouse.com named[313097]: no longer listening on 10.0.0.101#53 Apr 15 18:03:10 ws.linuxlighthouse.com named[313097]: no longer listening on 192.168.122.1#53 Apr 15 18:03:10 ws.linuxlighthouse.com named[334808]: using 7 UDP listeners per interface Apr 15 18:03:10 ws.linuxlighthouse.com named[334808]: listening on IPv6 interfaces, port 53 Apr 15 18:03:10 ws.linuxlighthouse.com named[334808]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 15 18:03:10 ws.linuxlighthouse.com named[334808]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 15 18:03:10 ws.linuxlighthouse.com named[334808]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 15 18:03:10 ws.linuxlighthouse.com named[334808]: command channel listening on 127.0.0.1#953 Apr 15 18:06:55 ws.linuxlighthouse.com named[334808]: no longer listening on ::#53 Apr 15 18:06:55 ws.linuxlighthouse.com named[334808]: no longer listening on 127.0.0.1#53 Apr 15 18:06:55 ws.linuxlighthouse.com named[334808]: no longer listening on 10.0.0.101#53 Apr 15 18:06:55 ws.linuxlighthouse.com named[334808]: no longer listening on 192.168.122.1#53 Apr 15 18:35:14 ws.linuxlighthouse.com named[336009]: using 7 UDP listeners per interface Apr 15 18:35:14 ws.linuxlighthouse.com named[336009]: listening on IPv6 interfaces, port 53 Apr 15 18:35:14 ws.linuxlighthouse.com named[336009]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 15 18:35:14 ws.linuxlighthouse.com named[336009]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 15 18:35:14 ws.linuxlighthouse.com named[336009]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 15 18:35:14 ws.linuxlighthouse.com named[336009]: command channel listening on 127.0.0.1#953 Apr 15 19:02:47 ws.linuxlighthouse.com named[336009]: no longer listening on ::#53 Apr 15 19:02:47 ws.linuxlighthouse.com named[336009]: no longer listening on 127.0.0.1#53 Apr 15 19:02:47 ws.linuxlighthouse.com named[336009]: no longer listening on 10.0.0.101#53 Apr 15 19:02:47 ws.linuxlighthouse.com named[336009]: no longer listening on 192.168.122.1#53 Apr 16 11:55:33 ws.linuxlighthouse.com named[496814]: using 7 UDP listeners per interface Apr 16 11:55:33 ws.linuxlighthouse.com named[496814]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 11:55:33 ws.linuxlighthouse.com named[496814]: command channel listening on 127.0.0.1#953 Apr 16 12:05:36 ws.linuxlighthouse.com named[496814]: no longer listening on 127.0.0.1#53 Apr 16 12:07:49 ws.linuxlighthouse.com named[497648]: using 7 UDP listeners per interface Apr 16 12:07:49 ws.linuxlighthouse.com named[497648]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 12:07:49 ws.linuxlighthouse.com named[497648]: command channel listening on 127.0.0.1#953 Apr 16 12:29:30 ws.linuxlighthouse.com named[497648]: no longer listening on 127.0.0.1#53 Apr 16 12:29:30 ws.linuxlighthouse.com named[499092]: using 7 UDP listeners per interface Apr 16 12:29:30 ws.linuxlighthouse.com named[499092]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 12:29:30 ws.linuxlighthouse.com named[499092]: command channel listening on 127.0.0.1#953 Apr 16 12:32:17 ws.linuxlighthouse.com named[499092]: no longer listening on 127.0.0.1#53 Apr 16 12:32:17 ws.linuxlighthouse.com named[499261]: using 7 UDP listeners per interface Apr 16 12:32:17 ws.linuxlighthouse.com named[499261]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 12:32:17 ws.linuxlighthouse.com named[499261]: command channel listening on 127.0.0.1#953 Apr 16 14:42:29 ws.linuxlighthouse.com named[499261]: no longer listening on 127.0.0.1#53 Apr 16 14:42:29 ws.linuxlighthouse.com named[507222]: using 7 UDP listeners per interface Apr 16 14:42:29 ws.linuxlighthouse.com named[507222]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 14:42:29 ws.linuxlighthouse.com named[507222]: command channel listening on 127.0.0.1#953 Apr 16 14:45:51 ws.linuxlighthouse.com named[507496]: using 7 UDP listeners per interface Apr 16 14:45:51 ws.linuxlighthouse.com named[507496]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 14:45:51 ws.linuxlighthouse.com named[507496]: command channel listening on 127.0.0.1#953 Apr 16 14:49:26 ws.linuxlighthouse.com named[507709]: using 7 UDP listeners per interface Apr 16 14:49:26 ws.linuxlighthouse.com named[507709]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 14:49:27 ws.linuxlighthouse.com named[507709]: command channel listening on 127.0.0.1#953 Apr 16 14:49:38 ws.linuxlighthouse.com named[507709]: no longer listening on 127.0.0.1#53 Apr 16 14:49:38 ws.linuxlighthouse.com named[507765]: using 7 UDP listeners per interface Apr 16 14:49:38 ws.linuxlighthouse.com named[507765]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 14:49:38 ws.linuxlighthouse.com named[507765]: command channel listening on 127.0.0.1#953 Apr 16 15:06:23 ws.linuxlighthouse.com named[507765]: no longer listening on 127.0.0.1#53 Apr 16 15:06:23 ws.linuxlighthouse.com named[508847]: using 7 UDP listeners per interface Apr 16 15:06:23 ws.linuxlighthouse.com named[508847]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 15:06:23 ws.linuxlighthouse.com named[508847]: command channel listening on 127.0.0.1#953 Apr 16 15:06:46 ws.linuxlighthouse.com named[508847]: no longer listening on 127.0.0.1#53 Apr 16 15:06:46 ws.linuxlighthouse.com named[508922]: using 7 UDP listeners per interface Apr 16 15:06:46 ws.linuxlighthouse.com named[508922]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 15:06:46 ws.linuxlighthouse.com named[508922]: command channel listening on 127.0.0.1#953 Apr 16 16:19:24 ws.linuxlighthouse.com named[513025]: using 7 UDP listeners per interface Apr 16 16:19:24 ws.linuxlighthouse.com named[513025]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 16:19:24 ws.linuxlighthouse.com named[513025]: command channel listening on 127.0.0.1#953 Apr 16 16:24:21 ws.linuxlighthouse.com named[513516]: using 7 UDP listeners per interface Apr 16 16:24:21 ws.linuxlighthouse.com named[513516]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 16:24:21 ws.linuxlighthouse.com named[513516]: command channel listening on 127.0.0.1#953 Apr 16 16:27:00 ws.linuxlighthouse.com named[513716]: using 7 UDP listeners per interface Apr 16 16:27:00 ws.linuxlighthouse.com named[513716]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 16:27:00 ws.linuxlighthouse.com named[513716]: command channel listening on 127.0.0.1#953 Apr 17 12:24:03 ws.linuxlighthouse.com named[706714]: using 7 UDP listeners per interface Apr 17 12:24:03 ws.linuxlighthouse.com named[706714]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 17 12:24:03 ws.linuxlighthouse.com named[706714]: command channel listening on 127.0.0.1#953 Apr 17 12:35:50 ws.linuxlighthouse.com named[707226]: using 7 UDP listeners per interface Apr 17 12:35:50 ws.linuxlighthouse.com named[707226]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 17 12:35:50 ws.linuxlighthouse.com named[707226]: command channel listening on 127.0.0.1#953 Apr 17 13:23:35 ws.linuxlighthouse.com named[708980]: using 7 UDP listeners per interface Apr 17 13:23:35 ws.linuxlighthouse.com named[708980]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 17 13:23:35 ws.linuxlighthouse.com named[708980]: command channel listening on 127.0.0.1#953 Apr 17 13:23:49 ws.linuxlighthouse.com named[709028]: using 7 UDP listeners per interface Apr 17 13:23:49 ws.linuxlighthouse.com named[709028]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 17 13:23:49 ws.linuxlighthouse.com named[709028]: command channel listening on 127.0.0.1#953 Apr 18 03:29:44 ws.linuxlighthouse.com named[858230]: using 7 UDP listeners per interface Apr 18 03:29:44 ws.linuxlighthouse.com named[858230]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 18 03:29:44 ws.linuxlighthouse.com named[858230]: command channel listening on 127.0.0.1#953 Apr 18 08:06:37 ws.linuxlighthouse.com named[869758]: using 7 UDP listeners per interface Apr 18 08:06:37 ws.linuxlighthouse.com named[869758]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 18 08:06:37 ws.linuxlighthouse.com named[869758]: command channel listening on 127.0.0.1#953 Apr 18 18:54:57 ws.linuxlighthouse.com named[906607]: using 7 UDP listeners per interface Apr 18 18:54:57 ws.linuxlighthouse.com named[906607]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 18 18:54:57 ws.linuxlighthouse.com named[906607]: command channel listening on 127.0.0.1#953 Apr 18 19:00:31 ws.linuxlighthouse.com named[906987]: using 7 UDP listeners per interface Apr 18 19:00:31 ws.linuxlighthouse.com named[906987]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 18 19:00:31 ws.linuxlighthouse.com named[906987]: command channel listening on 127.0.0.1#953 Apr 18 19:39:14 ws.linuxlighthouse.com named[909884]: using 7 UDP listeners per interface Apr 18 19:39:14 ws.linuxlighthouse.com named[909884]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 18 19:39:14 ws.linuxlighthouse.com named[909884]: command channel listening on 127.0.0.1#953 Apr 19 16:26:54 ws.linuxlighthouse.com named[1085800]: using 7 UDP listeners per interface Apr 19 16:26:54 ws.linuxlighthouse.com named[1085800]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 19 16:26:54 ws.linuxlighthouse.com named[1085800]: command channel listening on 127.0.0.1#953 Apr 19 17:53:37 ws.linuxlighthouse.com named[1088294]: using 7 UDP listeners per interface Apr 19 17:53:37 ws.linuxlighthouse.com named[1088294]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 19 17:53:37 ws.linuxlighthouse.com named[1088294]: command channel listening on 127.0.0.1#953 Apr 19 18:36:50 ws.linuxlighthouse.com named[1089724]: using 7 UDP listeners per interface Apr 19 18:36:50 ws.linuxlighthouse.com named[1089724]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 19 18:36:50 ws.linuxlighthouse.com named[1089724]: command channel listening on 127.0.0.1#953 Apr 19 19:06:05 ws.linuxlighthouse.com named[1090819]: using 7 UDP listeners per interface Apr 19 19:06:05 ws.linuxlighthouse.com named[1090819]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 19 19:06:05 ws.linuxlighthouse.com named[1090819]: command channel listening on 127.0.0.1#953 Apr 20 12:30:58 ws.linuxlighthouse.com named[1258277]: using 7 UDP listeners per interface Apr 20 12:30:58 ws.linuxlighthouse.com named[1258277]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 20 12:30:58 ws.linuxlighthouse.com named[1258277]: command channel listening on 127.0.0.1#953 Apr 20 13:59:26 ws.linuxlighthouse.com named[1263562]: using 7 UDP listeners per interface Apr 20 13:59:26 ws.linuxlighthouse.com named[1263562]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 20 13:59:26 ws.linuxlighthouse.com named[1263562]: command channel listening on 127.0.0.1#953 Apr 23 11:18:44 ws.linuxlighthouse.com named[1815058]: using 7 UDP listeners per interface Apr 23 11:18:44 ws.linuxlighthouse.com named[1815058]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 23 11:18:44 ws.linuxlighthouse.com named[1815058]: listening on IPv6 interface lo, ::1#53 Apr 23 11:18:44 ws.linuxlighthouse.com named[1815058]: command channel listening on 127.0.0.1#953 Apr 23 11:18:44 ws.linuxlighthouse.com named[1815058]: command channel listening on ::1#953 Apr 23 11:25:20 ws.linuxlighthouse.com named[1815058]: no longer listening on 127.0.0.1#53 Apr 23 11:25:20 ws.linuxlighthouse.com named[1815058]: no longer listening on ::1#53 Apr 23 11:25:51 ws.linuxlighthouse.com named[1815348]: using 7 UDP listeners per interface Apr 23 11:25:51 ws.linuxlighthouse.com named[1815348]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 23 11:25:51 ws.linuxlighthouse.com named[1815348]: listening on IPv6 interface lo, ::1#53 Apr 23 11:25:51 ws.linuxlighthouse.com named[1815348]: command channel listening on 127.0.0.1#953 Apr 23 11:25:51 ws.linuxlighthouse.com named[1815348]: command channel listening on ::1#953 Apr 23 11:35:49 ws.linuxlighthouse.com named[1815348]: no longer listening on 127.0.0.1#53 Apr 23 11:35:49 ws.linuxlighthouse.com named[1815348]: no longer listening on ::1#53 Apr 23 11:36:55 ws.linuxlighthouse.com named[1815795]: using 7 UDP listeners per interface Apr 23 11:36:55 ws.linuxlighthouse.com named[1815795]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 23 11:36:55 ws.linuxlighthouse.com named[1815795]: listening on IPv6 interface lo, ::1#53 Apr 23 11:36:55 ws.linuxlighthouse.com named[1815795]: command channel listening on 127.0.0.1#953 Apr 23 11:36:55 ws.linuxlighthouse.com named[1815795]: command channel listening on ::1#953
On Fri, Apr 23, 2021 at 4:40 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 07:13, Ed Greshko wrote:
On 24/04/2021 06:40, Jack Craig wrote:
netstat -nap | grep named tcp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:*
LISTEN 1815795/namedtcp 0 0 127.0.0.1:953 http://127.0.0.1:953
0.0.0.0:* LISTEN 1815795/named
tcp6 0 0 ::1:53 :::* LISTEN
1815795/named
tcp6 0 0 ::1:953 :::* LISTEN
1815795/named
udp 0 0 127.0.0.1:53 http://127.0.0.1:53 0.0.0.0:*
1815795/namedudp6 0 0 ::1:53 :::* 1815795/named unix 2 [ ] STREAM CONNECTED 4864955 1815795/named unix 2 [ ] DGRAM 4864952 1815795/named
Nope. Only listening on loopback addresses.
The systemctl command doesn't show the actual options. So, what does
ps -ax | grep named
return?
Also, if you do (make sure I'm using the correct IP address)
ncat -l 10.0.0.101 53
Does it bind as it should? It will appear to hang when working
correctly. Ctrl-C to quit, of course
Also....
journalctl -b 0 | grep -i listen | grep named
maybe helpful.
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 24/04/2021 08:00, Jack Craig wrote:
ps -ax | grep named 1814955 pts/4 S+ 0:00 sudo vi /etc/named.conf 1814962 pts/4 S+ 0:00 /usr/bin/vim /etc/named.conf 1815795 ? Ssl 0:09 /usr/sbin/named -u named -c /etc/named.conf 1825164 pts/0 S+ 0:00 grep --color=auto named [root@ws named$ [root@ws named$ ncat -l 10.0.0.101 53
it does 'hang'
OK.... Had you left it hanging then had I run "nmap -sS 108.220.213.1" should have shown the port "open"
See the comments below.
This series on 4/13 is "good". Listening on all interfaces
journalctl -b 0 | grep -i listen | grep named Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: using 7 UDP listeners per interface Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: listening on IPv6 interfaces, port 53 Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: command channel listening on 127.0.0.1#953 Apr 13 22:42:53 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 13 22:42:54 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 15 07:55:08 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: client @0x7f50600e6060 89.39.107.167#39720 (mailgate.listen.com http://mailgate.listen.com): view external-wan-view: query: mailgate.listen.com http://mailgate.listen.com IN A +T (10.0.0.101) Apr 15 09:24:02 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: client @0x7f505c0ef630 91.191.209.122#44020 (mx.foodamentalisten.de http://mx.foodamentalisten.de): view external-wan-view: query: mx.foodamentalisten.de http://mx.foodamentalisten.de IN A +T (10.0.0.101)
Probably a "systemctl restart named" issued. PID 905 is shutting down.
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: no longer listening on ::#53 Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: no longer listening on 127.0.0.1#53 Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: no longer listening on 10.0.0.101#53 Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[905]: no longer listening on 192.168.122.1#53
And a new PID 309193 is starting. Also 309193 shows "good"
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: using 7 UDP listeners per interface Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: listening on IPv6 interfaces, port 53 Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: command channel listening on 127.0.0.1#953 Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: no longer listening on ::#53 Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: no longer listening on 127.0.0.1#53 Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: no longer listening on 10.0.0.101#53 Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[309193]: no longer listening on 192.168.122.1#53
<SNIP>
Here named is getting shutdown.
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[336009]: no longer listening on ::#53 Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[336009]: no longer listening on 127.0.0.1#53 Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[336009]: no longer listening on 10.0.0.101#53 Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[336009]: no longer listening on 192.168.122.1#53
The next day when name is started again we no longer see....
listening on IPv4 interface eno1, 10.0.0.101#53
So, what happened? What changed? All subsequent entries are "bad".
For "fun" how about rebooting the system?
since you've been guiding, i have changed only as guided,... rebooting, ...
On Fri, Apr 23, 2021 at 5:20 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 08:00, Jack Craig wrote:
ps -ax | grep named 1814955 pts/4 S+ 0:00 sudo vi /etc/named.conf 1814962 pts/4 S+ 0:00 /usr/bin/vim /etc/named.conf 1815795 ? Ssl 0:09 /usr/sbin/named -u named -c /etc/named.conf 1825164 pts/0 S+ 0:00 grep --color=auto named [root@ws named$ [root@ws named$ ncat -l 10.0.0.101 53
it does 'hang'
OK.... Had you left it hanging then had I run "nmap -sS 108.220.213.1" should have shown the port "open"
See the comments below.
This series on 4/13 is "good". Listening on all interfaces
journalctl -b 0 | grep -i listen | grep named Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: using 7 UDP listeners per interface
Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv6 interfaces, port 53
Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: command channel listening on 127.0.0.1#953
Apr 13 22:42:53 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv4 interface eno1, 10.0.0.101#53
Apr 13 22:42:54 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv4 interface virbr0, 192.168.122.1#53
Apr 15 07:55:08 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: client @0x7f50600e6060 89.39.107.167#39720 ( mailgate.listen.com http://mailgate.listen.com): view external-wan-view: query: mailgate.listen.com http://mailgate.listen.com IN A +T (10.0.0.101)
Apr 15 09:24:02 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: client @0x7f505c0ef630 91.191.209.122#44020 ( mx.foodamentalisten.de http://mx.foodamentalisten.de): view external-wan-view: query: mx.foodamentalisten.de < http://mx.foodamentalisten.de%3E IN A +T (10.0.0.101)
Probably a "systemctl restart named" issued. PID 905 is shutting down.
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on ::#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on 127.0.0.1#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on 10.0.0.101#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on 192.168.122.1#53
And a new PID 309193 is starting. Also 309193 shows "good"
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: using 7 UDP listeners per interface
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv6 interfaces, port 53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv4 interface eno1, 10.0.0.101#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv4 interface virbr0, 192.168.122.1#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: command channel listening on 127.0.0.1#953
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on ::#53
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on 127.0.0.1#53
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on 10.0.0.101#53
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on 192.168.122.1#53
<SNIP>
Here named is getting shutdown.
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on ::#53
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on 127.0.0.1#53
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on 10.0.0.101#53
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on 192.168.122.1#53
The next day when name is started again we no longer see....
listening on IPv4 interface eno1, 10.0.0.101#53
So, what happened? What changed? All subsequent entries are "bad".
For "fun" how about rebooting the system?
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
*post reboot*
*systemctl status named* ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-04-23 17:51:14 PDT; 5s ago Process: 3507 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Process: 3509 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 3510 (named) Tasks: 11 (limit: 38336) Memory: 66.0M CPU: 94ms CGroup: /system.slice/named.service └─3510 /usr/sbin/named -u named -c /etc/named.conf
Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './DNSKEY/IN': 2001:500:2f::f#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './NS/IN': 2001:500:2f::f#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './DNSKEY/IN': 2001:7fd::1#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './NS/IN': 2001:7fd::1#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './DNSKEY/IN': 2001:503:ba3e::2:30#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './NS/IN': 2001:503:ba3e::2:30#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './DNSKEY/IN': 2001:500:12::d0d#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: network unreachable resolving './NS/IN': 2001:500:12::d0d#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: managed-keys-zone: Key 20326 for zone . acceptance timer complete: key … trusted Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: resolver priming query complete Hint: Some lines were ellipsized, use -l to show in full. [root@ws jackc$ *journalctl -b 0 | grep -i listen | grep named* Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: using 7 UDP listeners per interface Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: listening on IPv6 interface lo, ::1#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: command channel listening on 127.0.0.1#953 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: command channel listening on ::1#953
On Fri, Apr 23, 2021 at 5:47 PM Jack Craig jack.craig.aptos@gmail.com wrote:
since you've been guiding, i have changed only as guided,... rebooting, ...
On Fri, Apr 23, 2021 at 5:20 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 08:00, Jack Craig wrote:
ps -ax | grep named 1814955 pts/4 S+ 0:00 sudo vi /etc/named.conf 1814962 pts/4 S+ 0:00 /usr/bin/vim /etc/named.conf 1815795 ? Ssl 0:09 /usr/sbin/named -u named -c /etc/named.conf 1825164 pts/0 S+ 0:00 grep --color=auto named [root@ws named$ [root@ws named$ ncat -l 10.0.0.101 53
it does 'hang'
OK.... Had you left it hanging then had I run "nmap -sS 108.220.213.1" should have shown the port "open"
See the comments below.
This series on 4/13 is "good". Listening on all interfaces
journalctl -b 0 | grep -i listen | grep named Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: using 7 UDP listeners per interface
Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv6 interfaces, port 53
Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 13 22:42:48 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: command channel listening on 127.0.0.1#953
Apr 13 22:42:53 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv4 interface eno1, 10.0.0.101#53
Apr 13 22:42:54 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: listening on IPv4 interface virbr0, 192.168.122.1#53
Apr 15 07:55:08 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: client @0x7f50600e6060 89.39.107.167#39720 ( mailgate.listen.com http://mailgate.listen.com): view external-wan-view: query: mailgate.listen.com http://mailgate.listen.com IN A +T (10.0.0.101)
Apr 15 09:24:02 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: client @0x7f505c0ef630 91.191.209.122#44020 ( mx.foodamentalisten.de http://mx.foodamentalisten.de): view external-wan-view: query: mx.foodamentalisten.de < http://mx.foodamentalisten.de%3E IN A +T (10.0.0.101)
Probably a "systemctl restart named" issued. PID 905 is shutting down.
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on ::#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on 127.0.0.1#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on 10.0.0.101#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[905]: no longer listening on 192.168.122.1#53
And a new PID 309193 is starting. Also 309193 shows "good"
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: using 7 UDP listeners per interface
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv6 interfaces, port 53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv4 interface eno1, 10.0.0.101#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: listening on IPv4 interface virbr0, 192.168.122.1#53
Apr 15 11:29:22 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: command channel listening on 127.0.0.1#953
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on ::#53
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on 127.0.0.1#53
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on 10.0.0.101#53
Apr 15 12:57:26 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[309193]: no longer listening on 192.168.122.1#53
<SNIP>
Here named is getting shutdown.
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on ::#53
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on 127.0.0.1#53
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on 10.0.0.101#53
Apr 15 19:02:47 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[336009]: no longer listening on 192.168.122.1#53
The next day when name is started again we no longer see....
listening on IPv4 interface eno1, 10.0.0.101#53
So, what happened? What changed? All subsequent entries are "bad".
For "fun" how about rebooting the system?
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 24/04/2021 08:47, Jack Craig wrote:
since you've been guiding, i have changed only as guided,... rebooting, ...
Well, I don't think this is exactly correct.
As I noted, the incorrect output started on 4/16
Apr 16 11:55:33 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: using 7 UDP listeners per interface Apr 16 11:55:33 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 11:55:33 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: command channel listening on 127.0.0.1#953 Apr 16 12:05:36 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: no longer listening on 127.0.0.1#53
At that time I hadn't made any directions as to what needed changing.
Also, on 4/21 you indicated
named 1263562 1 0 13:59 ? 00:00:05 /usr/sbin/named -u named -c /etc/named.conf -4
but today you indicated
1815795 ? Ssl 0:09 /usr/sbin/named -u named -c /etc/named.conf
So, something was changed to add/remove the -4 option. Not something I recall talking about.
It almost seems as if this is still being picked up in named.conf
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; };
Maybe send your current named.conf?
On Fri, Apr 23, 2021 at 6:24 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 08:47, Jack Craig wrote:
since you've been guiding, i have changed only as guided,... rebooting,
...
Well, I don't think this is exactly correct.
As I noted, the incorrect output started on 4/16
Apr 16 11:55:33 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: using 7 UDP listeners per interface Apr 16 11:55:33 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 16 11:55:33 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: command channel listening on 127.0.0.1#953 Apr 16 12:05:36 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[496814]: no longer listening on 127.0.0.1#53
At that time I hadn't made any directions as to what needed changing.
Also, on 4/21 you indicated
named 1263562 1 0 13:59 ? 00:00:05 /usr/sbin/named -u named -c /etc/named.conf -4
but today you indicated
1815795 ? Ssl 0:09 /usr/sbin/named -u named -c /etc/named.conf
So, something was changed to add/remove the -4 option. Not something I recall talking about.
It almost seems as if this is still being picked up in named.conf
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; };
this was a mystery to me too; i had -4 in a named.conf/options later i looked for it, but w/o success; maybe the named.service script??
Maybe send your current named.conf?
attaching isnt happening for some reason so i'l need to inline it. it should be exactly as you sent me, pls yell if not so?
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 24/04/2021 10:13, Jack Craig wrote:
Maybe send your current named.conf?attaching isnt happening for some reason so i'l need to inline it. it should be exactly as you sent me, pls yell if not so?
Ahhh..... the file you sent me contains exactly what it *should not* contain.
The file you sent me has...
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; };
That will cause named to listen ONLY on the loopback interfaces.
Change that to be
options { // listen-on port 53 { 127.0.0.1; }; // listen-on-v6 port 53 { ::1; };
Or *remove* those lines.
Or change them to add the IP addresses of you interfaces.
ok, done. now we have, ....
systemctl status named ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-04-23 19:25:59 PDT; 39s ago Process: 6480 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=0/SUCCESS) Process: 6482 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 6483 (named) Tasks: 11 (limit: 38336) Memory: 69.1M CPU: 139ms CGroup: /system.slice/named.service └─6483 /usr/sbin/named -u named -c /etc/named.conf
Apr 23 19:26:15 ws.linuxlighthouse.com named[6483]: client @0x7f455417fc20 38.145.60.13#38954 (ws.linuxlighthouse.com): que…' denied Apr 23 19:26:15 ws.linuxlighthouse.com named[6483]: client @0x7f455417fc20 38.145.60.13#55978 (linuxlighthouse.com): query …' denied Apr 23 19:26:15 ws.linuxlighthouse.com named[6483]: client @0x7f455417fc20 38.145.60.13#35236 (ws.linuxlighthouse.com): que…' denied Apr 23 19:26:15 ws.linuxlighthouse.com named[6483]: client @0x7f455417fc20 38.145.60.13#45456 (ws.linuxlighthouse.com): que…' denied Apr 23 19:26:16 ws.linuxlighthouse.com named[6483]: client @0x7f455417fc20 54.184.140.48#63353 (108-220-213-121.40.xiaofeng…' denied Apr 23 19:26:16 ws.linuxlighthouse.com named[6483]: client @0x7f453c0114b0 89.39.107.167#48830 (smtps.cartorel.fr): query (…' denied Apr 23 19:26:31 ws.linuxlighthouse.com named[6483]: client @0x7f455417fc20 172.217.40.66#60083 (ws.linuxlighthouse.com): qu…' denied Apr 23 19:26:32 ws.linuxlighthouse.com named[6483]: client @0x7f455417fc20 173.194.169.10#59596 (ws.linuxlighthouse.com): q…' denied Apr 23 19:26:32 ws.linuxlighthouse.com named[6483]: network unreachable resolving 'ssl.gstatic.com/AAAA/IN': 2001:4860:4802:38::a#53 Apr 23 19:26:38 ws.linuxlighthouse.com named[6483]: client @0x7f45541d8300 5.188.206.236#41644 (remote.basicuitvaartoosterh…' denied Hint: Some lines were ellipsized, use -l to show in full.
journalctl -b 0 | grep -i listen | grep named Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: using 7 UDP listeners per interface Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: listening on IPv6 interface lo, ::1#53 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: command channel listening on 127.0.0.1#953 Apr 23 17:51:14 ws.linuxlighthouse.com named[3510]: command channel listening on ::1#953 Apr 23 19:25:59 ws.linuxlighthouse.com named[3510]: no longer listening on 127.0.0.1#53 Apr 23 19:25:59 ws.linuxlighthouse.com named[3510]: no longer listening on ::1#53 Apr 23 19:25:59 ws.linuxlighthouse.com named[6483]: using 7 UDP listeners per interface Apr 23 19:25:59 ws.linuxlighthouse.com named[6483]: listening on IPv6 interfaces, port 53 Apr 23 19:25:59 ws.linuxlighthouse.com named[6483]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 23 19:25:59 ws.linuxlighthouse.com named[6483]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 23 19:25:59 ws.linuxlighthouse.com named[6483]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 23 19:25:59 ws.linuxlighthouse.com named[6483]: command channel listening on 127.0.0.1#953 Apr 23 19:25:59 ws.linuxlighthouse.com named[6483]: command channel listening on ::1#953 [root@ws ~$ netstat -nap | grep named tcp 0 0 10.0.0.101:53 0.0.0.0:* LISTEN 6483/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 6483/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 6483/named tcp6 0 0 :::53 :::* LISTEN 6483/named tcp6 0 0 ::1:953 :::* LISTEN 6483/named udp 0 0 192.168.122.1:53 0.0.0.0:* 6483/named udp 0 0 10.0.0.101:53 0.0.0.0:* 6483/named udp 0 0 127.0.0.1:53 0.0.0.0:* 6483/named udp6 0 0 :::53 :::* 6483/named unix 2 [ ] DGRAM 88018 6483/named
unix 2 [ ] STREAM CONNECTED 88021 6483/named
[root@ws ~$
On Fri, Apr 23, 2021 at 7:20 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 10:13, Jack Craig wrote:
Maybe send your current named.conf?attaching isnt happening for some reason so i'l need to inline it. it should be exactly as you sent me, pls yell if not so?
Ahhh..... the file you sent me contains exactly what it *should not* contain.
The file you sent me has...
options { listen-on port 53 { 127.0.0.1; }; listen-on-v6 port 53 { ::1; };
That will cause named to listen ONLY on the loopback interfaces.
Change that to be
options { // listen-on port 53 { 127.0.0.1; }; // listen-on-v6 port 53 { ::1; };
Or *remove* those lines.
Or change them to add the IP addresses of you interfaces.
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 24/04/2021 10:29, Jack Craig wrote:
ok, done. now we have, ....
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[6483]: using 7 UDP listeners per interface Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[6483]: listening on IPv6 interfaces, port 53 Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[6483]: listening on IPv4 interface lo, 127.0.0.1#53 Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[6483]: listening on IPv4 interface eno1, 10.0.0.101#53 Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[6483]: listening on IPv4 interface virbr0, 192.168.122.1#53 Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[6483]: command channel listening on 127.0.0.1#953 Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com named[6483]: command channel listening on ::1#953
And I see.....
Nmap scan report for ws.linuxlighthouse.com (108.220.213.121) Host is up (0.16s latency). Not shown: 997 filtered ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http 443/tcp open https
And I get
[egreshko@meimei ~]$ host cnn.com 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases:
Host cnn.com not found: 5(REFUSED)
Which is correct since your named.conf currently contains
allow-query { localhost; };
So, at least your server is now contactable from the Internet. So you can go about adding in the zones you need as well as the access you want to allow.
This is wonderful ED, Thank YOU!!
first tho, a backup of key files...
On Fri, Apr 23, 2021 at 7:37 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 10:29, Jack Craig wrote:
ok, done. now we have, ....
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: using 7 UDP listeners per interface
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv6 interfaces, port 53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv4 interface eno1, 10.0.0.101#53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv4 interface virbr0, 192.168.122.1#53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: command channel listening on 127.0.0.1#953
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: command channel listening on ::1#953
And I see.....
Nmap scan report for ws.linuxlighthouse.com (108.220.213.121) Host is up (0.16s latency). Not shown: 997 filtered ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http 443/tcp open https
And I get
[egreshko@meimei ~]$ host cnn.com 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases:
Host cnn.com not found: 5(REFUSED)
Which is correct since your named.conf currently contains
allow-query { localhost; };So, at least your server is now contactable from the Internet. So you can go about adding in the zones you need as well as the access you want to allow.
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
almost, but no seegar,...
i and continuing to have dig lookups for linuxlighthouse.com a is timing out(refused or servfail)
anyone see my misconfiguration?? one error i need to address, my domain is 'linuxlighthouse.com'
i have mistakenly tried to include ws.linuxlighthouse.com & www.linuxlighthouse.com in my certificates..
i am missing the record to define www.<linuxlighthouse.com> ?
tia, jackc...
# Name Server: NS3.ATTDNS.COM # Name Server: WS.LINUXLIGHTHOUSE.COM
nmap -sS 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-30 13:07 PDT Nmap scan report for ws (108.220.213.121) Host is up (0.0020s latency). Not shown: 993 closed ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http 443/tcp open https 631/tcp open ipp 5000/tcp open upnp 8200/tcp open trivnet1 20005/tcp open btx
Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds [root@ws named$ netstat -tapnl | grep named tcp 0 0 10.0.0.101:53 0.0.0.0:* LISTEN 20563/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 20563/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 20563/named tcp6 0 0 :::53 :::* LISTEN 20563/named tcp6 0 0 ::1:953 :::* LISTEN 20563/named
nmap -A -T4 -p53 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-30 13:10 PDT Nmap scan report for ws (108.220.213.121) Host is up (0.0013s latency).
PORT STATE SERVICE VERSION 53/tcp open domain (generic dns response: NOTIMP) | fingerprint-strings: | DNSVersionBindReqTCP: | version |_ bind 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port53-TCP:V=7.80%I=7%D=4/30%Time=608C645D%P=x86_64-redhat-linux-gnu%r( SF:DNSVersionBindReqTCP,20,"\0\x1e\0\x06\x81\x05\0\x01\0\0\0\0\0\0\x07vers SF:ion\x04bind\0\0\x10\0\x03")%r(DNSStatusRequestTCP,E,"\0\x0c\0\0\x90\x04 SF:\0\0\0\0\0\0\0\0"); Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose|WAP|phone|storage-misc|proxy server|media device Running (JUST GUESSING): Linux 4.X|2.6.X|3.X (93%), Linksys embedded (93%), Google Android 4.4.X (92%), Synology DiskStation Manager 5.X (91%), WebSense embedded (90%), BlackBox embedded (90%) OS CPE: cpe:/o:linux:linux_kernel:4.4 cpe:/o:linux:linux_kernel cpe:/h:linksys:ea3500 cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3.16 cpe:/o:google:android:4.4.0 cpe:/a:synology:diskstation_manager:5.2 Aggressive OS guesses: Linux 4.4 (93%), Linksys EA3500 WAP (93%), Linux 2.6.18 - 2.6.32 (93%), Linux 3.16 (93%), Android 4.4.0 (92%), Linux 3.2 - 4.9 (92%), Linux 2.6.32 - 3.10 (91%), Linux 2.6.32 (91%), Linux 2.6.32 - 2.6.35 (91%), Linux 2.6.32 - 3.5 (91%) No exact OS matches for host (test conditions non-ideal). Network Distance: 1 hop
TRACEROUTE (using port 53/tcp) HOP RTT ADDRESS 1 0.87 ms ws (108.220.213.121)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 33.84 seconds
nmap -A -T4 -sU -p53 108.220.213.121 Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-30 13:12 PDT Nmap scan report for ws (108.220.213.121) Host is up (0.0013s latency).
PORT STATE SERVICE VERSION 53/udp open domain (generic dns response: NOTIMP) | fingerprint-strings: | DNSVersionBindReq: | version | bind | NBTStat: |_ CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port53-UDP:V=7.80%I=7%D=4/30%Time=608C64C1%P=x86_64-redhat-linux-gnu%r( SF:DNSVersionBindReq,1E,"\0\x06\x81\x05\0\x01\0\0\0\0\0\0\x07version\x04bi SF:nd\0\0\x10\0\x03")%r(DNSStatusRequest,C,"\0\0\x90\x04\0\0\0\0\0\0\0\0") SF:%r(NBTStat,32,"\x80\xf0\x80\x15\0\x01\0\0\0\0\0\0\x20CKAAAAAAAAAAAAAAAA SF:AAAAAAAAAAAAAA\0\0!\0\x01"); Too many fingerprints match this host to give specific OS details Network Distance: 1 hop
TRACEROUTE (using port 53/udp) HOP RTT ADDRESS 1 1.56 ms ws (108.220.213.121)
netstat -nap | grep named tcp 0 0 10.0.0.101:53 0.0.0.0:* LISTEN 20563/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 20563/named tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 20563/named tcp6 0 0 :::53 :::* LISTEN 20563/named tcp6 0 0 ::1:953 :::* LISTEN 20563/named udp 0 0 192.168.122.1:53 0.0.0.0:* 20563/named udp 0 0 10.0.0.101:53 0.0.0.0:* 20563/named udp 0 0 127.0.0.1:53 0.0.0.0:* 20563/named udp6 0 0 :::53 :::* 20563/named unix 2 [ ] STREAM CONNECTED 130890 20563/named
unix 2 [ ] DGRAM 130887 20563/named
On Fri, Apr 23, 2021 at 7:37 PM Ed Greshko ed.greshko@greshko.com wrote:
On 24/04/2021 10:29, Jack Craig wrote:
ok, done. now we have, ....
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: using 7 UDP listeners per interface
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv6 interfaces, port 53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv4 interface eno1, 10.0.0.101#53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: listening on IPv4 interface virbr0, 192.168.122.1#53
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: command channel listening on 127.0.0.1#953
Apr 23 19:25:59 ws.linuxlighthouse.com http://ws.linuxlighthouse.com
named[6483]: command channel listening on ::1#953
And I see.....
Nmap scan report for ws.linuxlighthouse.com (108.220.213.121) Host is up (0.16s latency). Not shown: 997 filtered ports PORT STATE SERVICE 53/tcp open domain 80/tcp open http 443/tcp open https
And I get
[egreshko@meimei ~]$ host cnn.com 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases:
Host cnn.com not found: 5(REFUSED)
Which is correct since your named.conf currently contains
allow-query { localhost; };So, at least your server is now contactable from the Internet. So you can go about adding in the zones you need as well as the access you want to allow.
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 01/05/2021 04:32, Jack Craig wrote:
almost, but no seegar,...
i and continuing to have dig lookups for linuxlighthouse.com http://linuxlighthouse.com a is timing out(refused or servfail)
anyone see my misconfiguration?? one error i need to address, my domain is 'linuxlighthouse.com http://linuxlighthouse.com'
i have mistakenly tried to include ws.linuxlighthouse.com http://ws.linuxlighthouse.com & www.linuxlighthouse.com http://www.linuxlighthouse.com in my certificates..
i am missing the record to define www.<linuxlighthouse.com http://linuxlighthouse.com> ?
I think my last response didn't go far enough to explain.
I had said:
[egreshko@meimei ~]$ host cnn.com <http://cnn.com> 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases: Host cnn.com <http://cnn.com> not found: 5(REFUSED) Which is correct since your named.conf currently contains allow-query { localhost; }; So, at least your server is now contactable from the Internet. So you can go about adding in the zones you need as well as the access you want to allow.
Your dns server REFUSED to answer the query. That is "correct" for the *test* named.conf file I sent. The *test* configuration contains....
allow-query { localhost; };
meaning only request sent via 127.0.0.1 will be serviced. All other sources will be REFUSED. Even a query from another host on your internal 10.0.0.X network will get REFUSED.
You need to fix that configuration option to allow queries from elsewhere.
On Fri, Apr 30, 2021 at 3:03 PM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 04:32, Jack Craig wrote:
almost, but no seegar,...
i and continuing to have dig lookups for linuxlighthouse.com <
http://linuxlighthouse.com%3E a is timing out(refused or servfail)
anyone see my misconfiguration?? one error i need to address, my domain is 'linuxlighthouse.com <
http://linuxlighthouse.com%3E'
i have mistakenly tried to include ws.linuxlighthouse.com <
http://ws.linuxlighthouse.com%3E & www.linuxlighthouse.com < http://www.linuxlighthouse.com%3E in my certificates..
i am missing the record to define www.<linuxlighthouse.com <
http://linuxlighthouse.com%3E%3E ?
I think my last response didn't go far enough to explain.
I had said:
[egreshko@meimei ~]$ host cnn.com <http://cnn.com> 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases: Host cnn.com <http://cnn.com> not found: 5(REFUSED) Which is correct since your named.conf currently contains allow-query { localhost; }; So, at least your server is now contactable from the Internet. Soyou can go about adding in the zones
you need as well as the access you want to allow.Your dns server REFUSED to answer the query. That is "correct" for the *test* named.conf file I sent. The *test* configuration contains....
allow-query { localhost; };
i would think that *allow-query { localhost; 108.220.213.121; };*
but that does not appear to work for me. what am i missing here?
tia, jackc...
meaning only request sent via 127.0.0.1 will be serviced. All other sources will be REFUSED. Even a query from another host on your internal 10.0.0.X network will get REFUSED.
You need to fix that configuration option to allow queries from elsewhere.
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
adding 108.220.213.121 to /etc/resolv.conf also doesnt seem to help...
On Fri, Apr 30, 2021 at 8:28 PM Jack Craig jack.craig.aptos@gmail.com wrote:
On Fri, Apr 30, 2021 at 3:03 PM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 04:32, Jack Craig wrote:
almost, but no seegar,...
i and continuing to have dig lookups for linuxlighthouse.com <
http://linuxlighthouse.com%3E a is timing out(refused or servfail)
anyone see my misconfiguration?? one error i need to address, my domain is 'linuxlighthouse.com <
http://linuxlighthouse.com%3E'
i have mistakenly tried to include ws.linuxlighthouse.com <
http://ws.linuxlighthouse.com%3E & www.linuxlighthouse.com < http://www.linuxlighthouse.com%3E in my certificates..
i am missing the record to define www.<linuxlighthouse.com <
http://linuxlighthouse.com%3E%3E ?
I think my last response didn't go far enough to explain.
I had said:
[egreshko@meimei ~]$ host cnn.com <http://cnn.com> 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases: Host cnn.com <http://cnn.com> not found: 5(REFUSED) Which is correct since your named.conf currently contains allow-query { localhost; }; So, at least your server is now contactable from the Internet. Soyou can go about adding in the zones
you need as well as the access you want to allow.Your dns server REFUSED to answer the query. That is "correct" for the *test* named.conf file I sent. The *test* configuration contains....
allow-query { localhost; };
i would think that *allow-query { localhost; 108.220.213.121; };*
but that does not appear to work for me. what am i missing here?
tia, jackc...
meaning only request sent via 127.0.0.1 will be serviced. All other sources will be REFUSED. Even a query from another host on your internal 10.0.0.X network will get REFUSED.
You need to fix that configuration option to allow queries from elsewhere.
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 01/05/2021 11:28, Jack Craig wrote:
On Fri, Apr 30, 2021 at 3:03 PM Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
> > > [egreshko@meimei ~]$ host cnn.com <http://cnn.com> <http://cnn.com <http://cnn.com>> 108.220.213.121 > Using domain server: > Name: 108.220.213.121 > Address: 108.220.213.121#53 > Aliases: > > Host cnn.com <http://cnn.com> <http://cnn.com <http://cnn.com>> not found: 5(REFUSED) > > Which is correct since your named.conf currently contains > > allow-query { localhost; }; > > So, at least your server is now contactable from the Internet. So you can go about adding in the zones > you need as well as the access you want to allow. > Your dns server REFUSED to answer the query. That is "correct" for the *test* named.conf file I sent. The *test* configuration contains.... allow-query { localhost; };i would think that *allow-query { localhost; 108.220.213.121; };*
but that does not appear to work for me. what am i missing here?
You are missing the fact that you attempting to run a *public* DNS server.
That means that your DNS server must accept queries from *any* source address.
allow-query { any; };
is what you'll need.
On Fri, Apr 30, 2021 at 9:05 PM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 11:46, Jack Craig wrote:
adding 108.220.213.121 to /etc/resolv.conf also doesnt seem to help...
That file has nothing to do with the DNS server.
I thought that list of NSs was the NS list used to resolve any lookup, yet another misconception on my part...
as allow-query { any; };
alone does not clear up the dns lookup failure, i had an earlier zone file that spelled out my noton of domain lookup, what is the lookup process laid out?
*REFUSED unexpected RCODE resolving 'linuxlighthouse.com/A/IN http://linuxlighthouse.com/A/IN': 144.160.20.47#53* what is more i find the below error in the named-run log, how do i drill down to find this ns3.attdns lookup failure??
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, Apr 18, 2021 at 12:59 PM Ed Greshko ed.greshko@greshko.com wrote:
On 19/04/2021 03:18, Jack Craig wrote:
On Fri, Apr 16, 2021 at 12:52 PM Doug H. <fedoraproject.org@wombatz.com
mailto:fedoraproject.org@wombatz.com> wrote:
On Fri, Apr 16, 2021, at 10:56 AM, Ed Greshko wrote: > On 16/04/2021 17:19, Ed Greshko wrote: > > On 16/04/2021 10:35, Jack Craig wrote: > >> First I get my static IP from AT&T actually a block of eightaddresses of which only the first do they agree to pass through.
> >> > > > > BTW, if you are hosting the DNS server and if your DNS serverhas the IP address of 108.220.213.121 then
> > this could be a problem.
*would you expand on this comment? i think this is an issue,... thx..*
You removed the most important part of my comment. Which was....
PORT STATE SERVICE VERSION 53/udp closed domain 53/tcp closed domain
This mean you don't have a DNS server (bind, I assume) listening on the standard port 53 on the 108.220.213.121 interface. That means that no system outside of your internals (10.0.0.x) can query your DNS server.
If I "telnet" to port 53 (tcp) to my ISP's name server...
[egreshko@meimei ~]$ telnet 168.95.1.1 53 Trying 168.95.1.1... Connected to 168.95.1.1. Escape character is '^]'. ^] telnet> close Connection closed.
Yours?
telnet 108.220.213.121 53 Trying 108.220.213.121... Connected to 108.220.213.121. Escape character is '^]'. Connection closed by foreign host.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 01/05/2021 12:31, Jack Craig wrote:
On Fri, Apr 30, 2021 at 9:05 PM Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
On 01/05/2021 11:46, Jack Craig wrote: > adding 108.220.213.121 to /etc/resolv.conf also doesnt seem to help... That file has nothing to do with the DNS server.I thought that list of NSs was the NS list used to resolve any lookup, yet another misconception on my part...
as allow-query { any; };
alone does not clear up the dns lookup failure, i had an earlier zone file that spelled out my noton of domain lookup, what is the lookup process laid out?
*REFUSED unexpected RCODE resolving 'linuxlighthouse.com/A/IN http://linuxlighthouse.com/A/IN': 144.160.20.47#53* what is more i find the below error in the named-run log, how do i drill down to find this ns3.attdns lookup failure??
You're sort of getting there. Right now you have recursion turn on. Eventually you'll want to turn that off.
But, at the moment if query your server I get
[egreshko@acer ~]$ host cnn.com 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases:
cnn.com has address 151.101.1.67 etc.....
Which means at least it is listening and processing recursive queries.
However.....
[egreshko@acer ~]$ host ws.linuxlighthouse.com 108.220.213.121 ;; connection timed out; no servers could be reached
That would seem to suggest that you don't have a zone configured for linuxlighthouse.com.
On Fri, Apr 30, 2021 at 10:14 PM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 12:31, Jack Craig wrote:
On Fri, Apr 30, 2021 at 9:05 PM Ed Greshko <ed.greshko@greshko.com
mailto:ed.greshko@greshko.com> wrote:
On 01/05/2021 11:46, Jack Craig wrote: > adding 108.220.213.121 to /etc/resolv.conf also doesnt seem tohelp...
That file has nothing to do with the DNS server.I thought that list of NSs was the NS list used to resolve any lookup,
yet another misconception on my part...
as allow-query { any; };
alone does not clear up the dns lookup failure, i had an earlier zone
file that spelled out my noton of domain lookup,
what is the lookup process laid out?
*REFUSED unexpected RCODE resolving 'linuxlighthouse.com/A/IN <
http://linuxlighthouse.com/A/IN%3E': 144.160.20.47#53*
what is more i find the below error in the named-run log, how do i drill
down to find this ns3.attdns
lookup failure??
You're sort of getting there. Right now you have recursion turn on. Eventually you'll want to turn that off.
But, at the moment if query your server I get
[egreshko@acer ~]$ host cnn.com 108.220.213.121 Using domain server: Name: 108.220.213.121 Address: 108.220.213.121#53 Aliases:
cnn.com has address 151.101.1.67 etc.....
Which means at least it is listening and processing recursive queries.
However.....
[egreshko@acer ~]$ host ws.linuxlighthouse.com 108.220.213.121 ;; connection timed out; no servers could be reached
That would seem to suggest that you don't have a zone configured for linuxlighthouse.com.
/usr/sbin/named-checkzone -d linuxlighthouse.com
/var/named/linuxlighthouse.com.db loading "linuxlighthouse.com" from "/var/named/linuxlighthouse.com.db" class "IN" zone linuxlighthouse.com/IN: loaded serial 2021042001 OK /usr/sbin/named-compilezone -i full -o - linuxlighthouse.com /var/named/linuxlighthouse.com.db zone linuxlighthouse.com/IN: loaded serial 2021042001 linuxlighthouse.com. 86400 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2021042001 86400 3600 604800 86400 linuxlighthouse.com. 86400 IN NS ws.linuxlighthouse.com. linuxlighthouse.com. 86400 IN A 108.220.213.121 linuxlighthouse.com. 86400 IN CAA 0 issue "letsencrypt.org" mail.linuxlighthouse.com. 86400 IN A 108.220.213.121 ws.linuxlighthouse.com. 86400 IN A 108.220.213.121 ws.linuxlighthouse.com. 86400 IN MX 10 ws.linuxlighthouse.com. ws2.linuxlighthouse.com. 86400 IN A 108.220.213.122 www.linuxlighthouse.com. 86400 IN A 108.220.213.121 OK *dig linuxlighthouse.com http://linuxlighthouse.com a*
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc32 <<>> linuxlighthouse.com a ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43116 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 72bffb4054c2ec9b4b228327608d02f41eb498288e928de9 (good) ;; QUESTION SECTION: ;linuxlighthouse.com. IN A
;; ANSWER SECTION: linuxlighthouse.com. 86400 IN A 108.220.213.121
;; AUTHORITY SECTION: linuxlighthouse.com. 86400 IN NS ws.linuxlighthouse.com.
;; ADDITIONAL SECTION: ws.linuxlighthouse.com. 86400 IN A 108.220.213.121
;; Query time: 1 msec ;; SERVER: 108.220.213.121#53(108.220.213.121) ;; WHEN: Sat May 01 00:27:48 PDT 2021 ;; MSG SIZE rcvd: 125
[jackc@ws etc $ host linuxlighthouse.com linuxlighthouse.com has address 108.220.213.121
[jackc@ws etc $ *host linuxlighthouse.com http://linuxlighthouse.com* linuxlighthouse.com has address 108.220.213.121
seems t be working better, how many holes do you see at this point??
thx, ...
On 01/05/2021 15:31, Jack Craig wrote:
seems t be working better, how many holes do you see at this point??
Since this now works....
[egreshko@meimei ~]$ host ws.linuxlighthouse.com ws.linuxlighthouse.com has address 108.220.213.121 ws.linuxlighthouse.com mail is handled by 10 ws.linuxlighthouse.com.
I'd say you're very close. People outside of your network can now query just fine.
As for holes.....
1. If you are going to host an email server then you have some changes to make. Normally email addresses are "domain" addresses as opposed to "host" addreses. So, you'd normally want your email address to be e.g. "jack@linuxlighthouse.com". But you don't have an MX record for your domain. You have it for a host.
[egreshko@meimei ~]$ host ws.linuxlighthouse.com ws.linuxlighthouse.com has address 108.220.213.121 ws.linuxlighthouse.com mail is handled by 10 ws.linuxlighthouse.com.
You'd really want these returns (I've, of course, made those up)
[egreshko@meimei ~]$ host linuxlighthouse.com linuxlighthouse.com has address 108.220.213.121 linuxlighthouse.com mail is handled by 10 ws.linuxlighthouse.com.
and
[egreshko@meimei ~]$ host ws.linuxlighthouse.com ws.linuxlighthouse.com has address 108.220.213.121
2. You now want to fix your named.conf to have "recursion no;" The default is "yes". You don't want your DNS server acting as a server every domain. If someone queries your server directly you want it to return (using cnn.com as the example).
Host cnn.com not found: 5(REFUSED)
3. And, I think you already know this, your web server's cert is wrong. The security report is
This server could not prove that it is linuxlighthouse.com; its security certificate is from ws.linuxlighthouse.com. This may be caused by a misconfiguration or an attacker intercepting your connection.
On Sat, May 1, 2021 at 1:32 AM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 15:31, Jack Craig wrote:
seems t be working better, how many holes do you see at this point??
Since this now works....
Well let's say it's limping along, as you point out below, it has some issues but that's great
huge step for me thanks to you guys
[egreshko@meimei ~]$ host ws.linuxlighthouse.com ws.linuxlighthouse.com has address 108.220.213.121 ws.linuxlighthouse.com mail is handled by 10 ws.linuxlighthouse.com.
I'd say you're very close. People outside of your network can now query just fine.
Yes the proverbial devil in the details
As for holes.....
- If you are going to host an email server then you have some changes to
make.
Well I'm not going to serve mailbut, I do want to have my DNS properly configured . so chasing down and resolving all these little issues is next
Normally email addresses are "domain" addresses as opposed to "host"
addreses. So, you'd normally want your email address to be e.g. " jack@linuxlighthouse.com". But you don't have an MX record for your domain. You have it for a host.
I actually have a host to serve this IP number so this error too must go
what's 'not clear to me is how I can expose that host/ip through my firewall configuration but in either case I want to get this MX configuration correct
[egreshko@meimei ~]$ host ws.linuxlighthouse.com ws.linuxlighthouse.com has address 108.220.213.121 ws.linuxlighthouse.com mail is handled by 10 ws.linuxlighthouse.com.
You'd really want these returns (I've, of course, made those up)
[egreshko@meimei ~]$ host linuxlighthouse.com linuxlighthouse.com has address 108.220.213.121 linuxlighthouse.com mail is handled by 10 ws.linuxlighthouse.com.
and
[egreshko@meimei ~]$ host ws.linuxlighthouse.com ws.linuxlighthouse.com has address 108.220.213.121
- You now want to fix your named.conf to have "recursion no;" The
default is "yes". You don't want your DNS server acting as a server every domain. If someone queries your server directly you want it to return (using cnn.com as the example).
This recursion option has been turned off right now , thank you for that
Host cnn.com not found: 5(REFUSED)
- And, I think you already know this, your web server's cert is wrong.
The security report is
It's a result of a confusion on my part about the difference between domain names and subdomains, i am updating letsencrypt now and looking to verify my ssl layer is setup correctly.
This server could not prove that it is linuxlighthouse.com; its security certificate is from ws.linuxlighthouse.com. This may be caused by a misconfiguration or an attacker intercepting your connection
Linuxlighthouse.com is the domain name ,ws.linuxlighthouse.com is the DNS servers' name.
It's definitely misconfiguration. in this case there's nothing on this side of the firewall that any attacker would want :(
-- Remind me to ignore comments which aren't germane to the thread.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 01/05/2021 16:31, Ed Greshko wrote:
After I sent the previous post I realized what I *think* is your goal. If I recall you're wanting your DNS server to service queries from inside your network as well as from outside.
As currently configured your DNS server is acting as an external/public server only.
So this....
2. You now want to fix your named.conf to have "recursion no;" The default is "yes". You don't want your DNS server acting as a server every domain. If someone queries your server directly you want it to return (using cnn.com as the example).
Host cnn.com not found: 5(REFUSED)
Would also result in this....
[egreshko@f33k ~]$ host cnn.com localhost Using domain server: Name: localhost Address: ::1#53 Aliases:
Host cnn.com not found: 5(REFUSED)
Which is certainly not what you'd want.
There are, in my mind, 2 schools of thought on "fixing" this.
1. If you have a small number of system in your local network just let them query external DNS servers such as your ISP's DNS server. You can handle exception using the /etc/hosts file.
2. Configure your DNS server with, I think the correct term is "views", such that an internal system query returns internal IP addresses (10.0.0.X) and an internal query allows recursion.
#1 is easy #2 requires research and work.
On 01/05/2021 17:16, Jack Craig wrote:
Well I'm not going to serve mailbut, I do want to have my DNS properly configured . so chasing down and resolving all these little issues is next
If you're not going to serve email and your not going to use email addresses in the linuxlighthouse.com domain then you don't want to define MX records.
MX records are "Mail eXchange" records and are specific to email.
Normally email addresses are "domain" addresses as opposed to "host" addreses. So, you'd normally want your email address to be e.g. "jack@linuxlighthouse.com <mailto:jack@linuxlighthouse.com>". But you don't have an MX record for your domain. You have it for a host.I actually have a host to serve this IP number so this error too must go
You do want an IP address for the "domain host" since you do want to service http://linuxlighthouse.com
what's 'not clear to me is how I can expose that host/ip through my firewall configuration but in either case I want to get this MX configuration correct
Again, not using @linuxlighthouse.com email addresses.....no MX records should be defined.
This recursion option has been turned off right now , thank you for that
See another post in the thread about this.
It's definitely misconfiguration. in this case there's nothing on this side of the firewall that any attacker would want :(
That may not be "true". If, for example, your web server is badly configured or otherwise lax in security it could be used as part of a phishing expedition.
On Sat, May 1, 2021 at 2:19 AM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 16:31, Ed Greshko wrote:
After I sent the previous post I realized what I *think* is your goal. If I recall you're wanting your DNS server to service queries from inside your network as well as from outside.
As currently configured your DNS server is acting as an external/public server only.
So this....
- You now want to fix your named.conf to have "recursion no;" The default is "yes".
You don't want your DNS server acting as a server every domain. If someone queries
your server directly you want it to return (using cnn.com
as the example).
Host cnn.com not found: 5(REFUSED)
Would also result in this....
[egreshko@f33k ~]$ host cnn.com localhost Using domain server: Name: localhost Address: ::1#53 Aliases:
Host cnn.com not found: 5(REFUSED)
Which is certainly not what you'd want.
There are, in my mind, 2 schools of thought on "fixing" this.
- If you have a small number of system in your local network just let
them query external DNS servers such as your ISP's DNS server. You can handle exception using the /etc/hosts file.
- Configure your DNS server with, I think the correct term is "views",
such that an internal system query returns internal IP addresses (10.0.0.X) and an internal query allows recursion.
#1 is easy #2 requires research and work.
I'll hold off deciding this for the moment, i need some sleep, ...
Still, i got a start on views/zones and /etc/named.conf is currently setup as ..
*view "wan-view"{ zone "linuxlighthouse.com http://linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-update { none; }; }; zone "." IN { type hint; file "named.ca http://named.ca"; };};* again, Thanks for all the support!!
On 01/05/2021 17:28, Jack Craig wrote:
I'll hold off deciding this for the moment, i need some sleep, ...
Still, i got a start on views/zones and /etc/named.conf is currently setup as ..
*view "wan-view" { zone "linuxlighthouse.com http://linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-update { none; }; };
zone "." IN { type hint; file "named.ca http://named.ca"; }; };* again, Thanks for all the support!!
Well, if you decide on using views you may want to check out the examples here
https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm
On Sat, 2021-05-01 at 17:28 +0800, Ed Greshko wrote:
If you're not going to serve email and your not going to use email addresses in the linuxlighthouse.com domain then you don't want to define MX records.
Or, you have an MX record that points to where your email is being hosted by something else.
On Sat, 2021-05-01 at 12:04 +0800, Ed Greshko wrote:
You are missing the fact that you attempting to run a *public* DNS server.
That means that your DNS server must accept queries from *any* source address.
allow-query { any; };
is what you'll need.
Supplemental info: You allow all queries, but you only provide answers for your own domain.
On 01/05/2021 20:07, Tim via users wrote:
On Sat, 2021-05-01 at 12:04 +0800, Ed Greshko wrote:
You are missing the fact that you attempting to run a *public* DNS server.
That means that your DNS server must accept queries from *any* source address.
allow-query { any; };
is what you'll need.
Supplemental info: You allow all queries, but you only provide answers for your own domain.
I covered that in a follow-on post. I didn't want to reveal that too soon as to not be able to verify a working configuration from afar.
It was actually good that I did that since the OP had a working config except that he hadn't defined a zone. So, I knew most things were working.
On 01/05/2021 20:05, Tim via users wrote:
On Sat, 2021-05-01 at 17:28 +0800, Ed Greshko wrote:
If you're not going to serve email and your not going to use email addresses in the linuxlighthouse.com domain then you don't want to define MX records.
Or, you have an MX record that points to where your email is being hosted by something else.
It sounded as if he wasn't going to use @linuxlighthouse.com for any emails.
Besides, if one insists on running their own DNS server instead of letting their registra do it I see them, if they are going to use email, insisting on running their own email server. :-) ;-)
On 4/30/21 1:32 PM, Jack Craig wrote:
almost, but no seegar,...
i and continuing to have dig lookups for linuxlighthouse.com a is timing out(refused or servfail)
anyone see my misconfiguration?? one error i need to address, my domain is 'linuxlighthouse.com'
i have mistakenly tried to include ws.linuxlighthouse.com & www.linuxlighthouse.com in my certificates..
I don't think that is a problem. My one certificate has two domains and five subdomains. Works fine.
On 4/30/21 9:31 PM, Jack Craig wrote:
On Fri, Apr 30, 2021 at 9:05 PM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 11:46, Jack Craig wrote:
adding 108.220.213.121 to /etc/resolv.conf also doesnt seem to help...
That file has nothing to do with the DNS server.
I thought that list of NSs was the NS list used to resolve any lookup, yet another misconception on my part...
as allow-query { any; };
alone does not clear up the dns lookup failure, i had an earlier zone file that spelled out my noton of domain lookup, what is the lookup process laid out?
*REFUSED unexpected RCODE resolving 'linuxlighthouse.com/A/IN http://linuxlighthouse.com/A/IN': 144.160.20.47#53* what is more i find the below error in the named-run log, how do i drill down to find this ns3.attdns lookup failure??
ns3.attdns.com. does publish an SOA record for linuxlighthouse.com.:
linuxlighthouse.com. 21599 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com.
It states that ws.linuxlighthouse.com. is the primary nameserver for the zone (and also the source for zone transfers) whose contact address is root@linuxlighthouse.com. attdns is secondary and gets its data from ws. Until ws publishes valid zone data lookups at attdns will be refused (no data available). To make that data available you will have to allow zone transfers TO ns3.attdns.com.
I created a zone file generator that produces the basics in either tinydns or bind format. Here's what it produced with your information:
$TTL 3D ; default ttl for records without a specified lifetime $ORIGIN 121.213.220.108.in-addr.arpa. @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 1619886507 ; serial number 16384 ; ns refresh 2048 ; ns retry 1048576 ; authority expiry 2560 ); min (RFC2308 §4) IN NS ws.linuxlighthouse.com. IN NS ns3.attdns.com.
$TTL 3D ; default ttl for records without a specified lifetime $ORIGIN linuxlighthouse.com. @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 1619886507 ; serial number 16384 ; ns refresh 2048 ; ns retry 1048576 ; authority expiry 2560 ); min (RFC2308 §4) IN NS ws.linuxlighthouse.com. IN NS ns3.attdns.com. ws IN A 108.220.213.121
I use knotd and know it won't accept the default times (the stuff between the parentheses) unless they are on one line. Bind, I can't say. To remove any ambiguities, and save yourself having to debug that, reformat what I provided so that your SOA is all on one line. Be sure to remove the comments before you do that. I can't help you with the bind config but you will have to provide server names, listening IPs, remote address of the secondary, probably some ACL, and a list of the zones that it will answer for.
By the way, I use this generator for my own nameservers (knotd) modified so the SOA is on one line and it works.
If by some chance you want to try knotd I also have a generator that creates the knot.conf files. If you go that route I can provide you with a knot.conf for your primary.
I've avoided bind like the plague since 4.something because I got owned. So, I upgraded to 4.9.3 and was owned within 3 seconds. Switched to tinydns which served very well for many years but has become a bit crusty. I use it internally for some stuff (VMs, etc) but it no longer serves well when working with mailservers. knot is fast and reliable and I recommend it when somebody asks. But I digress ;D
On 5/1/21 10:19 AM, Mike Wright wrote:
On 4/30/21 9:31 PM, Jack Craig wrote:
ps. Here is another set that includes your mailserver data based on the SOA.
$TTL 3D ; default ttl for records without a specified lifetime $ORIGIN linuxlighthouse.com. @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 1619890154 ; serial number 16384 ; ns refresh 2048 ; ns retry 1048576 ; authority expiry 2560 ); min (RFC2308 §4) IN NS ws.linuxlighthouse.com. IN NS ns3.attdns.com. IN MX linuxlighthouse.com. ws IN A 108.220.213.121 IN A 108.220.213.121
The first time I provided the reverse zone file. That was a mistake on my part. That is only useful if you have received a Delegation of Authority from AT&T and last I checked they won't do so for a single IP. /29 or greater is required. As a single IP AT&T provides it.
On Sat, May 1, 2021 at 5:25 AM Ed Greshko ed.greshko@greshko.com wrote:
On 01/05/2021 20:07, Tim via users wrote:
On Sat, 2021-05-01 at 12:04 +0800, Ed Greshko wrote:
You are missing the fact that you attempting to run a *public* DNS server.
That means that your DNS server must accept queries from *any* source address.
allow-query { any; };
is what you'll need.
Supplemental info: You allow all queries, but you only provide answers for your own domain.
I covered that in a follow-on post. I didn't want to reveal that too soon as to not be able to verify a working configuration from afar.
It was actually good that I did that since the OP had a working config except that he hadn't defined a zone. So, I knew most things were working.
And he had some very well versed assistance from this list! ;)
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 01/05/2021 17:28, Jack Craig wrote:
On Sat, May 1, 2021 at 2:19 AM Ed Greshko <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
2. Configure your DNS server with, I think the correct term is "views", such that an internal system query returns internal IP addresses (10.0.0.X) and an internal query allows recursion. #1 is easy #2 requires research and work.I'll hold off deciding this for the moment, i need some sleep, ...
Still, i got a start on views/zones and /etc/named.conf is currently setup as ..
*view "wan-view" { zone "linuxlighthouse.com http://linuxlighthouse.com" { type master; file "/var/named/linuxlighthouse.com.db"; allow-update { none; }; };
zone "." IN { type hint; file "named.ca http://named.ca"; }; };*
BTW, if you decide to go ahead with using views it would be helpful if you have a system on the "outside" for you to use to test queries.
As I understand it, all your "internal" systems have 10.0.0.X IP addresses.
But, I recall that your ws host does have a virbr0 interface. Meaning it is already configured for the creation of Virtual Machines.
So, you could deploy a VM which would acquire a 192.168.122.X address. Then you treat that IP range as part of the WAN while your 10.0.0.X addresses are your LAN. Now you can test views from "inside" as well as "outside".
On Sat, May 1, 2021, at 2:50 PM, Ed Greshko wrote:
BTW, if you decide to go ahead with using views it would be helpful if you have a system on the "outside" for you to use to test queries.
As I understand it, all your "internal" systems have 10.0.0.X IP addresses.
Yup. Something else I just noticed that *might* be important...
dig @WS.LINUXLIGHTHOUSE.COM LINUXLIGHTHOUSE.COM ns
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @WS.LINUXLIGHTHOUSE.COM LINUXLIGHTHOUSE.COM ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39676 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 2da4654bcbbfcf2e20c614f6608f10fb5882579a181961d8 (good) ;; QUESTION SECTION: ;LINUXLIGHTHOUSE.COM. IN NS
;; ANSWER SECTION: linuxlighthouse.com. 86400 IN NS ws.linuxlighthouse.com.
;; ADDITIONAL SECTION: ws.linuxlighthouse.com. 86400 IN A 108.220.213.121
;; Query time: 97 msec ;; SERVER: 108.220.213.121#53(108.220.213.121) ;; WHEN: Sun May 02 13:52:11 PDT 2021 ;; MSG SIZE rcvd: 128
That says that ws.linuxlighthouse.com is the one and only name server for the domain. Whereas whois shows the more normal 2 minimum:
whois LINUXLIGHTHOUSE.COM | grep ^Name
Name Server: WS.LINUXLIGHTHOUSE.COM Name Server: NS3.ATTDNS.COM
So, even if you let NS3.ATTDNS.COM pull the zone from you it might not work correctly if they just use the zone you feed them without adding themselves to the mix with an NS record.
On 03/05/2021 04:56, Doug H. wrote:
That says that ws.linuxlighthouse.com is the one and only name server for the domain. Whereas whois shows the more normal 2 minimum:
whois LINUXLIGHTHOUSE.COM | grep ^Name
Name Server: WS.LINUXLIGHTHOUSE.COM Name Server: NS3.ATTDNS.COM
So, even if you let NS3.ATTDNS.COM pull the zone from you it might not work correctly if they just use the zone you feed them without adding themselves to the mix with an NS record.
Good point. I'd forgotten about NS3.ATTDNS.COM.
Oddly, ns3.attdns.com doesn't return any ns records for the domain while google does.
[root@meimei proc]# dig @ns3.attdns.com linuxlighthouse.com
; <<>> DiG 9.16.11-RedHat-9.16.11-5.fc34 <<>> @ns3.attdns.com linuxlighthouse.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 13291 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;linuxlighthouse.com. IN A
;; Query time: 194 msec ;; SERVER: 2001:1890:1c00:5323::c:3#53(2001:1890:1c00:5323::c:3) ;; WHEN: Mon May 03 05:39:19 CST 2021 ;; MSG SIZE rcvd: 48
[root@meimei proc]# dig @8.8.8.8 linuxlighthouse.com ns
; <<>> DiG 9.16.11-RedHat-9.16.11-5.fc34 <<>> @8.8.8.8 linuxlighthouse.com ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61405 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;linuxlighthouse.com. IN NS
;; ANSWER SECTION: linuxlighthouse.com. 21599 IN NS ws.linuxlighthouse.com.
;; Query time: 212 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon May 03 05:40:29 CST 2021 ;; MSG SIZE rcvd: 65
On Sun, May 2, 2021 at 1:58 PM Doug H. fedoraproject.org@wombatz.com wrote:
On Sat, May 1, 2021, at 2:50 PM, Ed Greshko wrote:
BTW, if you decide to go ahead with using views it would be helpful if
you have
a system on the "outside" for you to use to test queries.
As I understand it, all your "internal" systems have 10.0.0.X IP
addresses.
Yup. Something else I just noticed that *might* be important...
*i think you are right, i've been wondering about the ns3's behaviour as the dnscheck page keeps telling me i have only one responding dns.*
*as it is part of the at&t dns, i have been ignoring this; now is the time to deal with it....*
*i am sporting mike's recent config file cuz its So much prettier than my hack. i hacked in a CAAA record & updated teh serial number giving me, ...*
*$TTL 3D ; default ttl for records without a specified lifetime$ORIGIN linuxlighthouse.com http://linuxlighthouse.com.linuxlighthouse.com http://linuxlighthouse.com. CAA 0 issue "letsencrypt.org http://letsencrypt.org"@ IN SOA ws.linuxlighthouse.com http://ws.linuxlighthouse.com. root.linuxlighthouse.com http://root.linuxlighthouse.com. ( 2021050301 ; serial number 16384 ; ns refresh 2048 ; ns retry 1048576 ; authority expiry 2560 ); min (RFC2308 §4) IN NS ws.linuxlighthouse.com http://ws.linuxlighthouse.com. IN NS ns3.attdns.com http://ns3.attdns.com.; IN MX linuxlighthouse.com http://linuxlighthouse.com.ws IN A 108.220.213.121 IN A 108.220.213.121*
*as an aside, if i add 'www in a 108.220.213.121'*
*would properly define 'www.linuxlighthouse.com http://www.linuxlighthouse.com' ???*
/usr/sbin/named-compilezone -i full -o - linuxlighthouse.com /var/named/linuxlighthouse.com.db
zone linuxlighthouse.com/IN: loaded serial 2021050301 linuxlighthouse.com. 259200 IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. 2021050301 16384 2048 1048576 2560 linuxlighthouse.com. 259200 IN NS ws.linuxlighthouse.com. linuxlighthouse.com. 259200 IN NS ns3.attdns.com. linuxlighthouse.com. 259200 IN CAA 0 issue "letsencrypt.org" ws.linuxlighthouse.com. 259200 IN A 108.220.213.121
dig @WS.LINUXLIGHTHOUSE.COM LINUXLIGHTHOUSE.COM ns
; <<>> DiG 9.11.28-RedHat-9.11.28-1.fc33 <<>> @WS.LINUXLIGHTHOUSE.COM LINUXLIGHTHOUSE.COM ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39676 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 2da4654bcbbfcf2e20c614f6608f10fb5882579a181961d8 (good) ;; QUESTION SECTION: ;LINUXLIGHTHOUSE.COM. IN NS
;; ANSWER SECTION: linuxlighthouse.com. 86400 IN NS ws.linuxlighthouse.com.
;; ADDITIONAL SECTION: ws.linuxlighthouse.com. 86400 IN A 108.220.213.121
;; Query time: 97 msec ;; SERVER: 108.220.213.121#53(108.220.213.121) ;; WHEN: Sun May 02 13:52:11 PDT 2021 ;; MSG SIZE rcvd: 128
That says that ws.linuxlighthouse.com is the one and only name server for the domain. Whereas whois shows the more normal 2 minimum:
whois LINUXLIGHTHOUSE.COM | grep ^Name
Name Server: WS.LINUXLIGHTHOUSE.COM Name Server: NS3.ATTDNS.COM
So, even if you let NS3.ATTDNS.COM pull the zone from you it might not work correctly if they just use the zone you feed them without adding themselves to the mix with an NS record.
*is my registrar or attdns the player to whine to?*
-- Doug Herr fedoraproject.org@wombatz.com _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Date: Monday, May 03, 2021 12:32:22 -0700 From: Mike Wright nobody@nospam.hostisimo.com
On 5/3/21 11:56 AM, Jack Craig wrote:
<big snip/> > > *is my registrar or attdns the player to whine to?
Your registrar. Your "control panel" should allow you to update your nameservers yourself.
I don't think "whine to" is quite the right phrasing.
You need to check with att to confirm that they will do (secondary) dns for you and if so, the server(s) that your domain is/will be set up on. They will need to know where the authoritative server is so they can set up their side to do the zone transfers.
As noted, you should then be able to update your nameserver entries in your registrar record through some type of interface on their site.
On 5/3/21 11:56 AM, Jack Craig wrote:
<another big snip/>
*as an aside, if i add 'www in a 108.220.213.121'*
oops, missed that one ;D
Yes. That is the right way to add a host. Just duplicate the ws line and change the ws to www.
fyi, the line below ws ... without a host specified is the one that also attaches your IP to your domainname and allows the @linuxlighthouse.com to work.
On 04/05/2021 03:54, Mike Wright wrote:
On 5/3/21 11:56 AM, Jack Craig wrote:
<another big snip/> > > *as an aside, if i add 'www in a 108.220.213.121'*
oops, missed that one ;D
Yes. That is the right way to add a host. Just duplicate the ws line and change the ws to www.
fyi, the line below ws ... without a host specified is the one that also attaches your IP to your domainname and allows the @linuxlighthouse.com to work.
???
[egreshko@meimei ~]$ dig linuxlighthouse.com [egreshko@meimei ~]$ host linuxlighthouse.com [egreshko@meimei ~]$ host linuxlighthouse.com ws.linuxlighthouse.com ;; connection timed out; no servers could be reached
On 04/05/2021 02:56, Jack Craig wrote:
That says that ws.linuxlighthouse.com <http://ws.linuxlighthouse.com> is the one and only name server for the domain. Whereas whois shows the more normal 2 minimum: >whois LINUXLIGHTHOUSE.COM <http://LINUXLIGHTHOUSE.COM> | grep ^Name Name Server: WS.LINUXLIGHTHOUSE.COM <http://WS.LINUXLIGHTHOUSE.COM> Name Server: NS3.ATTDNS.COM <http://NS3.ATTDNS.COM> So, even if you let NS3.ATTDNS.COM <http://NS3.ATTDNS.COM> pull the zone from you it might not work correctly if they just use the zone you feed them without adding themselves to the mix with an NS record./ / /is my registrar or attdns the player to whine to?/
I'm not sure if this applies to you, what with ATT having so many divisions....
From https://www.att.com/support/smallbusiness/article/smb-internet/KM1188676/
"Note: AT&T does not provide DNS service when listed as Secondary DNS, unless we are also the Primary DNS. It may take up to 48 hours for your Registrar to complete this transaction."
Also, note that ns3.attdns.com does not support recursion.
thx ed, i spent a whole day a week or so a couple weeks back to verify this secondary dns. i could swear that they said then i provide primary, they provide secondary. i'll pursue this more directly now.
On Mon, May 3, 2021 at 1:24 PM Ed Greshko ed.greshko@greshko.com wrote:
On 04/05/2021 02:56, Jack Craig wrote:
That says that ws.linuxlighthouse.com <http://ws.linuxlighthouse.com>is the one and only name server for the domain. Whereas whois shows the more normal 2 minimum:
>whois LINUXLIGHTHOUSE.COM <http://LINUXLIGHTHOUSE.COM> | grep ^Name Name Server: WS.LINUXLIGHTHOUSE.COM <http://WS.LINUXLIGHTHOUSE.COM> Name Server: NS3.ATTDNS.COM <http://NS3.ATTDNS.COM> So, even if you let NS3.ATTDNS.COM <http://NS3.ATTDNS.COM> pull thezone from you it might not work correctly if they just use the zone you feed them without adding themselves to the mix with an NS record.
/ / /is my registrar or attdns the player to whine to?/
I'm not sure if this applies to you, what with ATT having so many divisions....
From https://www.att.com/support/smallbusiness/article/smb-internet/KM1188676/
"Note: AT&T does not provide DNS service when listed as Secondary DNS, unless we are also the Primary DNS. It may take up to 48 hours for your Registrar to complete this transaction."
Also, note that ns3.attdns.com does not support recursion.
-- Remind me to ignore comments which aren't germane to the thread. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, 2021-05-03 at 11:56 -0700, Jack Craig wrote:
i think you are right, i've been wondering about the ns3's behaviour as the dnscheck page keeps telling me i have only one responding dns. as it is part of the at&t dns, i have been ignoring this; now is the time to deal with it....
i am sporting mike's recent config file cuz its So much prettier than my hack. i hacked in a CAAA record & updated teh serial number giving me, ...
$TTL 3D ; default ttl for records without a specified lifetime $ORIGIN linuxlighthouse.com. linuxlighthouse.com. CAA 0 issue "letsencrypt.org" @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2021050301 ; serial number 16384 ; ns refresh 2048 ; ns retry 1048576 ; authority expiry 2560 ); min (RFC2308 §4) IN NS ws.linuxlighthouse.com. IN NS ns3.attdns.com. ; IN MX linuxlighthouse.com. ws IN A 108.220.213.121 IN A 108.220.213.121
Are you sure that's constructed properly? There's usually a precise structure for zone files. All examples I've seen have things in this sequence (just the sequence, I've not typed in all the data):
$origin . $TTL SOA ( serial refresh time retry time expiry time minimum time ) NS A MX followed by the rest of your records
I'm not sure about where you might add a new thing, like CAA, but I wouldn't rearrange the order of that other things without being sure about it.
as an aside, if i add 'www in a 108.220.213.121'
would properly define 'www.linuxlighthouse.com' ???
Yes, anything you put left of IN A, that doesn't end in a dot, is a sub-domain (the server appends your domain name to it).
On Mon, May 3, 2021 at 6:32 PM Tim via users users@lists.fedoraproject.org wrote:
On Mon, 2021-05-03 at 11:56 -0700, Jack Craig wrote:
i think you are right, i've been wondering about the ns3's behaviour as the dnscheck page keeps telling me i have only one responding dns. as it is part of the at&t dns, i have been ignoring this; now is the time to deal with it....
i am sporting mike's recent config file cuz its So much prettier than my hack. i hacked in a CAAA record & updated teh serial number giving me, ...
$TTL 3D ; default ttl for records without a specified lifetime $ORIGIN linuxlighthouse.com. linuxlighthouse.com. CAA 0 issue "letsencrypt.org" @ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. ( 2021050301 ; serial number 16384 ; ns refresh 2048 ; ns retry 1048576 ; authority expiry 2560 ); min (RFC2308 §4) IN NS ws.linuxlighthouse.com. IN NS ns3.attdns.com. ; IN MX linuxlighthouse.com. ws IN A 108.220.213.121 IN A 108.220.213.121
Are you sure that's constructed properly? There's usually a precise structure for zone files. All examples I've seen have things in this
these links seem to verify the CAA's record format/content
https://www.entrust.com/knowledgebase/ssl/how-to-add-caa-record-into-a-dns-z... https://www.entrust.com/resources/certificate-solutions/tools/caa-lookup https://www.entrust.com/resources/certificate-solutions/tools/caa-lookup
$origin . $TTL SOA ( serial refresh time retry time expiry time minimum time ) NS A MX followed by the rest of your records
I'm not sure about where you might add a new thing, like CAA, but I wouldn't rearrange the order of that other things without being sure about it.
as an aside, if i add 'www in a 108.220.213.121'
would properly define 'www.linuxlighthouse.com' ???
Yes, anything you put left of IN A, that doesn't end in a dot, is a sub-domain (the server appends your domain name to it).
i've been challenged finding these rules... Thx! is this record format spelled out somewhere, RFC??? perhaps??
--
uname -rsvp Linux 3.10.0-1160.25.1.el7.x86_64 #1 SMP Wed Apr 28 21:49:45 UTC 2021 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, 2021-05-04 at 11:30 -0700, Jack Craig wrote:
i've been challenged finding these rules... Thx! is this record format spelled out somewhere, RFC??? perhaps
There probably is, but I would have learnt this from the BIND documentation years ago, and just kept pace with how BIND rewrites its own zone files (I have a DHCP server on my LAN, and zone files are updated by it). Be careful of helpful websites which have errors in them.
This side of thing (how the data is stored on your computer) will depend on what particular name server software you use.
How *they* serve it to the world would have its own set of rules.
-
Doug H. -
Ed Greshko -
Jack Craig -
Joe Zeff -
Mike Wright -
Richard -
Sam Varshavchik -
Subscriber -
Tim