On Sat, Nov 14, 2020 at 9:12 PM Tim via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sat, 2020-11-14 at 11:33 -0800, Jack Craig wrote:
> zone: /var/named/internal
>
>
> internal. 86400 IN SOA ws.linuxlighthouse.com.
> root.linuxlighthouse.com. 2020101601 86400 3600 604800 86400
> internal. 86400 IN NS ws.internal.
> internal. 86400 IN A 108.220.213.121
> internal. 86400 IN A 10.0.0.1
> internal. 86400 IN MX 10 mail.internal.
> mail.internal. 86400 IN A 108.220.213.122
> ws.internal. 86400 IN A 108.220.213.121
> ws.internal. 86400 IN A 10.0.0.101
> ws2.internal. 86400 IN A 10.0.0.102
> www.internal. 86400 IN A 108.220.213.121
> www.internal. 86400 IN A 10.0.0.101
Also, what names do you want resolved for internal searches?
i have about half dpzenn 10.0.0. ip's for internal.
your below has resulted na god external.view, but my internal.db keeps giving out of zone errors.
do you have input for the internal view as you did for external view? what am i missing?
tia, ...
external view...
Authoritative data for linuxlighthouse.com zone
;
$ORIGIN .
$TTL 86400
linuxlighthouse.com IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. (
2020101601 ; serial
1D ; refresh
1H ; retry
1W ; expire
86400 ; minimum
)
NS ws.linuxlighthouse.com.
A 108.220.213.121
$ORIGIN linuxlighthouse.com.
ws A 108.220.213.121
www A 108.220.213.121
;
$ORIGIN .
$TTL 86400
linuxlighthouse.com IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. (
2020101601 ; serial
1D ; refresh
1H ; retry
1W ; expire
86400 ; minimum
)
NS ws.linuxlighthouse.com.
A 108.220.213.121
$ORIGIN linuxlighthouse.com.
ws A 108.220.213.121
www A 108.220.213.121
internal view
~ ; Authoritative data for internal-lan-view zone
;
$ORIGIN linuxlighthouse.com.
$TTL 86400
@ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. (
2020101601 ; serial
1D ; refresh
1H ; retry
1W ; expire
86400 ; minimum
)
IN NS ws.linuxlighthouse.com.
ws IN A 10.0.0.101
www IN A 10.0.0.101
ws2 IN A 10.0.0.102
;printer IN A 10.0.0.108
;
$ORIGIN linuxlighthouse.com.
$TTL 86400
@ IN SOA ws.linuxlighthouse.com. root.linuxlighthouse.com. (
2020101601 ; serial
1D ; refresh
1H ; retry
1W ; expire
86400 ; minimum
)
IN NS ws.linuxlighthouse.com.
ws IN A 10.0.0.101
www IN A 10.0.0.101
ws2 IN A 10.0.0.102
;printer IN A 10.0.0.108
If you put a dot at the end of the name (mail.internal. etc), that's
the whole domain name, it's not going to use it as a hostname suffixed
with your domain name. Without a dot, they'll be prefix subdomains.
e.g. For an example.com zone file, an entry like this:
www A 192.168.1.2
will answer queries for: "www.example.com"
But, an entry like this:
www. A 192.168.1.2
would be an answer for a query about: "www"
At least, that's how BIND9 works on my computers. Though I have read
that it can handle different kinds of record files, I haven't tried
them out.
Here's an entire local network domain record on my system:
$ORIGIN .
$TTL 86400 ; 1 day
example.lan IN SOA ns.example.lan hostmaster.example.lan (
359 ; serial
300 ; refresh (5 minutes)
900 ; retry (15 minutes)
3600 ; expire (1 hour)
1800 ; minimum (30 minutes)
)
NS ns.example.lan.
A 192.168.1.1
MX 1 mail.example.lan.
$ORIGIN example.lan.
mail A 192.168.1.1
ns A 192.168.1.1
web CNAME www
www A 192.168.1.1
Taking that all in line by line.
* This is the top-level record for this domain (dot origin)
* With a 1 day time-to-live for record data.
* It's the start of authority record (master records) for an
example.lan domain name.
* Records held at ns.example.lan
* Admin contact is hostmaster@xxxxxxxxxxx
* The serial number is 359 (be sure to increment it any time you
change any DNS record data).
* Check for updated records every 5 minutes (this is a LAN with
dynamic IPs, so short is okay, here).
* If the master server is unresponsive, wait for 15 minutes before
trying again (keep using your previously cached data). I haven't
optimised this setting.
* Discard any unrefreshed cached data after 1 hour.
* Other DNS servers should cache this data for at least 30 minutes,
even if they've not been able to refresh it. Yes, I know it's
different from the 1 day TTL, I'd been trying to see which figures
were obeyed, but I don't remember my test results from all those
years ago.
* The domain's NS server is ns.example.lan (note the trailing dot,
meaning this is the end of this domain name, it's not a suffix to
add example.lan to the end of it). Theoretically, I could have just
written ns by itself, with no dot at the end, and the domain name
would be appended to it.
* The example.lan domain is at 192.168.1.1
* Its priority 1 mail exchanger is mail.example.lan (again, note the
trailing dot)
* The following records are subdomains of example.lan (the probably
redundant origin line).
* The mail subdomain (mail.example.lan) is at 192.168.1.1
* The ns subdomain (ns.example.lan) is at 192.168.1.1
* A web subdomain (web.example.lan) is an alternative for the www
subdomain
* The www subdomain (www.example.lan) is at 192.168.1.1
--
uname -rsvp
Linux 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
_______________________________________________
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
_______________________________________________ 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
