ed,

would you resend that caching cfg file; i cant find that email any  where!!
:(

sorry,...

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).
>
> Since you only appear to have one real interface, it's going to be
> harder to configure BIND to distinguish between what's inside and
> outside.  After all, the external queries are going to come from a
> local address (your router), you're probably going to have use the
> router's specific internal address as the definition for outside
> queries.
>
> If you only have one PC, as you've previously outlined, running BIND is
> serious overkill.  You can do all you need with the /etc/hosts file.
>
> ACLs have some predefined terms:
>
>  "any" matches any and every IP address,
>
>  "localhost" matches any IP used by the computer it's running on,
>
>  "localnets" matches any IP on any network the computer is on,
>
>  "none" matches nothing.
>
> When those definitions are not useful enough, you start using actual IP
> addresses or IP ranges (e.g. 192.168.0.0./24 is the entire range
> 192.168.0.0 through to 192.168.0.255).
>
> Try Ed's sample named.conf.  Then if you really want to try doing split
> DNS, I think you'll have to go down this route, using rules something
> like these *within* the config file:
>
>         listen-on port 53 { any; };
>
>         listen-on-v6 port 53 { any;};
>
>         allow-queries { any; };
>
>         acl wan { type in the internal IP of your router your PC is
> directly plugged into; };
>
>         acl lan { 127.0.0.1; };
>
>         view wan {
>                 match-clients { wan; };
>                 zone "wan-linuxlighthouse" {
>                         type master;
>                         file "wan-linuxlighthouse.zone";
>                 };
>         };
>
>
>         view lan {
>                 match-clients { lan; };
>                 zone "lan-linuxlighthouse" {
>                         type master;
>                         file "lan-linuxlighthouse.zone";
>                 };
>         }
>
> With the associated wan- and lan- zone files only containing IPs
> applicable to themselves (the wan zone only has public addresses, the
> lan zone only has local addresses).
>
> Match the special outside rule first, then fall back to the internal
> rules.
>
> NB:  While the defaults for various options are often any/all if you
> haven't set any contradicting rules, I don't know if alternative
> defaults have been complied in for Fedora's BIND.  So I play safe and
> define the things explicitly.
>
> > visible interfaces
> >
> >  ip a
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> > group default qlen 1000
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >     inet 127.0.0.1/8 scope host lo
> >        valid_lft forever preferred_lft forever
> >     inet6 ::1/128 scope host
> >        valid_lft forever preferred_lft forever
>
> That's your localhost with IPv4 and IPv6 addresses.  Localhost is how
> the computer refers to itself.  It's like you looking in the mirror and
> thinking "me."
>
> > 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> > state UP group default qlen 1000
> >     link/ether 50:65:f3:4a:ec:e5 brd ff:ff:ff:ff:ff:ff
> >     altname enp0s31f6
> >     inet 10.0.0.101/24 brd 10.0.0.255 scope global noprefixroute eno1
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::15ef:5535:377f:e73f/64 scope link noprefixroute
> >        valid_lft forever preferred_lft forever
>
> That's your ethernet interface within your network, between your
> computer and routers, and any other devices.
>
>
> > 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
> > state DOWN group default qlen 1000
> >     link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff
> >     inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
> >        valid_lft forever preferred_lft forever
> > 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master
> > virbr0 state DOWN group default qlen 1000
> >     link/ether 52:54:00:4f:91:99 brd ff:ff:ff:ff:ff:ff
>
> These are virtual bridges, which you don't appear to be using (a bridge
> between real interfaces, as in the prior paragraph, and emulated ones
> used by virtual installations).  For what it's worth, my computer had
> the same kind of thing set up by default.  But since I don't use
> virtual computers on my hardware, I removed them.
>
> From what I can gather of this tangled thread is that your network is
> something like:
>
> ISP --- router --- another router --- your computer
>
> Each router will have a different IP address at their inside and
> outside interfaces (that diagram has outside WAN on the left, inside
> LAN on the right).
>
> Your ISP allocates you a bunch of IPs.  You either need to configure
> your router to be all of those IPs and route them through to where you
> want (doing some complex NAT).  Or configure you router to be one of
> those IPs, and route the others through to where you want, and
> configure the destination(s) to be the other IPs (configuring your
> routers as gateways).  Domestic routers may not be configurable enough.
>
> --
>
> uname -rsvp
> Linux 3.10.0-1160.24.1.el7.x86_64 #1 SMP Thu Apr 8 19:51:47 UTC 2021 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@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to