Why does systemd-networkd consider UseDomains= (domain search list from DHCP) less safe than LLMNR?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite













UseDomains=



Takes a boolean argument, or the special value "route". When true, the domain name received from the DHCP server will be used as DNS
search domain over this link, similar to the effect of the Domains=
setting. If set to "route", the domain name received from the DHCP
server will be used for routing DNS queries only, but not for
searching, similar to the effect of the Domains= setting when the
argument is prefixed with "~". Defaults to false.



It is recommended to enable this option only on trusted networks, as setting this affects resolution of all host names, in particular of
single-label names. It is generally safer to use the supplied domain
only as routing domain, rather than as search domain, in order to not
have it affect local resolution of single-label names.




compare




LLMNR=



A boolean or "resolve". When true, enables Link-Local Multicast Name Resolution on the link. When set to "resolve", only resolution is
enabled, but not host registration and announcement. Defaults to true.




but LLMNR also resolves single-label names. Can anyone explain this?



Source: https://www.freedesktop.org/software/systemd/man/systemd.network.html as of systemd version 239.







share|improve this question

























    up vote
    0
    down vote

    favorite













    UseDomains=



    Takes a boolean argument, or the special value "route". When true, the domain name received from the DHCP server will be used as DNS
    search domain over this link, similar to the effect of the Domains=
    setting. If set to "route", the domain name received from the DHCP
    server will be used for routing DNS queries only, but not for
    searching, similar to the effect of the Domains= setting when the
    argument is prefixed with "~". Defaults to false.



    It is recommended to enable this option only on trusted networks, as setting this affects resolution of all host names, in particular of
    single-label names. It is generally safer to use the supplied domain
    only as routing domain, rather than as search domain, in order to not
    have it affect local resolution of single-label names.




    compare




    LLMNR=



    A boolean or "resolve". When true, enables Link-Local Multicast Name Resolution on the link. When set to "resolve", only resolution is
    enabled, but not host registration and announcement. Defaults to true.




    but LLMNR also resolves single-label names. Can anyone explain this?



    Source: https://www.freedesktop.org/software/systemd/man/systemd.network.html as of systemd version 239.







    share|improve this question























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite












      UseDomains=



      Takes a boolean argument, or the special value "route". When true, the domain name received from the DHCP server will be used as DNS
      search domain over this link, similar to the effect of the Domains=
      setting. If set to "route", the domain name received from the DHCP
      server will be used for routing DNS queries only, but not for
      searching, similar to the effect of the Domains= setting when the
      argument is prefixed with "~". Defaults to false.



      It is recommended to enable this option only on trusted networks, as setting this affects resolution of all host names, in particular of
      single-label names. It is generally safer to use the supplied domain
      only as routing domain, rather than as search domain, in order to not
      have it affect local resolution of single-label names.




      compare




      LLMNR=



      A boolean or "resolve". When true, enables Link-Local Multicast Name Resolution on the link. When set to "resolve", only resolution is
      enabled, but not host registration and announcement. Defaults to true.




      but LLMNR also resolves single-label names. Can anyone explain this?



      Source: https://www.freedesktop.org/software/systemd/man/systemd.network.html as of systemd version 239.







      share|improve this question














      UseDomains=



      Takes a boolean argument, or the special value "route". When true, the domain name received from the DHCP server will be used as DNS
      search domain over this link, similar to the effect of the Domains=
      setting. If set to "route", the domain name received from the DHCP
      server will be used for routing DNS queries only, but not for
      searching, similar to the effect of the Domains= setting when the
      argument is prefixed with "~". Defaults to false.



      It is recommended to enable this option only on trusted networks, as setting this affects resolution of all host names, in particular of
      single-label names. It is generally safer to use the supplied domain
      only as routing domain, rather than as search domain, in order to not
      have it affect local resolution of single-label names.




      compare




      LLMNR=



      A boolean or "resolve". When true, enables Link-Local Multicast Name Resolution on the link. When set to "resolve", only resolution is
      enabled, but not host registration and announcement. Defaults to true.




      but LLMNR also resolves single-label names. Can anyone explain this?



      Source: https://www.freedesktop.org/software/systemd/man/systemd.network.html as of systemd version 239.









      share|improve this question












      share|improve this question




      share|improve this question








      edited Jun 25 at 22:04
























      asked Jun 25 at 21:58









      sourcejedi

      18k22375




      18k22375




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote



          accepted










          There is a justification posted in 2015.
          https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg31563.html





          iiuc, the concern was that multi-level domain names (i.e. those with at least
          one dot) could be spoofed by controlling the search suffix. But for
          names with at least two levels glibc only uses the search list as a
          fallback.




          Well, sure, being able to influence things at the beginning of the
          search logic is more problematic than influencing things at the end of
          the search logic, but i still think it's problematic, since it still
          allows you to insert "home.foobar.com" into a domain "foobar.com" that
          doesn't have "home.foobar.com" itself but only "www.bar.com"...



          Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure,
          but it I still believe we should default to the safer options, and
          allow the others.



          Altering the search paths is inherently something that makes no sense
          on public networks, it only makes sense if you know your network well,
          and trust it to some level. Hence opt-in sounds like the better option
          to me.







          share|improve this answer





















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );








             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f451863%2fwhy-does-systemd-networkd-consider-usedomains-domain-search-list-from-dhcp-le%23new-answer', 'question_page');

            );

            Post as a guest






























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote



            accepted










            There is a justification posted in 2015.
            https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg31563.html





            iiuc, the concern was that multi-level domain names (i.e. those with at least
            one dot) could be spoofed by controlling the search suffix. But for
            names with at least two levels glibc only uses the search list as a
            fallback.




            Well, sure, being able to influence things at the beginning of the
            search logic is more problematic than influencing things at the end of
            the search logic, but i still think it's problematic, since it still
            allows you to insert "home.foobar.com" into a domain "foobar.com" that
            doesn't have "home.foobar.com" itself but only "www.bar.com"...



            Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure,
            but it I still believe we should default to the safer options, and
            allow the others.



            Altering the search paths is inherently something that makes no sense
            on public networks, it only makes sense if you know your network well,
            and trust it to some level. Hence opt-in sounds like the better option
            to me.







            share|improve this answer

























              up vote
              0
              down vote



              accepted










              There is a justification posted in 2015.
              https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg31563.html





              iiuc, the concern was that multi-level domain names (i.e. those with at least
              one dot) could be spoofed by controlling the search suffix. But for
              names with at least two levels glibc only uses the search list as a
              fallback.




              Well, sure, being able to influence things at the beginning of the
              search logic is more problematic than influencing things at the end of
              the search logic, but i still think it's problematic, since it still
              allows you to insert "home.foobar.com" into a domain "foobar.com" that
              doesn't have "home.foobar.com" itself but only "www.bar.com"...



              Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure,
              but it I still believe we should default to the safer options, and
              allow the others.



              Altering the search paths is inherently something that makes no sense
              on public networks, it only makes sense if you know your network well,
              and trust it to some level. Hence opt-in sounds like the better option
              to me.







              share|improve this answer























                up vote
                0
                down vote



                accepted







                up vote
                0
                down vote



                accepted






                There is a justification posted in 2015.
                https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg31563.html





                iiuc, the concern was that multi-level domain names (i.e. those with at least
                one dot) could be spoofed by controlling the search suffix. But for
                names with at least two levels glibc only uses the search list as a
                fallback.




                Well, sure, being able to influence things at the beginning of the
                search logic is more problematic than influencing things at the end of
                the search logic, but i still think it's problematic, since it still
                allows you to insert "home.foobar.com" into a domain "foobar.com" that
                doesn't have "home.foobar.com" itself but only "www.bar.com"...



                Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure,
                but it I still believe we should default to the safer options, and
                allow the others.



                Altering the search paths is inherently something that makes no sense
                on public networks, it only makes sense if you know your network well,
                and trust it to some level. Hence opt-in sounds like the better option
                to me.







                share|improve this answer













                There is a justification posted in 2015.
                https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg31563.html





                iiuc, the concern was that multi-level domain names (i.e. those with at least
                one dot) could be spoofed by controlling the search suffix. But for
                names with at least two levels glibc only uses the search list as a
                fallback.




                Well, sure, being able to influence things at the beginning of the
                search logic is more problematic than influencing things at the end of
                the search logic, but i still think it's problematic, since it still
                allows you to insert "home.foobar.com" into a domain "foobar.com" that
                doesn't have "home.foobar.com" itself but only "www.bar.com"...



                Sure, classic (non-DNSSEC) DNS is not ever going to be fully secure,
                but it I still believe we should default to the safer options, and
                allow the others.



                Altering the search paths is inherently something that makes no sense
                on public networks, it only makes sense if you know your network well,
                and trust it to some level. Hence opt-in sounds like the better option
                to me.








                share|improve this answer













                share|improve this answer



                share|improve this answer











                answered Jun 25 at 22:03









                sourcejedi

                18k22375




                18k22375






















                     

                    draft saved


                    draft discarded


























                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f451863%2fwhy-does-systemd-networkd-consider-usedomains-domain-search-list-from-dhcp-le%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?