Bug 248102
| Summary: | [local_unbound] default config file violates RFC | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Walter von Entferndt <walter.von.entferndt> |
| Component: | standards | Assignee: | Cy Schubert <cy> |
| Status: | New --- | ||
| Severity: | Affects Some People | CC: | cy, emaste, jlduran, pat, rgrimes, sblachmann |
| Priority: | --- | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Walter von Entferndt
2020-07-19 13:20:07 UTC
ping This really should be fixed. Though without looking at the RFC I would suspect the wording is that you :SHOULD: not send RFC1918 lookups to external servers, that only means FreeBSD is not doing the best it could, technically you do not have to do a :SHOULD: to be RFC compliant. If you want to site the RFC number and section I'll take a look. (In reply to Rodney W. Grimes from comment #2) I had dark memory that the meaning/usage in RFCs of these terms is non- intuitive, so I looked it up in RFC 2119 - it matches common sense: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. OK now for RFC 1918: Section 5. Operational Considerations [page 6]: If an enterprise uses the private address space, or a mix of private and public address spaces, then DNS clients outside of the enterprise *should* *not* see addresses in the private address space used by the enterprise, since these addresses would be ambiguous. One way to ensure this is to run two authority servers for each DNS zone containing both publically and privately addressed hosts. One server would be visible from the public address space and would contain only the subset of the enterprise's addresses which were reachable using public addresses. The other server would be reachable only from the private network and would contain the full set of data, including the private addresses and whatever public addresses are reachable the private network. In order to ensure consistency, both servers should be configured from the same data of which the publically visible zone only contains a filtered version. There is certain degree of additional complexity associated with providing these capabilities. Conclusio: Since the network expert wizzard who shipped that non- conformant default config can not know in advance about the /particular circumstances/ of an arbitrary random network setup running a local_unbound instance, s/he may please explain how s/he was able to RFC 2119 topic 4. *SHOULD* *NOT*: /the full implications should be understood and carefully weighed/. Soothsaying? Sorcery? Do we ship magic cristal balls? How can s/he weight what s/he doesn't know? Ah, sorry, that's what risk managers do. Is s/he? Yes, /there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but/ please - not by default. D'accord? PS Should we forward this to the dns/unbound port, I guess it's also affected, and s/he/they send the issue upstream? (In reply to Walter von Entferndt from comment #3) The forwarding of RFC1918 reverse look ups has existed historically since DNS started, because of clauses in RFC"s that say they SHOULD NOT be treated special. This change to stop doing that really comes about by RFC6761 6.1. Again, I have asserted FreeBSD should probably fix this, but technically still a SHOULD/SHOULD not situation. Further more, if we had still been using BIND in the base system, this would already be handled, the default BIND caching configuration does not forward these requests. This bug really is in the upstream unbound default configurations and should be addressed there, and then imported to FreeBSD, but that should not preclude someone fixing this before that can happen. (In reply to Rodney W. Grimes from comment #4) Thank you for supporting my suggestion, and referencing the much more appropriate RFC 6761 Section 6.1.4: "[...] Instead, caching DNS servers SHOULD, _by_ _default_, generate immediate (positive or negative) responses for all such queries. [...] Caching DNS servers SHOULD offer a configuration option (_disabled_ _by_ _default_) to enable upstream resolution of such names, [...]" (add. underlining to make clear to point of interest) Now again, since SHOULD/SHOULD NOT reads (RFC 1918): "[...] the case carefully weighed before implementing any behavior described with this label." I want to repeat that a SHOULD/SHOULD NOT _must_ _not_ be overridden _arbitrarily_ just because it's not a MUST/MUST NOT. This is clearly /not/ the case: there can no weighting w/o knowing the special circumstances of the deploying network. Thus, a SHOULD/SHOULD NOT has _regularly_ to be taken like MUST/MUST NOT for the domain of shipping default configurations. Very few exceptions may exist to this rule. In this case, I can not see any valid reason, no matter how hard I try. (In reply to Rodney W. Grimes from comment #4) Upstream is set "as expected": https://github.com/NLnetLabs/unbound/blob/bf0a91aa418f4e52d809f37d0c02ab16e0b554fb/doc/example.conf.in#L701 This was a deliberate change for FreeBSD, as it is *assumed* that you would only use it locally (base r268840). (In reply to Jose Luis Duran from comment #6) Apparently links are not working as expected. base r268840: https://github.com/freebsd/freebsd-src/commit/5741c3f5108e9a5edb63e5f06a6d2316975fc995 (In reply to Jose Luis Duran from comment #7) This is a separate problem. Please open a new PR for it. (In reply to Cy Schubert from comment #8) I was referring to my previous comment. :) (In reply to Jose Luis Duran from comment #6) > This was a deliberate change for FreeBSD, as it is *assumed* that you would > only use it locally (base r268840). I.e. assuming a local network either behind a professional firewall setup, or without any internet connection at all. This is 1. not documented (so-called "silent assumtion" <=> bad thing to do) 2. I doubt this a good assumption at all, since FreeBSD is documented to be a "general purpose" OS. Thank you in advance for changing that knob to comply with RFC 6761. (In reply to Walter von Entferndt from comment #10) I can relate completely, as I have been there before. However, per the FreeBSD Handbook [1]: > Unbound is provided in the FreeBSD base system. > By default, it will provide DNS resolution to the local machine only. > While the base system package can be configured to provide resolution > services beyond the local machine, it is recommended that such > requirements be addressed by installing Unbound from > the FreeBSD Ports Collection. [1]: https://docs.freebsd.org/en/books/handbook/network-servers/#_dns_server_configuration (In reply to Jose Luis Duran from comment #11) 1. The point of interest is that local_unbound sends information about the local network using private IPv4 address space out to the internet. That's a (small, but unnecessary) security risk that should be fixed, and it clearly violates RFC 6761. 2. That does _not_ free the default configuration shipped (or created by a script) to comply to RFC 6761 & the strict interpretation of RFC 2119 as I outlined in my comment #5: for the application/domain of default knobs, a SHOULD/SHOULD_NOT has to be treated as if it's a MUST/MUST_NOT. Very, very seldom there can be a /resonable/ exception to this general rule. Please either tell the reasons or even better, give up your resistance & simply change that knob as requested. The option exposes the internal LAN addresses which are hooked to the particular computer and use it as DNS cache. For good reasons this option is set default-off in upstream. Enabling this option ensures that the external DNS server operators get all the interesting metadata about the unsuspecting FreeBSD users and their internal network, its computers and their users' [company, family, ...] usage patterns. Please explain the reasons why it is deemed necessary that FreeBSD continues sending the unsuspecting users' sensitive metadata to external entities. Thank you. |
