On 4/30/21 9:31 PM, Jack Craig wrote:
On Fri, Apr 30, 2021 at 9:05 PM Ed Greshko <ed.greshko@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx. 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
_______________________________________________
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
