4:57 p.m.
Hi All,
Fedora 37
I have a caching server running. Other than digging
out my "forward" from /etc/named.conf to figure out
what my DNS server is, is there a way to use "dig"
or other to figure out what my actual DNS server is?
Many thanks,
-T
5:07 p.m.
On 26 Mar 2023, at 22:57, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
Hi All,
Fedora 37
I have a caching server running. Other than digging
out my "forward" from /etc/named.conf to figure out
what my DNS server is, is there a way to use "dig"
or other to figure out what my actual DNS server is?
No as that information is not sent to the dns client.
You have to look at the config in each layer of software your request traverses.
Barry
Many thanks,
-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
7:27 p.m.
On 3/26/23 15:07, Barry wrote:
> On 26 Mar 2023, at 22:57, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> Hi All,
>
> Fedora 37
>
> I have a caching server running. Other than digging
> out my "forward" from /etc/named.conf to figure out
> what my DNS server is, is there a way to use "dig"
> or other to figure out what my actual DNS server is?
No as that information is not sent to the dns client.
You have to look at the config in each layer of software your request traverses.
Barry
Rats! Thank you for the quick response!
1:26 p.m.
dnsmasq allows you to query servers using dig @localhost ch txt
servers.bind. But no other server implements it. There is no common way
to query forwarders from any cache. unbound-control list_forwards would
list forwarders defined in unbound. bind has no runtime tool to show
that, just read /etc/named.conf or named-checkconf -p output. Servers
like bind, unbound or knot-resolver do not require forwarders to work.
It may work just fine even without them.
The most universal way to obtain systemd dns servers is nmcli without
parameters. It would just show what NM provides. If dnsmasq or
systemd-resolved is used, it will say what were provided by the network.
Whether and what local cache is using, it is cache-specific.
On 3/27/23 02:27, ToddAndMargo via users wrote:
On 3/26/23 15:07, Barry wrote:
>
>
>> On 26 Mar 2023, at 22:57, ToddAndMargo via users
>> <users(a)lists.fedoraproject.org> wrote:
>>
>> Hi All,
>>
>> Fedora 37
>>
>> I have a caching server running. Other than digging
>> out my "forward" from /etc/named.conf to figure out
>> what my DNS server is, is there a way to use "dig"
>> or other to figure out what my actual DNS server is?
>
> No as that information is not sent to the dns client.
>
> You have to look at the config in each layer of software your request
> traverses.
>
>
> Barry
>
Rats! Thank you for the quick response!
_______________________________________________
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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
8:24 p.m.
On Mon, 2023-04-03 at 20:26 +0200, Petr Menšík wrote:
dnsmasq allows you to query servers using dig @localhost ch txt
servers.bind. But no other server implements it.
Huh, what? "dig" comes from bind-utils, utilities for the BIND server.
There's also "rndc" to twiddle with BIND from the command line.
Servers like bind, unbound or knot-resolver do not require
forwarders
to work. It may work just fine even without them.
They *should* always work fine without them, unless you have a peculiar
ISP which interferes with normal DNS functionality. But the original
poster used them on purpose, to indirectly use the internet with
external censorship filtering.
--
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.2.8-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:14:19
UTC 2023 x86_64
5:09 p.m.
On Sun, Mar 26, 2023 at 5:57 PM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
I have a caching server running. Other than digging
out my "forward" from /etc/named.conf to figure out
what my DNS server is, is there a way to use "dig"
or other to figure out what my actual DNS server is?
resolvectl status might work.
Slade
7:29 p.m.
On 3/26/23 15:09, Slade Watkins via users wrote:
On Sun, Mar 26, 2023 at 5:57 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org>>
wrote:
I have a caching server running. Other than digging
out my "forward" from /etc/named.conf to figure out
what my DNS server is, is there a way to use "dig"
or other to figure out what my actual DNS server is?
resolvectl status might work.
Slade
$ resolvectl status
Failed to get global data: The name is not activatable
$ resolvectl
Failed to get global data: The name is not activatable
Rats!
6:33 p.m.
On Sun, 2023-03-26 at 14:57 -0700, ToddAndMargo via users wrote:
I have a caching server running. Other than digging
out my "forward" from /etc/named.conf to figure out
what my DNS server is, is there a way to use "dig"
or other to figure out what my actual DNS server is?
/etc/named.conf will only have the forwarders that you've configured
into it. If your query is about which ones you're supposed to be
using, such as your ISP-supplied ones are, that's another matter. But
if you want to know what your DNS server is likely to be on a machine
that's running a name server, it's likely 127.0.0.1.
Traditionally, all you had to do was cat /etc/resolv.conf to see what
name server DHCP had configured for you.
In a GUI, there's often a NetworkManager icon you could right-click on
to see "Connection Information" on your current connections.
And as Slade Watkins said, "resolvectl status" on Fedora will answer that.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
12:44 a.m.
On 27 Mar 2023, at 01:31, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
On 3/26/23 16:33, Tim via users wrote:
> "resolvectl status" on Fedora will answer that.
$ resolvectl status
Failed to get global data: The name is not activatable
Are you running sysyemd-resolved? If not the the failure is not surprising.
Barry
_______________________________________________
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:30 p.m.
On 3/26/23 22:44, Barry wrote:
> On 27 Mar 2023, at 01:31, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 3/26/23 16:33, Tim via users wrote:
>> "resolvectl status" on Fedora will answer that.
>
> $ resolvectl status
> Failed to get global data: The name is not activatable
Are you running sysyemd-resolved? If not the the failure is not surprising.
Barry
Indeed I am not.
1:41 a.m.
Tim:
> "resolvectl status" on Fedora will answer that.
ToddAndMargo:
$ resolvectl status
Failed to get global data: The name is not activatable
Are you on-line?
And did any of the other options work?
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
12:30 p.m.
On 3/26/23 23:41, Tim via users wrote:
Tim:
>> "resolvectl status" on Fedora will answer that.
ToddAndMargo:
> $ resolvectl status
> Failed to get global data: The name is not activatable
Are you on-line?
And did any of the other options work?
No. And I am also not running sysyemd-resolved
11:22 p.m.
Tim:
> Are you on-line?
>
> And did any of the other options work?
ToddAndMargo:
No. And I am also not running sysyemd-resolved
Perhaps we should go back to the start, your question is itself a bit
odd. DNS means Domain Name System, but we all presume you want to know
the address of your Domain Name Server.
When a device joins a network it is typical that a DHCP server assigns
it an addresses (numerical IP, hostname, domain name), and provides
some other addresses (gateway IP, nameserver(s), subnet mask). The
DHCP server need properly configuring to provide that info. Your
device will glean that info, and use it, even if you are running your
own name server.
And one would expect that all of that gets cancelled when disconnecting
(not that people often cleanly disconnect, as opposed to just losing
connection).
Failing that, without a DHCP server, variously named auto-config
schemes can take place (Bonjour, ZeroConf, etc) which do a similar
task. This time, the device, itself, self sets several of those
parameters, but not in a way that can communicate outside of the
network. It'll pick a random IP address from within a local-only
range, it'll broadcast hostname queries waiting for an answer from
anyone.
Failing that, you hand set your network configuration.
Normally, when you connect up to your ISP their DHCP server assigns you
all that networking info. Some don't, some expect you to set some
things, though that's an older way of doing things. And some just fail
badly. If you want to know your ISP's DNS servers to put into your
network configuration, or into your name daemon's forwarder IPs, you
could try:
a) Connecting via DHCP and copying the details
b) Asking them what the DNS server IPs are
c) Googling them
Bearing in mind that an ISP's DNS servers may change, at any time, they
may expect you to use DHCP to keep them current.
If there's a router between your ISP and your device, *it* will have
your ISP's DNS IPs in it, as your ISP's DHCP server will have
configured it, and you can copy them. And *it* will probably act as
your DHCP server for the rest of your network. You may be able to
customise its DHCP settings to suit your LAN. That router will act as
your DNS server, or simply pass queries through. You can use that
router's IP as your DNS forwarder IP.
You may not need to use your ISP's DNS servers, you could simply use
Goggle's, or some other public DNS server (there are various public
ones, with and without censoring). This may actually be better for you
than your ISP's. The only gotcha is that some ISPs will give a
different answer to their mailserver's IP to their own clients than to
the rest of the world.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
1:09 a.m.
On 3/27/23 21:22, Tim via users wrote:
Tim:
>> Are you on-line?
>>
>> And did any of the other options work?
ToddAndMargo:
> No. And I am also not running sysyemd-resolved
Perhaps we should go back to the start, your question is itself a bit
odd. DNS means Domain Name System, but we all presume you want to know
the address of your Domain Name Server.
When a device joins a network it is typical that a DHCP server assigns
it an addresses (numerical IP, hostname, domain name), and provides
some other addresses (gateway IP, nameserver(s), subnet mask). The
DHCP server need properly configuring to provide that info. Your
device will glean that info, and use it, even if you are running your
own name server.
And one would expect that all of that gets cancelled when disconnecting
(not that people often cleanly disconnect, as opposed to just losing
connection).
Failing that, without a DHCP server, variously named auto-config
schemes can take place (Bonjour, ZeroConf, etc) which do a similar
task. This time, the device, itself, self sets several of those
parameters, but not in a way that can communicate outside of the
network. It'll pick a random IP address from within a local-only
range, it'll broadcast hostname queries waiting for an answer from
anyone.
Failing that, you hand set your network configuration.
Normally, when you connect up to your ISP their DHCP server assigns you
all that networking info. Some don't, some expect you to set some
things, though that's an older way of doing things. And some just fail
badly. If you want to know your ISP's DNS servers to put into your
network configuration, or into your name daemon's forwarder IPs, you
could try:
a) Connecting via DHCP and copying the details
b) Asking them what the DNS server IPs are
c) Googling them
Bearing in mind that an ISP's DNS servers may change, at any time, they
may expect you to use DHCP to keep them current.
If there's a router between your ISP and your device, *it* will have
your ISP's DNS IPs in it, as your ISP's DHCP server will have
configured it, and you can copy them. And *it* will probably act as
your DHCP server for the rest of your network. You may be able to
customise its DHCP settings to suit your LAN. That router will act as
your DNS server, or simply pass queries through. You can use that
router's IP as your DNS forwarder IP.
You may not need to use your ISP's DNS servers, you could simply use
Goggle's, or some other public DNS server (there are various public
ones, with and without censoring). This may actually be better for you
than your ISP's. The only gotcha is that some ISPs will give a
different answer to their mailserver's IP to their own clients than to
the rest of the world.
I was looking for a way I could look up the final DNS
server, regardless of was type of local server I was
going through. I don't think it is possible. It looks
like I should dig it out from /etc/named.conf's
forwards section.
# grep -i forwarders /etc/named.conf | grep -v "#"
forwarders { 208.67.222.123; 208.67.220.123; };
forwarders {8.8.8.8; 8.8.4.4; };
And it looks like I have to be root to read /etc/named.conf,
so never mind.
2:23 a.m.
On 28 Mar 2023, at 07:10, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
On 3/27/23 21:22, Tim via users wrote:
> Tim:
>>> Are you on-line?
>>>
>>> And did any of the other options work?
> ToddAndMargo:
>> No. And I am also not running sysyemd-resolved
> Perhaps we should go back to the start, your question is itself a bit
> odd. DNS means Domain Name System, but we all presume you want to know
> the address of your Domain Name Server.
> When a device joins a network it is typical that a DHCP server assigns
> it an addresses (numerical IP, hostname, domain name), and provides
> some other addresses (gateway IP, nameserver(s), subnet mask). The
> DHCP server need properly configuring to provide that info. Your
> device will glean that info, and use it, even if you are running your
> own name server.
> And one would expect that all of that gets cancelled when disconnecting
> (not that people often cleanly disconnect, as opposed to just losing
> connection).
> Failing that, without a DHCP server, variously named auto-config
> schemes can take place (Bonjour, ZeroConf, etc) which do a similar
> task. This time, the device, itself, self sets several of those
> parameters, but not in a way that can communicate outside of the
> network. It'll pick a random IP address from within a local-only
> range, it'll broadcast hostname queries waiting for an answer from
> anyone.
> Failing that, you hand set your network configuration.
> Normally, when you connect up to your ISP their DHCP server assigns you
> all that networking info. Some don't, some expect you to set some
> things, though that's an older way of doing things. And some just fail
> badly. If you want to know your ISP's DNS servers to put into your
> network configuration, or into your name daemon's forwarder IPs, you
> could try:
> a) Connecting via DHCP and copying the details
> b) Asking them what the DNS server IPs are
> c) Googling them
> Bearing in mind that an ISP's DNS servers may change, at any time, they
> may expect you to use DHCP to keep them current.
> If there's a router between your ISP and your device, *it* will have
> your ISP's DNS IPs in it, as your ISP's DHCP server will have
> configured it, and you can copy them. And *it* will probably act as
> your DHCP server for the rest of your network. You may be able to
> customise its DHCP settings to suit your LAN. That router will act as
> your DNS server, or simply pass queries through. You can use that
> router's IP as your DNS forwarder IP.
> You may not need to use your ISP's DNS servers, you could simply use
> Goggle's, or some other public DNS server (there are various public
> ones, with and without censoring). This may actually be better for you
> than your ISP's. The only gotcha is that some ISPs will give a
> different answer to their mailserver's IP to their own clients than to
> the rest of the world.
I was looking for a way I could look up the final DNS
server, regardless of was type of local server I was
going through.
To lookup a name can involves a lot of dns servers,
not sure how many is typical but is likely 3 or more until cached answers exist.
What do you mean by final dns server?
Barry
I don't think it is possible. It looks
like I should dig it out from /etc/named.conf's
forwards section.
# grep -i forwarders /etc/named.conf | grep -v "#"
forwarders { 208.67.222.123; 208.67.220.123; };
forwarders {8.8.8.8; 8.8.4.4; };
And it looks like I have to be root to read /etc/named.conf,
so never mind.
_______________________________________________
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
7:10 a.m.
On 3/28/23 00:23, Barry wrote:
> On 28 Mar 2023, at 07:10, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 3/27/23 21:22, Tim via users wrote:
>> Tim:
>>>> Are you on-line?
>>>>
>>>> And did any of the other options work?
>> ToddAndMargo:
>>> No. And I am also not running sysyemd-resolved
>> Perhaps we should go back to the start, your question is itself a bit
>> odd. DNS means Domain Name System, but we all presume you want to know
>> the address of your Domain Name Server.
>> When a device joins a network it is typical that a DHCP server assigns
>> it an addresses (numerical IP, hostname, domain name), and provides
>> some other addresses (gateway IP, nameserver(s), subnet mask). The
>> DHCP server need properly configuring to provide that info. Your
>> device will glean that info, and use it, even if you are running your
>> own name server.
>> And one would expect that all of that gets cancelled when disconnecting
>> (not that people often cleanly disconnect, as opposed to just losing
>> connection).
>> Failing that, without a DHCP server, variously named auto-config
>> schemes can take place (Bonjour, ZeroConf, etc) which do a similar
>> task. This time, the device, itself, self sets several of those
>> parameters, but not in a way that can communicate outside of the
>> network. It'll pick a random IP address from within a local-only
>> range, it'll broadcast hostname queries waiting for an answer from
>> anyone.
>> Failing that, you hand set your network configuration.
>> Normally, when you connect up to your ISP their DHCP server assigns you
>> all that networking info. Some don't, some expect you to set some
>> things, though that's an older way of doing things. And some just fail
>> badly. If you want to know your ISP's DNS servers to put into your
>> network configuration, or into your name daemon's forwarder IPs, you
>> could try:
>> a) Connecting via DHCP and copying the details
>> b) Asking them what the DNS server IPs are
>> c) Googling them
>> Bearing in mind that an ISP's DNS servers may change, at any time, they
>> may expect you to use DHCP to keep them current.
>> If there's a router between your ISP and your device, *it* will have
>> your ISP's DNS IPs in it, as your ISP's DHCP server will have
>> configured it, and you can copy them. And *it* will probably act as
>> your DHCP server for the rest of your network. You may be able to
>> customise its DHCP settings to suit your LAN. That router will act as
>> your DNS server, or simply pass queries through. You can use that
>> router's IP as your DNS forwarder IP.
>> You may not need to use your ISP's DNS servers, you could simply use
>> Goggle's, or some other public DNS server (there are various public
>> ones, with and without censoring). This may actually be better for you
>> than your ISP's. The only gotcha is that some ISPs will give a
>> different answer to their mailserver's IP to their own clients than to
>> the rest of the world.
>
> I was looking for a way I could look up the final DNS
> server, regardless of was type of local server I was
> going through.
To lookup a name can involves a lot of dns servers,
not sure how many is typical but is likely 3 or more until cached answers exist.
What do you mean by final dns server?
Barry
> I don't think it is possible. It looks
> like I should dig it out from /etc/named.conf's
> forwards section.
>
> # grep -i forwarders /etc/named.conf | grep -v "#"
> forwarders { 208.67.222.123; 208.67.220.123; };
> forwarders {8.8.8.8; 8.8.4.4; };
>
> And it looks like I have to be root to read /etc/named.conf,
> so never mind.
I was just trying to figure out what the DNF was when using a caching
name server: the "forwarders", without having to dig
it our of /etc/named.conf
4:24 a.m.
bind and its named.service has no autoconfiguration that I know about.
Someone has to write forwarders {} into /etc/named.conf or its included
file. Whoever did that should know how has he chosen used forwarders. If
that were any tool, it might have easier source file.
In general there is no final DNS you can obtain. The final DNS depends
on the name you query. There can be multiple layers of forwarders
chained behind themselves. I think the best bet would be processing what
connections offered as their name servers. nmcli without parameters
might help with that. But there is no specialized tool to tell you that
set of servers. General automatic tool, which could tell you for any
local cache, what servers would it use for a name query, does not exist
(yet). bind, unbound or dnsmasq does not provide API to create such tool.
On 3/28/23 14:10, ToddAndMargo via users wrote:
On 3/28/23 00:23, Barry wrote:
>
>
>> On 28 Mar 2023, at 07:10, ToddAndMargo via users
>> <users(a)lists.fedoraproject.org> wrote:
>>
>> On 3/27/23 21:22, Tim via users wrote:
>>> Tim:
>>>>> Are you on-line?
>>>>>
>>>>> And did any of the other options work?
>>> ToddAndMargo:
>>>> No. And I am also not running sysyemd-resolved
>>> Perhaps we should go back to the start, your question is itself a bit
>>> odd. DNS means Domain Name System, but we all presume you want to
>>> know
>>> the address of your Domain Name Server.
>>> When a device joins a network it is typical that a DHCP server assigns
>>> it an addresses (numerical IP, hostname, domain name), and provides
>>> some other addresses (gateway IP, nameserver(s), subnet mask). The
>>> DHCP server need properly configuring to provide that info. Your
>>> device will glean that info, and use it, even if you are running your
>>> own name server.
>>> And one would expect that all of that gets cancelled when
>>> disconnecting
>>> (not that people often cleanly disconnect, as opposed to just losing
>>> connection).
>>> Failing that, without a DHCP server, variously named auto-config
>>> schemes can take place (Bonjour, ZeroConf, etc) which do a similar
>>> task. This time, the device, itself, self sets several of those
>>> parameters, but not in a way that can communicate outside of the
>>> network. It'll pick a random IP address from within a local-only
>>> range, it'll broadcast hostname queries waiting for an answer from
>>> anyone.
>>> Failing that, you hand set your network configuration.
>>> Normally, when you connect up to your ISP their DHCP server assigns
>>> you
>>> all that networking info. Some don't, some expect you to set some
>>> things, though that's an older way of doing things. And some just
>>> fail
>>> badly. If you want to know your ISP's DNS servers to put into your
>>> network configuration, or into your name daemon's forwarder IPs, you
>>> could try:
>>> a) Connecting via DHCP and copying the details
>>> b) Asking them what the DNS server IPs are
>>> c) Googling them
>>> Bearing in mind that an ISP's DNS servers may change, at any time,
>>> they
>>> may expect you to use DHCP to keep them current.
>>> If there's a router between your ISP and your device, *it* will have
>>> your ISP's DNS IPs in it, as your ISP's DHCP server will have
>>> configured it, and you can copy them. And *it* will probably act as
>>> your DHCP server for the rest of your network. You may be able to
>>> customise its DHCP settings to suit your LAN. That router will act as
>>> your DNS server, or simply pass queries through. You can use that
>>> router's IP as your DNS forwarder IP.
>>> You may not need to use your ISP's DNS servers, you could simply use
>>> Goggle's, or some other public DNS server (there are various public
>>> ones, with and without censoring). This may actually be better for
>>> you
>>> than your ISP's. The only gotcha is that some ISPs will give a
>>> different answer to their mailserver's IP to their own clients than to
>>> the rest of the world.
>>
>> I was looking for a way I could look up the final DNS
>> server, regardless of was type of local server I was
>> going through.
>
> To lookup a name can involves a lot of dns servers,
> not sure how many is typical but is likely 3 or more until cached
> answers exist.
>
> What do you mean by final dns server?
>
> Barry
>
>
>
>
>
>> I don't think it is possible. It looks
>> like I should dig it out from /etc/named.conf's
>> forwards section.
>>
>> # grep -i forwarders /etc/named.conf | grep -v "#"
>> forwarders { 208.67.222.123; 208.67.220.123; };
>> forwarders {8.8.8.8; 8.8.4.4; };
>>
>> And it looks like I have to be root to read /etc/named.conf,
>> so never mind.
I was just trying to figure out what the DNF was when using a caching
name server: the "forwarders", without having to dig
it our of /etc/named.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
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
7:01 a.m.
On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
I was looking for a way I could look up the final DNS
server, regardless of was type of local server I was
going through. I don't think it is possible. It looks
like I should dig it out from /etc/named.conf's
forwards section.
Do you mean you are trying to determine the authoritative name server
for the hostname? There is an option to dig '+nssearch' that sounds
like it might be able to do this, but I'm not sure how it is used and
my feeble attempts did not work.
7:10 a.m.
On 3/28/23 05:01, Go Canes wrote:
On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
> I was looking for a way I could look up the final DNS
> server, regardless of was type of local server I was
> going through. I don't think it is possible. It looks
> like I should dig it out from /etc/named.conf's
> forwards section.
Do you mean you are trying to determine the authoritative name server
for the hostname? There is an option to dig '+nssearch' that sounds
like it might be able to do this, but I'm not sure how it is used and
my feeble attempts did not work.
I was just trying to figure out what the DNF was when using a caching
name server: the "forwarders", without having to dig
it our of /etc/named.conf
3:36 p.m.
On 28 Mar 2023, at 13:10, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
On 3/28/23 05:01, Go Canes wrote:
>> On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users
>> <users(a)lists.fedoraproject.org> wrote:
>> I was looking for a way I could look up the final DNS
>> server, regardless of was type of local server I was
>> going through. I don't think it is possible. It looks
>> like I should dig it out from /etc/named.conf's
>> forwards section.
> Do you mean you are trying to determine the authoritative name server
> for the hostname? There is an option to dig '+nssearch' that sounds
> like it might be able to do this, but I'm not sure how it is used and
> my feeble attempts did not work.
I was just trying to figure out what the DNF was when using a caching name server: the
"forwarders", without having to dig
it our of /etc/named.conf
Cannot be done except by reading the config files.
In the case of my named.conf there are no forwarders.
You cannot tell that is happening without reading the named.conf.
What is the problem that you are trying solve?
Barry
_______________________________________________
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
9:32 a.m.
On 3/28/23 05:01, Go Canes wrote:
On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
> I was looking for a way I could look up the final DNS
> server, regardless of was type of local server I was
> going through. I don't think it is possible. It looks
> like I should dig it out from /etc/named.conf's
> forwards section.
Do you mean you are trying to determine the authoritative name server
for the hostname? There is an option to dig '+nssearch' that sounds
like it might be able to do this, but I'm not sure how it is used and
my feeble attempts did not work.
dig @8.8.8.8 your.domain. ns
3:45 p.m.
On 3/28/23 07:32, Mike Wright wrote:
On 3/28/23 05:01, Go Canes wrote:
> On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users
> <users(a)lists.fedoraproject.org> wrote:
>> I was looking for a way I could look up the final DNS
>> server, regardless of was type of local server I was
>> going through. I don't think it is possible. It looks
>> like I should dig it out from /etc/named.conf's
>> forwards section.
>
> Do you mean you are trying to determine the authoritative name server
> for the hostname? There is an option to dig '+nssearch' that sounds
> like it might be able to do this, but I'm not sure how it is used and
> my feeble attempts did not work.
dig @8.8.8.8 your.domain. ns
It is not showing my end DNS server or any
dns server at all. I tried substituting
other IP's including my own lan IP and my
WAN IP (which times out) and no DNS
shows up at all
4:31 p.m.
On 03/28/2023 02:45 PM, ToddAndMargo via users wrote:
It is not showing my end DNS server or any
dns server at all. I tried substituting
other IP's including my own lan IP and my
WAN IP (which times out) and no DNS
shows up at all
I get the impression that what you want is the machine that gives you
authoritative answers to your dns queries. If so, there's no one
answer, as that depends on which domain you're asking about at any given
time. Look here for an explanation of how it works:
https://www.datadoghq.com/knowledge-center/dns-resolution/
5:59 p.m.
On 3/28/23 14:31, Joe Zeff wrote:
On 03/28/2023 02:45 PM, ToddAndMargo via users wrote:
> It is not showing my end DNS server or any
> dns server at all. I tried substituting
> other IP's including my own lan IP and my
> WAN IP (which times out) and no DNS
> shows up at all
I get the impression that what you want is the machine that gives you
authoritative answers to your dns queries. If so, there's no one
answer, as that depends on which domain you're asking about at any given
time. Look here for an explanation of how it works:
https://www.datadoghq.com/knowledge-center/dns-resolution/
I was just wanting to see what DNS I was actually using.
I have this in my /etc/naned/conf
options {
# the following forwarders is Family Friendly Open DNS (no porn
sites):
forwarders { 208.67.222.123; 208.67.220.123; };
};
and
zone "bravesoftware.com" IN {
type forward;
forward only;
forwarders {8.8.8.8; 8.8.4.4; };
};
The purpose is that Open DNS blocks Brave Browser's
Private Window with Tor's name resolution as it
is a work around for viewing pron sites.
Since I do not deliberately go to porn sites,
I use Family friendly Open DNS to protect me
from an funny business and trickery and
me being a kluz with the mosue at times.
But I still want to be able to use Brave's TOR
private window for looking up stuff that is just
nobody else's business, such as medical things or
things that can be easily misunderstood by law
enforcement, such as the common name for the
polymer polyvinyl carboxy. (I would not look
it up, except on TOR).
So I was curious as to what DNS was looking up what.
6:39 p.m.
On Tue, Mar 28, 2023 at 7:00 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
I was just wanting to see what DNS I was actually using.
dig and nslookup both display the IP address of the DNS resolver that
you are querying. But if you are asking for which DNS resolver
actually provided the answer, that would be more difficult as prior
posts have indicated.
For example, if I do a DNS lookup of lists.fedoraproject.org, and
assuming none of the DNS resolvers have the data cached, my local DNS
server (my ISP router) will forward the request to a DNS resolver it
has configured, that DNS server will do the same, etc., until we
either get a cached answer, or we go all the way up to one of the root
DNS servers which can forward to the authoritative DNS server for the
domain. So if you are trying to determine which of the servers in the
forward chain provided the answer, that is difficult (again as per
prior answers).
7:28 p.m.
On 3/28/23 16:39, Go Canes wrote:
On Tue, Mar 28, 2023 at 7:00 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
> I was just wanting to see what DNS I was actually using.
dig and nslookup both display the IP address of the DNS resolver that
you are querying. But if you are asking for which DNS resolver
actually provided the answer, that would be more difficult as prior
posts have indicated.
For example, if I do a DNS lookup of lists.fedoraproject.org, and
assuming none of the DNS resolvers have the data cached, my local DNS
server (my ISP router) will forward the request to a DNS resolver it
has configured, that DNS server will do the same, etc., until we
either get a cached answer, or we go all the way up to one of the root
DNS servers which can forward to the authoritative DNS server for the
domain. So if you are trying to determine which of the servers in the
forward chain provided the answer, that is difficult (again as per
prior answers).
ya, no fooling!
Well Brave's private windows with TOR is working,
and I am not willing to test a porn site to find
out if I have things configured right.
8:01 p.m.
On 3/28/23 16:39, Go Canes wrote:
On Tue, Mar 28, 2023 at 7:00 PM ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
> I was just wanting to see what DNS I was actually using.
dig and nslookup both display the IP address of the DNS resolver that
you are querying. But if you are asking for which DNS resolver
actually provided the answer, that would be more difficult as prior
posts have indicated.
For example, if I do a DNS lookup of lists.fedoraproject.org, and
assuming none of the DNS resolvers have the data cached, my local DNS
server (my ISP router) will forward the request to a DNS resolver it
has configured, that DNS server will do the same, etc., until we
either get a cached answer, or we go all the way up to one of the root
DNS servers which can forward to the authoritative DNS server for the
domain. So if you are trying to determine which of the servers in the
forward chain provided the answer, that is difficult (again as per
prior answers).
You've got a good grasp of what it going on. Here are the missing bits.
This is a representation of a some url:
WWW.GOOGLE.COM.
SUBDOMAIN.DOMAIN.TLD. (TLD = top level domain, beneath . )
Note the dot at the very end. All searches begin there. To make this
easier we'll use google's name servers to start. Since dig is in wide
use we'll use it for dns searches. (As for options to dig: the only one
of use to any but very advanced, specialized users is +short --
+nssearch is of no use to us. Forget you ever heard of it.)
There are only a few types of dns records:
SOA start of authority - primary ns, contact email, timestamp,
various ttls (I'm not going to include timestamps and ttls here)
NS name servers
MX mail exchangers
A ipv4 IP addresses
AAAA ipv6 IP addresses
CNAME aliases for domain names
TXT text records used for all sorts of things, even random comments
There are others that, for the most part, are irrelevant to mere mortals.
Who is the Start Of Authority for "." ?
dig +short @8.8.8.8 . SOA
a.root-servers.net. nstld.verisign-grs.com.
Ask the SOA who their name servers are
dig @a.root-servers.net. root-servers.net. NS
a.root-servers.net. 3600000 IN A 198.41.0.4
a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30
( + 12 more )
Ask a root-server who are the name servers for COM.
dig @k.root-servers.net. com. NS
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
( + 12 more )
Ask a gtld-server who are the name servers for GOOGLE.COM.
dig @f.gtld-servers.net. google.com. NS
ns1.google.com. 172800 IN A 216.239.32.10
ns1.google.com. 172800 IN AAAA 2001:4860:4802:32::a
( + 3 more )
Ask a google name server for the IP for www.google.com.
dig @ns3.google.com. www.google.com. A
www.google.com. 193 IN A 142.250.189.228
And that is the AUTHORITATIVE answer provided by google's dns authority.
As you can see, in every case, from the top down, each level points to
the authority for the next level down by answering a request for an NS
record. It isn't random. Those are the facts on the ground at the time
the request was made.
And that's how you find out who the authoritative name server for a
domain is.
PS. There is a special top level domain (arpa.) that handles lookups
for IP addresses. Its domain is in-addr.arpa. It matches IPs to the
associated host name by returning a PTR (pointer) record. This is how
mailservers prove they are not fraudulent. Look up the MX record, it
gives a host name. Lookup the host name, get an IP. Lookup up the PTR
for that IP. It should match the original MX host name lookup.
5:22 a.m.
On Tue, 2023-03-28 at 15:59 -0700, ToddAndMargo via users wrote:
I was just wanting to see what DNS I was actually using.
I have this in my /etc/naned/conf
options {
# the following forwarders is Family Friendly Open DNS (no porn sites):
forwarders { 208.67.222.123; 208.67.220.123; };
};
The above name servers will actually handle the beginning of your
queries for all domains (they'll going the through the same processes
as if your name server did it, itself), except for any exceptions that
you've configured, such as:
and
zone "bravesoftware.com" IN {
type forward;
forward only;
forwarders {8.8.8.8; 8.8.4.4; };
};
Your name server will pass the task onto 8.8.8.8 and 8.8.4.4 for that
domain name (and its subdomains, e.g. www.bravesoftware.com, it's mail
servers, etc), and that name server will do the queries.
In essence, your name server is doing nothing but pass some queries
here, other's there.
The purpose is that Open DNS blocks Brave Browser's
Private Window with Tor's name resolution as it
is a work around for viewing pron sites.
Since I do not deliberately go to porn sites,
I use Family friendly Open DNS to protect me
from an funny business and trickery and
me being a kluz with the mosue at times.
But I still want to be able to use Brave's TOR
private window for looking up stuff that is just
nobody else's business, such as medical things or
things that can be easily misunderstood by law
enforcement, such as the common name for the
polymer polyvinyl carboxy. (I would not look
it up, except on TOR).
I was under the impression that privacy based anonymising browsers
shouldn't use your general DNS servers (because that leaks
information). They should find some anonymous servers when they start
up, and use them.
Look at Google, it's goal is databasing everything. Tie a bunch of
queries to the same IP, roll it all together, it doesn't matter what
privacy options you attempt, which different browsers you use, or if
you remove cookies. If you don't want some queries in that database,
don't use Google for them. They continually find ways to work around
any things we do to stop them doing that.
I'm sick of being asked to set a cookie setting the fact that I don't
want cookies. FFS! If I completely switch off cookies in my browser,
it's a dead loop of an unanswerable question, rather than not being
asked the question.
It's been quite some time since I accidentally ended up at a porn site,
some bright spark decided a great way to hook people into their site
was to have some pages about fixing common problems your printer. You
google that innocent thing, as will a huge number of people, and ended
up at a page with porn banners. Google's got better at derating those
kinds of baiting page results these days.
So I was curious as to what DNS was looking up what.
Switch on logging in your nameserver, do "tail -f" on the log file, or
figure out how rndc works, watch some queries go through. Try some in
your normal browser, try some in your privacy browser.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
10:46 a.m.
On 03/29/2023 04:22 AM, Tim via users wrote:
Look at Google, it's goal is databasing everything. Tie a bunch
of
queries to the same IP, roll it all together, it doesn't matter what
privacy options you attempt, which different browsers you use, or if
you remove cookies. If you don't want some queries in that database,
don't use Google for them. They continually find ways to work around
any things we do to stop them doing that.
Try using startpage.com instead. Yes, it sends its queries through
google, but the queries are sent from them, not you, and there's nothing
tying them to your IP.
9:22 p.m.
Tim:
> Look at Google, it's goal is databasing everything. Tie a
bunch of
> queries to the same IP, roll it all together, it doesn't matter what
> privacy options you attempt, which different browsers you use, or if
> you remove cookies. If you don't want some queries in that database,
> don't use Google for them. They continually find ways to work around
> any things we do to stop them doing that.
Joe Zeff:
Try using startpage.com instead. Yes, it sends its queries through
google, but the queries are sent from them, not you, and there's nothing
tying them to your IP.
Perhaps initially, but if you're sent to a page with Google ads, you
check your gmail, you use your Android phone, or do any number of
ordinary internet activities, and you're identifiable. I seem to
recall some research saying you only needed to do about four things on
the internet before you analysable. If you run a browse with script
blocker, you notice that so many pages have over a dozen different
domains running scripts for that page. The world-wide-web was aptly
named.
Since we're not planning malfeasance, most of us have less concerns
about getting on a list (depending on what country you live it). Many
have lost their pissed-off-ness about that, but the advertising
following you around is annoying, can be considered harassment, and
medical issues people read up about can ruin job opportunities, etc.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
9:26 p.m.
On 03/29/2023 08:22 PM, Tim via users wrote:
Perhaps initially, but if you're sent to a page with Google ads,
you
check your gmail, you use your Android phone, or do any number of
ordinary internet activities, and you're identifiable.
That may be so, but at least by using startpage.com you're not letting
them mine your search history as well.
4:39 a.m.
How would that work?
Instead of that you send startpage.com all your history. If that site
has more trust than common big tech company, it would be your choice.
But it should be clear to you some organization would be always able to
mine (bigger) part of your browsing history. You can make work arounds
by using VPN or at least encrypted DNS, but choosing trusted internet
provider should be always a start. Any workarounds typically just change
who would be able to watch your browsing.
On 3/30/23 04:26, Joe Zeff wrote:
On 03/29/2023 08:22 PM, Tim via users wrote:
> Perhaps initially, but if you're sent to a page with Google ads, you
> check your gmail, you use your Android phone, or do any number of
> ordinary internet activities, and you're identifiable.
That may be so, but at least by using startpage.com you're not letting
them mine your search history as well.
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
11:49 a.m.
On 04/12/2023 03:39 AM, Petr Menšík wrote:
How would that work?
> That may be so, but at least by using startpage.com you're
not letting
> them mine your search history as well.
>
Stop topposting!
Startpage anonomyzes queries before sending them off to Google, and
keeps no logs. All Google knows is that the query came from Startpage,
not where it originated, so they can't tell who's asking.
8:32 p.m.
On 3/28/23 14:31, Joe Zeff wrote:
On 03/28/2023 02:45 PM, ToddAndMargo via users wrote:
> It is not showing my end DNS server or any
> dns server at all. I tried substituting
> other IP's including my own lan IP and my
> WAN IP (which times out) and no DNS
> shows up at all
I get the impression that what you want is the machine that gives you
authoritative answers to your dns queries. If so, there's no one
answer, as that depends on which domain you're asking about at any given
time.
Hi Joe, I find your answer misleading. When you request the NS record
from a resolver ( caching name server ) you get the official TOP down
AUTHORITATIVE answer in effect at the time the record was cached. There
is only one answer. If you don't trust that the resolver is providing
the current IP address for that domain's authority (NS) you can pull it
yourself by starting at the top and following the chain of authority all
the way down until you reach the the domain's current NS record.
7:33 a.m.
On Mon, 2023-03-27 at 23:09 -0700, ToddAndMargo via users wrote:
I was looking for a way I could look up the final DNS
server, regardless of was type of local server I was
going through. I don't think it is possible. It looks
like I should dig it out from /etc/named.conf's
forwards section.
# grep -i forwarders /etc/named.conf | grep -v "#"
forwarders { 208.67.222.123; 208.67.220.123; };
forwarders {8.8.8.8; 8.8.4.4; };
I don't know what you mean by "final"? Simply the last one in the list
of your servers? Or you mean upstream, the ones that answered the
queries that your name server asked of it, that you asked of your own
name server?
When you have a series of DNS servers that you can query, the old
behaviour was to always consult the first one on the list. And only
walk down the list when it doesn't respond, until it gets to one that
does. For the next DNS query, it start at the top of the list again,
waiting for the first one to respond, or not, then walk down the list
one by one. And "not responding" really means exactly that. If a
server responds with any answer, even an answer that doesn't have the
requested data, it has responded, and that's the end of your query.
Then there's other behaviours, where the system keeps querying the last
DNS server that has responded (ignoring ones that have failed it
earlier), or it can randomly ask any server in the list.
If you dig a domain name (e.g. dig example.com), the results will tell
you what servers are responsible for its records.
For what it's worth, if you grep /etc/named.conf for forwarders, you
mightn't find what you expect. You can have forwarders that only apply
to certain domain names.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7
15:41:52 UTC 2023 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.
3:47 p.m.
On 3/28/23 05:33, Tim via users wrote:
On Mon, 2023-03-27 at 23:09 -0700, ToddAndMargo via users wrote:
> I was looking for a way I could look up the final DNS
> server, regardless of was type of local server I was
> going through. I don't think it is possible. It looks
> like I should dig it out from /etc/named.conf's
> forwards section.
>
> # grep -i forwarders /etc/named.conf | grep -v "#"
> forwarders { 208.67.222.123; 208.67.220.123; };
> forwarders {8.8.8.8; 8.8.4.4; };
I don't know what you mean by "final"? Simply the last one in the list
of your servers? Or you mean upstream, the ones that answered the
queries that your name server asked of it, that you asked of your own
name server?
When you have a series of DNS servers that you can query, the old
behaviour was to always consult the first one on the list. And only
walk down the list when it doesn't respond, until it gets to one that
does. For the next DNS query, it start at the top of the list again,
waiting for the first one to respond, or not, then walk down the list
one by one. And "not responding" really means exactly that. If a
server responds with any answer, even an answer that doesn't have the
requested data, it has responded, and that's the end of your query.
Then there's other behaviours, where the system keeps querying the last
DNS server that has responded (ignoring ones that have failed it
earlier), or it can randomly ask any server in the list.
If you dig a domain name (e.g. dig example.com), the results will tell
you what servers are responsible for its records.
For what it's worth, if you grep /etc/named.conf for forwarders, you
mightn't find what you expect. You can have forwarders that only apply
to certain domain names.
the ones that answered the queries that your name
server asked of it
4:53 a.m.
On Tue, 2023-03-28 at 13:47 -0700, ToddAndMargo via users wrote:
the ones that answered the queries that your name
server asked of it
The general process for asking a real domain server for a domain name
like www.example.com is that it'd consult its records (*) to find a
root server, ask one of the various root servers who deals with .com,
then it'd ask one of the .com servers who has the records for
example.com, then it'd query it, for whatever subdomain you wanted
(www.example.com).
i.e. It reads the domain name backwards from how you do.
.
.com
example.com
www.example.com
* (Your name server will have these as part of its install, and it will
update them, or yum/dnf will with rpm updates.)
It's a wee bit more convoluted than that, it goes a bit like this:
who holds the records for <some domain-name>.
that's held by <someone-else by name>
what's the IP address for that <someone-else's name>
connect to that <someone-else's IP>
who holds the record for <some domain-name>
that's held by <another-someone-else by name>
what's the IP...
There's a reason why the queries might go along the line of who holds
the records for example.com? They're held by nameserver.example.net,
rather than being directly told they're being held at 93.184.216.34.
It allows a consistent nameserver name to be used for the records, but
the IP addresses may be variable.
If you look in your own domain records, it'll will give a nameserver
for your domain as a domain-NAME-address, further down will be a record
giving a numerical-IP-address for that domain-NAME-address.
I've had a few people go, "no, it doesn't work that way." Yes, it
does, look in the files for a nameserver!
There aren't a great number of steps for finding out domain name
records, it's reasonably straightforward, other than a couple of things
off the top of my head: If you're using forwarders, they're an extra
step. And if a domain uses glue records, that's another step.
If you have forwarders for certain domains, they'll follow a different
sequence. Likewise, if you forward all queries. Your server will ask
the forwarder to do that work. Essentially, your server will only
answer some queries (the ones without any forwarders).
Glue records: The public records may say that a domain is handled by a
big hosting server, everyone queries it. It has a record that
redirects them to some other host that actually handles them. I always
forget what advantage that's supposed to have. I do know of the
problems they can cause, where someone foollishly sets things up so the
records are held somewhere that isn't publicly accessible.
Some domains will have their records hosted by several name servers
(think of Google having 4 domain servers, to spread the load around).
Queries will randomly get responded to by one of them.
dig example.com will tell you
the records for that domain (the answer section)
the nameserver that holds those records (the authority section) [the one that provided the
answers]
and the one that directly answered you (the query section) [and that'll be your
server]
You can think of the last two as passing a note to you across the room.
It's generally all you need to know, until you're trying to track down
where something is going wrong. Such as sometimes you get an answer,
sometimes you don't. Is a server failing? Are four backup servers
handling the queries, and one of them is bad.
The dig tool will allow you to directly query individual servers, so
you can trace such things.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
3:36 p.m.
On 3/29/23 02:53, Tim via users wrote:
dig example.com
$ dig gbis.com
...
;; Query time: 71 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
Not real helpful. I think I will just ping a
porn site and see what happens.
$ ping xxx.com
PING xxx.com (146.112.61.106) 56(84) bytes of data.
64 bytes from hit-adult.opendns.com (146.112.61.106): icmp_seq=1 ttl=58
time=12.1 ms
And that answered my question.
options {
forwarders { 208.67.222.123; 208.67.220.123; };
is not being bypassed by
zone "bravesoftware.com" IN {
type forward;
forward only;
forwarders {8.8.8.8; 8.8.4.4; };
};
Thank you all for the help! (I should of realized
that a ping would have solve the question instantly.)
-T
10:36 p.m.
On Wed, 2023-04-12 at 13:36 -0700, ToddAndMargo via users wrote:
$ dig gbis.com
...
;; Query time: 71 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
Not real helpful. I think I will just ping a
porn site and see what happens.
You've truncated that far too much for us to tell whether you've
assessed that correctly. All that tells us that whatever the query,
and whatever answers, or lack of answers, dig probed 127.0.0.1 for it,
and it responded in some way. *Your* query was internal, but what it
did with your query, we don't know.
$ ping xxx.com
PING xxx.com (146.112.61.106) 56(84) bytes of data.
64 bytes from hit-adult.opendns.com (146.112.61.106): icmp_seq=1 ttl=58
time=12.1 ms
And that answered my question.
Since you got an IP to ping for that domain name, something did *not*
block the DNS query. It was resolved. But that looks like their
substitute for the blocked site. If I try that address in a web
browser I get an unhelpful error message, with a bit of info about
trying to resolve the problem. If I ran a censoring site, my error
page would have said "blocked page, reason porn" (or other reasons).
If I try pinging a non-existent domain name, I get this response:
$ ping bulldust.lan
ping: bulldust.lan: Name or service not known
That can be because the domain name doesn't exist, or my DNS server
didn't get an IP for it (it could pretend it doesn't exist).
If I had a censoring DNS server, it could provide an IP that's actually
for someone else. That could be a server that simply throws up a "page
is blocked" message to any of the blocked domain names, so you know
what happened. In that case, I'd could get a ping response akin to:
$ ping nastysite.lan
PING safeblocker.lan (93.184.216.34) 56(84) bytes of data.
64 bytes from safeblocker.lan (93.184.216.34): icmp_seq=1 ttl=50 time=161 ms
64 bytes from safeblocker.lan (93.184.216.34): icmp_seq=2 ttl=50 time=161 ms
Where I *might* see that the response came from somewhere else, and I
*might* get some ping responses. I tried pinging nastysite, the server
gave me their safe IP instead, and that IP resolved to safeblocker.
The kind of thing you got. Though, a ping test is not a browsing test.
If I try pinging an existing domainname, one that isn't responding to
pings, I get this response.
$ ping nastyserver.lan
PING nastyserver.lan (192.168.1.44) 56(84) bytes of data.
From rocky.lan (192.168.1.1) icmp_seq=1 Destination Host Unreachable
(the from line is the machine I'm typing the command into)
However, I can't tell from that whether it's switched off, or not
responding to pings. It could be fully functional, but ignoring pings.
Ping only proves that some network hardware answered its pings. A lack
of a response doesn't mean a site isn't there, it doesn't prove that a
web server isn't running. Conversely, if you do get a ping response,
it also doesn't prove that a web server is running. It's not a web
server that responds to pings.
It's a bit like looking for the power light on my PC. It only shows
that it's switched on. It doesn't tell me anything about what may, or
may not, be running on it.
Ping tests a network end-to-end, provides some timing information about
those pings and their responses. Beyond that it tells you virtually
nothing (some people may look at the nature of the ping responses, and
decide because it's so-many bytes, etc, it's possibly some particular
OS). But still, it's only testing pings. If you want to test
something else, like the presence of a website, you need to try
browsing to it.
For what it's worth, mangling DNS to block a website will only be
partially successful. Only the big sites might have consistent IPs,
new crap pops up every minute and a censoring DNS server will always be
out-of-date (same with anti-virus), and browsers can use other means
than traditional DNS queries to connect (so places like schools would
need to use more effective blocking techniques).
e.g. https://en.wikipedia.org/wiki/DNS_over_HTTPS can bypass your
network's configured DNS server(s). It will use another technique to
directly query something over the internet.
At this stage, I don't think you get to pick what it uses. You only
have a choice whether your web browser has DoH enabled. So you want
want to check it's off.
And DoT is another alternative:
https://en.wikipedia.org/wiki/DNS_over_TLS
And HTTP proxies are another (the proxy can do the resolving).
options {
forwarders { 208.67.222.123; 208.67.220.123; };
is not being bypassed by
zone "bravesoftware.com" IN {
type forward;
forward only;
forwarders {8.8.8.8; 8.8.4.4; };
};
I can't really tell that from what you've posted.
I can tell that from that snippet of the named.conf file, that if you
make any DNS queries of your DNS server regarding "bravesoftware.com"
it will ask either 8.8.8.8 or 8.8.4.4 for the answers. Every other DNS
query, made through your DNS server, will be answered by 208.67.222.123
or 208.67.220.123 (FamilyShield DNS servers).
But if a browser doesn't query your DNS server, it won't be censored.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
1:37 a.m.
On Thu, 2023-04-13 at 13:06 +0930, Tim via users wrote:
a ping test is not a browsing test
I did start off with something saying that before the in-depth
commentary bit, but didn't notice I'd lost it.
You need to check with your browser that content filtering is working,
as well as ensuring you've set your networking options up the way you
expected, browsers don't always work the way you expect them (they can
bypass ordinary DNS lookups in various ways).
Since you're using https://www.opendns.com/ as a filter, it has a set
of test instructions to check it's working, including testing the
filtering options. Try that as a test without having to test load an
actual adult site.
https://support.opendns.com/hc/en-us/articles/227986567-How-to-test-for-s...
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 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.
3:37 a.m.
On 4/12/23 23:37, Tim via users wrote:
Thank you!
398
days inactive
416
days old
43 comments
8 participants
participants (8)
-
Barry -
Go Canes -
Joe Zeff -
Mike Wright -
Petr Menšík -
Slade Watkins -
Tim -
ToddAndMargo