BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:32:28Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/690Systematic concurrency testing of named and other BIND 9 tools2023-11-02T16:32:28ZOndřej SurýSystematic concurrency testing of named and other BIND 9 toolsWe should add systematic concurrency testing to our CI, here are some links to get us started:
https://dl.acm.org/citation.cfm?id=1985824
https://www.faculty.ece.vt.edu/chaowang/pubDOC/Wang11HaPSet.pdf
https://insights.sei.cmu.edu/sei...We should add systematic concurrency testing to our CI, here are some links to get us started:
https://dl.acm.org/citation.cfm?id=1985824
https://www.faculty.ece.vt.edu/chaowang/pubDOC/Wang11HaPSet.pdf
https://insights.sei.cmu.edu/sei_blog/2014/10/thread-safety-analysis-in-c-and-c.html
http://diy.inria.fr + http://diy.inria.fr/linux/
http://www.1024cores.net/home/relacy-race-detector
And on Windows:
https://archive.codeplex.com/?p=chesstool
https://pdfs.semanticscholar.org/186e/82657c803bf9f5f58be4d6ff17d1420dbbeb.pdfNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/689dig: fix behavior for -6 used with IPv4-mapped IPv6 addresses2023-11-02T16:32:27ZMichał Kępieńdig: fix behavior for -6 used with IPv4-mapped IPv6 addressesThis is a spin-off from !755. Over there, @each [said][1]:
> If "dig -6" is used but only v4 addresses are in resolv.conf, I would have expected it to use v4-mapped addresses instead of giving up -- that's what it does if an ipv4 addre...This is a spin-off from !755. Over there, @each [said][1]:
> If "dig -6" is used but only v4 addresses are in resolv.conf, I would have expected it to use v4-mapped addresses instead of giving up -- that's what it does if an ipv4 address is specified on the command line with the -6 flag.
To which I [replied][2]:
> What does _not_ make sense to me, though (...), is why we attempt using IPv4-mapped IPv6 addresses when `-6` was specified. Apparently we have been doing this for the past 17 years (since da5795a32a5b28fc8afd59e4887e19ec1252d0d0). I personally find this very confusing. The man page for `dig` says:
>
> ```
> -6
> Use IPv6 only.
> ```
> To me, this means: "`dig` will only communicate using IPv6". But if you use `-6` in conjunction with an IPv4 address, it **will** use IPv4 to send the query. After all, IPv4-mapped IPv6 addresses are not some kind of an IPv6 transition mechanism but merely a way of storing an IPv4 address in an `AF_INET6` socket structure. To me, this looks as if `dig` fails to deliver on its promise not to use IPv4. What is the use case for doing this?
The way I read it, @ondrej [agreed][3] with me:
> I think this is wrong. If -6 is specified I would expect dig to use only IPv6 to communicate with the outside.
Given the above, I propose to, at minimum, change the default in `dig` from `+mapped` to `+nomapped`, the rationale being that `dig` should not implicitly use IPv4 if `-6` was explicitly specified, but it is okay to allow the user to keep using this quirk if it is explicitly requested by passing `+mapped` on the command line.
The somewhat more extreme version of this change would treat command lines in the likes of `dig -6 @192.0.2.1` (or, correspondingly, `dig -6 @::ffff:192.0.2.1`) as errors, i.e. we would completely remove the `+[no]mapped` option, causing `-6` to become a more strict limit.
Any thoughts on this are welcome.
[1]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_21896
[2]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_21997
[3]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_22998Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/661rich configuration API2023-11-02T16:32:27ZPetr Špačekpspacek@isc.orgrich configuration API### Description
BIND is hard to configure from outside using APIs, especially when it comes to reading configuration back. It is of course possible to always generate full config file from scratch and restart named process but it has so...### Description
BIND is hard to configure from outside using APIs, especially when it comes to reading configuration back. It is of course possible to always generate full config file from scratch and restart named process but it has some drawbacks:
- previous configuration which requires modification must be stored elsewhere (because named.conf is hard to parse from outside)
- it makes combining manual tweaking in config with automation becomes harder than necessary
### Request
In general I suggest to provide an configuration API which allows user to tweak running instance, and very importantly, also obtain configuration from the running instance. It would make life much easier for people who want to manage BIND using external tools.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/657Add a seatbelt to IDN2023-11-02T16:32:27ZOndřej SurýAdd a seatbelt to IDNFrom paf on dns-operations:
> Please please please do check what happens when you have bidirectional strings before you decide that having U-LABEL output be the default.
>
> I am the conservative kind that am so nervous over these kind...From paf on dns-operations:
> Please please please do check what happens when you have bidirectional strings before you decide that having U-LABEL output be the default.
>
> I am the conservative kind that am so nervous over these kind of things that I would say "let the user turn on IDN output if the user know what the user is doing".
>
> You might require LOCALE processing, and get different result depending on the shell you use, so "just" look at whether the output is a TTY is something that I think is not enough.
>
> So be careful, and do proper QA, by at least reaching out to people having different directionality by default.
> For bidi issues, please look for example on these old blog posts of mine:
>
> https://stupid.domain.name/node/681
> https://stupid.domain.name/node/682
> https://stupid.domain.name/node/683
>
> You might at least make your code more stable. Add a seatbelt...Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/598Wishlist: statistics for DNS-over-TCP and TLS2024-02-29T16:01:45ZTony FinchWishlist: statistics for DNS-over-TCP and TLSA couple of suggestions:
1. For DNS-over-TLS using a proxy, it would be nice to have separate statistics counters from queries that came from the proxy. When the TLS proxy is running on the same server, it would be enough to have sepa...A couple of suggestions:
1. For DNS-over-TLS using a proxy, it would be nice to have separate statistics counters from queries that came from the proxy. When the TLS proxy is running on the same server, it would be enough to have separate counters when the client address is in the interface list that BIND keeps track of. Is this generally useful enough to be worthwhile?
2. For DNS-over-TCP (and by implication, DNS-over-TLS) it would be helpful to have some guide to setting TCP idle timeouts. Two things would help:
* include the connection age in the query log - useful for later analysis, but no good if query logging needs to be left off
* keep an overall histogram of connection age - I don't know of any smaller summary statistics that would be useful, because the distribution of queries is very skewedBIND 9.19.xAydın MercanAydın Mercanhttps://gitlab.isc.org/isc-projects/bind9/-/issues/595Exceeding transfers-per-ns quota aborts zone refresh2023-11-02T16:32:27ZGhost UserExceeding transfers-per-ns quota aborts zone refresh### Summary
A zone transfer abandoned because the selected master host's `transfers-per-ns` quota is reached cancels the whole refresh activity for the zone even when alternative master hosts are configured and below quota.
This causes...### Summary
A zone transfer abandoned because the selected master host's `transfers-per-ns` quota is reached cancels the whole refresh activity for the zone even when alternative master hosts are configured and below quota.
This causes updates to be unnecessarily delayed; another refresh will not occur until the zone's refresh timer expires or another NOTIFY message is received.
The effect of this is that just one slow master host effectively torpedoes overall zone-transfer latency even when lots of other master servers are available to use. A slow master which holds its zone transfer sessions open longer than usual causing it to reach its quota kills off the refresh activities for all zones that it's named's currently preferred master for.
### Steps to reproduce
Use the likes of `tc` on a slave host to slow TCP sessions to its first-listed master host to the point where the number of concurrent TCP transfer sessions exceeds the `transfers-per-ns` limit. Observe that slave hosts abort refresh activities for zones due to `transfers-per-ns` quota without trying the other master hosts.
### What is the current *bug* behavior?
Exceeding the `transfers-per-ns` quota for one master aborts the refresh activity for the zone, not just the transfer from the over-quota master.
### What is the expected *correct* behavior?
If there are other masters for the zone, they are below their own `transfers-per-ns` quota, and the global `transfers-in` quota is not exceeded, the alternative masters should be used.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/593Follow-up from "WIP: Miscellaneous style fixes - implicit casts to bool and u...2018-10-13T05:36:44ZOndřej SurýFollow-up from "WIP: Miscellaneous style fixes - implicit casts to bool and uninitialized variables fixes"The following discussion from !851 should be addressed:
- [ ] @ondrej commented on a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/851#note_24017): (+3 comments)
> This makes me little bit worried about the...The following discussion from !851 should be addressed:
- [ ] @ondrej commented on a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/851#note_24017): (+3 comments)
> This makes me little bit worried about the tests we have. No test has caught this, so we should probably make an issue from this, so there's a test.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/497[ISC-support #13383] Add RRset size-limiting option to protect masters from r...2024-02-20T10:59:13ZCathy Almond[ISC-support #13383] Add RRset size-limiting option to protect masters from rogue dynamic updates and slaves from damaging IXFR/AXFRsBased on https://support.isc.org/Ticket/Display.html?id=13383
The issue is that although the DNS protocol does not restrict how many RRs can exist in a single RRset, once the number of RRs becomes significantly large, both dynamic updat...Based on https://support.isc.org/Ticket/Display.html?id=13383
The issue is that although the DNS protocol does not restrict how many RRs can exist in a single RRset, once the number of RRs becomes significantly large, both dynamic updates and inbound IXFRs become highly CPU-intensive and performance degrading. Encountering oversized RRsets in a production environment is almost certainly the result of a rogue client or poorly-considered configuration/design, but the outcome for any DNS servers having to maintain oversized RRsets can be a significantly degraded performance.
(This scenario is similar to the one that led to the introduction of BIND option max-rrset which protects servers that are hosting zones provided by 3rd parties from being overwhelmed unexpectedly by a zone that unexpectedly becomes of significant size - more than the hosting server can handle).
---
Some more background information to the case leading to this request is that it was observed in a zone that has an RRset consisting of 4K RRs of type A for the same hostname, that adding a new RR with a different TTL can take in excess of several seconds and the task performing the update consumes a significant amount of CPU doing so.
The reason why adding an additional RR causes so much internal zone maintenance activity is complex, but it is directly due to the TTL change and what this implies for maintenance of the .jnl file (used both to satisfy outbound IXFR requests, and for rolling forward/loading the zone locally, in case of an unexpected interrupt of named (a normal rndc stop will write the current version of the zone to disk, but a sigterm or crash won't - although see option flush-zones-on-shutdown which defaults to "no" that can influence this).
When the TTL of one of the RRset changes, it results in all of the other RRs in the set having to be updated to adopt the new TTL at the same time (a difference in TTL between the members of the same RRset is not permitted). Although the TTL is stored on a per-RRset basis internal to BIND, this is, unfortunately, not the end of the story. When the RRset is being updated, named has to generate the set of zone content changes for the .jnl file - and it's here that this becomes, not a single RR add, but the deletion of 4K RRs and the addition of 4K+1 RRs. And this is what drives named doing exactly this when it adds this new RRset itself to its zone.
However, this gets worse (and this next part explains why the maintenance of large RRsets increases exponentially rather than linearly). When you add a RR to a pre-existing RRset, in order to prevent duplicates, for each 'add' named has to check the new candidate against all of the other RRs already in the set. So, when adding the 200th, we have to check it against 199 others, but for the 4001th, it's checking against 4000 others.
Yes, potentially we could optimise this internally for the single case where we know we've checked the one RR that we're adding, on the basis that we know the only reason we're doing 4K deletes and adds is to change the TTL on the whole lot, but that really we're just adding one new RR. But that is not going to help a slave server receiving an IXFR of the same update, and it's not going to help this server if it needs to reload/replay the zone update from the .jnl file if it gets interrupted.
So similarly, just accepting an IXFR for a zone with 4K+ new RRs to be added to a single RRset is also going to impact named, irrespective of the TTLs on those RRs. (Basically, oversized RRsets are bad news for a server that is properly checking the contents of zones that it is loading/updating).
---
Therefore, going back to the request for a new option... it's clearly bordering on insane to have RRsets of this size - DNS certainly wasn't designed to handle them (think of the query responses and the clients!) and BIND certainly wasn't optimised internally for this extreme scenario. Therefore, please could we have a new option (with sane defaults on a per-RTYPE basis) to prevent accidental craziness that degrades performance.
Something like:
max-rrset [rrtype] integer;
(Defaults to be discussed... but they're potentially going to be different for PTR vs other RTYPEs).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/459[RT 39964] logging of NXDOMAIN query-responses (response source and type)2024-03-13T13:46:50ZVicky Riskvicky@isc.org[RT 39964] logging of NXDOMAIN query-responses (response source and type)Edited/compressed from the original in classic bugs-RT
for analyzing queries resulting in NXDOMAIN responses...
Please add the following to normal query log:
a) what kind of answer was given (nxrrset, rrset (how many) or servfail)
b) w...Edited/compressed from the original in classic bugs-RT
for analyzing queries resulting in NXDOMAIN responses...
Please add the following to normal query log:
a) what kind of answer was given (nxrrset, rrset (how many) or servfail)
b) where did the answer came from (authorative, from cache or was it the result of a recursive search)
The actual content of the answer is not needed outside some very special debug-cases and for these cases you have to do a complete network trace anyway.
spawned from #39253: dnstap wish-list: Query log limited by zone/domain & Answer logging
Reference to https://support.isc.org/Ticket/Display.html?id=8385 added
----
* This is response, not query information
<from Ray>
NB: recording these either means two separate log entries (one for query, one for response) or if they're merged that the query log will now be in response order rather than request order.
------
This request is for 'normal' query logging, but many have asked for this via **dnstap** as well. We would love to get this in dnstap if that is possible, realizing there is a standards/schema issue with dnstap.
------
Tagging with 9.13.3 because we would really like to try for this in 9.14.0. This is a fairly long standing and frequently-heard request.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/421Add support-status command to rndc2021-10-15T22:01:55ZOndřej SurýAdd support-status command to rndcWhile reading https://www.ubuntu.com/info/release-end-of-life I came to an idea that it would be a good to have a `rndc support-status` command that would print the support status of the current version and the current release branch.
A...While reading https://www.ubuntu.com/info/release-end-of-life I came to an idea that it would be a good to have a `rndc support-status` command that would print the support status of the current version and the current release branch.
As it doesn't get automatically executed, it could easily just call home to ask.
@vicky @cathya What do you think?Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/352Refactored RPZ has a scalability design problem2021-10-04T12:50:35ZGhost UserRefactored RPZ has a scalability design problem(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default u...(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default update rate plus the fact that RPZ does a full iteration of the DB will not work for them as their data is not latency tolerant and their policy zones are large.
There was a separate bug ticket by a popular reporter from another ISC customer in the last 1-2 months that asked whether this 60s update time could be improved to match the old RPZ behavior.
I feel this can be addressed. BIND RPZ would need to hook not just into `dns_db_updatenotify_register()`, but also into a `newdbversion` signal and every `add` and `del` update to the DB. Note that the RPZ view summary datastructure is still not versioned, so RPZ code would have to separately batch and keep aside a copy of the update diffs until the DB version commit passes, and then apply just the diffs to the RPZ view summary data structure instead of iterating the zone. I think versioning the view summary datastructure would be too much work and complicate the structure.. as long as the diff is applied to it after the DB version commit passes, there should be no problem of inconsistent data.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/349Set __attribute__((warn_unused_result)) on all function that return values to...2018-08-30T19:28:06ZMark AndrewsSet __attribute__((warn_unused_result)) on all function that return values to catch unused results.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/211Feature Request to Allow Dynamic Addition/Removal of Forwarders (similar to r...2024-02-14T14:23:14ZCathy AlmondFeature Request to Allow Dynamic Addition/Removal of Forwarders (similar to rndc addzone)[ISC-support #12719]
Originally submitted to BUGs as https://bugs.isc.org/Ticket/Display.html?id=35890
An ISC Support customer expressed surprise at the failure, after trying, and failing (but with side-effects) to add a zone of type "forward" using rndc a...
Originally submitted to BUGs as https://bugs.isc.org/Ticket/Display.html?id=35890
An ISC Support customer expressed surprise at the failure, after trying, and failing (but with side-effects) to add a zone of type "forward" using rndc addzone.
Per discussion with engineering at the time, addzone isn't intended to support addition of zone type forward AND forward zones aren't really traditionally zone-like so it does not work. The ARM is/was incorrect to suggest that it does.
Further information around this is available on bind-users:
https://lists.isc.org/pipermail/bind-users/2016-November/098007.html
This feature is still wished-for.
Also
'"rndc addzone" does not handle zones of all types which can be defined
in named.conf. this is intended, but not documented in the ARM or elsewhere.
It would be good if the behavior were documented and clear error messages
were emitted when a zone of the wrong type was attempted'
From [Support ticket #6898](https://support.isc.org/Ticket/Display.html?id=6898)
Also from [Support ticket #12719](https://support.isc.org/Ticket/Display.html?id=12719)
And others have asked too..Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/172rrl tests fail intermittently2023-08-23T12:50:45ZOndřej Surýrrl tests fail intermittentlyWe have one occurrence here:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/5453
```
S:rrl:Mon Mar 19 16:25:54 UTC 2018
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTRANGE:11400 - 11499
I:rrl:0 instead of 50 '192.0.2.8' responses for a*...We have one occurrence here:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/5453
```
S:rrl:Mon Mar 19 16:25:54 UTC 2018
T:rrl:1:A
A:rrl:System test rrl
I:rrl:PORTRANGE:11400 - 11499
I:rrl:0 instead of 50 '192.0.2.8' responses for a*.a9.tld2
I:rrl:60 instead of 10 dropped responses for a*.a9.tld2
I:rrl:0 instead of 50 NOERROR responses for a*.a9.tld2
I:rrl:exit status: 1
R:rrl:FAIL
E:rrl:Mon Mar 19 16:26:13 UTC 2018
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/107[RT#45306] RNDC & Views2018-02-23T20:23:34ZVicky Riskvicky@isc.org[RT#45306] RNDC & ViewsIt would be useful if rndc treated views as first-class objects.
Its command syntax has the [view] last, so while several commands act
on "all" when no target is specified, you can't say "all in this view".
There are a number of cases...It would be useful if rndc treated views as first-class objects.
Its command syntax has the [view] last, so while several commands act
on "all" when no target is specified, you can't say "all in this view".
There are a number of cases where one would like to do things to
all zones in a view.
The immediate example is this:
rndc freeze/thaw have the syntax:
freeze [zone [class [view]]]
thaw [zone [class [view]]]
I'm in the unfortunate situation of having to do a bulk renumbering
of a view that contains a lot (well, for me) of zones..., and I need
to do an atomic update, while not freezing other views.
For the next round, it would be useful to have something like:
rndc freeze -view internal # Freeze all zones in the "internal" view
...
rndc thaw -view internal
Other cases where a view as a whole seems to be a sensible target:
rndc flush
rndc notify
rndc refresh
rndc reload
rndc retransfer
rndc sync
Thanks.
--
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Download smime.p7s
application/pkcs7-signature 4.4KiBNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/104[RT#43640] Tool to gather all necessary files to accompany a core dump2018-05-30T23:53:20ZVicky Riskvicky@isc.org[RT#43640] Tool to gather all necessary files to accompany a core dumpWhen customers or others report a crash to us, they often don't understand what we need to be able to analyze the coredump file.
Evan said 'it would be cool to be able to run a tool that collects all the necessary file and tars them up ...When customers or others report a crash to us, they often don't understand what we need to be able to analyze the coredump file.
Evan said 'it would be cool to be able to run a tool that collects all the necessary file and tars them up ready to be submitted'.
Such a tool would need to be able to identify the binary from the core dump (or, optionally be told which is is), run ldd against the binary, collect all the libs, collect the debug symbols/package if these are separate and so on.
(There may be some contributed scripts around that are more generic we could use as the basis for this?)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/102[RT#43428] Silence some 'expected' logging messages2018-02-23T19:57:38ZVicky Riskvicky@isc.org[RT#43428] Silence some 'expected' logging messagesThe user is a high volume hosting provider.
Under attack scenarios, the amount of logging BIND is doing can make a difference.
This user would like to be able to silence some sorts of frequently-recurring messages that are 'expected', ...The user is a high volume hosting provider.
Under attack scenarios, the amount of logging BIND is doing can make a difference.
This user would like to be able to silence some sorts of frequently-recurring messages that are 'expected', because they are basically probing behavior from prospective attackers. An example would be an unsuccessful AXFR from a client that is not permitted to AXFR.
things that would ideally be logged at a higher level:
- Successful AXFR
- Terminated AXFR
- Unsuccessful AXFR from an authorized clientNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/85Automatic database filename generation2021-08-25T15:37:12ZRay BellisAutomatic database filename generationNSD has the ability to automatically generate a zone's filename based on a template string, instead of requiring them to be specified within each zone's configuration:
```
%s is replaced with the zone name.
...NSD has the ability to automatically generate a zone's filename based on a template string, instead of requiring them to be specified within each zone's configuration:
```
%s is replaced with the zone name.
%1 is replaced with the first character of the zone name.
%2 is replaced with the second character of the zone name.
%3 is replaced with the third character of the zone name.
%z is replaced with the toplevel domain name of the zone.
%y is replaced with the next label under the toplevel domain.
%x is replaced with the next-next label under the toplevel
domain.
```
It would be useful if BIND has a similar feature. This would also work well with Catalog Zones, where it is not expected that the Catalog Zone itself would hold the filename, but where the secondary server would synthesise a filename for itself.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/74Encrypt/ pseudonymize IP addresses in log files2018-02-21T18:11:16ZVicky Riskvicky@isc.orgEncrypt/ pseudonymize IP addresses in log filesUsers who need to store log files wish to minimize the possibility of leaking information that easily identifies users. Applying some encrpyption to obfuscate addresses provides some protection. There are several use cases:
1) With the ...Users who need to store log files wish to minimize the possibility of leaking information that easily identifies users. Applying some encrpyption to obfuscate addresses provides some protection. There are several use cases:
1) With the advent of GDPR, operators of public dns services (e.g. ISP resolvers) may require the ability to encrypt these logs as they are created, so the only stored data they have is at least anonymized. If the logs are leaked somehow, it will at least require some effort to de-anonymize them. These operators may need to be able to decrypt to uncover the original IP address, in case their analysis shows abuse that they need to block.
2) Operators of root servers, ccTLDs, gTLDs and other public services may wish to be able to share data for research purposes (e.g. with DNS-OARC's ditl program). In this case, it is preferable that the encryption not be reversible, and it is desirable to be able to run the encryption on an existing log file. This use case is already under discussion in RSSAC.
* It would be ideal to be able to apply this pseudonymization to both native BIND logs and dnstap log files.
* Performance is obviously an important consideration.
* This will need to work for both IPv4 and IPv6 addresses and the result fit into the space in the logs reserved for those addresses (which are obviously different lengths).
Relevant existing work:
* Bert Hubert has created a tool, 'ipcipher' `https://powerdns.org/ipcipher/` for Power DNS. He gave a presentation at NDSS DNS Privacy Workshop that described some of the issues with implementing this. Others have created additional implementations, including one by Frank Denis in C.
* There is also apparently a NIST standard for format-preserving encryption. (Paul Hoffman knows about this)
Other things that are needed:
* Tool you can pipe an existing pcap through that will produce a log file where IP addresses are encrypted (producing output that is irreversible)
* Utility that enables frequent key rotation for this processNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/53Implement "NXDOMAIN cut" (RFC 8020)2023-11-02T16:32:26ZStéphane BortzmeyerImplement "NXDOMAIN cut" (RFC 8020)BIND has "NSEC aggressive caching" (NSEC-only, see #50) but this requires DNSSEC. For non-DNSSEC zones, "NXDOMAIN cut" could be interesting (RFC 8020).
It is already implemented in Unbound (option "harden-below-nxdomain:")
[Is there a ...BIND has "NSEC aggressive caching" (NSEC-only, see #50) but this requires DNSSEC. For non-DNSSEC zones, "NXDOMAIN cut" could be interesting (RFC 8020).
It is already implemented in Unbound (option "harden-below-nxdomain:")
[Is there a tag "Resolver"? This could be useful for resolver-only features.]Not planned