Re: [dns-operations] Single label queries on Windows (11)
Even on *x nslookup and dig tools use own resolution code. That is because they are DNS specific utilities. Not something using getaddrinfo() calls, which common applications use. Is there alternative to "getent ahosts " on Microsoft systems? Using ping for that helps in a limited way, but is not perfect. On 7/9/23 06:30, Greg Choules via dns-operations wrote: -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Single label queries on Windows (11)
Ah, this is embarrassing. Yes, trailing dot have helped. I am sorry for the confusion. >nslookup -type=ns org. Server: pihole Address: 192.168.88.9 Non-authoritative answer: org nameserver = b2.org.afilias-nst.org <http://b2.org.afilias-nst.org/> org nameserver = a2.org.afilias-nst.info <http://a2.org.afilias-nst.info/> org nameserver = c0.org.afilias-nst.info <http://c0.org.afilias-nst.info/> org nameserver = b0.org.afilias-nst.org <http://b0.org.afilias-nst.org/> org nameserver = a0.org.afilias-nst.info <http://a0.org.afilias-nst.info/> org nameserver = d0.org.afilias-nst.org <http://d0.org.afilias-nst.org/> a0.org.afilias-nst.info <http://a0.org.afilias-nst.info/> internet address = 199.19.56.1 a2.org.afilias-nst.info <http://a2.org.afilias-nst.info/> internet address = 199.249.112.1 b0.org.afilias-nst.org <http://b0.org.afilias-nst.org/> internet address = 199.19.54.1 b2.org.afilias-nst.org <http://b2.org.afilias-nst.org/> internet address = 199.249.120.1 c0.org.afilias-nst.info <http://c0.org.afilias-nst.info/> internet address = 199.19.53.1 d0.org.afilias-nst.org <http://d0.org.afilias-nst.org/> internet address = 199.19.57.1 a0.org.afilias-nst.info <http://a0.org.afilias-nst.info/> IPv6 address = 2001:500:e::1 a2.org.afilias-nst.info <http://a2.org.afilias-nst.info/> IPv6 address = 2001:500:40::1 b0.org.afilias-nst.org <http://b0.org.afilias-nst.org/> IPv6 address = 2001:500:c::1 b2.org.afilias-nst.org <http://b2.org.afilias-nst.org/> IPv6 address = 2001:500:48::1 c0.org.afilias-nst.info <http://c0.org.afilias-nst.info/> IPv6 address = 2001:500:b::1 d0.org.afilias-nst.org <http://d0.org.afilias-nst.org/> IPv6 address = 2001:500:f::1 On 7/7/23 20:32, Viktor Dukhovni wrote: On Fri, Jul 07, 2023 at 08:09:39PM +0200, Petr Menšík wrote: I have tested recently how Windows 11 behaves when resolving single label queries. I have expected it might try to use LLMNR. But I did not expect it would do so also when trying nslookup, a tool which should be DNS only tool. I have tried: nslookup -type=ns com 9.9.9.9 It is not too surprising if this is also subject to the default suffix list of the network "connection", which initialises the resolution context, and then just overrides the server. Have you tried: nslookup -type=ns com. 9.9.9.9 with an explicit trailing "."? I thought I have tried that, but turns out I have tried that only when testing behavior of systemd-resolved installation on Linux, where it was useless. On Windows it helps. Parameter -debug showed it indeed appends default domain suffix and does not try without it after negative response. nslookup from ISC BIND9 behaves a bit better, but that is an acceptable difference. $ nslookup -domain=home.arpa -debug -type=ns org Server: 127.0.0.1 Address: 127.0.0.1#53 QUESTIONS: org.home.arpa, type = NS, class = IN ANSWERS: AUTHORITY RECORDS: -> home.arpa origin = localhost mail addr = nobody.invalid serial = 1 refresh = 3600 retry = 1200 expire = 604800 minimum = 10800 ttl = 10800 ADDITIONAL RECORDS: ** server can't find org.home.arpa: NXDOMAIN Server: 127.0.0.1 Address: 127.0.0.1#53 QUESTIONS: org, type = NS, class = IN ANSWERS: -> org nameserver = b0.org.afilias-nst.org. ttl = 1824 -> org nameserver = b2.org.afilias-nst.org. ttl = 1824 -> org nameserver = c0.org.afilias-nst.info. ttl = 1824 -> org nameserver = d0.org.afilias-nst.org. ttl = 1824 -> org nameserver = a0.org.afilias-nst.info. ttl = 1824 -> org nameserver = a2.org.afilias-nst.info. ttl = 1824 AUTHORITY RECORDS: ADDITIONAL RECORDS: Non-authoritative answer: org nameserver = b0.org.afilias-nst.org. org nameserver = b2.org.afilias-nst.org. org nameserver = c0.org.afilias-nst.info. org nameserver = d0.org.afilias-nst.org. org nameserver = a0.org.afilias-nst.info. org nameserver = a2.org.afilias-nst.info. Authoritative answers can be found from: Got NXDOMAIN. I were very suprised, learned that does not exist. Even more suprising were fact, that it presented the result came from the specified server. But the result should have been for "com.." What happens when you configure the network connection with a default suffix of "."? "nslookup -domain=. -type=ns com" works fine as well. -- Petr Menšík Software Engineer, RHEL Red Hat,https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Single label queries on Windows (11)
Hello, I have tested recently how Windows 11 behaves when resolving single label queries. I have expected it might try to use LLMNR. But I did not expect it would do so also when trying nslookup, a tool which should be DNS only tool. I have tried: nslookup -type=ns com 9.9.9.9 Got NXDOMAIN. I were very suprised, learned that does not exist. Even more suprising were fact, that it presented the result came from the specified server. I am quite certain that server can resolve it successfully. When I run the same command on my Linux system, it works as it should. nslookup -type=ns microsoft.com 9.9.9.9 Of course works as expected. I would like to file some kind of bug. But have no idea how that could be done for Windows (desktop). Is there any bug tracker or at least documentation, why it does behave this way? Would you know a good contact to anyone from Microsoft, who may I contact? Is this behavior considered correct? Thanks in advance! Regards, Petr -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] How should work name resolution on a modern system?
On 11. 06. 22 5:56, Viktor Dukhovni wrote: On Fri, Jun 10, 2022 at 09:16:11PM +0200, Petr Menšík wrote: - first is libc interface getaddrinfo() provided by nss plugins. Names can be resolved also by different protocols than just DNS. A good examples might be MDNS (RFC 6762), LLMNR (RFC 4795) or Samba (nmblookup). Standardized calls provide only blocking resolution interface. The nsswitch (originall from SunOS IIRC) indeed has limitations, but is unlikely to fade away quickly, especially because it also handles non-DNS queries (passwd, group, services, ...). That said, best practice for "hosts" has been essentially: hosts: files dns with a very short /etc/hosts with just the local system address and name, perhaps only a loopback address at that. But this was before as mention below the introduction of "mdns" et. al., and in some "enterprise" environments "samba" or similar. Enterprise samba uses DNS. I think legacy network lookup would be used by older Windows systems or NAS storages. Maybe it is not so important. I am quite sure MDNS is used often on Apple systems. * Asynchronous interface does not exist in useful form. It is easy to handle multiple connections in single thread, but multiple resolutions in single thread are not supported. nss plugins are simple to write, but hard to use in responsibe program. Should that be changed? Indeed asynchronous interfaces for some of these would be quite useful, and some dedicated libraries (alternatives to good-*old* libresolv) provide these for DNS specifically, but they are not ubiquitous, and would introduce completely new APIs undreamed of in SvID and POSIX. * MDNS usually uses names under .local domain. What should be preferred order of single label names, like 'router.'? Should be LLMNR tried first, samba first or DNS search applied first? Should it avoid reaching DNS when search domain is not set? I rather expect there is no one-size-fits-all answer, and so nsswitch.conf or equivalent is here to stay. Sometimes one wants no "mdns" or similar at all. The right answer for a laptop trying to locate nearby printers is rather different than the answer for a server racked in a datacentre. Sure, mdns would have rare usage on server releases. dns-sd.org has link to DNS only implementation, I expect that would be a good way to have printers located from datacenters if required. - primary interest for us is DNS protocol. On Unix systems it specifies nameservers to use in /etc/resolv.conf also with some options. We would like to offer DNS cache installed on local machine, which should increase speed of repeatedly resolved names. Definitely, with DNSSEC validation, and (on laptops) perhaps support for probing of DNSSEC support when switching between WiFi networks, or opting in to a captive portal, so that DNSSEC is used when available, once the portal T etc have been dealt with, and real DNS servers (ideally) become reachable. Sure. I have made a bit research of how Network Manager does it. It tries resolution via systemd-resolved, if not possible, falls back to normal resolution in curl library. I have not found any trace of DNSSEC support during it. I think it should disable validation during connection test phase. If captive portal is detected, keep it disabled. Also set maximum TTL to 1s or flush cache at captive portal passed event. I think cache flush would be required only if any name validation failed and captive portal were detected. * I would like to have support for multiple interfaces and redirection of names subtree to local network interfaces servers. For example 'home.arpa' redirected to local router at home, but example.com redirected to VPN connection. This is largely a laptop problem, but indeed the local caching nameserver could have appropriate stub zones defined, so that queries for "special" zones are sent to non-default servers. I think also servers can have some use-cases, when some service provides link to internal company network. Also network maintained by libvirt od podman might have its own dnsmasq, which maintains names for started containers. They might want to map pods.example.com to podman or vms.example.net to VM. If it runs different networks, host should connect them and make then reachable. But this is different, because those networks are not received from different devices. Orchestration should be able to configure it appropriately. I think RFC 8801 and RFC 7556 specify standardized way to list interface specific domains. Existing implementations misuse RFC 2937 for a source of such list now. Something like this is implemented by systemd-resolved on Ubuntu and Fedora systems. But it introduced couple of new issues. Is something similar implemented on end user machines? I think laptop and phones are typical devices with multiple interfaces, where it would make sense. This is a complex question, that can't be an
[dns-operations] How should work name resolution on a modern system?
Hello DNS experts, I were thinking about requirements for future name resolution primarily on Linux desktop and servers. But if anyone could comment other systems and their design, I would be glad too. I would like to formulate requirements first and find a good way to implement them later. We have two ways used to resolve names to ip addresses on GNU/Linux. - first is libc interface getaddrinfo() provided by nss plugins. Names can be resolved also by different protocols than just DNS. A good examples might be MDNS (RFC 6762), LLMNR (RFC 4795) or Samba (nmblookup). Standardized calls provide only blocking resolution interface. * Asynchronous interface does not exist in useful form. It is easy to handle multiple connections in single thread, but multiple resolutions in single thread are not supported. nss plugins are simple to write, but hard to use in responsibe program. Should that be changed? * MDNS usually uses names under .local domain. What should be preferred order of single label names, like 'router.'? Should be LLMNR tried first, samba first or DNS search applied first? Should it avoid reaching DNS when search domain is not set? - primary interest for us is DNS protocol. On Unix systems it specifies nameservers to use in /etc/resolv.conf also with some options. We would like to offer DNS cache installed on local machine, which should increase speed of repeatedly resolved names. * I would like to have support for multiple interfaces and redirection of names subtree to local network interfaces servers. For example 'home.arpa' redirected to local router at home, but example.com redirected to VPN connection. I think RFC 8801 and RFC 7556 specify standardized way to list interface specific domains. Existing implementations misuse RFC 2937 for a source of such list now. Something like this is implemented by systemd-resolved on Ubuntu and Fedora systems. But it introduced couple of new issues. Is something similar implemented on end user machines? I think laptop and phones are typical devices with multiple interfaces, where it would make sense. My questions: - how should single label names be handled? -- is domain (opt. 15) and search (opt. 117) from DHCP already dead? Should they be completely avoided even in trusted networks? -- in which order should be resolution tried? Should machine cache block queries to single label hostnames not expanded to FQDN on DNS protocol? -- I have seen usage of search domains on cloud technologies. Is there common example what they are used for? Do we need ndots option with value different from 1? - should we expect DNSSEC capabilities on every machine? -- should we even enable DNSSEC validation on every machine by default? When it would be good idea and when it wouldn't? - should asynchronous API be prepared for common name to addresses and vice versa? One which would support both local network resolution and unicast DNS in easy to use way? Usable even in GUI applications without common hassle with worker threads? If there is documentation for name subtree mapping to interface servers on different systems, I would be glad if you could share links to it. If we should improve current situation, I would like to first gather expected requirements for such system. Is there some summary already? Thank you for any feedback! Best Regards, Petr -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
That might not be true on some Linux distributions. Those with systemd-resolved preinstalled (Ubuntu and Fedora) send single label queries to LLMNR multicast resolution. I think it uses the search directive for list of domains for local networks, but otherwise ignores them. It is debatable whether this approach is more secure or better. On 04. 06. 22 2:18, Randy Bush wrote: Do we have any idea how many systems still use search lists? linux and freebsd installs encourage them -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] DNSSEC queries to Amazon EC2 without signatures
Is anyone from Amazon EC2 DNS team present? We have Testing Farm for Fedora project on AWS instances. Because our internal network restricts outgoing DNS packets, we always rely on resolvers provided by the network. However, our unbound test containing DNSSEC validation fails. The server does not answer to dnssec enabled query with signatures, which are required for working resolution. Another issue is bad handling of empty non-terminals. Name dig soa us-east-2.compute.internal answers without error, but dig soa compute.internal ends with NXDOMAIN status. Because Amazon is member of DNS-OARC, do you know, when such reports should be directed? Thanks! -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream
No, SHA-1 is not going to be disabled the same way MD5 were disabled in RHEL 7. Normal message digests using SHA-1 will still work. I know NSEC3 has no other alternative and therefore we cannot afford breaking it altogether. It would break almost all resolution in the most common top level domains. Any attempt to do that would be clear blocker for a release and no, nothing such is planned or implemented. What will start failing are attempts to verify digests made using SHA-1 and RSA keys used in the same openssl API call. I have included examples of openssl calls which would now return error. sha1sum and similar tools should still work unmodified. That means also NSEC3 would still work. I haven't seen complete API call list affected by this change. I cannot share it therefore. Power DNS developer said their implementation still works. It seems using lower-level API calls can avoid this change of policy. That is discouraged by our internal guidelines, but could be used as a workaround. I haven't tested those ways. On 4/14/22 07:02, Shreyas Zare wrote: > > Hi, > > Apart from DNSSEC validation, have you also tested DNS servers hosting > DNSSEC signed zones with NSEC3? This is since NSEC3 only has SHA1 > specified > <https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml> > and this may cause the DNS server unable to update the zone to create > new NSEC3 records. This will mean that even if the zone is signed with > ECDSA algorithms but use NSEC3 then they are going to fail. > Yes, I am aware there is no other hash algorithm standardized. I have tested NSEC3 stays working and validates in DEFAULT policy. If you can find a case where it stopped working on centos stream9 container, please share steps to reproduce with me. I don't think that can happen, but you can prove me wrong. > > Regards, > *Shreyas Zare* > Technitium <https://technitium.com/> > > Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream
No, I wanted just the first message to reach both, because I am subscribed to both lists. Interested people can search archives of the other list. I expected those lists have very likely disjoint members not able to write to both. Feel free to remove epel-devel from further responses here to avoid receiving errors (and vice versa). On 4/14/22 00:49, Mark Andrews wrote: > If you wanted epel-devel list members to see the discussion you have failed. > > Your message to the epel-devel mailing-list was rejected for the following > reasons: > > The message is not from a list member > > The original message as received by Mailman is attached. > > From: Mark Andrews > Subject: Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and > CentOS 9 Stream > Date: 14 April 2022 at 08:44:55 AEST > To: Petr Menšík > Cc: DNS-Operations , > epel-de...@lists.fedoraproject.org > > > The only way to detect if the server is running in this mode is to actually > attempt a verification and to see if it fails. That requires precomputed > signatures as you can’t sign using RSASHA1 in FIPS mode but you can verify > RSASHA1 in FIPS mode. I am not sure what is the platform you are describing. RHEL 9 won't be able to verify RSASHA1 signature even in default policy, let alone in FIPS mode. > > In FIPS mode one can check if the server is running in FIPS mode or not by > calling FIPS_mode() or EVP_default_properties_is_fips_enabled() and you can > adjust the list of algorithms supported by libcrypto at runtime before > attempting to validate anything. You don’t end up doing a lot of work just > to have EVP_VerifyFinal() fail because of an unsignalled policy switch. > > Mark Yes, I find it also disturbing that there is no good public API to check SHA-1 availability except attempting a real crypto operation. I hope that will improve later, but I don't know well working candidate API at the moment. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream
I admit feedback from the DNS community were mostly negative or indifferent. Because the cause of this breakage is already merged and prepared for release, it would have to be reverted. We have no feedback from our customers on this topic yet, because already released RHEL 9 Beta did not contain the responsible change. Final RHEL 9.0 haven't been released yet. I am trying to receive feedback how critical this change can be. What types of deployments can it affect or even break? I think SMTP services using DANE might be hit by this change. I don't have any numbers how many our customers need SHA-1 domains secure. I would like to receive any opinions here. Ideally backed by some numbers. On 4/13/22 20:35, Paul Hoffman wrote: > To date, have any of your customers or anyone in the DNS community, supported > your choice of how to implement this? If not, or if only a trivial number > have, does that affect your decision on how to implement this? This decision were not made by me and I had no vote for it before it was done. I try to reduce negative impact of it. But probability of reverting that change just because DNSSEC validators not prepared for it is low. Unless it has dramatic negative impact which I haven't found so far. > > --Paul Hoffman -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream
Hello DNS users, I have already created some bugs to inform some affected software packages. But I would like to notify also here with prepared plan to obsolete SHA-1 in upcoming RHEL 9.0. Final documentation is not yet created for it, but it could be tested already on centos container: docker pull quay.io/centos/centos:stream9 delv command from bind-utils or unbound-host -D from unbound can test it. delv would still fail, because it does not follow crypto-policy configuration which named consumes. I have filled tracker bug for EPEL9 components I know on bug #2073066 [1]. If your software validates DNSSEC signatures, it might start failing on domain names signed with RSASHA1 or NSEC3RSASHA1 algorithms. If you have package validating DNSSEC on EPEL9 which I have not mentioned and it is affected, please create a bug blocking this tracker bug. If have created the bug but is not affected, please close it with NOTABUG. Crypto-policy DEFAULT makes some openssl or gnutls methods to fail, when RSASHA-1 key is used. That includes openssl function EVP_VerifyFinal (used in bind) and EVP_DigestVerifyInit (used in unbound). Because used crypto policy DEFAULT prevents such signature verification, DNSSEC validators may start to return failures on those names. A simple workaround would be switching to crypto policy DEFAULT:SHA1: update-crypto-policies --set DEFAULT:SHA1 I have created list to TLD affected and attached them to the bug [2]. But it includes many more names, such as icann.org, ietf.org or paypal.com. I know it violates still active RFC 8624 [3], but because it is enforced by lower-level API, it is possible just to follow or fail. I think so far every crypto call failure results in bogus result and returns status SERVFAIL on the reply. Would it make sense to create some common cases, where the result would be fallback to insecure reply without AD bit, but no failure? Supported bind and unbound packages will start considering those names as insecure to prevent validation failures. There has been interesting conversation on mattermost Town Square [4] on this topic. Worth noting might be also threads on unbound [5] and Fedora discussion about implementing the same way [6]. Best Regards, Petr 1. https://bugzilla.redhat.com/show_bug.cgi?id=2073066 2. https://bugzilla.redhat.com/show_bug.cgi?id=2073066#c7 3. https://datatracker.ietf.org/doc/html/rfc8624#section-3.1 4. https://chat.dns-oarc.net/community/channels/town-square 5. https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html 6. https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Split view autoconfiguration
On 11/12/20 9:00 PM, Florian Weimer wrote: > * Petr Menšík: > >> I'll try to rephrase. Connection provides list of domains, it considers >> internal. All names in that domains should be resolved using DNS servers >> provided by that connection. Because common network connection managed >> by NM or systemd-networkd does not have "internal domains" property, >> systemd-resolved and dnssec-trigger uses DHCP search (119) option. > > Is it really a list, though? > > I expect corporate networks to use RPZ to manage things like > typo-squatting, so it's going to be very long, and perhaps not even > readily disclosable for contractual reasons. I don't think they should share the whole RPZ zone via that list. I should be able to send all queries to VPN for safety checking and only selected to my local/home network, reversing the functionality. I expect that domain list per connection would be usually limited to 5 names, not hundred of names. Just bare minimum for basic functionality, not RPZ protection for any bad site on the internet. Something like "corp.example.net, labs.example.org". Since I have installed my own system not managed or supported by our IT and have also own internet connection, I don't think the VPN (nor the company) has to monitor all my internet usage. Therefore I would like send there only traffic directed to VPN, avoiding personal queries to go there as well. I am refering to Split DNS change proposed to Fedora [1]. I have been using dnssec-trigger for years. Think there should be some standard way to define configuration in more standard way. It is also question, how should VPN connection be configured to send all queries to the VPN or not. An employer might require it in the contract. When I need multiple VPN connections, it would have to choose somehow. How? 1. https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS > > Thanks, > Florian > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Split view autoconfiguration
On 11/12/20 3:01 PM, Paul Wouters wrote: > On Nov 12, 2020, at 07:59, Petr Menšík wrote: >> >> Hello DNS experts, Hi Paul, >> >> I am looking for correct way to autoconfigure split DNS. By that, I mean >> something that dnssec-trigger prepares, when I connect to our enterprise >> VPN. It keeps most of queries to original connection servers provided. > > That is exactly what RFC 8598 does for IKEv2/IPsec. This is supported by > libreswan and supports a local unbound. For the next version of libreswan we > will add support for NM. systemd-resolved, knot, resolvconf (Debian) Could you provide issue or merge request on NM if available? > > I submitted build for openvpn with unbound support but those changes got lost > over time. > >> But for special internal domains, it redirects queries on local running >> unbound server to addresses provided by VPN connection. Similar way >> behaves systemd-resolved and dnsmasq configured by Network Manager. > > I don’t quite understand what you are saying here? I'll try to rephrase. Connection provides list of domains, it considers internal. All names in that domains should be resolved using DNS servers provided by that connection. Because common network connection managed by NM or systemd-networkd does not have "internal domains" property, systemd-resolved and dnssec-trigger uses DHCP search (119) option. > >> I think they use DHCP option 119 [1], which was originally used for >> different thing. It is already used and can be used as a hint. But its >> purpose is to search relative names. I found only explicit configuration >> for IKEv2 [2], which provides required information. > > DHCP options are only useful for non-VPN connections. There has been talk > about putting the RFC 8598 options into a dhcp option but people connecting > to enterprise wired/wireless don’t have a split dns normally. Either you > (have to) trust the network or you fully distrust it (and want dot/doh to an > external party) They still can be connected to different network by wired and wireless connection. They may want to send some name queries over "untrusted" wireless and different over "trusted" wired connection. List of internal domains provided for each connection may help with autoconfiguration. Anyway, it might want to propagate lan domain instead, when I send all default queries to VPN server. I would like then lan. domain still sent to my home router and not to the VPN. DHCP option would work for that case. > > >> Am I missing standard way to pass internal domains on VPN connections >> for different types? Is there any best practice or recommendation how to >> configure it in general? > > openvpn surely has something but as I said, patches were lost. WireGuard will > invent something homegrown once they have their userland daemon (WG-dynamic). I personally think VPN should not usually push it directly to specific nameserver. Instead, some standard tool should be used, whatever supported local resolver is running. Most often it woult be Network Manager on linux machine. Not sure if resolvconf would be correct tool for that. > We can’t really standardize openvpn/WireGuard. We could prepare standard handler and let VPN plugin to extract variables from specific connection protocol. >> Is it so uncommon to have split horizon setup with internal connection? >> I hope I don't know just correct terminology, could you help with that? >> Is there DHCP option 119 alternative, which means list of internal >> domains without additional search hints? Is there other way to configure it? > > For IETF standard VPN protocol, we have the solution, and it is implemented. > I can give you a certificate for VPN.nohats.ca to test. Would be useful for testing. > > Note it does do fallback to re-using the list of dns domains as search > domains in resolv.conf if it doesn’t find a locally running dns server. > > Paul > This means IPSEC VPN has configured "internal" domains. When local endpoint is not able to configure split-dns on the machine, they are converted to search domains, correct? I think there should be also other ways to manually configure internal domains for a connection. Just like Domains= in systemd-networkd, but not only for consumption of systemd-resolved. Is there any way to configure something similar in different systems? What about Windows 10 or Apple OSX? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Split view autoconfiguration
Hello DNS experts, Hi Paul, I am looking for correct way to autoconfigure split DNS. By that, I mean something that dnssec-trigger prepares, when I connect to our enterprise VPN. It keeps most of queries to original connection servers provided. But for special internal domains, it redirects queries on local running unbound server to addresses provided by VPN connection. Similar way behaves systemd-resolved and dnsmasq configured by Network Manager. I think they use DHCP option 119 [1], which was originally used for different thing. It is already used and can be used as a hint. But its purpose is to search relative names. I found only explicit configuration for IKEv2 [2], which provides required information. Am I missing standard way to pass internal domains on VPN connections for different types? Is there any best practice or recommendation how to configure it in general? Is it so uncommon to have split horizon setup with internal connection? I hope I don't know just correct terminology, could you help with that? Is there DHCP option 119 alternative, which means list of internal domains without additional search hints? Is there other way to configure it? Thank you in advance. Best regards, Petr 1. https://tools.ietf.org/html/rfc3397 2. https://tools.ietf.org/html/rfc8598 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
