[wip]: Write about systemd-resolved

content/posts/systemd-resolved-private-ep/index.md

@@ -0,0 +1,41 @@
++++
+title = "Specific DNS servers for specific domain names with systemd-resolved"
+date = "2024-04-04"
+draft = true
+
+[extra]
+comment = true
+
+[taxonomies]
+tags=["linux"]
++++
+
+Today I had an issue related to Azure Private Endpoints.
+I think I found a nice work around, so I thought I'd write a blog post about it.
+It's only applicable to Linux systems using systemd-resolved for DNS resolution (e.g. most Ubuntu and Fedora installations).
+
+### Background
+
+I'm connected to a client's company network, to work on an application which uses blob storage through an azure storage account.
+This storage account has a private endpoint configured so that it can be used by the application without going through the public internet
+when the application is running in azure (networking - subnets / vnets is configured accordingly. Not important right now.)
+
+### Problem
+
+When I run the application locally I get timeouts and connection errors when trying to connect to blob storage.
+This turns out to be because the vnet mentioned above is peered to the on-premise network I connect to,
+and the default DNS server on this has been configured such that the blob storage endpoint I'm talking to (*.blob.core.windows.net)
+gets resolved to the private endpoint's private IP address.
+_However_ some kind of network security is blocking the connection to this private IP address.
+
+I verify this using `dig +short {storageaccountname}.blob.core.windows.net`.
+
+### Potential solutions and work-arounds
+
+Normally the best solution to this kind of problem would be to further troubleshoot why the connection to the private endpoint is getting blocked
+(probably a network security group or a firewall configuration),
+but in my case I just wanted to work-aroud the issue by connecting to the storage account using the storage account's public IP address
+(note that this requires your public ip address to be whitelisted in the storage account's firewall if enabled).
+
+The quickest work-around is probably to update the /etc/hosts file with the public IP address of my storage account.
+This will work, but it feels a bit too manual. I'd like to specify a