Using a VPN with DNS

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Using a VPN with DNS

Roger Adams
Quick questions.

Does using Cloudflare (or any other DNS) with a VPN make the connection more secure?

If so, are all VPNs the same, does using any DNS make a difference to the security of the connection?

Cheers

Roger

Sent from my iPhone

>



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

@lbutlr
On 2018-04-05 (21:21 MDT), Roger Adams <[hidden email]> wrote:
>
> Quick questions.
>
> Does using Cloudflare (or any other DNS) with a VPN make the connection more secure?

Depends on the VPN.

> If so, are all VPNs the same, does using any DNS make a difference to the security of the connection?

Some VPNs tunnel the DNS, some do not.

The security of the VPN connection is unaffected either way, but the amount of data that is leaked is different.

--
A.D. 1517: Martin Luther nails his 95 Theses to the church door and is
promptly moderated down to (-1, Flamebait). -- Yu Suzuki




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

Fritz Mills
In reply to this post by Roger Adams

> On Apr 5, 2018, at 10:21 PM, Roger Adams <[hidden email]> wrote:
>
> Quick questions.
>
> Does using Cloudflare (or any other DNS) with a VPN make the connection more secure?
>
> If so, are all VPNs the same, does using any DNS make a difference to the security of the connection?
>

Apologies in advance for what are surely stupid, uninformed questions, but don’t you need to connect to a DNS server to *get* to a VPN?

And then, once you’re connected to a VPN, wouldn’t all of your DNS queries go through the VPN?

How else could it work?






____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

Rodney
> On Apr 6, 2018, at 17:14, Fritz Mills <[hidden email]> wrote:
>
> Apologies in advance for what are surely stupid, uninformed questions, but don’t you need to connect to a DNS server to *get* to a VPN?

Not if you know the IP address of the VPN server, but getting the VPN’s via DNS won’t put you at risk, especially if you’re using a third party DNS.

> And then, once you’re connected to a VPN, wouldn’t all of your DNS queries go through the VPN?

all your traffic will go through the VPN, so you have to trust the VPN… :-(



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

Rodney
In reply to this post by Roger Adams

On Apr 6, 2018, at 05:21, Roger Adams <[hidden email]> wrote:

Does using Cloudflare (or any other DNS) with a VPN make the connection more secure?

If so, are all VPNs the same, does using any DNS make a difference to the security of the connection?

I’m the one who asked the original questions about Cloudflare. My questions were answered, but I seem to’ve opened a can of worms. Before people start reaching for their tinfoil hats, I’ll try to clear up some misconceptions about DNS (explaining an external audit to a non-IT person is beyond the scope of this message, and probably beyond the capability of anyone on the planet). I do have some qualifications for talking about DNS. It was part of my responsibility before I retired. However, retirement was a while ago, so things might’ve changed or my memory might have failed. In any event, I’ll just be hitting the high points with what follows. If you’re curious, O’Reilly has an excellent book on the subject. I also don’t know much about IPV6, so this is all about IPV4. I know that what follows is long and boring, but unless you’ve read it, or the equivalent, then you’re probably wasting time by asking DNS security questions.

What is DNS? DNS, the Domain Name System, is the phonebook of the Internet. It provides two main pieces of information; it resolves names to numbers (and vise versa), and provides routing information for email. I’ll leave “SOA”, “CNAME”, and other records as an exercise for the alert reader.

A DNS server’s job is not to protect “user data”, but to give it to anyone who asks for it and to do so quickly and accurately. The two major security issues with a DNS server are whether or not the data it provides is correct, and whether or not the “bad guys”, however you define them, can find out what information you’re asking for. I’ll address both of those after I’ve explained about how DNS works, but I can tell you that the second issue is extremely minor, even if you do live in Russia, and the damaging information is more readily available from other sources than via DNS.

DNS is a distributed system, meaning that there is no central authority for it except for the very top level of the hierarchy which is called “.”. The folks who manage “.” then designate domains underneath such as “com” “gov”, “uk”, “xxx’, whatever. The people who manage those domains below “.” can in turn allocate domains underneath them such as “tidbits” under “com". I’ll use the TidBITS domain as an example, because more people reading this will be familiar with it, and I’m not including any information that isn’t trivial to find by anyone who knows what to ask for. BTW, when written as “tidbits.com”, it is a “relative path”. The absolute path is “tidbits.com.”; “.” is the top of the tree. That’s not all that important at the moment, but you will see the trailing “.” In the examples below.

Since there is no central authority, every domain owner is responsible for designating at least one DNS server that is authoritative for addresses within that domain. Every device on the Internet that wants to access a resource by name must somehow query the server that is authoritative for the domain where the resource resides or access a server where the information is cached. Most of us ordinary folks who own domains only care about maybe a web server and email, so the ISP for the domain usually manages the DNS on our behalf.

Here are the DNS records that are authoritative for the TidBITS domain:

There are two of them, which is common practice. The “86400” is the TTL (Time To Live) for the records (or 24 hours). That is the time permitted to cache the records locally before they should be refreshed.

The “IN” just says that this is an Internet record; records come (or once came) in other flavors as well.

The last entry on each line is the absolute path name of the TidBITS name servers. To look up the IP address for www.tidbits.com, somebody needs to ask one of those two servers for it.

Here are the address (“A”) records for the web server www.tidbits.com:

www.tidbits.com. 300 IN A 104.28.5.110
www.tidbits.com. 300 IN A 104.28.4.110

There are two records (and note the trailing “.” on the end of the name), which implies that either the web server has two interfaces, or there are two separate instances of the server. If your computer does a DNS lookup for the server, you’ll only get one record, and if all goes well, it’ll be a tossup as to which one you get, unless your DNS server is smart enough to notice that one server responds faster than the other. This is for load balancing.

The 300 is the TTL, or Time To Live for the record. It gives the time, in seconds, during which the records can be cached locally. 300 seconds seems a bit short, unless the addresses change frequently...

The number on the end of each line is the IP address, the object of the exercise.

For sending mail to someone with an “…@tidbits.com” email address, your MTA (Mail Transfer Agent) needs MX (Mail eXchange) records:

The format for the MX records is similar to the first two. The last item on each line is the name of a mail server, and the preceding number is the priority for each server, with 1 being the highest. This is a common configuration for redundancy, or to get email through a firewall.

When your MTA, whatever it happens to be, tries to send an email to “…@tidbits.com”, it will first try to send it to the highest priority server (sparky). If that server is unreachable, your client will try mx-capricab. If that one isn’t reachable, your client will keep the email, and keep trying, until one of those servers is reachable. If your client can reach mx-capricab, but not sparky, then it will send your mail there, and it will be kept until sparky is reachable (or forwarded through a firewall to sparky if a firewall is why sparky isn’t accessible via the Internet).

So how does your device get this “A” and “MX" information? It obviously can’t store the names and addresses of all the DNS servers on the Internet, especially since there is no one person or group that is responsible for maintaining them all. Your device gets the TidBITS information via a DNS server that is assigned to your device via DHCP when the device boots, or it uses the one you chose yourself (such as 8.8.8.8 for Google’s free DNS or 1.1.1.1 for Cloudflare).

Your device asks your DNS server for information about the TidBITS domain. If your designated server doesn’t have the information cached, it recursively queries the higher level servers, starting with “.” if necessary, until it either gets an answer or someone in authority tells it there isn’t one. In days of old, the IP addresses for the “.” servers were the only addresses a non-authoritative server would know by default. It would always start at “.” To resolve addresses, build up its cache during operation, and update the cache as the TTL for the various entries expired.

If your server gets an answer, it returns it to you, and also caches the answer for the time specified by the TTL field. So, if you or someone else asks for the same information before the TTL expires, then the server can return it immediately.

So, your DNS server has no data of its own. If someone at TidBITS screws up an “A” or “MX” record, your server can neither know or care. That’s the downside of distributed management. If your server gives you the information TidBITS provides, then it has done its job, regardless of how wrong that information might be.

Now that I’ve described, more or less accurately, how DNS works, I can address security issues.

Let’s first get rid of the fake issue; a DNS server can tell who is asking for information and pass it along to the “bad guys”. Your designated DNS server doesn’t know that “you” accessed anything. All it knows is that a device with a certain IP address asked for information. Unless you’ve paid for a static IP address, that ain’t gonna be you. For home users, it’ll probably be the address assigned to your home router when the request was made. I have maybe a dozen or so devices, ranging from a fully loaded iMac to a couple of smoke detectors, that will show the same IP address to the Internet. For a business you could have hundreds or thousands of systems. The router could get a new IP address every time the DHCP lease expires or when the system is restarted. If you hang out in coffee shops, or take advantage of your mobile phone provider’s hotspots, then you could have any number of different addresses assigned to you during a relatively short time, and hundreds or thousands of people could use your old addresses. If you’re using the DNS server provided by your ISP, then your ISP could cross reference DNS requests with DHCP logs to see who the addresses were assigned to at the time a request was made, but they’ll probably be looking at your traffic directly rather than your DNS queries.

So what are the real threats? Many DNS servers that are either “free” or operated by ISPs will return the address of a web server loaded with ads if you type “www.tidbits.coom”, for example, instead of just failing to return an address. The real bad guys can substitute fake addresses for real ones to make people think they’re going to their bank site, whatever. For MX records, the highest priority server address, “sparky” in the example above, could be replaced by the address of a malicious server which would scan the email before forwarding it to its intended destination. These are the reasons you probably don’t want to switch to “Joe’s DNS” unless you know Joe really well. IIRC, there have been viruses that would hack people’s DNS settings in order to send them to fake banking sites, etc.

Anyhow, HTH, and if you’ve read all the way to the bottom I’m both impressed and surprised.





____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

Woodard Paul
Thanks for the write up, it filled in some holes for me.

Paul

On Apr 6, 2018, at 2:46 PM, Rodney <[hidden email]> wrote:


On Apr 6, 2018, at 05:21, Roger Adams <[hidden email]> wrote:

Does using Cloudflare (or any other DNS) with a VPN make the connection more secure?

If so, are all VPNs the same, does using any DNS make a difference to the security of the connection?

I’m the one who asked the original questions about Cloudflare. My questions were answered, but I seem to’ve opened a can of worms. Before people start reaching for their tinfoil hats, I’ll try to clear up some misconceptions about DNS (explaining an external audit to a non-IT person is beyond the scope of this message, and probably beyond the capability of anyone on the planet). I do have some qualifications for talking about DNS. It was part of my responsibility before I retired. However, retirement was a while ago, so things might’ve changed or my memory might have failed. In any event, I’ll just be hitting the high points with what follows. If you’re curious, O’Reilly has an excellent book on the subject. I also don’t know much about IPV6, so this is all about IPV4. I know that what follows is long and boring, but unless you’ve read it, or the equivalent, then you’re probably wasting time by asking DNS security questions.

What is DNS? DNS, the Domain Name System, is the phonebook of the Internet. It provides two main pieces of information; it resolves names to numbers (and vise versa), and provides routing information for email. I’ll leave “SOA”, “CNAME”, and other records as an exercise for the alert reader.

A DNS server’s job is not to protect “user data”, but to give it to anyone who asks for it and to do so quickly and accurately. The two major security issues with a DNS server are whether or not the data it provides is correct, and whether or not the “bad guys”, however you define them, can find out what information you’re asking for. I’ll address both of those after I’ve explained about how DNS works, but I can tell you that the second issue is extremely minor, even if you do live in Russia, and the damaging information is more readily available from other sources than via DNS.

DNS is a distributed system, meaning that there is no central authority for it except for the very top level of the hierarchy which is called “.”. The folks who manage “.” then designate domains underneath such as “com” “gov”, “uk”, “xxx’, whatever. The people who manage those domains below “.” can in turn allocate domains underneath them such as “tidbits” under “com". I’ll use the TidBITS domain as an example, because more people reading this will be familiar with it, and I’m not including any information that isn’t trivial to find by anyone who knows what to ask for. BTW, when written as “tidbits.com”, it is a “relative path”. The absolute path is “tidbits.com.”; “.” is the top of the tree. That’s not all that important at the moment, but you will see the trailing “.” In the examples below.

Since there is no central authority, every domain owner is responsible for designating at least one DNS server that is authoritative for addresses within that domain. Every device on the Internet that wants to access a resource by name must somehow query the server that is authoritative for the domain where the resource resides or access a server where the information is cached. Most of us ordinary folks who own domains only care about maybe a web server and email, so the ISP for the domain usually manages the DNS on our behalf.

Here are the DNS records that are authoritative for the TidBITS domain:

There are two of them, which is common practice. The “86400” is the TTL (Time To Live) for the records (or 24 hours). That is the time permitted to cache the records locally before they should be refreshed.

The “IN” just says that this is an Internet record; records come (or once came) in other flavors as well.

The last entry on each line is the absolute path name of the TidBITS name servers. To look up the IP address for www.tidbits.com, somebody needs to ask one of those two servers for it.

Here are the address (“A”) records for the web server www.tidbits.com:

www.tidbits.com. 300 IN A 104.28.5.110
www.tidbits.com. 300 IN A 104.28.4.110

There are two records (and note the trailing “.” on the end of the name), which implies that either the web server has two interfaces, or there are two separate instances of the server. If your computer does a DNS lookup for the server, you’ll only get one record, and if all goes well, it’ll be a tossup as to which one you get, unless your DNS server is smart enough to notice that one server responds faster than the other. This is for load balancing.

The 300 is the TTL, or Time To Live for the record. It gives the time, in seconds, during which the records can be cached locally. 300 seconds seems a bit short, unless the addresses change frequently...

The number on the end of each line is the IP address, the object of the exercise.

For sending mail to someone with an “…@tidbits.com” email address, your MTA (Mail Transfer Agent) needs MX (Mail eXchange) records:

The format for the MX records is similar to the first two. The last item on each line is the name of a mail server, and the preceding number is the priority for each server, with 1 being the highest. This is a common configuration for redundancy, or to get email through a firewall.

When your MTA, whatever it happens to be, tries to send an email to “…@tidbits.com”, it will first try to send it to the highest priority server (sparky). If that server is unreachable, your client will try mx-capricab. If that one isn’t reachable, your client will keep the email, and keep trying, until one of those servers is reachable. If your client can reach mx-capricab, but not sparky, then it will send your mail there, and it will be kept until sparky is reachable (or forwarded through a firewall to sparky if a firewall is why sparky isn’t accessible via the Internet).

So how does your device get this “A” and “MX" information? It obviously can’t store the names and addresses of all the DNS servers on the Internet, especially since there is no one person or group that is responsible for maintaining them all. Your device gets the TidBITS information via a DNS server that is assigned to your device via DHCP when the device boots, or it uses the one you chose yourself (such as 8.8.8.8 for Google’s free DNS or 1.1.1.1 for Cloudflare).

Your device asks your DNS server for information about the TidBITS domain. If your designated server doesn’t have the information cached, it recursively queries the higher level servers, starting with “.” if necessary, until it either gets an answer or someone in authority tells it there isn’t one. In days of old, the IP addresses for the “.” servers were the only addresses a non-authoritative server would know by default. It would always start at “.” To resolve addresses, build up its cache during operation, and update the cache as the TTL for the various entries expired.

If your server gets an answer, it returns it to you, and also caches the answer for the time specified by the TTL field. So, if you or someone else asks for the same information before the TTL expires, then the server can return it immediately.

So, your DNS server has no data of its own. If someone at TidBITS screws up an “A” or “MX” record, your server can neither know or care. That’s the downside of distributed management. If your server gives you the information TidBITS provides, then it has done its job, regardless of how wrong that information might be.

Now that I’ve described, more or less accurately, how DNS works, I can address security issues.

Let’s first get rid of the fake issue; a DNS server can tell who is asking for information and pass it along to the “bad guys”. Your designated DNS server doesn’t know that “you” accessed anything. All it knows is that a device with a certain IP address asked for information. Unless you’ve paid for a static IP address, that ain’t gonna be you. For home users, it’ll probably be the address assigned to your home router when the request was made. I have maybe a dozen or so devices, ranging from a fully loaded iMac to a couple of smoke detectors, that will show the same IP address to the Internet. For a business you could have hundreds or thousands of systems. The router could get a new IP address every time the DHCP lease expires or when the system is restarted. If you hang out in coffee shops, or take advantage of your mobile phone provider’s hotspots, then you could have any number of different addresses assigned to you during a relatively short time, and hundreds or thousands of people could use your old addresses. If you’re using the DNS server provided by your ISP, then your ISP could cross reference DNS requests with DHCP logs to see who the addresses were assigned to at the time a request was made, but they’ll probably be looking at your traffic directly rather than your DNS queries.

So what are the real threats? Many DNS servers that are either “free” or operated by ISPs will return the address of a web server loaded with ads if you type “www.tidbits.coom”, for example, instead of just failing to return an address. The real bad guys can substitute fake addresses for real ones to make people think they’re going to their bank site, whatever. For MX records, the highest priority server address, “sparky” in the example above, could be replaced by the address of a malicious server which would scan the email before forwarding it to its intended destination. These are the reasons you probably don’t want to switch to “Joe’s DNS” unless you know Joe really well. IIRC, there have been viruses that would hack people’s DNS settings in order to send them to fake banking sites, etc.

Anyhow, HTH, and if you’ve read all the way to the bottom I’m both impressed and surprised.




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

Mike Noonan-2
In reply to this post by Rodney
very interesting.  thx.  Mike 



On Apr 6, 2018, at 11:46 AM, Rodney <[hidden email]> wrote:


On Apr 6, 2018, at 05:21, Roger Adams <[hidden email]> wrote:

Does using Cloudflare (or any other DNS) with a VPN make the connection more secure?

If so, are all VPNs the same, does using any DNS make a difference to the security of the connection?

I’m the one who asked the original questions about Cloudflare. My questions were answered, but I seem to’ve opened a can of worms. Before people start reaching for their tinfoil hats, I’ll try to clear up some misconceptions about DNS (explaining an external audit to a non-IT person is beyond the scope of this message, and probably beyond the capability of anyone on the planet). I do have some qualifications for talking about DNS. It was part of my responsibility before I retired. However, retirement was a while ago, so things might’ve changed or my memory might have failed. In any event, I’ll just be hitting the high points with what follows. If you’re curious, O’Reilly has an excellent book on the subject. I also don’t know much about IPV6, so this is all about IPV4. I know that what follows is long and boring, but unless you’ve read it, or the equivalent, then you’re probably wasting time by asking DNS security questions.

What is DNS? DNS, the Domain Name System, is the phonebook of the Internet. It provides two main pieces of information; it resolves names to numbers (and vise versa), and provides routing information for email. I’ll leave “SOA”, “CNAME”, and other records as an exercise for the alert reader.

A DNS server’s job is not to protect “user data”, but to give it to anyone who asks for it and to do so quickly and accurately. The two major security issues with a DNS server are whether or not the data it provides is correct, and whether or not the “bad guys”, however you define them, can find out what information you’re asking for. I’ll address both of those after I’ve explained about how DNS works, but I can tell you that the second issue is extremely minor, even if you do live in Russia, and the damaging information is more readily available from other sources than via DNS.

DNS is a distributed system, meaning that there is no central authority for it except for the very top level of the hierarchy which is called “.”. The folks who manage “.” then designate domains underneath such as “com” “gov”, “uk”, “xxx’, whatever. The people who manage those domains below “.” can in turn allocate domains underneath them such as “tidbits” under “com". I’ll use the TidBITS domain as an example, because more people reading this will be familiar with it, and I’m not including any information that isn’t trivial to find by anyone who knows what to ask for. BTW, when written as “tidbits.com”, it is a “relative path”. The absolute path is “tidbits.com.”; “.” is the top of the tree. That’s not all that important at the moment, but you will see the trailing “.” In the examples below.

Since there is no central authority, every domain owner is responsible for designating at least one DNS server that is authoritative for addresses within that domain. Every device on the Internet that wants to access a resource by name must somehow query the server that is authoritative for the domain where the resource resides or access a server where the information is cached. Most of us ordinary folks who own domains only care about maybe a web server and email, so the ISP for the domain usually manages the DNS on our behalf.

Here are the DNS records that are authoritative for the TidBITS domain:

There are two of them, which is common practice. The “86400” is the TTL (Time To Live) for the records (or 24 hours). That is the time permitted to cache the records locally before they should be refreshed.

The “IN” just says that this is an Internet record; records come (or once came) in other flavors as well.

The last entry on each line is the absolute path name of the TidBITS name servers. To look up the IP address for www.tidbits.com, somebody needs to ask one of those two servers for it.

Here are the address (“A”) records for the web server www.tidbits.com:

www.tidbits.com. 300 IN A 104.28.5.110
www.tidbits.com. 300 IN A 104.28.4.110

There are two records (and note the trailing “.” on the end of the name), which implies that either the web server has two interfaces, or there are two separate instances of the server. If your computer does a DNS lookup for the server, you’ll only get one record, and if all goes well, it’ll be a tossup as to which one you get, unless your DNS server is smart enough to notice that one server responds faster than the other. This is for load balancing.

The 300 is the TTL, or Time To Live for the record. It gives the time, in seconds, during which the records can be cached locally. 300 seconds seems a bit short, unless the addresses change frequently...

The number on the end of each line is the IP address, the object of the exercise.

For sending mail to someone with an “…@tidbits.com” email address, your MTA (Mail Transfer Agent) needs MX (Mail eXchange) records:

The format for the MX records is similar to the first two. The last item on each line is the name of a mail server, and the preceding number is the priority for each server, with 1 being the highest. This is a common configuration for redundancy, or to get email through a firewall.

When your MTA, whatever it happens to be, tries to send an email to “…@tidbits.com”, it will first try to send it to the highest priority server (sparky). If that server is unreachable, your client will try mx-capricab. If that one isn’t reachable, your client will keep the email, and keep trying, until one of those servers is reachable. If your client can reach mx-capricab, but not sparky, then it will send your mail there, and it will be kept until sparky is reachable (or forwarded through a firewall to sparky if a firewall is why sparky isn’t accessible via the Internet).

So how does your device get this “A” and “MX" information? It obviously can’t store the names and addresses of all the DNS servers on the Internet, especially since there is no one person or group that is responsible for maintaining them all. Your device gets the TidBITS information via a DNS server that is assigned to your device via DHCP when the device boots, or it uses the one you chose yourself (such as 8.8.8.8 for Google’s free DNS or 1.1.1.1 for Cloudflare).

Your device asks your DNS server for information about the TidBITS domain. If your designated server doesn’t have the information cached, it recursively queries the higher level servers, starting with “.” if necessary, until it either gets an answer or someone in authority tells it there isn’t one. In days of old, the IP addresses for the “.” servers were the only addresses a non-authoritative server would know by default. It would always start at “.” To resolve addresses, build up its cache during operation, and update the cache as the TTL for the various entries expired.

If your server gets an answer, it returns it to you, and also caches the answer for the time specified by the TTL field. So, if you or someone else asks for the same information before the TTL expires, then the server can return it immediately.

So, your DNS server has no data of its own. If someone at TidBITS screws up an “A” or “MX” record, your server can neither know or care. That’s the downside of distributed management. If your server gives you the information TidBITS provides, then it has done its job, regardless of how wrong that information might be.

Now that I’ve described, more or less accurately, how DNS works, I can address security issues.

Let’s first get rid of the fake issue; a DNS server can tell who is asking for information and pass it along to the “bad guys”. Your designated DNS server doesn’t know that “you” accessed anything. All it knows is that a device with a certain IP address asked for information. Unless you’ve paid for a static IP address, that ain’t gonna be you. For home users, it’ll probably be the address assigned to your home router when the request was made. I have maybe a dozen or so devices, ranging from a fully loaded iMac to a couple of smoke detectors, that will show the same IP address to the Internet. For a business you could have hundreds or thousands of systems. The router could get a new IP address every time the DHCP lease expires or when the system is restarted. If you hang out in coffee shops, or take advantage of your mobile phone provider’s hotspots, then you could have any number of different addresses assigned to you during a relatively short time, and hundreds or thousands of people could use your old addresses. If you’re using the DNS server provided by your ISP, then your ISP could cross reference DNS requests with DHCP logs to see who the addresses were assigned to at the time a request was made, but they’ll probably be looking at your traffic directly rather than your DNS queries.

So what are the real threats? Many DNS servers that are either “free” or operated by ISPs will return the address of a web server loaded with ads if you type “www.tidbits.coom”, for example, instead of just failing to return an address. The real bad guys can substitute fake addresses for real ones to make people think they’re going to their bank site, whatever. For MX records, the highest priority server address, “sparky” in the example above, could be replaced by the address of a malicious server which would scan the email before forwarding it to its intended destination. These are the reasons you probably don’t want to switch to “Joe’s DNS” unless you know Joe really well. IIRC, there have been viruses that would hack people’s DNS settings in order to send them to fake banking sites, etc.

Anyhow, HTH, and if you’ve read all the way to the bottom I’m both impressed and surprised.




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

@lbutlr
In reply to this post by Fritz Mills
On 2018-04-06 (09:14 MDT), Fritz Mills <[hidden email]> wrote:
>
> Apologies in advance for what are surely stupid, uninformed questions, but don’t you need to connect to a DNS server to *get* to a VPN?

Probably not. Most VPNs I've used you connect to an IP address.

> And then, once you’re connected to a VPN, wouldn’t all of your DNS queries go through the VPN?

Depends on the VPN. Many (Most?) do not handle UDP packets.

--
Q: how do you titillate an ocelot?  A: you oscillate its tit a lot.



____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

Roger Adams
In reply to this post by Roger Adams
>> I’m the one who asked the original questions about Cloudflare. My questions were answered, but I seem to’ve opened a can of worms. Before people start reaching for their tinfoil hats, I’ll try to clear up some misconceptions about DNS (explaining an external audit to a non-IT person is beyond the scope of this message, and probably beyond the capability of anyone on the planet). I do have some qualifications for talking about DNS. It was part of my responsibility before I retired. However, retirement was a while ago, so things might’ve changed or my memory might have failed. In any event, I’ll just be hitting the high points with what follows. If you’re curious, O’Reilly has an excellent book on the subject. I also don’t know much about IPV6, so this is all about IPV4. I know that what follows is long and boring, but unless you’ve read it, or the equivalent, then you’re probably wasting time by asking DNS security questions.
>>
>> What is DNS? DNS, the Domain Name System, is the phonebook of the Internet. It provides two main pieces of information; it resolves names to numbers (and vise versa), and provides routing information for email. I’ll leave “SOA”, “CNAME”, and other records as an exercise for the alert reader.
>>
>> A DNS server’s job is not to protect “user data”, but to give it to anyone who asks for it and to do so quickly and accurately. The two major security issues with a DNS server are whether or not the data it provides is correct, and whether or not the “bad guys”, however you define them, can find out what information you’re asking for. I’ll address both of those after I’ve explained about how DNS works, but I can tell you that the second issue is extremely minor, even if you do live in Russia, and the damaging information is more readily available from other sources than via DNS.
>>
>> DNS is a distributed system, meaning that there is no central authority for it except for the very top level of the hierarchy which is called “.”. The folks who manage “.” then designate domains underneath such as “com” “gov”, “uk”, “xxx’, whatever. The people who manage those domains below “.” can in turn allocate domains underneath them such as “tidbits” under “com". I’ll use the TidBITS domain as an example, because more people reading this will be familiar with it, and I’m not including any information that isn’t trivial to find by anyone who knows what to ask for. BTW, when written as “tidbits.com”, it is a “relative path”. The absolute path is “tidbits.com.”; “.” is the top of the tree. That’s not all that important at the moment, but you will see the trailing “.” In the examples below.
>>
>> Since there is no central authority, every domain owner is responsible for designating at least one DNS server that is authoritative for addresses within that domain. Every device on the Internet that wants to access a resource by name must somehow query the server that is authoritative for the domain where the resource resides or access a server where the information is cached. Most of us ordinary folks who own domains only care about maybe a web server and email, so the ISP for the domain usually manages the DNS on our behalf.
>>
>> Here are the DNS records that are authoritative for the TidBITS domain:
>>
>> tidbits.com. 86400 IN NS duke.ns.cloudflare.com.
>> tidbits.com. 86400 IN NS lady.ns.cloudflare.com.
>>
>> There are two of them, which is common practice. The “86400” is the TTL (Time To Live) for the records (or 24 hours). That is the time permitted to cache the records locally before they should be refreshed.
>>
>> The “IN” just says that this is an Internet record; records come (or once came) in other flavors as well.
>>
>> The last entry on each line is the absolute path name of the TidBITS name servers. To look up the IP address for www.tidbits.com, somebody needs to ask one of those two servers for it.
>>
>> Here are the address (“A”) records for the web server www.tidbits.com:
>>
>> www.tidbits.com. 300 IN A 104.28.5.110
>> www.tidbits.com. 300 IN A 104.28.4.110
>>
>> There are two records (and note the trailing “.” on the end of the name), which implies that either the web server has two interfaces, or there are two separate instances of the server. If your computer does a DNS lookup for the server, you’ll only get one record, and if all goes well, it’ll be a tossup as to which one you get, unless your DNS server is smart enough to notice that one server responds faster than the other. This is for load balancing.
>>
>> The 300 is the TTL, or Time To Live for the record. It gives the time, in seconds, during which the records can be cached locally. 300 seconds seems a bit short, unless the addresses change frequently...
>>
>> The number on the end of each line is the IP address, the object of the exercise.
>>
>> For sending mail to someone with an “…@tidbits.com” email address, your MTA (Mail Transfer Agent) needs MX (Mail eXchange) records:
>>
>> tidbits.com. 300 IN MX 1 sparky.tidbits.com.
>> tidbits.com. 300 IN MX 10 mx-capricab.easydns.com.
>>
>> The format for the MX records is similar to the first two. The last item on each line is the name of a mail server, and the preceding number is the priority for each server, with 1 being the highest. This is a common configuration for redundancy, or to get email through a firewall.
>>
>> When your MTA, whatever it happens to be, tries to send an email to “…@tidbits.com”, it will first try to send it to the highest priority server (sparky). If that server is unreachable, your client will try mx-capricab. If that one isn’t reachable, your client will keep the email, and keep trying, until one of those servers is reachable. If your client can reach mx-capricab, but not sparky, then it will send your mail there, and it will be kept until sparky is reachable (or forwarded through a firewall to sparky if a firewall is why sparky isn’t accessible via the Internet).
>>
>> So how does your device get this “A” and “MX" information? It obviously can’t store the names and addresses of all the DNS servers on the Internet, especially since there is no one person or group that is responsible for maintaining them all. Your device gets the TidBITS information via a DNS server that is assigned to your device via DHCP when the device boots, or it uses the one you chose yourself (such as 8.8.8.8 for Google’s free DNS or 1.1.1.1 for Cloudflare).
>>
>> Your device asks your DNS server for information about the TidBITS domain. If your designated server doesn’t have the information cached, it recursively queries the higher level servers, starting with “.” if necessary, until it either gets an answer or someone in authority tells it there isn’t one. In days of old, the IP addresses for the “.” servers were the only addresses a non-authoritative server would know by default. It would always start at “.” To resolve addresses, build up its cache during operation, and update the cache as the TTL for the various entries expired.
>>
>> If your server gets an answer, it returns it to you, and also caches the answer for the time specified by the TTL field. So, if you or someone else asks for the same information before the TTL expires, then the server can return it immediately.
>>
>> So, your DNS server has no data of its own. If someone at TidBITS screws up an “A” or “MX” record, your server can neither know or care. That’s the downside of distributed management. If your server gives you the information TidBITS provides, then it has done its job, regardless of how wrong that information might be.
>>
>> Now that I’ve described, more or less accurately, how DNS works, I can address security issues.
>>
>> Let’s first get rid of the fake issue; a DNS server can tell who is asking for information and pass it along to the “bad guys”. Your designated DNS server doesn’t know that “you” accessed anything. All it knows is that a device with a certain IP address asked for information. Unless you’ve paid for a static IP address, that ain’t gonna be you. For home users, it’ll probably be the address assigned to your home router when the request was made. I have maybe a dozen or so devices, ranging from a fully loaded iMac to a couple of smoke detectors, that will show the same IP address to the Internet. For a business you could have hundreds or thousands of systems. The router could get a new IP address every time the DHCP lease expires or when the system is restarted. If you hang out in coffee shops, or take advantage of your mobile phone provider’s hotspots, then you could have any number of different addresses assigned to you during a relatively short time, and hundreds or thousands of people could use your old addresses. If you’re using the DNS server provided by your ISP, then your ISP could cross reference DNS requests with DHCP logs to see who the addresses were assigned to at the time a request was made, but they’ll probably be looking at your traffic directly rather than your DNS queries.
>>
>> So what are the real threats? Many DNS servers that are either “free” or operated by ISPs will return the address of a web server loaded with ads if you type “www.tidbits.coom”, for example, instead of just failing to return an address. The real bad guys can substitute fake addresses for real ones to make people think they’re going to their bank site, whatever. For MX records, the highest priority server address, “sparky” in the example above, could be replaced by the address of a malicious server which would scan the email before forwarding it to its intended destination. These are the reasons you probably don’t want to switch to “Joe’s DNS” unless you know Joe really well. IIRC, there have been viruses that would hack people’s DNS settings in order to send them to fake banking sites, etc.
>>
>> Anyhow, HTH, and if you’ve read all the way to the bottom I’m both impressed and surprised.
>>
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://tidbits.com/pipermail/tidbits-talk/attachments/20180406/a155ed57/attachment-0001.html>

Hi Rodney,

Thank you for your detailed explanation regarding DNS and I appreciate the trouble you have taken to clearly express your points.

I can see that DNS has nothing to do with internet security and that my original question had inadvertently confused the two and for which I apologise for opening the can of worms that you refer to above..    I use either my ISP DNS addresses or Cloudfare ones over several Macs (the latter to test the speed difference between the two) and I also use a VPN for all my internet traffic in the hope that my internet usage is more secure than it would otherwise be.     I am not sure whether or not my hope is justified but I do take my internet security very seriously on all my Macs, not that I have much that would be of interest to normal people but perhaps would be to other, less scrupulous ones.

Thank you again for your detailed reply.

Cheers

Roger
.


____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____
Reply | Threaded
Open this post in threaded view
|

Re: Using a VPN with DNS

Rodney

On Apr 8, 2018, at 13:54, Roger Adams <[hidden email]> wrote:

Thank you for your detailed explanation regarding DNS and I appreciate the trouble you have taken to clearly express your points.

You’re very welcome.

I can see that DNS has nothing to do with internet security …

That’s not true. DNS has very much to do with Internet security, just not in the way some folks seem to think.

A malicious DNS server can cause you a lot of grief. That’s why I’d want to understand a provider’s business model before using any “free" service.

I’m just saying that a 3rd party server, one independent of your service provider, isn’t going to reveal who “you” are to anyone. There are far easier ways to figure that out than by watching DNS queries. Even Google isn’t going to learn enough from Google DNS to target you with ads. They’ll just learn which sites are most popular, and which locations on the planet are accessing them. That’s useful information for to sell to site owners and advertisers, but won’t tell them which individuals are accessing those sites.

and that my original question had inadvertently confused the two and for which I apologise for opening the can of worms that you refer to above.

The can of worms was already open. You asked a legitimate question.

I use either my ISP DNS addresses or Cloudfare ones over several Macs (the latter to test the speed difference between the two) and I also use a VPN for all my internet traffic in the hope that my internet usage is more secure than it would otherwise be.     I am not sure whether or not my hope is justified but I do take my internet security very seriously on all my Macs, not that I have much that would be of interest to normal people but 

For a “normal user”, the VPN is “chicken soup”; it couldn’t hurt, assuming you can trust your VPN provider which is another issue altogether. A VPN won’t offer more security per transaction than sites that use https. All a VPN does is mask which sites you’re accessing.

I don’t use a VPN for a couple of reasons. My fiber download speed is, according to Speedtest, close to a gigabit, so a VPN probably would slow things down for me. I also don’t care who knows which sites I visit. I just make sure that any sites I send personal information to use https. I could use a VPN to access “region locked” content, such as US TV shows, but I don’t watch enough TV to make the expense worthwhile. Besides, US providers try hard to block access via VPN, so I’m not sure how reliable the service would be for that kind of thing.

For other people, there are many legitimate reasons to use a VPN. As always YMMV.




____________TidBITS Talk Participation Guidelines____________
Post only when you have something substantive to contribute.
Be polite and constructive, and comment on posts, not people.
Quote sparingly, if at all. We all read the previous message.
Start threads with a new message to [hidden email].
Read archives at: http://sparky.tidbits.com/pipermail/tidbits-talk/
Unsubscribe at: http://sparky.tidbits.com/mailman/options/tidbits-talk
____Mailing List Manners: http://tidbits.com/series/1141 ____