21 Apr
2021
21 Apr
'21
1:39 p.m.
-- 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.aptos@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.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,...
>>
>>
>>>