Re: on to letsencrypt

[Jack Craig <jack.craig.aptos@xxxxxxxxx>]

-- 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@xxxxxxxxx> wrote:

ed, i found the caching file test, results shortly,...

On Wed, Apr 21, 2021 at 11:21 AM Jack Craig <jack.craig.aptos@xxxxxxxxx> wrote:

On Wed, Apr 21, 2021 at 12:48 AM Tim via users <users@xxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure