When troubleshooting name resolution issues on a Windows client, NSlookup is an essential tool. However, it is important to understand that using NSlookup on a DirectAccess client might not always work as you expect. Although using NSlookup on a DirectAccess client will work normally when the client is on the corporate network, it will not provide the correct results to queries for internal hostnames when the DirectAccess client is outside of the corporate network without taking additional steps. This is because when a DirectAccess client is outside the corporate network, the Name Resolution Policy Table (NRPT) is enabled. The NRPT provides policy-based name resolution routing for DirectAccess clients, sending name resolution requests for certain namespaces to specific DNS servers. You can view the NRPT on a Windows 8.x DirectAccess client by issuing the following PowerShell command:
Get-DnsClientNrptPolicy
You can view the NRPT on a Windows 7 DirectAccess client by issuing the following netsh command:
netsh namespace show policy
Here you’ll notice that the namespace .lab.richardhicks.net is configured to use the DNS64 service running on the DirectAccess server at 2002:62bd:d898:3333::1. Notice also that the host nls.lab.richardhicks.net is not configured to use a DNS server. This effectively exempts this host from the NRPT, forcing name resolution requests for this Fully-Qualified Domain Name (FQDN) to be delivered to the DNS servers configured on the network adapter.
A Working Example
With the NRPT enabled, which occurs whenever the DirectAccess client is outside of the corporate network, a name resolution request for app1.lab.richardhicks.net would be sent to the DNS64 service on the DirectAccess server. A name resolution request for technet.microsoft.com would be sent to the DNS servers assigned to the network adapter because the NRPT contains no entry for this namespace. And even though the host nls.lab.richardhicks.net is a part of the internal namespace, a name resolution request for this host would also be sent to the DNS servers assigned to the network adapter because it has been specifically exempted from the NRPT.
NSlookup
The NSlookup utility is unaware of the NRPT. Whenever you use NSlookup it will, by default, automatically send queries directly to the DNS servers configured on the network adapter, regardless of the NRPT. If you wish to use NSlookup to test name resolution for external hostnames, use it as you normally would. However, if you wish to use NSlookup to resolve internal hostnames over the DirectAccess connection, you will need to tell NSlookup to use the DNS64 service running on the DirectAccess server. You can do this by running NSlookup interactively and using the server command to point it to the IPv6 address of the DNS64 service, which you can find in the NRPT.
This also applies to the PowerShell cmdlet Resolve-DNSname. Here you’ll use the -Server switch to specify the DNS64 server’s IPv6 address.
Resolve-DNSName –Server <DNS64_IPv6_Address> app1.lab.richardhicks.net
thiagobeier
/ May 15, 2014Hi guys let me know something when DA (EDGE server) is behind a firewall it will only use ipv4, right? so the NRPT table will still be used to resolve ipv6 names ? Regards,
wn7client [FW] [FW] corpnet (AD , APP, IIS)
Richard Hicks
/ May 15, 2014IPv6 is always used between the DirectAccess client and server, regardless of network configuration. What changes when DirectAccess is behind a NAT is the IPv6 transition protocol. For edge deployments, the client can choose between 6to4, Teredo, and IP-HTTPS. For NAT deployments, only IP-HTTPS is supported. The NRPT still functions the same way in either configuration.
thiagobeier
/ June 4, 2014Hi , we solve it disabling the the teredo, 6to4 interface in the external client, but in the lab we used ip-https passing through a router not a firewall to make it simple.
thiagobeier
/ June 4, 2014Hi Richard talking about NRPT and we have a situation here where
the internal FQDN: corp.company.com
additional forward dns zone: mycompany.com (all the applications web, SharePoint, answers at app1.mycompany.com (internaly)
external FQDN DNS zone mycompany.commy
all Windows 7 and 8 are working normally but when we try to resolve app1.mycompany.com (published only internal it doesn’t work. How can I set it up at NRPT to solve it?
our topology
http://social.technet.microsoft.com/Forums/getfile/465114
Ashish
/ July 9, 2015Hello Richard,
What happens if we have enabled force tunneling with NRTP exceptions? How ill the client try to access the site which are their in NRTP exceptions?
Richard Hicks
/ July 11, 2015Force tunneling configures the NRTP to forward name resolution requests for ALL namespaces (not just the corporate namespace) to the DirectAccess DNS64 service. In this configuration there are no NRPT exemptions.
DADemon
/ September 11, 2015Richard, We recently implemented a production pilot of DA on Windows Server 2012 R2. We have a very large organization and are attempting to determine what may be causing all of our Window 7 client machines to be unable to resolve internet addresses when connected to DA. In the same environment, our Windows 8.1 and Windows 10 devices have no issues handling this. When I look at the local DNS resolver cache on the client after attempting to ping a random website (i.e. google.com) I see about 11 entries for IPv4 and IPv6 addresses for google.com. However the result returned to the command prompt is as follows: “Ping request could not find client google.com. Please check the name and try again.”
Richard M. Hicks
/ September 11, 2015That’s unusual. Can you connect with me via email and we can discuss in more detail?
matt
/ January 13, 2016Hi,
Thanks this has really cleared up a lot of questions on how DNS resolution is working with DirectAccess. However, I have followed your steps provided and when I try and run it against my DNS64 address I get the message:
server 2002:6e6e:6e03:3333::1
DNS request timed out.
timeout was 2 seconds.
Default Server: [2002:6e6e:6e03:3333::1]
Address: 2002:6e6e:6e03:3333::1
Richard M. Hicks
/ January 18, 2016Are you able to ping the DN64 address?
matt
/ January 18, 2016Yes able to ping the dns64 address.
Richard M. Hicks
/ January 19, 2016Do you have IPsec tunnels as well? Get-NetIpsecMainModeSA will tell you.
Adam
/ February 9, 2016I have a similar problem; no DNS resolution. Can ping the DNS64 address but nslookup does not work. No IPsec tunnels showing after running Get-NetIpsecMainModeSA. Eternally grateful to anyone who can contribute to a resolution.
Richard M. Hicks
/ February 11, 2016Drop me a note. I’ll see if I can shed some light on why things may not be working for you. 🙂
vaulti
/ March 2, 2016Hello Richard,
I have the same problem like Adam. No DNS Resolution. No-IPsec tunnels. But i can ping and RDP the DNS64 adress. This is driving me crazy. Can you help me?
Thanks
Richard M. Hicks
/ March 3, 2016I can help, but I’ll need additional information. Send me an email and I’ll let you know what I need. 🙂
Ross
/ May 25, 2016Hi Richard,
Thanks for the excellent blog post. I’m in the same situation as these guys – ping DNS64 address but no name resolution. Name resolution works locally on the DA server. Single IP, NATed IP/HTTPS only set up.
Thanks
Richard M. Hicks
/ May 28, 2016If you can ping the DNS64 address and the DTEs, but can’t access internal resources, I would suspect that you also don’t have any IPsec tunnels either. If that’s the case, investigate why IPsec is failing (missing or incorrect certificates, computer account missing or disabled, etc.).
vaulti
/ May 29, 2016Hi Ross,
In my case it turned out that I had a trouble with my Firewall-GPO. Check if the Firewall is enabled and configured correctly on the Clients and Server
Greetings
ecartini
/ March 31, 2016Hello All,
One of the issues we are facing in our DA environment is the ability for our help desk technicians to use microsft SCCM to remote a machine that’s is corrected to DA. I have been doing all kinds of research and still can not get this feature to work correctly. Currently I am going do the path of isatap and DNS.
Any help would be greatly appreciated.
Thank you!
Richard M. Hicks
/ March 31, 2016Your management servers and/or workstations must have an IPv6 address for outbound management. This can be a native IPv6 address (preferred) or an ISATAP IPv6 (optional). If you search for “ISATAP” on this site you’ll find a few articles I’ve written about it. The first I’d suggest reading is http://directaccess.richardhicks.com/2013/06/24/isatap-recommendations-for-directaccess-deployments/.
If you have enabled load balancing or multisite, additional configuration is required that isn’t yet documented. Drop me a note if that’s the case and I’ll explain in more detail.
Bruno Guerra
/ April 25, 2016Great Article. We got a problem to access a website of company, that is hosted outside of organization. Configured http://www.company.com for exception and it works successfully. Regards.
saud naeem
/ January 24, 2018could you please share the process how did you acheive that, we have a same problem.
Bruno Guerra
/ January 27, 2018take a look a second image.
https://blogs.technet.microsoft.com/tomshinder/2010/04/01/directaccess-client-location-awareness-nrpt-name-resolution/
If my memory is goord, i told that.
digitalfix
/ May 10, 2017Trying to troubleshoot an issue from the other direction:
DA Clients can resolve and connect to infrastructure servers, however
Servers cannot resolve or connect to DA Clients (PIng of short name or FQDN gives could not find hostname, nslookup however returns the ipv6 address correctly)
Richard M. Hicks
/ May 10, 2017Are you trying this from a Windows 10 or Windows Server 2016 system? If so, you’ll want to read this: https://directaccess.richardhicks.com/2017/01/03/directaccess-manage-out-with-isatap-fails-on-windows-10-and-windows-server-2016/. 🙂
digitalfix
/ May 11, 2017That’s a good read for our up coming deployment, this is for a server 2012r2 to win 7 clients, I think the fault lies with the application (trend office scan server). Looks like we need to deploy some edge servers for our DA clients.
Chris
/ May 24, 2017Hi Richard, should you be able to resolve the Domains NetBIOS name using nslookup/resolve-dnsname? We are having issues with long delays before being able to resolve internal server addresses after connecting.
Richard M. Hicks
/ May 24, 2017Absolutely. 🙂
Eddie
/ July 3, 2017Hi,
Just thought I should leave a comment as we were having DNS issues and could not find a solution. For us, performing a get-daconnectionstatus returned NameResolutionFailure no matter what we did. All components on the Remote Access Dashboard had green ticks. All client side diagnostics were positive aside from ‘netsh advfirewall monitor show mmsa’ returning ‘No SAs match specified criteria’. All certificates were working and being validated. The firewall and all Group Policies were applied correctly on the client devices. However, the clients were always in a state of connecting.
The solution in our case was Group Policy on the DA server. An upstream policy had disabled the Windows Firewall causing the connection failures. Once the offending policy was blocked and the server firewall was functioning the clients connected without issue. So, check the Windows Firewall status on your server.
It would be good if the Remote Access Dashboard checked this in the Operations Status page.
Richard M. Hicks
/ July 10, 2017Hi Eddie. Thanks for sharing your experience. As you learned, the Windows firewall is crucial for the operation of DirectAccess. It must be enabled on the DirectAccess client and the server as well. It is a shame that the Remote Access Management console doesn’t check its operation and report on it though! It’s a serious oversight on the part of the DirectAccess developers, that’s for sure!
Andrew
/ November 7, 2017Hey Richard, I’m curious if you’ve ever run into IPsec tunnels not being established on some client computers while other client computers have no issues. I think I have narrowed it down to a certificate issue. On a computer with no IPsec tunnels, I can delete the computer certificates and re-enroll from our CA. After that, DirectAccess is able to establish a connection and I can reach internal resources. About 30 seconds later, it drops back out. Rinse and repeat. I haven’t found a reason the certificates could be the issue. Only a few of our client machines (~10 out of 800) are affected. Any thoughts on how to proceed? Crazy issue to troubleshoot. 🙂
Richard M. Hicks
/ November 8, 2017Wow, that is very strange. I’ve never encountered a scenario like that. Have you enabled IPsec auditing to see if that yields any clues?
Andrew
/ November 8, 2017I have – most of the events that were generated while I was troubleshooting said that negotiation timed out. Because of that, I went down the certificate path. Since then, I haven’t seen anymore logs in Event Viewer related to IPsec. I will keep an eye on it as I continue troubleshooting. I am considering migrating our CA from 2012 to 2016. I am also making sure that these clients (Windows 10 Edu Creators Edition) are fully patched. I will also see what updates are available for our DA server and apply them if they make sense (it is running on Server 2016).
Richard M. Hicks
/ November 9, 2017If you plan to upgrade your PKI, be advised that it is disruptive to clients outside of the network when you make the change. You’ll have to bring them back inside or connect via VPN to update group policy after you make the change in the Remote Access Management console.
Andrew
/ November 15, 2017My original issue with IPsec tunnels was self-inflicted. I caused the issue by removing certificates and re-enrolling with our CA while I was troubleshooting this problem… I probably chose the wrong certificate. With that off the table, our symptoms show in this order:
1. A connection via IPHTTPS is established *I haven’t tested whether or not this is an issue over Teredo* – DCA shows Connecting…
2. IPsec tunnels are created (both MMSA and QMSA show in Windows Firewall) – DCA shows Connecting…
3. DirectAccess attempts to validate the connection back to the corporate network. We chose to ping our DC and use a HTTP test back to the web probe host. – DCA shows Connecting…
4. The connection is established (the above tests passed) – DCA shows Connected.
5. About 5-30 seconds later, the DCA status changes from ‘connected’ to ‘connecting’ – it says it is attempting to contact the DirectAccess server. Oddly enough, there are still IPsec tunnels established. The IPHTTPS connection shows as active too.
6. The corporate network is unreachable. The DNS server is unreachable.
It ended up being software on the client machines, not a server issue, causing the problem. We are running Lenovo recommended updates on our laptops anytime they are at our Help Desk. ‘Intel Online Connect’ is included in that list of recommendations. Basically, any computer our Help Desk sees will have Windows updates and system updates installed. So, a good number of laptops in our environment were getting ‘Intel Online Connect’. Removing it and restarting has resolved the connection issue. Luckily, all of our teachers and students return to campus every day so removing it via SCCM won’t be an issue.
It looks like Lenovo and Intel worked closely with each other to get this software to all devices with 7th and 8th gen chips (https://www.digitaltrends.com/computing/lenovo-now-supports-intel-online-connect/). We just updated all of our hardware so that is why it was recommended to us. It isn’t inherently bad software, it just breaks DirectAccess. I suspect it has to do with DirectAccess’ encryption. Somehow the software is interfering with it. There are reports of this issue on Lenovo’s and Intel’s forums when the product was still called ‘Intel Technology Access Driver’… At least I am assuming that is what it was called in the past. Maybe this is coincidental and ‘Intel Online Connect’ is a completely new product.
-https://communities.intel.com/thread/63449
-https://forums.lenovo.com/t5/Pre-Installed-Lenovo-Software/Intel-Technology-Access-Driver-T450s-Microsoft-DirectAccess/td-p/2079402
-https://support.lenovo.com/ca/en/solutions/ht103347
Thanks for your help! I hope this information helps someone in the future. We have reached out to Microsoft and Lenovo to report the problem.
Richard M. Hicks
/ November 19, 2017Thanks so much for sharing this! I’m sure it will help others who may be experiencing the same problem. It’s a good troubleshooting less though, and one I learned a long time ago. Whenever I encounter unusual behavior like this, I always insist on testing with a clean machine or, at a minimum, removing all unnecessary GPOs and any installed third-party software. Not just disabling it, but removing it. As you learned here, and based on my extensive experience, often the culprit is third-party software interfering with DirectAccess operation in some way!
Mike Pietrorazio
/ December 28, 2017Hello, I’ve got a strange issue where DA clients connecting to the internal LAN are delayed in detecting the domain profile. So, for the 1st few minutes all network resources fails. It seems as thought when the connection first initiates, it tries to connect to the /insideoutside website on the DA server, but the Windows Firewall on the client is blocking DNS resolution of the FQDN to the NLS website. I guess it tries on IPV6 a few times, times out, then succeeds on IPV4. After successful domain detection, which could take several minutes, everything works fine on IPV6. We have native IPV6. An 11 month support case with Microsoft was closed because they could not find the problem. -Thanks for any help.
Richard M. Hicks
/ December 30, 2017Wow, that sounds really unusual. I would have to suspect it has something to do with the NLS, but without digging in myself I would just be guessing. If you’d like me to look in to this for you, drop me a email and I’ll have you send me some details from your environment.
Mike Pietrorazio
/ January 9, 2018What email address do I contact you at?
Richard M. Hicks
/ January 9, 2018You can use the contact form here: https://directaccess.richardhicks.com/contact/. 🙂
Michał Grzegorek
/ May 29, 2019Hi Richard,
I’m experiencing the same issue where I can ping DNS server, but when I try to resolve DNS name, it doesn’t work. The client machine is Windows 10 1903. Direct Access works perfect and Windows 10 1809 and below. Can you please advise?
Richard M. Hicks
/ May 30, 2019If you can ping the DNS server but it doesn’t respond to DNS queries I would question if you have a fully established DirectAccess connection. To me it sounds like you’ve got an IPv6 transition technology established but no IPsec connections. ICMP/Ping is exempt from IPsec policy processing, so you’d be able to ping but nothing else. I’d have a close look to make sure IPsec is functioning properly.
Muditha
/ May 30, 2019Hi Richard
I configured the DA server & tested Client connection. GP is fine. Client not connecting from outside network.
This is the output from Connectivity troubleshoot tool.
31/05/2019 3:24:38 PM]: In worker thread, going to start the tests.
[31/05/2019 3:24:38 PM]: Running Network Interfaces tests.
[31/05/2019 3:24:38 PM]: Ethernet (Realtek PCIe GBE Family Controller): fe80::cdc1:9dc2:173c:8185%18;: 192.168.220.94/255.255.255.0;
[31/05/2019 3:24:38 PM]: Default gateway found for Ethernet.
[31/05/2019 3:24:38 PM]: Ethernet has configured the default gateway 192.168.220.254.
[31/05/2019 3:24:38 PM]: Default gateway 192.168.220.254 for Ethernet replies on ICMP Echo requests, RTT is 0 msec.
[31/05/2019 3:24:38 PM]: Received a response from the public DNS server (8.8.8.8), RTT is 32 msec.
[31/05/2019 3:24:38 PM]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[31/05/2019 3:24:38 PM]: Running Inside/Outside location tests.
[31/05/2019 3:24:38 PM]: NLS is https://DirectAccess-NLS.xxxxxxxxx:62000/insideoutside.
[31/05/2019 3:24:38 PM]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[31/05/2019 3:24:38 PM]: NRPT contains 3 rules.
[31/05/2019 3:24:38 PM]: Found (unique) DNS server: fddc:e3d0:7c2:3333::1
[31/05/2019 3:24:38 PM]: Send an ICMP message to check if the server is reachable.
[31/05/2019 3:24:38 PM]: DNS Server fddc:e3d0:7c2:3333::1 does not reply on ICMP Echo requests.
[31/05/2019 3:24:38 PM]: Running IP connectivity tests.
[31/05/2019 3:24:38 PM]: The 6to4 interface service state is default.
[31/05/2019 3:24:38 PM]: Teredo inferface status is offline.
[31/05/2019 3:24:38 PM]: The configured DirectAccess Teredo server is win1807.ipv6.microsoft.com..
[31/05/2019 3:24:38 PM]: The IPHTTPS interface is operational.
[31/05/2019 3:24:38 PM]: The IPHTTPS interface status is IPHTTPS interface not installed..
[31/05/2019 3:24:38 PM]: IPHTTPS is used as IPv6 transition technology.
[31/05/2019 3:24:38 PM]: The configured IPHTTPS URL is https://xxxxxxxxxxxx:443.
[31/05/2019 3:24:38 PM]: IPHTTPS has a single site configuration.
[31/05/2019 3:24:38 PM]: IPHTTPS URL endpoint is: https://xxxxxxxx:443.
[31/05/2019 3:24:39 PM]: Successfully connected to endpoint https://xxxxxxxxx:443.
[31/05/2019 3:24:39 PM]: No response received from xxx.com.
[31/05/2019 3:24:39 PM]: Running Windows Firewall tests.
[31/05/2019 3:24:39 PM]: The current profile of the Windows Firewall is Public.
[31/05/2019 3:24:39 PM]: The Windows Firewall is enabled in the current profile Public.
[31/05/2019 3:24:39 PM]: The outbound Windows Firewall rule Core Networking – Teredo (UDP-Out) is enabled.
[31/05/2019 3:24:39 PM]: The outbound Windows Firewall rule Core Networking – IPHTTPS (TCP-Out) is enabled.
[31/05/2019 3:24:39 PM]: Running certificate tests.
[31/05/2019 3:24:39 PM]: No usable machine certificate found.
[31/05/2019 3:24:39 PM]: Found 0 machine certificates on this client computer.
[31/05/2019 3:24:39 PM]: Running IPsec infrastructure tunnel tests.
[31/05/2019 3:24:39 PM]: Failed to connect to domain sysvol share \\xxxxxxx\sysvol\xxxxxxxxxxx\Policies.
[31/05/2019 3:24:39 PM]: Running IPsec intranet tunnel tests.
[31/05/2019 3:24:39 PM]: Failed to connect to fddc:e3d0:7c2:1000::1 with status IcmpError.
[31/05/2019 3:24:39 PM]: Failed to connect to fddc:e3d0:7c2:1000::2 with status IcmpError.
[31/05/2019 3:24:39 PM]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.xxxxxxxx.
[31/05/2019 3:24:39 PM]: Running selected post-checks script.
[31/05/2019 3:24:39 PM]: No post-checks script specified or the file does not exist.
[31/05/2019 3:24:39 PM]: Finished running post-checks script.
[31/05/2019 3:24:39 PM]: Finished running all tests.
Richard M. Hicks
/ June 7, 2019Unfortunately this log file isn’t fully meaningful without some additional context. If you’ll send me an email directly I’ll tell you what additional information I need to offer advice for you. 🙂
Pas
/ July 17, 2019Hi Richard,
Thank you for posting very useful information.
From your experience, have you built multisite/single-site DA solutions in Google GCP?
Quoted from the link https://cloud.google.com/vpc/docs/vpc
I found the above from GCP documentation and was not sure if the Google platform would be the ideal platform to deploy a DA solution?
Thanks in advance,
Pas
Richard M. Hicks
/ July 17, 2019I’ve not yet deployed DirectAccess on the Google Cloud Platform (GCP), but I’ve done it numerous times on Azure and Amazon Web Services (AWS). I expect it will work with some of the same limitations DirectAccess has on Azure and AWS. For example, you can’t enable load balancing for DirectAccess in Azure. Also, you can’t enable outbound management using ISATAP. Details on deploying DirectAccess in Azure can be found here: https://directaccess.richardhicks.com/2016/09/19/deploying-directaccess-in-microsoft-azure/.
Robert Meany
/ April 9, 2020Richard,
Is it possible to configure DirectAccess to register its client IPV6 addresses with the intranet DNS servers so that our internal devices can connect out to the clients for management purposes? Very specifically I need to be able to use SCCM remote control on the direct access clients so we can provide support… Right now when I try to ping or connect to our DA clients from anything on the intranet other than the DA server itself, DNS cannot resolve their addresses..
Thank you for any insight you can provide on this.
Richard M. Hicks
/ April 10, 2020Yes, and typically it happens by default and doesn’t require any special configuration. Not sure why that isn’t happening in your case…
Corey R
/ May 10, 2020We’ve been using DirectAccess for quite a few years on a Server 2012 R2 server. We have everything working great, including Manage Out using ISATAP. However, with the adoption of Cloud Services we have a small annoyance. We use Cloudflare to Proxy many of our cloud services. We have many internal CNAME DNS entries pointing to something like host.domain.com.cdn.cloudflare.net, which obviously resolves externally. However, when accessing these addresses over DA we end up with an issue. Exempting the DNS entries from NRPT is the obvious solution, just like we do with many services that already have edge services. But I’m wondering if there’s an easier solution to handle internal DNS entries that resolve to an external server… I hope that make sense or perhaps exempting is the only solution? Thanks!
Richard M. Hicks
/ May 14, 2020If you want traffic going to host.domain.com.cdn.cloudflare.net to go over the DirectAccess tunnel, your only option is to put that entry in your NRPT configuration. No other way to accomplish that.
Ansmar
/ November 17, 2020How about entering aliases (CNAMEs) of Azure service – for example storage-accounts have storageaccountname.file.core.windows.net aliases but the actual record is file.randomstring.store.core.windows.net. This record may change I believe so I wouldn’t want to use it.
We would like to restrict the use of these storage accounts to our companys public ip and that’s why we need to tunnel traffic to those storage accounts
Richard M. Hicks
/ November 17, 2020That might work, but it’s not something I’ve tested. Azure may have an issue with it, but I’m not sure.
Guillaume
/ June 14, 2020Hello, Richard,
The above connection problem is now solved. However the customer can’t find the DC for example, I think there is a name resolution problem. It is possible to go on the internet to open a session with his login, but it is not possible to go on a machine of the domain for example. With the commands \\NB-123456\c$ or \\domain.ch
Thank you for your help.
Guillaume
Richard M. Hicks
/ June 18, 2020Do either of those names resolve to IPv6 addresses?
Guillaume
/ June 18, 2020Not precisely if I ping one of his machines I get a response from the public IPv4 address of the machine that comes out in the responses to the ping.