-- 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(a)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(a)gmail.com>
wrote:
>
>
> On Wed, Apr 21, 2021 at 12:48 AM Tim via users <
> users(a)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,...
>
>
>>