-- 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? On Wed, Apr 21, 2021 at 11:33 AM Jack Craig <jack.craig.ap...@gmail.com> wrote: > ed, i found the caching file test, results shortly,... > > On Wed, Apr 21, 2021 at 11:21 AM Jack Craig <jack.craig.ap...@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,... >> >> >>>
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@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
