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
On 26 Mar 2023, at 22:57, ToddAndMargo via users users@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 3/26/23 15:07, Barry wrote:
On 26 Mar 2023, at 22:57, ToddAndMargo via users users@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!
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@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
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.
On Sun, Mar 26, 2023 at 5:57 PM ToddAndMargo via users < 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
On 3/26/23 15:09, Slade Watkins via users wrote:
On Sun, Mar 26, 2023 at 5:57 PM ToddAndMargo via users <users@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!
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.
On 27 Mar 2023, at 01:31, ToddAndMargo via users users@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 3/26/23 22:44, Barry wrote:
On 27 Mar 2023, at 01:31, ToddAndMargo via users users@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.
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?
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
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.
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.
On 28 Mar 2023, at 07:10, ToddAndMargo via users users@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 3/28/23 00:23, Barry wrote:
On 28 Mar 2023, at 07:10, ToddAndMargo via users users@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
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@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users users@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.
On 3/28/23 05:01, Go Canes wrote:
On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users users@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
On 28 Mar 2023, at 13:10, ToddAndMargo via users users@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@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 3/28/23 05:01, Go Canes wrote:
On Tue, Mar 28, 2023 at 2:10 AM ToddAndMargo via users users@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
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@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
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/
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.
On Tue, Mar 28, 2023 at 7:00 PM ToddAndMargo via users users@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).
On 3/28/23 16:39, Go Canes wrote:
On Tue, Mar 28, 2023 at 7:00 PM ToddAndMargo via users users@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.
On 3/28/23 16:39, Go Canes wrote:
On Tue, Mar 28, 2023 at 7:00 PM ToddAndMargo via users users@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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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-succ...
On 4/12/23 23:37, Tim via users wrote:
https://support.opendns.com/hc/en-us/articles/227986567-How-to-test-for-succ...
Thank you!
-
Barry -
Go Canes -
Joe Zeff -
Mike Wright -
Petr Menšík -
Slade Watkins -
Tim -
ToddAndMargo