9:30 p.m.
Hi All,
I am use to seeing 127.0.0.1, but now I am seeing
things like 127.0.0.53.
This is used with my caching named server on
port 53.
So I figured that the last digit was the (local)
port.
So I tried CUPS: 127.0.0.631. No joy. CUPS
still wanted 127.0.0.1:631.
So what exactly is the last field in 127.0.0.xxx?
Yours in confusion,
-T
9:32 p.m.
On Fri, Dec 16, 2022 at 10:31 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
I am use to seeing 127.0.0.1, but now I am seeing
things like 127.0.0.53.
This is used with my caching named server on
port 53.
So I figured that the last digit was the (local)
port.
So I tried CUPS: 127.0.0.631. No joy. CUPS
still wanted 127.0.0.1:631.
So what exactly is the last field in 127.0.0.xxx?
https://duckduckgo.com/?q=IPv4+tutorial
10:04 p.m.
On 12/16/22 19:32, Jeffrey Walton wrote:
On Fri, Dec 16, 2022 at 10:31 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> I am use to seeing 127.0.0.1, but now I am seeing
> things like 127.0.0.53.
>
> This is used with my caching named server on
> port 53.
>
> So I figured that the last digit was the (local)
> port.
>
> So I tried CUPS: 127.0.0.631. No joy. CUPS
> still wanted 127.0.0.1:631.
>
> So what exactly is the last field in 127.0.0.xxx?
https://duckduckgo.com/?q=IPv4+tutorial
Where in the the tutorials does it talk about
the 127. addresses?
11:27 p.m.
ToddAndMargo:
> So I tried CUPS: 127.0.0.631. No joy. CUPS still wanted
> 127.0.0.1:631.
Joe Zeff:
That isn't a valid IP address.
Both are valid addresses.
127.0.0.631 is *unlikely* to be in use, but is valid.
127.0.0.1:631 is port 631 at 127.0.0.1.
Valid addresses, but only on the same machine. 127.x.y.z is each
machine's way to refer to itself.
Some people use the different addresses to remind them on whatever
purpose they're using it for. I don't see any particularly useful
about doing that.
I seem to recall that NTPD did something similar with its use of the
127. addresses.
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.0.10-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:53:11
UTC 2022 x86_64
12:06 a.m.
On 12/16/22 21:33, Jeffrey Walton wrote:
On Sat, Dec 17, 2022 at 12:27 AM Tim via users
<users(a)lists.fedoraproject.org> wrote:
> [...]
> Both are valid addresses.
>
> 127.0.0.631 is *unlikely* to be in use, but is valid.
Huh? Citation, please.
I almost questioned you until I realized what your point was. It would
have helped if you explained what you meant. Yes, 631 is not a valid IP
octet.
12:13 a.m.
On 12/16/22 22:06, Samuel Sieb wrote:
On 12/16/22 21:33, Jeffrey Walton wrote:
> On Sat, Dec 17, 2022 at 12:27 AM Tim via users
> <users(a)lists.fedoraproject.org> wrote:
>> [...]
>> Both are valid addresses.
>>
>> 127.0.0.631 is *unlikely* to be in use, but is valid.
>
> Huh? Citation, please.
I almost questioned you until I realized what your point was. It would
have helped if you explained what you meant. Yes, 631 is not a valid IP
octet.
And now I see that you trimmed out the part that said that and I didn't
read back along the whole thread.
1:07 a.m.
On 12/16/2022 11:06 PM, Samuel Sieb wrote:
I almost questioned you until I realized what your point was. It
would
have helped if you explained what you meant. Yes, 631 is not a valid IP
octet.
Exactly. I've been retired for over a decade but I found it obvious the
moment I saw that "address."
3:09 a.m.
Tim:
> [...]
> Both are valid addresses.
>
> 127.0.0.631 is *unlikely* to be in use, but is valid.
Jeffrey Walton
Huh? Citation, please.
Sorry, mental lapse there. The parts in numerical IP addresses go up
to 255, maximum.
That'll teach me to reply to an email while watching TV!
Interestingly, the error message (for that) in Firefox is rather
useless. It could actually say why it won't work (invalid address),
rather than this:
"Hmm. We’re having trouble finding that site.
"We can’t connect to the server at 127.0.0.631.
"If that address is correct, here are three other things you can try:
Try again later.
Check your network connection.
If you are connected but behind a firewall, check that Firefox has
permission to access the Web."
GoogleChrome just shows some odd google search results.
--
uname -rsvp
Linux 3.10.0-1160.80.1.el7.x86_64 #1 SMP Tue Nov 8 15:48:59 UTC 2022 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.
11:46 a.m.
On 12/17/22 01:09, Tim via users wrote:
Tim:
>> [...]
>> Both are valid addresses.
>>
>> 127.0.0.631 is *unlikely* to be in use, but is valid.
Jeffrey Walton
> Huh? Citation, please.
>
Sorry, mental lapse there. The parts in numerical IP addresses go up
to 255, maximum.
That'll teach me to reply to an email while watching TV!
Interestingly, the error message (for that) in Firefox is rather
useless. It could actually say why it won't work (invalid address),
rather than this:
"Hmm. We’re having trouble finding that site.
"We can’t connect to the server at 127.0.0.631.
"If that address is correct, here are three other things you can try:
Try again later.
Check your network connection.
If you are connected but behind a firewall, check that Firefox has
permission to access the Web."
GoogleChrome just shows some odd google search results.
ping: 127.0.0.631: Name or service not known
12:51 p.m.
On 12/17/22 10:35, Patrick O'Callaghan wrote:
On Sat, 2022-12-17 at 09:46 -0800, Mike Wright wrote:
> ping: 127.0.0.631: Name or service not known
Once again: 127.0.0.631 is not a valid IP address. The final octet can
never be greater than 255 (2^8-1).
I think the point here was to see what different programs say when you
give it an invalid IP address. In general, what happens is that the
program tries to do a DNS lookup which fails and you get an answer like
that, not an explanation that the IP address is invalid.
1:14 p.m.
On 12/17/22 10:51, Samuel Sieb wrote:
On 12/17/22 10:35, Patrick O'Callaghan wrote:
> On Sat, 2022-12-17 at 09:46 -0800, Mike Wright wrote:
>> ping: 127.0.0.631: Name or service not known
>
> Once again: 127.0.0.631 is not a valid IP address. The final octet can
> never be greater than 255 (2^8-1).
I think the point here was to see what different programs say when you
give it an invalid IP address. In general, what happens is that the
program tries to do a DNS lookup which fails and you get an answer like
that, not an explanation that the IP address is invalid.
Thank you Samuel
4:09 p.m.
On Sat, 2022-12-17 at 10:51 -0800, Samuel Sieb wrote:
I think the point here was to see what different programs say when
you
give it an invalid IP address. In general, what happens is that the
program tries to do a DNS lookup which fails and you get an answer like
that, not an explanation that the IP address is invalid.
Yep! Dig acts weirdly, too.
If you try "dig 127.0.0.631" it tries to resolve it to an IP without
complaint (of course there's no answer).
If you try "dig -x 127.0.0.631" it resolves it as localhost.
That's dig querying whatever F36 is doing internally (probably is
systemd-resolved.service):
[tim@fluffy ~]$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
If I make dig query a real DNS server (BIND on CentOS7) it doesn't get
answers.
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 6.0.10-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:53:11
UTC 2022 x86_64
9:54 p.m.
Up to 255
On Fri, Dec 16, 2022, 10:31 PM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
Hi All,
I am use to seeing 127.0.0.1, but now I am seeing
things like 127.0.0.53.
This is used with my caching named server on
port 53.
So I figured that the last digit was the (local)
port.
So I tried CUPS: 127.0.0.631. No joy. CUPS
still wanted 127.0.0.1:631.
So what exactly is the last field in 127.0.0.xxx?
Yours in confusion,
-T
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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, report it:
https://pagure.io/fedora-infrastructure/new_issue
10:06 p.m.
On Fri, Dec 16, 2022, 10:31 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
wrote:
Hi All,
I am use to seeing 127.0.0.1, but now I am seeing
things like 127.0.0.53.
This is used with my caching named server on
port 53.
So I figured that the last digit was the (local)
port.
So I tried CUPS: 127.0.0.631. No joy. CUPS
still wanted 127.0.0.1:631 <http://127.0.0.1:631>;.
So what exactly is the last field in 127.0.0.xxx?
Yours in confusion,
-T
On 12/16/22 19:54, Bill C wrote:
Up to 255
Are they the port number? Or is the
"53" a coincidence?
To me, the port number always comes after
the IP address IP:port
10:09 p.m.
127.0.0.1 is reserved for your machine. There are series of private
addresses in each ip class. 127 series and 192.168 series. They will not
work on the internet. A port of 53 would look like 127.0.0.1:53.
On Fri, Dec 16, 2022, 11:06 PM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
> On Fri, Dec 16, 2022, 10:31 PM ToddAndMargo via users
> <users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
> wrote:
>
> Hi All,
>
> I am use to seeing 127.0.0.1, but now I am seeing
> things like 127.0.0.53.
>
> This is used with my caching named server on
> port 53.
>
> So I figured that the last digit was the (local)
> port.
>
> So I tried CUPS: 127.0.0.631. No joy. CUPS
> still wanted 127.0.0.1:631 <http://127.0.0.1:631>;.
>
> So what exactly is the last field in 127.0.0.xxx?
>
> Yours in confusion,
> -T
On 12/16/22 19:54, Bill C wrote:
> Up to 255
>
Are they the port number? Or is the
"53" a coincidence?
To me, the port number always comes after
the IP address IP:port
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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, report it:
https://pagure.io/fedora-infrastructure/new_issue
10:14 p.m.
It's called the loopback address. The private class of ip is not
nonroutable.
On Fri, Dec 16, 2022, 11:10 PM Bill C <bill.cu1234(a)gmail.com> wrote:
127.0.0.1 is reserved for your machine. There are series of private
addresses in each ip class. 127 series and 192.168 series. They will not
work on the internet. A port of 53 would look like 127.0.0.1:53.
On Fri, Dec 16, 2022, 11:06 PM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
> > On Fri, Dec 16, 2022, 10:31 PM ToddAndMargo via users
> > <users(a)lists.fedoraproject.org
<mailto:users@lists.fedoraproject.org>>
> > wrote:
> >
> > Hi All,
> >
> > I am use to seeing 127.0.0.1, but now I am seeing
> > things like 127.0.0.53.
> >
> > This is used with my caching named server on
> > port 53.
> >
> > So I figured that the last digit was the (local)
> > port.
> >
> > So I tried CUPS: 127.0.0.631. No joy. CUPS
> > still wanted 127.0.0.1:631 <http://127.0.0.1:631>;.
> >
> > So what exactly is the last field in 127.0.0.xxx?
> >
> > Yours in confusion,
> > -T
>
>
> On 12/16/22 19:54, Bill C wrote:
> > Up to 255
> >
>
> Are they the port number? Or is the
> "53" a coincidence?
>
> To me, the port number always comes after
> the IP address IP:port
>
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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, report it:
https://pagure.io/fedora-infrastructure/new_issue
10:23 p.m.
On 12/16/22 20:06, ToddAndMargo via users wrote:
> On Fri, Dec 16, 2022, 10:31 PM ToddAndMargo via users
> <users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
> wrote:
>
> Hi All,
>
> I am use to seeing 127.0.0.1, but now I am seeing
> things like 127.0.0.53.
>
> This is used with my caching named server on
> port 53.
>
> So I figured that the last digit was the (local)
> port.
>
> So I tried CUPS: 127.0.0.631. No joy. CUPS
> still wanted 127.0.0.1:631 <http://127.0.0.1:631>;.
>
> So what exactly is the last field in 127.0.0.xxx?
>
> Yours in confusion,
> -T
On 12/16/22 19:54, Bill C wrote:
> Up to 255
>
Are they the port number? Or is the
"53" a coincidence?
informative. I use 127.53.0.1 to indicate a dns authority on lo and
127.0.53.1 to indicate a dns resolver on lo. Use anything valid
following the 127. Use them as your own secret code if you want or just
stick to 127.0.0.1.
To me, the port number always comes after
the IP address IP:port
correct.
127.0.0.0/8 is the loopback address. That means that any IP that begins
with 127 is a valid loopback address. The three 0's can each be any
number from 0 through 255.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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, report it:
https://pagure.io/fedora-infrastructure/new_issue
11:18 p.m.
On 12/16/22 20:23, Mike Wright wrote:
On 12/16/22 20:06, ToddAndMargo via users wrote:
>> On Fri, Dec 16, 2022, 10:31 PM ToddAndMargo via users
>> <users(a)lists.fedoraproject.org
>> <mailto:users@lists.fedoraproject.org>> wrote:
>>
>> Hi All,
>>
>> I am use to seeing 127.0.0.1, but now I am seeing
>> things like 127.0.0.53.
>>
>> This is used with my caching named server on
>> port 53.
>>
>> So I figured that the last digit was the (local)
>> port.
>>
>> So I tried CUPS: 127.0.0.631. No joy. CUPS
>> still wanted 127.0.0.1:631 <http://127.0.0.1:631>;.
>>
>> So what exactly is the last field in 127.0.0.xxx?
>>
>> Yours in confusion,
>> -T
>
>
> On 12/16/22 19:54, Bill C wrote:
> > Up to 255
> >
>
> Are they the port number? Or is the
> "53" a coincidence?
informative. I use 127.53.0.1 to indicate a dns authority on lo and
127.0.53.1 to indicate a dns resolver on lo. Use anything valid
following the 127. Use them as your own secret code if you want or just
stick to 127.0.0.1.
>
> To me, the port number always comes after
> the IP address IP:port
correct.
127.0.0.0/8 is the loopback address. That means that any IP that begins
with 127 is a valid loopback address. The three 0's can each be any
number from 0 through 255.
So the 127.0.0.53 was the bind guys being sneaky!
Thank you!
12:11 a.m.
On 12/16/22 21:18, ToddAndMargo via users wrote:
On 12/16/22 20:23, Mike Wright wrote:
> 127.0.0.0/8 is the loopback address. That means that any IP that
> begins with 127 is a valid loopback address. The three 0's can each
> be any number from 0 through 255.
So the 127.0.0.53 was the bind guys being sneaky!
That's not bind. systemd-resolved is on 127.0.0.53 and 127.0.0.54 on my
system. bind would most likely try to get 127.0.0.1 as you demonstrated
in your other email. If you want systemd-resolved to use your bind
server instead of the dhcp offered one, then modify
/etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS server.
12:44 a.m.
On 12/16/22 22:11, Samuel Sieb wrote:
On 12/16/22 21:18, ToddAndMargo via users wrote:
> On 12/16/22 20:23, Mike Wright wrote:
>> 127.0.0.0/8 is the loopback address. That means that any IP that
>> begins with 127 is a valid loopback address. The three 0's can each
>> be any number from 0 through 255.
>
>
> So the 127.0.0.53 was the bind guys being sneaky!
That's not bind. systemd-resolved is on 127.0.0.53 and 127.0.0.54 on my
system. bind would most likely try to get 127.0.0.1 as you demonstrated
in your other email. If you want systemd-resolved to use your bind
server instead of the dhcp offered one, then modify
/etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS server.
Named/bind uses port 53
$ grep -i 53 /etc/services
domain 53/tcp # name-domain server
domain 53/udp
Everything is commented out in my
/etc/systemd/resolved.conf
12:50 a.m.
Is that Dnsmasq like bind? The only thing I've ever cared to run would be
something like rsync and ssh as far as servers.
On Sat, Dec 17, 2022, 1:44 AM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 12/16/22 22:11, Samuel Sieb wrote:
> On 12/16/22 21:18, ToddAndMargo via users wrote:
>> On 12/16/22 20:23, Mike Wright wrote:
>>> 127.0.0.0/8 is the loopback address. That means that any IP that
>>> begins with 127 is a valid loopback address. The three 0's can each
>>> be any number from 0 through 255.
>>
>>
>> So the 127.0.0.53 was the bind guys being sneaky!
>
> That's not bind. systemd-resolved is on 127.0.0.53 and 127.0.0.54 on my
> system. bind would most likely try to get 127.0.0.1 as you demonstrated
> in your other email. If you want systemd-resolved to use your bind
> server instead of the dhcp offered one, then modify
> /etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS server.
Named/bind uses port 53
$ grep -i 53 /etc/services
domain 53/tcp # name-domain server
domain 53/udp
Everything is commented out in my
/etc/systemd/resolved.conf
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)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, report it:
https://pagure.io/fedora-infrastructure/new_issue
12:54 a.m.
On 12/16/22 22:44, ToddAndMargo via users wrote:
On 12/16/22 22:11, Samuel Sieb wrote:
> On 12/16/22 21:18, ToddAndMargo via users wrote:
>> On 12/16/22 20:23, Mike Wright wrote:
>>> 127.0.0.0/8 is the loopback address. That means that any IP that
>>> begins with 127 is a valid loopback address. The three 0's can each
>>> be any number from 0 through 255.
>>
>>
>> So the 127.0.0.53 was the bind guys being sneaky!
>
> That's not bind. systemd-resolved is on 127.0.0.53 and 127.0.0.54 on
> my system. bind would most likely try to get 127.0.0.1 as you
> demonstrated in your other email. If you want systemd-resolved to use
> your bind server instead of the dhcp offered one, then modify
> /etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS server.
Named/bind uses port 53
$ grep -i 53 /etc/services
domain 53/tcp # name-domain server
domain 53/udp
Not sure what your point is here. Yes, they *all* use port 53, but on
different IP addresses. By default, resolv.conf points to
systemd-resolved, so you need to tell that to pass it on to bind.
Everything is commented out in my
/etc/systemd/resolved.conf
Yes, so you need to uncomment the DNS line and edit it.
1:40 p.m.
On 12/16/22 22:54, Samuel Sieb wrote:
On 12/16/22 22:44, ToddAndMargo via users wrote:
> On 12/16/22 22:11, Samuel Sieb wrote:
>> On 12/16/22 21:18, ToddAndMargo via users wrote:
>>> On 12/16/22 20:23, Mike Wright wrote:
>>>> 127.0.0.0/8 is the loopback address. That means that any IP that
>>>> begins with 127 is a valid loopback address. The three 0's can
>>>> each be any number from 0 through 255.
>>>
>>>
>>> So the 127.0.0.53 was the bind guys being sneaky!
>>
>> That's not bind. systemd-resolved is on 127.0.0.53 and 127.0.0.54 on
>> my system. bind would most likely try to get 127.0.0.1 as you
>> demonstrated in your other email. If you want systemd-resolved to
>> use your bind server instead of the dhcp offered one, then modify
>> /etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS server.
>
> Named/bind uses port 53
>
> $ grep -i 53 /etc/services
> domain 53/tcp # name-domain server
> domain 53/udp
Not sure what your point is here. Yes, they *all* use port 53, but on
different IP addresses. By default, resolv.conf points to
systemd-resolved, so you need to tell that to pass it on to bind.
> Everything is commented out in my
> /etc/systemd/resolved.conf
Yes, so you need to uncomment the DNS line and edit it.
I set DNS=127.0.0.1
No Joy. It was still random
# systemctl restart systemd-resolved.service
Then I tried DNS=127.0.0.1:53 and it is working
stable and fast, for now. I have thought I
had it working several times before, but got
my heart broken.
And now it is failing again.
It begs the question, if /etc/resolv.conf states
nameserver 127.0.0.53
why do I need to explicitly tell resolved what it
is in resolved.conf.
I re-commented the DNS= line and am continuing
troubleshooting
1:47 p.m.
On 12/17/22 11:40, ToddAndMargo via users wrote:
On 12/16/22 22:54, Samuel Sieb wrote:
> On 12/16/22 22:44, ToddAndMargo via users wrote:
>> On 12/16/22 22:11, Samuel Sieb wrote:
>>> On 12/16/22 21:18, ToddAndMargo via users wrote:
>>>> On 12/16/22 20:23, Mike Wright wrote:
>>>>> 127.0.0.0/8 is the loopback address. That means that any IP that
>>>>> begins with 127 is a valid loopback address. The three 0's can
>>>>> each be any number from 0 through 255.
>>>>
>>>>
>>>> So the 127.0.0.53 was the bind guys being sneaky!
>>>
>>> That's not bind. systemd-resolved is on 127.0.0.53 and 127.0.0.54
>>> on my system. bind would most likely try to get 127.0.0.1 as you
>>> demonstrated in your other email. If you want systemd-resolved to
>>> use your bind server instead of the dhcp offered one, then modify
>>> /etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS server.
>>
>> Named/bind uses port 53
>>
>> $ grep -i 53 /etc/services
>> domain 53/tcp # name-domain server
>> domain 53/udp
>
> Not sure what your point is here. Yes, they *all* use port 53, but on
> different IP addresses. By default, resolv.conf points to
> systemd-resolved, so you need to tell that to pass it on to bind.
>
>> Everything is commented out in my
>> /etc/systemd/resolved.conf
>
> Yes, so you need to uncomment the DNS line and edit it.
I set DNS=127.0.0.1
No Joy. It was still random
# systemctl restart systemd-resolved.service
Then I tried DNS=127.0.0.1:53 and it is working
stable and fast, for now. I have thought I
had it working several times before, but got
my heart broken.
And now it is failing again.
It begs the question, if /etc/resolv.conf states
nameserver 127.0.0.53
why do I need to explicitly tell resolved what it
is in resolved.conf.
I think you're still missing the difference here. 127.0.0.53 is
systemd-resolved. Your bind is at 127.0.0.1. You need to tell resolved
to pass the requests to bind.
What does "resolvectl" show?
Then put the DNS entry back in the config and restart resolved and try
"resolvectl" again.
2:22 p.m.
On 12/17/22 11:47, Samuel Sieb wrote:
On 12/17/22 11:40, ToddAndMargo via users wrote:
> On 12/16/22 22:54, Samuel Sieb wrote:
>> On 12/16/22 22:44, ToddAndMargo via users wrote:
>>> On 12/16/22 22:11, Samuel Sieb wrote:
>>>> On 12/16/22 21:18, ToddAndMargo via users wrote:
>>>>> On 12/16/22 20:23, Mike Wright wrote:
>>>>>> 127.0.0.0/8 is the loopback address. That means that any IP that
>>>>>> begins with 127 is a valid loopback address. The three 0's
can
>>>>>> each be any number from 0 through 255.
>>>>>
>>>>>
>>>>> So the 127.0.0.53 was the bind guys being sneaky!
>>>>
>>>> That's not bind. systemd-resolved is on 127.0.0.53 and 127.0.0.54
>>>> on my system. bind would most likely try to get 127.0.0.1 as you
>>>> demonstrated in your other email. If you want systemd-resolved to
>>>> use your bind server instead of the dhcp offered one, then modify
>>>> /etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS server.
>>>
>>> Named/bind uses port 53
>>>
>>> $ grep -i 53 /etc/services
>>> domain 53/tcp # name-domain server
>>> domain 53/udp
>>
>> Not sure what your point is here. Yes, they *all* use port 53, but
>> on different IP addresses. By default, resolv.conf points to
>> systemd-resolved, so you need to tell that to pass it on to bind.
>>
>>> Everything is commented out in my
>>> /etc/systemd/resolved.conf
>>
>> Yes, so you need to uncomment the DNS line and edit it.
>
> I set DNS=127.0.0.1
>
> No Joy. It was still random
>
> # systemctl restart systemd-resolved.service
>
>
> Then I tried DNS=127.0.0.1:53 and it is working
> stable and fast, for now. I have thought I
> had it working several times before, but got
> my heart broken.
>
> And now it is failing again.
>
> It begs the question, if /etc/resolv.conf states
>
> nameserver 127.0.0.53
>
> why do I need to explicitly tell resolved what it
> is in resolved.conf.
I think you're still missing the difference here. 127.0.0.53 is
systemd-resolved. Your bind is at 127.0.0.1. You need to tell resolved
to pass the requests to bind.
What does "resolvectl" show?
Then put the DNS entry back in the config and restart resolved and try
"resolvectl" again.
All this silliness started as of Fedora Core 37.
There were no issues with 36.
eno2 is my internet connected Ethernet port
# host gbis.com
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached
And two minutes later:
# host gbis.com
gbis.com has address 54.151.57.48
gbis.com mail is handled by 0 gbis.com.
But it does not hold. Back and forth and
back and forth
# cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
0.0.0.0 192.168.250.1 0.0.0.0 UG 0 0 0
eno2
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0
virbr0
192.168.250.0 0.0.0.0 255.255.255.0 U 0 0 0
eno2
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
I tried setting DNS= to my IP address of br0. It shows
up in resolvectl, but not /etc/resolv.conf.
If I set nameserver in resolv.conf to my IP address
of br0, it work great, until resolved over writes it
with 127.0.0.53 next tile I exhale.
with DNS= commented out
Looks like it is working to me:
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
# resolvectl (all DNF= commented out)
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eno2)
Current Scopes: DNS LLMNR/IPv4
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
Link 3 (eno1)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 4 (br0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 5 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
2:32 p.m.
On 12/17/22 12:22, ToddAndMargo via users wrote:
On 12/17/22 11:47, Samuel Sieb wrote:
> On 12/17/22 11:40, ToddAndMargo via users wrote:
>> On 12/16/22 22:54, Samuel Sieb wrote:
>>> On 12/16/22 22:44, ToddAndMargo via users wrote:
>>>> On 12/16/22 22:11, Samuel Sieb wrote:
>>>>> On 12/16/22 21:18, ToddAndMargo via users wrote:
>>>>>> On 12/16/22 20:23, Mike Wright wrote:
>>>>>>> 127.0.0.0/8 is the loopback address. That means that any IP
>>>>>>> that begins with 127 is a valid loopback address. The three
0's
>>>>>>> can each be any number from 0 through 255.
>>>>>>
>>>>>>
>>>>>> So the 127.0.0.53 was the bind guys being sneaky!
>>>>>
>>>>> That's not bind. systemd-resolved is on 127.0.0.53 and
127.0.0.54
>>>>> on my system. bind would most likely try to get 127.0.0.1 as you
>>>>> demonstrated in your other email. If you want systemd-resolved to
>>>>> use your bind server instead of the dhcp offered one, then modify
>>>>> /etc/systemd/resolved.conf to set 127.0.0.1 as the primary DNS
>>>>> server.
>>>>
>>>> Named/bind uses port 53
>>>>
>>>> $ grep -i 53 /etc/services
>>>> domain 53/tcp # name-domain server
>>>> domain 53/udp
>>>
>>> Not sure what your point is here. Yes, they *all* use port 53, but
>>> on different IP addresses. By default, resolv.conf points to
>>> systemd-resolved, so you need to tell that to pass it on to bind.
>>>
>>>> Everything is commented out in my
>>>> /etc/systemd/resolved.conf
>>>
>>> Yes, so you need to uncomment the DNS line and edit it.
>>
>> I set DNS=127.0.0.1
>>
>> No Joy. It was still random
>>
>> # systemctl restart systemd-resolved.service
>>
>>
>> Then I tried DNS=127.0.0.1:53 and it is working
>> stable and fast, for now. I have thought I
>> had it working several times before, but got
>> my heart broken.
>>
>> And now it is failing again.
>>
>> It begs the question, if /etc/resolv.conf states
>>
>> nameserver 127.0.0.53
>>
>> why do I need to explicitly tell resolved what it
>> is in resolved.conf.
>
> I think you're still missing the difference here. 127.0.0.53 is
> systemd-resolved. Your bind is at 127.0.0.1. You need to tell
> resolved to pass the requests to bind.
>
> What does "resolvectl" show?
>
> Then put the DNS entry back in the config and restart resolved and try
> "resolvectl" again.
All this silliness started as of Fedora Core 37.
There were no issues with 36.
eno2 is my internet connected Ethernet port
# host gbis.com
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached
And two minutes later:
# host gbis.com
gbis.com has address 54.151.57.48
gbis.com mail is handled by 0 gbis.com.
But it does not hold. Back and forth and
back and forth
# cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
0.0.0.0 192.168.250.1 0.0.0.0 UG 0 0 0
eno2
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0
virbr0
192.168.250.0 0.0.0.0 255.255.255.0 U 0 0 0
eno2
192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0
br0
I tried setting DNS= to my IP address of br0. It shows
up in resolvectl, but not /etc/resolv.conf.
If I set nameserver in resolv.conf to my IP address
of br0, it work great, until resolved over writes it
with 127.0.0.53 next tile I exhale.
with DNS= commented out
Looks like it is working to me:
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
# resolvectl (all DNF= commented out)
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eno2)
Current Scopes: DNS LLMNR/IPv4
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
Link 3 (eno1)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 4 (br0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 5 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
This might be a hint: Global and eno2 are different
when I set
DNS=192.168.255.10:53
# systemctl restart systemd-resolved.service
# resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.255.10
DNS Servers: 192.168.255.10
Link 2 (eno2)
Current Scopes: DNS LLMNR/IPv4
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
Link 3 (eno1)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 4 (br0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 5 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
3:32 p.m.
On 12/17/22 12:32, ToddAndMargo via users wrote:
On 12/17/22 12:22, ToddAndMargo via users wrote:
> On 12/17/22 11:47, Samuel Sieb wrote:
>> On 12/17/22 11:40, ToddAndMargo via users wrote:
>>> On 12/16/22 22:54, Samuel Sieb wrote:
>>>> On 12/16/22 22:44, ToddAndMargo via users wrote:
>>>>> On 12/16/22 22:11, Samuel Sieb wrote:
>>>>>> On 12/16/22 21:18, ToddAndMargo via users wrote:
>>>>>>> On 12/16/22 20:23, Mike Wright wrote:
>>>>>>>> 127.0.0.0/8 is the loopback address. That means that any
IP
>>>>>>>> that begins with 127 is a valid loopback address. The
three
>>>>>>>> 0's can each be any number from 0 through 255.
>>>>>>>
>>>>>>>
>>>>>>> So the 127.0.0.53 was the bind guys being sneaky!
>>>>>>
>>>>>> That's not bind. systemd-resolved is on 127.0.0.53 and
>>>>>> 127.0.0.54 on my system. bind would most likely try to get
>>>>>> 127.0.0.1 as you demonstrated in your other email. If you want
>>>>>> systemd-resolved to use your bind server instead of the dhcp
>>>>>> offered one, then modify /etc/systemd/resolved.conf to set
>>>>>> 127.0.0.1 as the primary DNS server.
>>>>>
>>>>> Named/bind uses port 53
>>>>>
>>>>> $ grep -i 53 /etc/services
>>>>> domain 53/tcp # name-domain server
>>>>> domain 53/udp
>>>>
>>>> Not sure what your point is here. Yes, they *all* use port 53, but
>>>> on different IP addresses. By default, resolv.conf points to
>>>> systemd-resolved, so you need to tell that to pass it on to bind.
>>>>
>>>>> Everything is commented out in my
>>>>> /etc/systemd/resolved.conf
>>>>
>>>> Yes, so you need to uncomment the DNS line and edit it.
>>>
>>> I set DNS=127.0.0.1
>>>
>>> No Joy. It was still random
>>>
>>> # systemctl restart systemd-resolved.service
>>>
>>>
>>> Then I tried DNS=127.0.0.1:53 and it is working
>>> stable and fast, for now. I have thought I
>>> had it working several times before, but got
>>> my heart broken.
>>>
>>> And now it is failing again.
>>>
>>> It begs the question, if /etc/resolv.conf states
>>>
>>> nameserver 127.0.0.53
>>>
>>> why do I need to explicitly tell resolved what it
>>> is in resolved.conf.
>>
>> I think you're still missing the difference here. 127.0.0.53 is
>> systemd-resolved. Your bind is at 127.0.0.1. You need to tell
>> resolved to pass the requests to bind.
>>
>> What does "resolvectl" show?
>>
>> Then put the DNS entry back in the config and restart resolved and
>> try "resolvectl" again.
>
>
> All this silliness started as of Fedora Core 37.
> There were no issues with 36.
>
> eno2 is my internet connected Ethernet port
>
>
> # host gbis.com
> ;; communications error to 127.0.0.53#53: timed out
> ;; communications error to 127.0.0.53#53: timed out
> ;; no servers could be reached
>
> And two minutes later:
> # host gbis.com
> gbis.com has address 54.151.57.48
> gbis.com mail is handled by 0 gbis.com.
>
> But it does not hold. Back and forth and
> back and forth
>
>
>
>
> # cat /etc/resolv.conf
>
> nameserver 127.0.0.53
> options edns0 trust-ad
> search .
>
>
>
> # netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window
> irtt Iface
> 0.0.0.0 192.168.250.1 0.0.0.0 UG 0 0
> 0 eno2
> 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0
> 0 virbr0
> 192.168.250.0 0.0.0.0 255.255.255.0 U 0 0
> 0 eno2
> 192.168.255.0 0.0.0.0 255.255.255.0 U 0 0
> 0 br0
>
>
> I tried setting DNS= to my IP address of br0. It shows
> up in resolvectl, but not /etc/resolv.conf.
>
> If I set nameserver in resolv.conf to my IP address
> of br0, it work great, until resolved over writes it
> with 127.0.0.53 next tile I exhale.
>
>
> with DNS= commented out
> Looks like it is working to me:
> Current DNS Server: 127.0.0.1
> DNS Servers: 127.0.0.1
>
>
>
> # resolvectl (all DNF= commented out)
> Global
> Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
> resolv.conf mode: stub
>
> Link 2 (eno2)
> Current Scopes: DNS LLMNR/IPv4
> Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
> Current DNS Server: 127.0.0.1
> DNS Servers: 127.0.0.1
>
> Link 3 (eno1)
> Current Scopes: none
> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
>
> Link 4 (br0)
> Current Scopes: none
> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
>
> Link 5 (virbr0)
> Current Scopes: none
> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
This might be a hint: Global and eno2 are different
when I set
DNS=192.168.255.10:53
# systemctl restart systemd-resolved.service
# resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.255.10
DNS Servers: 192.168.255.10
Link 2 (eno2)
Current Scopes: DNS LLMNR/IPv4
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
Link 3 (eno1)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 4 (br0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 5 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Fixed the [expletive deleted]
# dnf remove resolvconf
# dnf install resolvconf --releasever=36
# vi /etc/dnf/dnf.conf
excludepkgs=resolvconf
reboot
The ball is back in Fedora's court:
systemd-resolved messes up bind
https://bugzilla.redhat.com/show_bug.cgi?id=2154484
3:45 p.m.
On 12/17/22 13:32, ToddAndMargo via users wrote:
On 12/17/22 12:32, ToddAndMargo via users wrote:
> On 12/17/22 12:22, ToddAndMargo via users wrote:
>> On 12/17/22 11:47, Samuel Sieb wrote:
>>> On 12/17/22 11:40, ToddAndMargo via users wrote:
>>>> On 12/16/22 22:54, Samuel Sieb wrote:
>>>>> On 12/16/22 22:44, ToddAndMargo via users wrote:
>>>>>> On 12/16/22 22:11, Samuel Sieb wrote:
>>>>>>> On 12/16/22 21:18, ToddAndMargo via users wrote:
>>>>>>>> On 12/16/22 20:23, Mike Wright wrote:
>>>>>>>>> 127.0.0.0/8 is the loopback address. That means that
any IP
>>>>>>>>> that begins with 127 is a valid loopback address.
The three
>>>>>>>>> 0's can each be any number from 0 through 255.
>>>>>>>>
>>>>>>>>
>>>>>>>> So the 127.0.0.53 was the bind guys being sneaky!
>>>>>>>
>>>>>>> That's not bind. systemd-resolved is on 127.0.0.53 and
>>>>>>> 127.0.0.54 on my system. bind would most likely try to get
>>>>>>> 127.0.0.1 as you demonstrated in your other email. If you
want
>>>>>>> systemd-resolved to use your bind server instead of the dhcp
>>>>>>> offered one, then modify /etc/systemd/resolved.conf to set
>>>>>>> 127.0.0.1 as the primary DNS server.
>>>>>>
>>>>>> Named/bind uses port 53
>>>>>>
>>>>>> $ grep -i 53 /etc/services
>>>>>> domain 53/tcp # name-domain server
>>>>>> domain 53/udp
>>>>>
>>>>> Not sure what your point is here. Yes, they *all* use port 53,
>>>>> but on different IP addresses. By default, resolv.conf points to
>>>>> systemd-resolved, so you need to tell that to pass it on to bind.
>>>>>
>>>>>> Everything is commented out in my
>>>>>> /etc/systemd/resolved.conf
>>>>>
>>>>> Yes, so you need to uncomment the DNS line and edit it.
>>>>
>>>> I set DNS=127.0.0.1
>>>>
>>>> No Joy. It was still random
>>>>
>>>> # systemctl restart systemd-resolved.service
>>>>
>>>>
>>>> Then I tried DNS=127.0.0.1:53 and it is working
>>>> stable and fast, for now. I have thought I
>>>> had it working several times before, but got
>>>> my heart broken.
>>>>
>>>> And now it is failing again.
>>>>
>>>> It begs the question, if /etc/resolv.conf states
>>>>
>>>> nameserver 127.0.0.53
>>>>
>>>> why do I need to explicitly tell resolved what it
>>>> is in resolved.conf.
>>>
>>> I think you're still missing the difference here. 127.0.0.53 is
>>> systemd-resolved. Your bind is at 127.0.0.1. You need to tell
>>> resolved to pass the requests to bind.
>>>
>>> What does "resolvectl" show?
>>>
>>> Then put the DNS entry back in the config and restart resolved and
>>> try "resolvectl" again.
>>
>>
>> All this silliness started as of Fedora Core 37.
>> There were no issues with 36.
>>
>> eno2 is my internet connected Ethernet port
>>
>>
>> # host gbis.com
>> ;; communications error to 127.0.0.53#53: timed out
>> ;; communications error to 127.0.0.53#53: timed out
>> ;; no servers could be reached
>>
>> And two minutes later:
>> # host gbis.com
>> gbis.com has address 54.151.57.48
>> gbis.com mail is handled by 0 gbis.com.
>>
>> But it does not hold. Back and forth and
>> back and forth
>>
>>
>>
>>
>> # cat /etc/resolv.conf
>>
>> nameserver 127.0.0.53
>> options edns0 trust-ad
>> search .
>>
>>
>>
>> # netstat -rn
>> Kernel IP routing table
>> Destination Gateway Genmask Flags MSS Window
>> irtt Iface
>> 0.0.0.0 192.168.250.1 0.0.0.0 UG 0 0 0 eno2
>> 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
>> 192.168.250.0 0.0.0.0 255.255.255.0 U 0 0 0 eno2
>> 192.168.255.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
>>
>>
>> I tried setting DNS= to my IP address of br0. It shows
>> up in resolvectl, but not /etc/resolv.conf.
>>
>> If I set nameserver in resolv.conf to my IP address
>> of br0, it work great, until resolved over writes it
>> with 127.0.0.53 next tile I exhale.
>>
>>
>> with DNS= commented out
>> Looks like it is working to me:
>> Current DNS Server: 127.0.0.1
>> DNS Servers: 127.0.0.1
>>
>>
>>
>> # resolvectl (all DNF= commented out)
>> Global
>> Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
>> resolv.conf mode: stub
>>
>> Link 2 (eno2)
>> Current Scopes: DNS LLMNR/IPv4
>> Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
>> DNSSEC=no/unsupported
>> Current DNS Server: 127.0.0.1
>> DNS Servers: 127.0.0.1
>>
>> Link 3 (eno1)
>> Current Scopes: none
>> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
>> DNSSEC=no/unsupported
>>
>> Link 4 (br0)
>> Current Scopes: none
>> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
>> DNSSEC=no/unsupported
>>
>> Link 5 (virbr0)
>> Current Scopes: none
>> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
>> DNSSEC=no/unsupported
>
>
>
> This might be a hint: Global and eno2 are different
> when I set
>
> DNS=192.168.255.10:53
>
> # systemctl restart systemd-resolved.service
>
> # resolvectl
> Global
> Protocols: LLMNR=resolve -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
> resolv.conf mode: stub
> Current DNS Server: 192.168.255.10
> DNS Servers: 192.168.255.10
>
> Link 2 (eno2)
> Current Scopes: DNS LLMNR/IPv4
> Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
> Current DNS Server: 127.0.0.1
> DNS Servers: 127.0.0.1
>
> Link 3 (eno1)
> Current Scopes: none
> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
>
> Link 4 (br0)
> Current Scopes: none
> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
>
> Link 5 (virbr0)
> Current Scopes: none
> Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
> DNSSEC=no/unsupported
Fixed the [expletive deleted]
# dnf remove resolvconf
# dnf install resolvconf --releasever=36
# vi /etc/dnf/dnf.conf
excludepkgs=resolvconf
reboot
The ball is back in Fedora's court:
systemd-resolved messes up bind
https://bugzilla.redhat.com/show_bug.cgi?id=2154484
Works even better with resolvconf completely removed.
Ha!
7:48 p.m.
ToddAndMargo via users writes:
All this silliness started as of Fedora Core 37.
There were no issues with 36.
How certain are you that you had systemd-resolved installed in 36, and it
didn't get pulled in during the upgrade to 37?
This particular rpm package has a tendency to get pulled in as a weak update
dependency, every once in a while. It
# host gbis.com
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; no servers could be reached
And two minutes later:
# host gbis.com
gbis.com has address 54.151.57.48
gbis.com mail is handled by 0 gbis.com.
But it does not hold. Back and forth and
back and forth
Yes. I've seen this. Despite bind-chroot running on the same blankety-blank
server, if I allowed systemd-resolved to handle DNS queries on this server
it will occasionally try to convince me that the DNS server is unreachable.
The only way to fix this reliably is to uninstall systemd-resolved.
9:07 p.m.
On 12/17/22 17:48, Sam Varshavchik wrote:
ToddAndMargo via users writes:
> All this silliness started as of Fedora Core 37.
> There were no issues with 36.
How certain are you that you had systemd-resolved installed in 36, and
it didn't get pulled in during the upgrade to 37?
This particular rpm package has a tendency to get pulled in as a weak
update dependency, every once in a while. It
> # host gbis.com
> ;; communications error to 127.0.0.53#53: timed out
> ;; communications error to 127.0.0.53#53: timed out
> ;; no servers could be reached
>
> And two minutes later:
> # host gbis.com
> gbis.com has address 54.151.57.48
> gbis.com mail is handled by 0 gbis.com.
>
> But it does not hold. Back and forth and
> back and forth
Yes. I've seen this. Despite bind-chroot running on the same
blankety-blank server, if I allowed systemd-resolved to handle DNS
queries on this server it will occasionally try to convince me that the
DNS server is unreachable.
The only way to fix this reliably is to uninstall systemd-resolved.
I did. It helped a little.
5:10 a.m.
On 17/12/2022 05:23, Mike Wright wrote:
[snip]
127.0.0.0/8 is the loopback address. That means that any IP that
begins with
127 is a valid loopback address. The three 0's can each be any number from 0
through 255.
>
I thought that the last octet could not be 0 (address of the network) or 255
(broadcast). Is this not the same for the Loopback?
G
5:17 a.m.
On Sat, 2022-12-17 at 12:10 +0100, GianPiero Puccioni wrote:
On 17/12/2022 05:23, Mike Wright wrote:
[snip]
> 127.0.0.0/8 is the loopback address. That means that any IP that
> begins with
> 127 is a valid loopback address. The three 0's can each be any
> number from 0
> through 255.
> >
I thought that the last octet could not be 0 (address of the network)
or 255 (broadcast). Is this not the same for the Loopback?
127.0.0.0/8 refers to the network, not to a specific address. The final
0 octet would be the broadcast address if used in an IP packet.
poc
7:32 a.m.
On 12/17/22 12:17, Patrick O'Callaghan wrote:
On Sat, 2022-12-17 at 12:10 +0100, GianPiero Puccioni wrote:
> I thought that the last octet could not be 0 (address of the
network)
> or 255 (broadcast). Is this not the same for the Loopback?
127.0.0.0/8 refers to the network, not to a specific address. The final
0 octet would be the broadcast address if used in an IP packet.
Well actually it is the 0.0.0 ending part that refers to the network,
since this is a /8 network.
So 127.3.4.0 is a perfectly valid address even if it ends with a 0.
The "0 at last octet" rules only applies to /24 networks.
Regards.
--
Roberto Ragusa mail at robertoragusa.it
7:38 a.m.
On Sat, 2022-12-17 at 14:32 +0100, Roberto Ragusa wrote:
On 12/17/22 12:17, Patrick O'Callaghan wrote:
> On Sat, 2022-12-17 at 12:10 +0100, GianPiero Puccioni wrote:
> > I thought that the last octet could not be 0 (address of the
> > network)
> > or 255 (broadcast). Is this not the same for the Loopback?
>
> 127.0.0.0/8 refers to the network, not to a specific address. The
> final
> 0 octet would be the broadcast address if used in an IP packet.
Well actually it is the 0.0.0 ending part that refers to the network,
since this is a /8 network.
So 127.3.4.0 is a perfectly valid address even if it ends with a 0.
The "0 at last octet" rules only applies to /24 networks.
I regularly get that the wrong way round :-)
poc
539
days inactive
540
days old
36 comments
11 participants
participants (11)
-
Bill C -
GianPiero Puccioni -
Jeffrey Walton -
Joe Zeff -
Mike Wright -
Patrick O'Callaghan -
Roberto Ragusa -
Sam Varshavchik -
Samuel Sieb -
Tim -
ToddAndMargo