bugzilla-daemon at netfilter.org
2017-Mar-14 14:05 UTC
[Bug 1130] New: Better handling DNS names in nft ruleset
https://bugzilla.netfilter.org/show_bug.cgi?id=1130 Bug ID: 1130 Summary: Better handling DNS names in nft ruleset Product: nftables Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: nft Assignee: pablo at netfilter.org Reporter: pascal.ernster+bugzilla.netfilter.org at rub.de nft currently allows the usage of DNS hostnames instead of IP addresses in the ruleset, however it doesn't handle them very well. For instance, if the hostname cannot be resolved immediately at the time the ruleset is loaded, nft simply bails out and doesn't load the entire ruleset. This is problematic, because in a typical scenario, during system boot, nft is run on purpose *before* the network interfaces are brought up to prevent the machine from letting through unfiltered traffic from potentially untrusted networks. IMHO, it would be desirable that nft handles this more gracefully. For example, if DNS resolution fails, nft could log a warning and at least load all rules which do not require a functional DNS resolution, wait a few seconds, try if DNS resolution works again, and then automatically reload the ruleset (this time of course including rules containing DNS hostnames). At the very least though, the loading of an entire ruleset should not be prevented by the inability to resolve a single DNS name. Another possible solution might be some form of persistent local DNS cache. Keep in mind though that "just update the cache on loading a ruleset" might not be the best idea because such a ruleset might have been loaded weeks or even months before the machine running nftables is rebooted. I'm reluctant to use something like /etc/hosts to hack around this problem because this would remove any benefit of using DNS in the first place. -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170314/f60de7e6/attachment.html>
bugzilla-daemon at netfilter.org
2017-Mar-14 14:09 UTC
[Bug 1130] Better handling of DNS names in nft ruleset
https://bugzilla.netfilter.org/show_bug.cgi?id=1130 Pascal Ernster <pascal.ernster+bugzilla.netfilter.org at rub.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Better handling DNS names |Better handling of DNS |in nft ruleset |names in nft ruleset -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170314/9222c3e1/attachment.html>
bugzilla-daemon at netfilter.org
2017-Mar-14 15:25 UTC
[Bug 1130] Better handling of DNS names in nft ruleset
https://bugzilla.netfilter.org/show_bug.cgi?id=1130 Pablo Neira Ayuso <pablo at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Pablo Neira Ayuso <pablo at netfilter.org> --- If you're seeking to improve human readability, then I'd suggest you use variable definitions, eg. define yahoo = { 98.139.183.24, 98.138.253.109, 206.190.36.45 } add table x add chain x y { type filter hook output priority 0; } add rule x y ip daddr $yahoo drop -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170314/8c14fc98/attachment.html>
bugzilla-daemon at netfilter.org
2017-Mar-14 15:27 UTC
[Bug 1130] Better handling of DNS names in nft ruleset
https://bugzilla.netfilter.org/show_bug.cgi?id=1130 --- Comment #2 from Pablo Neira Ayuso <pablo at netfilter.org> --- (In reply to Pablo Neira Ayuso from comment #1)> If you're seeking to improve human readability, then I'd suggest you use > variable definitions, eg. > > define yahoo = { 98.139.183.24, 98.138.253.109, 206.190.36.45 }You can keep autogenerate these via script, keep it in a separated file and include this file, eg. $ cat namebase.nft define yahoo = { 98.139.183.24, 98.138.253.109, 206.190.36.45 } ... $ cat ruleset.nft include "namebase.nft" add table x add chain x y { type filter hook output priority 0; } add rule x y ip daddr $yahoo drop -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170314/df32046d/attachment.html>
bugzilla-daemon at netfilter.org
2017-Jul-07 10:32 UTC
[Bug 1130] Better handling of DNS names in nft ruleset
https://bugzilla.netfilter.org/show_bug.cgi?id=1130 Pablo Neira Ayuso <pablo at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|ASSIGNED |RESOLVED -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20170707/02d85e4a/attachment.html>
Reasonably Related Threads
- [Bug 1195] New: 'list ruleset' of 'nft -f' outputs garbage while 'nft list ruleset' seems to work.
- [Bug 1118] New: nft: nft -f and nft list ruleset use different sets of service -> port mappings
- [Bug 1349] New: "nft list ruleset" shows rules twice
- [Bug 1450] New: Using certain simple set combinations with TCP flags causes error in mergesort.c from nft list ruleset
- [Bug 1706] New: Nft is slow when loading ruleset with lots of add element calls of different interval maps