Re: How to fix a hand-edited dynamic zone?
William_D. Colburn wrote: > > What I want to know now: is there a better solution to that problem than > what I did? Better practices for fixing that which I could have followed? I think recovering from a secondary copy is about the best you can do. The zone file and journal are no longer consistent with each other, but the tools expect and require them to be consistent. There's an exception: named-journalprint looks at the journal only, not the zone file, so it doesn't require them to be consistent. So you can recover by using named-journalprint to get a human-readable list of changes to the zone, manually apply them to the zone file, then delete the journal and restart `named`. This is much more tedious and error-prone than a zone transfer, but it's an option to keep in mind in case you get into more serious trouble. To avoid the problem in the future, you can make this mistake less likely by changing the masterfile-format to "raw", so that if anyone tries to load the file into an editor they will be confronted by gibberish, and hopefully (!) look for documentation that explains the right way to modify the zone. My primary server has raw dynamic zones, and I use `nsvi` to edit dynamic zones in place, or `nspatch` to update a live zone from a file stored in version control. https://dotat.at/prog/nsdiff/ -- Tony Finch(he/they) Cambridge, England Southeast Iceland: Southwesterly severe gale 9 to violent storm 11, becoming cyclonic 6 to gale 8 later. High or very high, becoming mainly very rough later. Rain. Moderate or poor. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is there an rndc command to get the list of configured zones?
Klaus Darilion via bind-users wrote: > I checked all options of rndc to get the list of zones configured/served by > bind - but I can't find any. > Is it really not possible to get this list from a running Bind process? The statistics channel is your friend when rndc lets you down. Below I have pasted a wee script I have lying around, or you might like JP Mens' bzl program https://github.com/jpmens/bzl https://jpmens.net/2010/10/21/using-binds-statistics-server-to-list-zones-and-axfr-the-list/ #!/bin/sh case $# in (1) ;; (*) echo 1>&2 'usage: lszones [:port]' exit 1 esac curl -Ssf http://$1/json | jq '.views | to_entries | .[] | .key as $view | .value.zones[] | "\($view) \(.type) \(.serial) \(.name)" ' -- Tony Finch(he/they) Cambridge, England Fair Isle, Faeroes: South or southwest 5 to 7. Moderate, occasionally slight, becoming moderate or rough. Occasional rain and fog patches, showers later in Faeroes. Moderate or good, occasionally very poor. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: isc python module
BÖSCH Christian wrote: > "White, Peter" wrote: > > > > I don’t mean to hijack the thread, but I think this is related. I also > > use the BIND python modules. In particular, I'm using it to update my > > catalog zones as described here: https://kb.isc.org/docs/aa-01401 > > Yes, I'm using that too and wondering how to do that in 9.18 without the > isc module and in near future without the rndc protocol. Instead of the isc.rndc module, you can use the subprocess module to invoke the rndc command. The RNDC protocol is not going away and it is not likely to change any time soon, so the old isc.rndc module should continue to work. But it's easier to use the command line program. -- Tony Finch(he/they) Cambridge, England Berwick upon Tweed to Whitby: North 4 to 6. Slight or moderate, occasionally rough for a time. Showers, perhaps thundery, becoming fair later. Good, occasionally poor.-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delete/update MX record
@lbutlr wrote: > Using nsupdate when I try to delete an MX record for a domain, I get > REFSUED. > > When I try to add an MX record with the same priority (or not), it > leaves the old record as well. > > How do I remove and replace the MX record for a domain with nsupdate? The UPDATE protocol will not tell the client why it didn't work; for that you must check `named`s logs. In general, with UPDATE it's best to delete then add records for a name, using a single UPDATE transaction to avoid any point in time where the name is missing. The comments in nsdiff say: # For each owner name prepare deletion commands followed by addition # commands. This ensures TTL adjustments and CNAME/other replacements # are handled correctly. Ensure each owner's changes are not split below. There's are a couple of cases where this doesn't work: the SOA and NS RRsets. For SOA, you can just add the new record which implicitly replaces the old one. For NS records, in my experience complete replacement is rare enough that it's OK to simply nspatch the zone twice. (The NS delete will be ignored instead of rejected.) -- Tony Finch(he/they) Cambridge, England Shetland Isles: Variable 3 or less, becoming north or northeast 3 or 4 later. Slight, but smooth in southeast. Mainly fair. Good. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Primary zone not fully maintained by BIND
Sandro wrote: > > I was notified this morning by my registrar, that validation of my zone > records failed. Upon inspection, it turned out that only the SOA record was > still up to date. A and MX al returned RRSIG expired. Yuck, that's painful. > Since I want to avoid this happening again, I would like to understand what > went wrong. The place I would look first is the log messages from `named`: is it complaining about anything? One of the things I have to take care with (because I have got it wrong several times!) is filesystem permissions: can `named` read the .private keys? can it read and write to the zone files? can it read and write to the directories containing the keys and the zone files? -- Tony Finch(he/they) Cambridge, England Rattray Head to Berwick upon Tweed: Variable, mainly south, 2 to 4, becoming northwest 4 or 5, occasionally 6 later. Slight, occasionally smooth in south, becoming slight or moderate later in north. Showers, perhaps thundery at first. Good, occasionally poor at first. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Correct response to NS request in case of dual delegation when one delegation returns REFUSED
Ondřej Surý wrote: > > > 1) client asks Bind: what is NS for "cluster"? > > 2) Bind seems to issue requests to both "storage1" and "storage2" for "NS > > cluster", one of which always returns "REFUSED" > > 3) Answer of Bind to client does not contain the one that was "refused". > > no, I think it’s different problem. > > Both storage1 and storage2 need to return the full set of NS for the > cluster query because the NS set from child zone will override the > delegation from the parent. And, Marki, if you need a pointer to where this behaviour is specified, look at https://www.rfc-editor.org/rfc/rfc2181#section-5.4.1 In particular, + The authoritative data included in the answer section of an authoritative reply. In your case this is the single-record NS answer from one of the clusters, and it outranks: + Additional information from an authoritative answer, Data from the authority section of a non-authoritative answer, Additional information from non-authoritative answers. In your case this is the two-record NS in the referral from your parent zone. If these devices allow you to configure DNS servers for readiness checks separately from general-purpose DNS, then you might be able to work around the problem by pointing the readiness checks at an authoritative-only server, if the devices are willing to find their answer in the AUTHORITY section of the response. If. Maybe. -- Tony Finch(he/they) Cambridge, England Trafalgar: In southeast, northerly, but easterly in far southeast, 4 to 6, increasing 7, perhaps gale 8 later, near gibraltar strait. In northwest, variable 2 to 4, becoming northerly 5 later in southeast. In southeast, moderate, occasionally rough. in northwest, rough becoming moderate. In southeast, fair. In northwest, showers later. In southeast, good. In northwest, good.-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fwd: Request to use "Canonical/Mirror"
Greg Choules wrote: > > IMHO the terms "primary" and "secondary" are just as meaningful as the > terms "master" and "slave", but without the emotional and historical > baggage. I think "master" and "slave" is actively misleading, because the DNS protocol does not allow a master to tell a slave to do anything. (The closest is NOTIFY which is a hint not a command.) > You just have to give yourself time to get used to them. Indeed :-) -- Tony Finch(he/they) Cambridge, England Fitzroy, Sole: South or southwest, 4 to 6, occasionally 7 later in west. Rough or very rough. Showers. Good. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "Length"-output in DNSSEC-Policy state-files vs. "Key Length"-output on dnsviz.net
Tom wrote: > I'm wondering about the value of the "Length"-field in the dnssec-policy > state-file output, which results in "Length: 256" for domains, which are > signed with algorithm 13 (ECDSAP256SHA256) That's the size of the cryptographic modulus, i.e. the size of the numbers in the guts of the cryptographic algorithm. > and the "Key length"-output for the domain on "dnsviz.net" (ZSK or KSK), > which results in "Key Length: 512". For P-256 the public key needs two coordinates to identify the point on the curve, so it's twice the nominal size of the algorithm. DNSviz is not being entirely consistent here, because RSA public keys also require a few more bits than their nominal size (for the public exponent), but DNSviz shows their nominal size rather than the size of the public key blob in the DNSKEY record. (The public exponent is usually 65537, which is why RSA keys typically start AwEAA rather than being completely random.) -- Tony Finch(he/they) Cambridge, England Trafalgar: Northerly or northeasterly 3 to 5, but easterly 5 to 7 in far southeast. Slight or moderate, occasionally rough later in north. Fair. Good. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Determining Which Authoritative Sever to Use
Bob McDonald wrote: > > My question is this; how do the recursive servers determine from > the information in the stub zone which name server to query? As well as what Bob Croswell said about SRTT (which is entirely correct), there's a subtlety with stub zones in particular. A stub zone works a bit like the root zone hints, in that the name servers that you configure are just used to find the zone's NS records. This means that stub zones don't override where queries are routed for these zones. If you want your resolver to ignore the NS records on your internal zones, you should use static-stub instead. Regarding anycast, it isn't necessary for internal authoritative servers unless your organization is really huge (and probably not even then): it is simpler to just use the DNS's standard reliabilty features. All you need to do is have more than one authoritative server for each zone. On the other hand, anycast is a good way to improve the availability and maintainability of your resolvers, because your users' devices talk directly to them, and if they don't work there might as well not be an Internet connection. -- Tony Finch(he/they) Cambridge, England Selsey Bill to Lyme Regis: East or southeast, veering south later, 2 to 4. Smooth or slight, occasionally moderate for a time offshore. Fair. Good. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Transitioning to new algorithm for DNSSEC
frank picabia wrote: > On Thu, May 5, 2022 at 1:46 PM wrote: > > > > Tony wrote a nice article about that: > > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html > > Thanks for that. My problem is these notes have little in common with how > the digital ocean guide > ran it ( > https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server-2 > ), That guide is sadly very out of date. You really don't want to use SHA1 (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html) and for at least 10 years it has been much easier to use `named`s automatic signing than to use dnssec-signzone. I think if you are still using `dnssec-signzone`, I would recommend switching over to automatic signing with your existing keys, before doing an algorithm rollover. And set up a test zone so that you can run through the process a few times, so that you can learn from your mistakes before doing it in production. > and I don't think our domain registrar supports CDS records. You can ignore the CDS stuff - my registrar didn't support it either, but I have tools that can use my CDS records to work out the correct thing to tell my registrar to do. > I don't understand how people can run little rndc commands as if this > sticks without putting an include for the keys in the zone file. `named` automatically adds the keys to the zone according to the timing information in the key files. (At least, that's the way I did it before dnssec-policy made things even more automatic.) -- Tony Finch(he/they) Cambridge, England Trafalgar: Northerly or northeasterly 4 or 5, occasionally 3 in far southeast. Moderate, but slight in far southeast. Fair. Good. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
Timothe Litt wrote: > On 02-May-22 09:02, Stephane Bortzmeyer wrote: > > Fun is a sufficient reason. > > I would never discourage anyone from having (harmless) fun. > > On the other hand, unless your codes postaux are spherical (or a circular > projection), your LOC will be at best an approximation of a point in the > postal zone. At my previous job there used to be a TXT record at cam.ac.uk saying "The University of Cambridge", which I replaced with a LOC record to avoid interference with things like SPF and domain authentication. It's also used as a test record by the keepalived health check scripts. Cambridge has a residency rule for students that requires them to live within 3 miles of the city centre, so the 10km diameter in the LOC record is in some sense correct and reasonably accurate. cam.ac.uk LOC 52 12 19.000 N 0 7 5.000 E 18.00m 1m 100m 100m -- Tony Finch(he/they) Cambridge, England Lundy, Fastnet, Irish Sea: Variable becoming southwest, 2 to 4. Smooth or slight. Occasional rain or drizzle, fog patches in Irish Sea. Moderate or good, occasionally very poor in Irish Sea. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and forwarding
Duchscher, Dave J via bind-users wrote: > We have an internal DNS server that we would like to forward its > outgoing queries to a main DNS server that connects to the outside world > and is doing DNSSEC validation. The problem is that the DNSSEC > validation doesn't work for queries from the internal DNS server. > Doing DNSSEC validation on the internal DNS server that is forwarding to > the main DNS server has been problematic with some domain failing > intermittently and others just not working at all. Is there a way to > allow the main DNS server handle DNSSEC validation? In this situation, with multiple tiers of caches, if you want DNSSEC validation, you should turn it on everywhere you can. It sounds to me like your outer server has somehow got data in its cache that can't be validated by the inner server (though I'm not entirely sure how that might happen). If they both validate then I would expect the problems to go away. -- Tony Finch(he/they) Cambridge, England Rockall, Malin, Hebrides: North or northeast 4 to 6, occasionally 7 at first. Moderate or rough. Wintry showers. Good, occasionally poor. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using nsupdate in scripts
Philip Prindeville wrote: > > I'm operating on a residential ILEC that hasn't deployed IPv6, so > turning off IPv6 isn't "self-harm", it's what cyber security > professionals refer to as "reducing attack surface". Sorry, that was unkind of me, and it's a topic I should not be sarcastic about. It isn't clear to me exactly how configurable or hardcoded your script needs to be. If you know it will always run in a v4-only environment, or in either v4-only or dual-stack environments, you might as well hardcode -4 -l and you'll only need to change it if you have a v6-only deployment. -- Tony Finch(he/they) Cambridge, England Dover, Wight, Portland, Plymouth: Cyclonic 2 to 4 at first except in Plymouth, otherwise northwest 4 to 6, becoming variable 2 to 4 later. In Plymouth, rough or very rough, becoming moderate or rough, elsewhere slight or moderate. Rain at first. Good, occasionally poor at first. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using nsupdate in scripts
Philip Prindeville wrote:
>
> But I've noticed that since I added the following to my options { }:
>
> allow-transfer { none; };
> dnssec-validation auto;
> listen-on-v6 { none; } ;
>
> That I get a *lot* of lines like:
>
> ; Communication with ::1#53 failed: connection refused
"Doctor it hurts when I do this!"
When you use `nsupdate -l` you are using a hard-coded configuration, that
uses a compiled-in path to the session key and fixed IPv4 and IPv6
localhost addresses.
If that doesn't fit your setup then you need to adjust the command-line
options for `nsupdate`.
I think for your purposes it would be best to add an environment variable
for the nsupdate options, so that the admin can set the variable to
contain different options if bare -l doesn't fit their needs. So if in
some fit of self-harm they have turned off IPv6, they can add -4 to the
variable, or they can get more creative with the -k option. (Sadly you
have to set the server address in the update script, not on the command
line.)
--
Tony Finch(he/they) Cambridge, England
Rockall: West or southwest 7 to severe gale 9, decreasing 4 to 6
later. Very rough, becoming very rough or high. Rain or showers. Good,
occasionally poor.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NOTAUTH on dynamic update followed by approved update
Hellige, Charles D wrote: > We have been using nsupdate for some time without issue. We recently > started seeing NOTAUTH failures in the named logs followed by successful > adding/deleting messages. The records are getting created but there are > times when we see several (NOTAUTH) errors before we finally get a > successful message. My wild guess is that someone is using a DNS UPDATE client that has a noisy and blundering algorithm for working out which zone it is updating. In a DNS UPDATE message, the first section (corresponding to the question section in a normal DNS query) contains the name of the zone to be updated. If the DNS server is not authoritative for that zone, it returns a NOTAUTH error. And the zone name to be an exact match for the name of the zone apex (its SOA record), no subdomains allowed. > 11-Mar-2022 10:07:19.748 update: info: grn-mid: view GRN: updating zone > 'ops.company.com/IN': update failed: not authoritative for update zone > (NOTAUTH) > 11-Mar-2022 10:07:19.821 update: info: grn-mid: view GRN: updating zone > 'ops.company.com/IN': adding an RR at 'test-09.ops.company.com' A 1.1.1.9 These log messages tell me two (or maybe three) things: first, the NOTAUTH error is provoked by an UPDATE request whose zone is a subdomain of the correct zone. (The zone name in the log message is the closest match, not the name from the request.) And second, the UPDATE was trying to add a record that is not a direct subdomain of the zone apex, it's a sub-sub-domain. (And third, the NOTAUTH log message is probably a bug because it should state the zone name from the request not the closest match in the server configuration.) So it looks like the UPDATE client is searching for the correct zone in a ham-fisted way, by taking the name of the record and stripping off a label each time it gets a NOTAUTH response from the server. By contrast, what `nsupdate` does is make a SOA query for the name of the record it is tryng to update (or the first one, I guess, if there's more than one). If the record is not at a zone apex then the negative response will contain the SOA record for the correct zone in its AUTHORITY section. (PS. you get the prize for my first message to this list with my new email address!) -- Tony Finch(he/they) Cambridge, England Viking, North Utsire, South Utsire: Southerly or southeasterly 5 to 7. Moderate or rough, becoming slight or moderate in South Utsire. Occasional drizzle. Good, occasionally poor. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Capabilities and limitations of catalog zones
John Thurston wrote: > Are we not able to use catalog zones to propagate zone-configuration for > anything other than 'master' zones? It is only for configuring authoritative secondary zones. You are right that this isn't completely clear in the documentation, uless you read the whole section carefully (it is not stated explicitly in the section's introduction). https://bind9.readthedocs.io/en/v9_16_25/advanced.html#catalog-zones Tony. -- f.anthony.n.finchhttps://dotat.at/ Rockall, Malin, Hebrides, Bailey: West, becoming cyclonic, 7 to severe gale 9, occasionally storm 10 except Malin, becoming north or northwest 5 to 7 later. High or very high, occasionally very rough later. Squally wintry showers. Moderate or poor. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation via AD bit?
Gregory Shapiro via bind-users wrote: > > Two questions: Slightly expanding on Mark's answers... > 1. Is there a reason when BIND is running as both a recursive server and > an authoritative server for a domain, it doesn't set the AD bit when > answering resolver queries for one of its authoritative domains? AD means "I validated this" and AA means "I am authoritative for this". In almost all cases, authoritative servers don't validate the zones they serve - as Mark said, it's unnecessary. Because they don't validate it would be wrong to set AD. (But note that BIND's "mirror" zones do validate authoritative zones and the AD/AA bits change accordingly.) > 2. Should sendmail not be trusting the AD bit in replies from the admin > configured (i.e., trusted by admin) resolvers? It's dangerous territory. Sendmail isn't alone: for example, OpenSSH also relies on the AD bit to validate SSHFP records. But using AD is only safe if the validating resolver is running on localhost. Unfortunately the portable subset of the resolver API doesn't allow programs to check their recursive server addresses, so they just have to hope that they have been configured by a careful person. (On a mail server there are also performance reasons for running a local resolver, so I guess you are OK in this respect.) As Mark says, ideally these programs would do their own validation, but to get good performance the program should ideally be able to make concurrent queries for the chain of trust, and once again the standard resolver makes it difficult. Or the program can hope the recursive server is running on localhost so it doesn't matter too much if the queries are serialized. There are workarounds for your AA problem. You might try using mirror zones instead of secondary zones. Or you can ensure that queries for your secondary zones go through a validating resolver. This is a bit like the common pairing of NSD and Unbound on the same server, but with BIND you can do it in one process. The trick is to use two views: one is authoritative-only, and has your secondary zone configurations. The other is recursive-only, but it has static-stub zone configurations for all your secondary zones, pointing at localhost. Then you arrange for these self-queries to be handled by the authoritative view. I have used this setup for a while on my workstation for testing / experimental purposes, but I never put it into serious production because it's too far along the mad science spectrum. Tony. -- f.anthony.n.finchhttps://dotat.at/ Thames: Northwest 7 to severe gale 9, backing west 5 to 7. Slight or moderate in southwest, otherwise rough or very rough, becoming moderate. Rain. Good, occasionally moderate. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.16.25 "file descriptor exceeds limit" messages
Anand Buddhdev wrote: > > The server has many IP addresses. In named.conf, there are 129 IPv6 addresses > in the "listen-on-v6" option and 128 IPv4 addresses in the "listen-on" option. > The server begins running, but then repeatedly emits this log: > > general: error: socket: file descriptor exceeds limit (46474/21000) Hmm, (128+129)*88*2 == 45232, (2 == UDP + TCP) so the big number looks plausible. The 21000 limit comes from a hardcoded value for ISC_SOCKET_MAXSOCKETS. You can adjust -U (number of listeners) on the command line to avoid hitting the fixed MAXSOCKETS limit, and leave -n (max sockets) unset, at its default. You can also set ISC_SOCKET_MAXSOCKETS at build time, if you can work out how to wrangle the build system :-) Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle, Faeroes: Southwest 6 to gale 8, occasionally severe gale 9 in Fair Isle, veering northwest gale 8 to storm 10. Rough or very rough, occasionally moderate at first in southeast Fair Isle, becoming very rough or high. Rain, squally showers later, wintry in Faeroes. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17
Gehrkens.IT GmbH | Heiko Wundram wrote: > > From what I gather, this behaviour sounds almost like what RFC 8020 proposes > (NXDOMAIN cut), but at least according to the corresponding ticket, that > isn't implemented in BIND. The other things that can cause the behaviour you observed are synth-from-dnssec and qname-minimization. It might make sense to forward the whole of .lan and .local to your Windows resolvers, assuming you have one set of servers that knows the whole namespace. Tony. -- f.anthony.n.finchhttps://dotat.at/ Bailey: Northwest 5 or 6, backing southwest 6 to gale 8, perhaps severe gale 9 later. Very rough, becoming rough for a time. Showers, rain later. Good, becoming moderate or poor later. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
egoitz--- via bind-users wrote: > > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 2020220241 > Activate: 2020220341 > Inactive: 20211215230338 > Delete: 20211217230338 Yes, it can be confusing when the state of the key files doesn't match the state of the zone. I think you said you have renamed all your key files back to their usual non-OLD names. Good; that is necessary if named is still looking for a key file even if it shouldn't need it any more. Then, try running `rndc sign `, to make named reload the keys. I think that should also get it to make whatever updates might be necessary. Then look at the logs to see if there are errors, and look at the DNSKEY RRset (with its RRSIGs) to make sure it matches what you expect. If that doesn't get things straightened out then, um, dunno :-) I guess it is possible to get into a muddle if you try to move a key out of the way very soon after its delete time. By default, named does key maintenance infrequently, so I guess if you move the key after its deletion time but before the next key maintenance cycle, things will get out of sync. But I have not checked whether my guess is right or not. Tony. -- f.anthony.n.finchhttps://dotat.at/ St Davids Head to Great Orme Head, including St Georges Channel: Variable 2 to 4. Smooth or slight. Fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best practice for forwarding Dnstap (unix socket) traffic to another address
Fred Morris wrote: > > What I'm looking at is trying to build a BIND kernel, like a nanokernel. Socat > won't work in this case, because because there's no "IPC" layer, because there > is only one process in the kernel. Sounds fun. I think your solution must be to modify BIND's dnstap sender so that it can use a TCP socket as an alternative to a unix domain socket. Tony. -- f.anthony.n.finchhttps://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Southwesterly 3 to 5. Mainly slight or moderate, but smooth or slight in Firth of Clyde. Fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: your mail
Diego Garcia wrote: > > Each 20/30 minutes and lasting about 5 minutes i got 'timeout' in bind > querys. After that time everything works fine again. > > My bind server got response (from 0.1 to 2 seconds) but reply with a ICMP > 'port unreachable'. > > Any idea the problem or what i can check? > > Firewall is off while testing. > > My bind server is a NAT router. It sounds like the NAT is interfering with BIND's resolver. In general, NAT (as well as stateful firewalls) do not work well with the DNS, because UDP port randomization uses a lot of (mostly useless) connection-tracking state. So it's best to put a full service resolver outside a NAT if possible. In your case, I guess there are several possible IP addresses that BIND can use as the query source address. Try setting the query-source option in named.conf to an IP address that's outside the NAT. You will need to use tcpdump to verify that the right packets with the right addresses are appearing on the wire. Tony. -- f.anthony.n.finchhttps://dotat.at/ Portland, Plymouth: Northeast, veering east or southeast, 3 or 4. Slight or moderate, occasionally rough at first in Plymouth. Fog patches at first in south. Moderate or good, occasionally very poor at first in south. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to show run the active configuration on bind
Mik J via bind-users wrote: > How can I check which variables are loaded in memory and considered as active. As Ray said, usually it isn't ambiguous. But there are a couple of semi-relevant tools that are worth knowing about: You can use `named-checkconf -p` to canonicalize your configuration (so you don't have to chase down include files, etc.), plus the -x option strips out secrets (TSIG keys) which is handy for tech support cases. And the statistics channel has loads of details, some of which are config-related. `curl http://SERVER:8053/json/v1 | gron | less` is a good way to get an idea of what it contains. Tony. -- f.anthony.n.finchhttps://dotat.at/ Humber, Thames: Northwest 7 to severe gale 9, decreasing 5 later. Rough or very rough, becoming moderate or rough later. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: transfer-source / notify-source warnings if a port is specified
Duncan wrote: > > Is there any option to suppress warnings if using transfer-source / > notify-source specifying ports ? There are good reasons for these warnings. NOTIFY uses UDP, and source port randomization in UDP is important to protect against spoofing. Spoofing NOTIFY is relatively harmless, but it does create more work for the target server than other requests, so you don't want to make it easy. Zone transfers use TCP. A TCP connection is identified by its 4-tuple: its source and destination addresses and ports. Multiple concurrent TCP connections to the same server require differing source ports, because the rest of the 4-tuple must be the same. If you fix your zone transfer TCP source port, then every zone transfer to your server from its upstream (primary/master) will have the same 4-tuple. This means you will only be able to perform one zone transfer at a time because there can only be one TCP connection at a time with the same 4-tuple. You are also probably going to have an unhappy encounter with the various TCP connection shutdown timers (FIN_WAIT, CLOSE_WAIT, etc.) that prevent successive TCP connections with the same 4-tuple from getting muddled up. So you can suppress the warnings, and avoid the problems they are warning you about, by not specifying the source ports. Tony. -- f.anthony.n.finchhttps://dotat.at/ Southwest Forties, Cromarty, Forth, Tyne, Dogger: Southwesterly 5 to 7, occasionally gale 8 at first except in Cromarty, then decreasing 4 at times. Moderate or rough in southwest Forties and Dogger, but elsewhere slight or moderate. Rain or showers. Good, occasionally poor for a time. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious failures in a dynamically updated to a sub /24 reverse DNS domain P.S.
Mirsad Goran Todorovac wrote: > Please excuse me, as I am a bit confused ... > > I have tried to verify your findings, but I've found something awkward: Something has changed, because earlier I got: ; <<>> DiG 9.10.6 <<>> soa 192/27.186.198.193.in-addr.arpa @193.0.9.6 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25229 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available and now instead I get a referral: ; <<>> DiG 9.10.6 <<>> soa 192/27.186.198.193.in-addr.arpa @193.0.9.6 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26187 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;192/27.186.198.193.in-addr.arpa. INSOA ;; AUTHORITY SECTION: 186.198.193.in-addr.arpa. 14400 IN NS dns1.carnet.hr. 186.198.193.in-addr.arpa. 14400 IN NS dns2.carnet.hr. ;; Query time: 22 msec ;; SERVER: 193.0.9.6#53(193.0.9.6) ;; WHEN: Wed Dec 29 23:35:20 GMT 2021 ;; MSG SIZE rcvd: 107 And the SOA serial number for 198.193.in-addr.arpa has bumped to 2021122901. The actual delegation that was missing was for 186.198.193.in-addr.arpa, not the delegation for your zone 192/27.186.198.193.in-addr.arpa This error was partially hidden because of the shared carnet.hr nameservers. Tony. -- f.anthony.n.finchhttps://dotat.at/ partnership and community in all areas of life ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious failures in a dynamically updated to a sub /24 reverse DNS domain
Mirsad Goran Todorovac wrote: > > I have recently implemented dynamic updates to a sub /24 reverse DNS > domain, 193.198.186.192/27. > I had upstream domain 192/27.186.198.193.in-addr.arpa. delegated from > authoritative servers. > > However, something still isn't right. In some reverse PTR addresses, the > resolver sees first redirection, and the second redirection, but somehow > fails to connect them in a reverse lookup: It looks to me like someone forgot to update the serial number on the zone 198.193.in-addr.arpa so your new delegation failed to propagate as it should have, The servers for 198.193.in-addr.arpa are: dns1.carnet.hr dns2.carnet.hr ns.ripe.net The first two know about the delegation for your zone 192/27.186.198.193.in-addr.arpa but ns.ripe.net does not. This is the cause of the inconsistencies that you observed. The SOA serial number for 198.193.in-addr.arpa is the same 2021052502 on all its nameservers. Tony. -- f.anthony.n.finchhttps://dotat.at/ the market alone does not distribute wealth or income fairly ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
Danilo Godec via bind-users wrote: > > I have an authoritative DNS server for a domain, but I was also going to > use the same server as a recursive DNS for my internal network, limiting > recursion by the IP. Apparently, this is a bad idea that can lead to > cache poisoning... Sort of. It's complicated. Of course DNSSEC can prevent cache poisoning, but there is more to this particular question. In older DNS software (BIND 8 and before) there was not much separation between the recursive cache and authoritative data. It was possible for recursive clients to get data into the cache that could leak into authoritative responses, e.g. glue addresses, and addresses of CNAME or MX targets that pointed out-of-zone. This could lead to cache poisoning of other recursive servers, especially those that trusted additional data too much (before RFC 2181). BIND 9 keeps its authoritative and recursive data more separate. As a user you can see this in the ACL options, allow-recursion, allow-query-cache, etc. It is possible to configure BIND 9 so that remote clients see an authoritative-only view, and local clients have access to a recursive view, but it isn't entirely straightforward. Best practice is still to configure servers that appeaar in NS records to be authoritative-only. Tony. -- f.anthony.n.finchhttps://dotat.at/ Trafalgar: Variable 4 or less, but southerly 5 or 6 in northwest. Moderate or rough in southeast, rough or very rough in northwest. Fog patches. Moderate or good, occasionally very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Millions of './ANY/IN' queries denied
Ondřej Surý wrote: > FTR RRL will not help on this case. There’s no difference between > response with TC and response with REFUSED. Yes and no :-) RRL uses a mixture of "slip" (i.e. truncation) and dropping responses, so it will attenuate REFUSED spam. (The documentatin is not very clear about when it drops, tho...) Tony. -- f.anthony.n.finchhttps://dotat.at/ North Utsire: Variable 4 or less becoming westerly or northwesterly 3 or 4. Moderate. Drizzle. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recommendations for replacing a master server without breaking DNSSEC
Ralph Seichter via bind-users wrote: > > How would you go about moving all functionality from Alpha to Beta, > ideally with minimal downtime, and with the hard requirement of not > breaking DNSSEC? How would one need to handle key material, zone > signatures, journals, etc.? There was this time when we had a hardware failure that took out our primary DNS server. It looked like it was going to take a long time to fix the failure, so I stood up a replacement primary on different hardware, which was relatively quick using our Ansible playbooks. So the new server had a copy of all the relevant secrets (DNSSEC private keys, TSIG keys, ssh keys, ...) installed by Ansible, which meant that the new server's zones would all validate OK. So it was able to rebuild all the zones and sign them from scratch, then take over from the dead server. Using the same keys makes the process much easier than trying to do a key rollover at the same time. Don't make delicate ops work needlessly tricky! We also use `serial-update-method unixtime`, so I did not have to worry about SOA serial number resets. If you are currently using the default `increment` method you can switch to unixtime without having to worry about wraps (tho `date` is problematic). Do this before the migration, to remove another hazard. When you are standing up a new primary, there are a few things you can do to check that the new zones are OK: use https://dotat.at/prog/nsdiff/ to verify that the non-dnssec zone contents are identical; use `dnssec-verify` to check the DNSSEC parts. A minor downside of rebuilding from scratch like this is that your secondaries will have to retransfer the complete zone contents, but that was not a problem at our scale (cam.ac.uk is 150,000 records and we have similarly sized private and reverse DNS zones). Basically, I ignored the journals as ephemeral, and I knew that re-signing from scratch would generate working signatures even though they are all different from the old signatures. Even if you are running both old and new in parallel before the switchover, unixtime means you don't have to worry about serial numbers either. (The biggest mistake I made with this operational surprise was to rebuild the primary on the same IP addresses rather than promote its sibling to take over on different addresses. I chose to do it in place so I did not have to reconfigure the other servers to point to the alternate primary; instead I had to do some delicate and unscripted firewall adjustments to stop the other servers from pulling down incomplete zones while the rebuild was in progress. In retrospect that was the wrong choice. But since you are moving to a new location I suspect you don't have this hazard.) I think a procedure like this is a good way to migrate a primary server if the old and new servers are run by the same people, though I recommend that you don't do it very quickly after a hardware failre if you can avoid it. Tony. -- f.anthony.n.finchhttps://dotat.at/ Lundy, Fastnet, Irish Sea: West or northwest 3 to 5, veering north or northeast 6 to gale 8. Smooth or slight, becoming slight or moderate, then moderate or rough in Fastnet and later elsewhere. Showers. Good, occasionally moderate. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named failed to resolve forwarding queries(with global forwarders specified with "forward only") when "server section statement" has forwarder IP
Nagesh Thati wrote: > > Can anyone tell me why I am getting tsig errors and SERVFAIL errors for > non managed zones? Why named using the "server statement" TSIG key in > forwarding queries instead of using this TSIG only for ixfr/axfr? TSIG is a bit confusing to set up because there are a bunch of options and the use-cases and pros and cons can be unclear. The `server` clause has a grab-bag of options that you can specify about other nameservers that your server might communicate with for whatever reason. If you configure a TSIG key in a `server` clause, it is used for all traffic with that server. (There will normally be a corresponding config on the other server for traffic in the opposite direction.) It's convenient to use for traffic between authoritative servers, because it gives you one place to secure refresh queries, notifies, and zone transfers. But in a more complicated configuration like yours it can have an unwanted effect on other traffic. Another approach is to configure TSIG for each kind of traffic separately. More explicit, but more verbose. The way I like to do this is to have `acl` clauses with helpful names, which can then be used in allow-notify and allow-transfer options to require TSIG for incoming requests; and corresponding top-level `primaries` clauses for use in per-zone `primaries` and/or `also-notify` clauses for outgoing requests. I can put all this access control stuff into a shared config file used on all my servers, and the authoritative TSIG stuff will not affect recursive queries. (For example, at Cambridge we have a mutual secondarying arrangement with Imperial College with TSIG and IPv6 and DNSSEC and all that good stuff; our recursive servers don't know anything special about the Imperial zones, and we don't need or want recursive queries between us to use TSIG. Our recursive servers still have the same shared access control config, but the Imperial parts are not used there, because none of the zone clauses refer to the Imperial acl/primaries names.) This kind of explicit TSIG configuration doesn't work in all cases: for instance, you can't specify TSIG keys in the `forwarders` clause, so you have to use a `server` clause to configure TSIG for forwarding. I haven't answered your specific questions because I'm not sure I understand the details of your setup properly, but I hope this more general answer is helpful. Tony. -- f.anthony.n.finchhttps://dotat.at/ harness technological change to human advantage ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC implementation on IPv6 PTR Zones
Divya wrote: > How to create DS for 2409::/28 The fun / maddening part of managing reverse DNS is getting to know how your RIR handles it, and the weird differences from common-or-garden forward domain registrations. In your case, 2409::/28 is allocated by APNIC. They have a bit of documentation at the link below, tho I can't find anything about DS records or DNSSEC. Perhaps it's more obvious once you have logged into their resource management web pages. https://www.apnic.net/manage-ip/manage-resources/reverse-dns/ Tony. -- f.anthony.n.finchhttps://dotat.at/ Sole, Lundy, Fastnet: Northeast 4 to 6. Slight or moderate in Lundy, otherwise moderate or rough, becoming slight or moderate in Fastnet. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possible to condition a view based on the interface the query comes in on?
Fred Morris wrote: > > Didn't see any reason that it had to be separate instances of BIND, > thought maybe I could do it with views, but I've run into a couple of > roadblocks: > > 1. listen-on isn't supported in views. Right, listen-on is for the server as a whole. To control which view is used to answer a query based on the server address, use the `match-destinations` option. For details see https://bind9.readthedocs.io/en/v9_16_23/reference.html#view-statement-grammar > 2. internet wisdom augurs that response-policy isn't supported either. Don't believe everything you read on the internet :-) Yes, you can have different RPZ configurations in different views. Another trick that's useful for the kind of setup you are planning is to use the `attach-cache` option so that your views can share the same cache. This improves performance and reduces memory usage. It still works with differing RPZ policies because RPZ only affects the responses sent to clients; RPZ doesn't change how recursion works or what records are saved in the cache. Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle, Faeroes: Westerly or southwesterly 7 to severe gale 9, occasionally storm 10 for a time in Faeroes, decreasing 5 to 7 later. Rough or very rough, becoming high for a time. Occasional rain. Moderate, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ rule to apply to NS record requests?
John Thurston wrote: > If I have a Reverse Policy Zone (RPZ) defined, I can define a specific answer > to be sent for a specific record-type for a specific name: > >foo.bar.com IN A 10.11.12.13 >foo.bar.com IN TXT "Hello World" > > But I can't seen to define one for the record-type NS > > Is this possible? The RPZ documentation doesn't say you can't include NS records as "local data", but I guess you might trip over BIND's checks for what makes sense at a zone cut: in a normal zone you can't have A and TXT and NS at the same name (unless it's the zone apex). But even if it did work, it's unlikely to do what you want. (You didn't say why you want NS records so that's a somewhat risky assumption...) In typical setups, RPZ is deployed on recursive servers, whose clients are basically all stub resolvers. Stubs don't do anything special with NS records, and they almost never make NS queries. So normally, using RPZ to substitue NS records will not have any useful effect. Tony. -- f.anthony.n.finchhttps://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Southwesterly veering westerly, 5 or 6. Slight or moderate, occasionally rough near Mull of Kintyre. Rain then showers. Good, occasionally moderate at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: host your subdomain on your own ?
Grant Taylor via bind-users wrote: > On 11/13/21 7:29 AM, Tony Finch wrote: > > You should make sure that your public nameservers return a definite nodata > > or NXDOMAIN reply for your private names, not REFUSED, nor a referral to an > > RFC 1918 address. The latter two will cause resolvers to retry, and the > > retries can become a large proportion of your total authoritative query > > traffic. > > Please elaborate on the mechanics behind returning a ""private IP > causing resolvers to retry? Is it the resolvers rejecting the ""private > IP and retrying? Yes, because they get a referral to nameservers that don't respond or that respond incorrectly. Tony. -- f.anthony.n.finchhttps://dotat.at/ Forties: East or southeast, veering south later, 4 to 6. Moderate. Fog patches at first. Moderate or good, occasionally very poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: host your subdomain on your own ?
A couple of generaal points about private names and addresses: If you have a private subdomain, e.g. private.cam.ac.uk, and a non-negligible number of users, the names *will* leak into the outside world and your public nameservers will get queries for them. You should make sure that your public nameservers return a definite nodata or NXDOMAIN reply for your private names, not REFUSED, nor a referral to an RFC 1918 address. The latter two will cause resolvers to retry, and the retries can become a large proportion of your total authoritative query traffic. I have some vague unease about the interaction between the web security model and names that resolve to RFC 1918 addresses outside their home network. And some more specific unease about risks of ssh, if you are ever careless about accepting ssh unknown host warnings. So I guess if you are careful and you know what you are doing (and by implication, if you don't have many users) you can put RFC 1918 addresses in public zones, but I wouldn't recommend it. Assign yourself an IPv6 ULA prefix and use that instead :-) Tony. -- f.anthony.n.finchhttps://dotat.at/ Plymouth, Biscay: Northwest veering north or northeast, 3 to 5. Moderate or rough. Occasional drizzle or showers later. Moderate or good, occasionally poor later. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record for @?
@lbutlr via bind-users wrote: > I have a domain that I hot DNS and email for, but not web. I set the A > record for www.example.com to the IP of the web server with nsupdate, > removing the old CNAME the pointed to the local webserver, but the web > monkey for the new website is saying that www has to be a CNAME and the > @ record should be the A record pointing to the IP. You can do that, but it might have weird effects if someone tries to send email to someth...@www.example.com. I generally think it's neater for both the zone file origin (aka @) and the www subdomain to have A/ records pointing at the web server. > I don't think this is right, and if it is I am not sure how to use > nsupdate to make this change. @ is just an abbreviation for (in this case) example.com (it's handy for writing instructions or zone file that work the same for any domain name). In cases where there isn't an implicit origin, such as nsupdate, you need to write the records out in full instead, e.g. www.example.com. CNAME example.com. Tony. -- f.anthony.n.finchhttps://dotat.at/ North Foreland to Selsey Bill: Northwesterly, backing westerly or southwesterly 3 or 4, increasing 4 to 6 later. Smooth or slight, occasionally moderate later. Showers later. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating Reverse Zones
Edwardo Garcia wrote: > > I guess bind can not consolidate like this and we have to put up with a > million /24 zone files ? I was thinking because we can do classless dele > with smaller than /24, it would work on bigger :) It is possible! The basic idea (very briefly) is: With classless reverse DNS for prefixes longer than /24, you need a CNAME in the /24 zone pointing at each address in the classless zone. For shorter prefixes, you need a DNAME in the /16 zone pointing at each /24 in the classless zone. There are some documents explaining how we use this trick in production at https://www.dns.cam.ac.uk/domains/reverse/ with links to the less Cambridge-specific explanations in the last two paragraphs of that page, viz: https://www.dns.cam.ac.uk/domains/reverse/technical.html https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis Tony. -- f.anthony.n.finchhttps://dotat.at/ Lundy, Fastnet: Northwest 4 or 5, occasionally 6 in Lundy. Rough or very rough, becoming moderate or rough, then moderate later. Showers. Good, occasionally moderate. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CNAME query
Sonal Pahuja wrote: > > We are sending a CNAME query but currently we don't have any CNAME > record, just have NS info. What should be the Bind9 response for this > CNAME query? Will it return NS Record in Authority/Answer section? In general, applications should not make CNAME queries because then they have to implement their own CNAME-chasing logic which is fraught with peril. Instead they should query for the final type the application needs, and let the DNS server handle CNAMEs. (In fact, DNS resolvers also should not make CNAME queries if they are looking for another type.) If you query for CNAME at a delegation point, the result you get depends: * If the server is authoritative for the parent zone, but not the child zone, and does not offer recursive service, you will get a referral in response. * If it is a recursive server, and your query has RD=1 (recursion desired) you should get a NODATA/NOERROR response from the child zone. The exact contents of the response can depend on the server's implementation and/or configuration; see RFC 2308 for details. * If it is a recursive server, and your query has RD=0, then the response will depend on the contents of the server's cache. Tony. -- f.anthony.n.finchhttps://dotat.at/ Humber, Thames: West 4 to 6, occasionally 7 at first in Humber. Slight or moderate, occasionally rough. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to measure use of forwarders?
Parkin, Richard (R.) wrote: > > I’d like to understand how much traffic is flowing to each forwarder > (QPS, etc) and monitor that for any issues. Is there a way to do that > effectively in Bind without putting some kind of network device on the > outbound path to measure it? If not, does anyone have any suggestions? One option is dnstap, though you will need to do your own scripting to get the numbers you are interested in. You can configure dnstap to log only forwarded queries so it doesn't have to drink the whole firehose. Tony. -- f.anthony.n.finchhttps://dotat.at/ Irish Sea, Shannon: West or southwest 4 to 6. Moderate or rough in Shannon, slight or moderate in Irish Sea. Occasional drizzle. Good occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: KSK signing zone records
raf via bind-users wrote: > On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton > wrote: > > > What algorithm(s) are you using for ZSK and KSK? If they’re not the > > same algorithm, then both will be used to sign the entire zone. > > Just out of curiosity, why is that? > Isn't having the KSK sign the ZSK enough? As well as what Mark said, the reason signing is per-algorithm is to do with downgrade protection: if there's a situation where validators support different algorithms (e.g. some have deprecated a bad algorithm but some have not yet deployed its replacement) then a signer can support all the validators by signing with both algorithms, without causing problems for the newer validators that want to distrust the old algorithm. A validator can decide whether a zone is secure or not based purely on the algorithms listed in its DS RRset. Tony. -- f.anthony.n.finchhttps://dotat.at/ Northwest Bailey: Southwesterly 3 to 5. Slight. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
raf via bind-users wrote:
>
> But that means that it applies to all of the zones in
> /etc/bind/named.conf.default-zones which is not helpful. It also applies
> to the zones in /etc/bind/zones.rfc1918 if that is included in
> /etc/bind/named.conf.local (which a comment there suggested). That's not
> helpful either.
A tangential point, but I think this kind of setup (with lots of empty
zones) isn't necessary, if you are doing DNSSEC validation and you turn on
synth-from-dnssec - much less configuration clutter.
> Can you sign 127.in-addr.arpa and 168.192.in-addr.arpa?
You can: it's harmless but pointless and wasteful.
> I've come to the conclusion that putting dnssec-policy in the options {}
> stanza, so that it applies to all zones, is a terrible idea. It only
> makes sense (to me) to add dnssec-policy to each individual (real)
> authoritative zone {} stanza.
It makes sense to configure dnssec-policy in one place if you have an
authoritative-only primary server, which is configured with just the zones
that it is signing. (The extra zones in the Debian config are only
suitable for a recursive server.)
> What I found more upsetting, was that my carefully crafted, well
> documented zonefiles in /var/cache/bind had been overwritten by bind so
> as to include the DNSSEC records. It might seem obvious to anyone who
> uses DNS updates that that was going to happen, but I wasn't expecting
> it. It would be great if the DNSSEC guide could be updated to mention
> that this happens, and include advice to keep your zonefile sources
> somewhere other than where bind looks for them.
Yes, this is a relatively common gotcha. You can avoid overwritten zone
files by turning on inline-signing mode, so that your source zone files
are separate from the signed zone files maintained by named. If your
configuration uses dynamic updates or DNSSEC then the zone files are
normally owned by named and will be rewritten, and you are right that
there isn't much warning of this in the documentation.
> But the real problem is that bind crashed, and dumped core, and couldn't
> start at all.
There should be something in the logs to indicate why this might have
happened; failing that a stack trace from the core dump would have been
helpful.
> I have a new question about the process of updating zonefiles when
> dnssec-policy is in use. From now on, I'll have my zonefile sources
> somewhere other than /var/cache/bind (e.g. /etc/bind/zone). When I make
> changes, I'll install them to /var/cache/bind and reload bind9. Bind9
> will replace them with the signed versions. Is it OK for me to modify my
> unsigned sources, install them over the top of bind's signed versions,
> and will bind happily recreate all of the DNSSEC records each time?
No, I'm afraid it's more complicated than that.
You can do what you suggest if the server uses inline-signing mode. If
not, your process will go wrong horribly: you need to use `rndc freeze`
and `rndc thaw` if you are manually editing a zone file that is owned by
named, BUT if you do that with a signed zone, you will lose all the
signatures and it will have to be re-signed from scratch. Not good.
Another alternative is to enable `update-policy local`, and use nsdiff and
nsupdate to make the live zone match your source files.
http://dotat.at/prog/nsdiff/
Tony.
--
f.anthony.n.finchhttps://dotat.at/
North Fitzroy, Sole: Westerly or northwesterly 4 to 6 veering
northerly or northwesterly 3 to 5. Rough becoming moderate. Showers
then fair. Good, occasionally moderate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching key types for authorizing updates
John Thurston wrote:
>
> But as far as I can tell, the name of the key needs to match the hostname in
> the update-policy statement. I can define a new aes-256 key, but it can't have
> the name "foo.bar.baz.com" while the current md5 key is defined. Nor can I
> find a way to craft an update-policy statement line to let a new key with a
> different name manipulate the desired TXT records, while letting the current
> key continue to work.
I think you want something like:
update-policy {
grant "foo.bar.baz.com_aes256" subdomain "foo.bar.baz.com" TXT;
};
i.e. using the "subdomain" rule type instead of "selfsub", so the
domain name (second foo...) doesn't need to match the keyname (first
foo...)
Tony.
--
f.anthony.n.finchhttps://dotat.at/
work to the benefit of all
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: AW: Deprecating auto-dnssec and inline-signing in 9.18+
Klaus Darilion via bind-users wrote: > > By reading this KB I do not know how the user will be informed which DS > (or DNSKEY) must be submitted to the parent zone. I know you to convert > a DNSKEY to DS, but IMO the KB is very good but missest hat point. I would expect the zone's apex CDS and CDNSKEY records to change, but neither are mentioned in the KB article. Tony. -- f.anthony.n.finchhttps://dotat.at/ a fair voting system for all elections ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind doesn't stop contacting global ROOT DNS servers after commenting(#) the the root hint zone in named.conf
Ramesh wrote:
>
> I commented the root hint zone section(default) in the named.conf file to
> stop bind from communicating to the global root DNS servers and it should
> only use the internal forwarders available in the options{} section.
I think the config option you want is `forward only`. The default is
`forward first` which has the fallback behaviour that you observed.
On my servers I don't configure a hint zone: using BIND's built-in hints
and trust anchor reduces the amount of configuration that needs to be
deployed in the chroots and which can go stale.
Tony.
--
f.anthony.n.finchhttps://dotat.at/
the market alone does not distribute wealth or income fairly
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: response policy zones (rpz) and views - memory consumption
Jiri Hromadka wrote: > > Is there any way to reuse already loaded rpz zone in memory for other > views ? I know in-view is not an option for rpz, using one master / > slave zones has same memory effect. Yeah, in-view would be perfect, if only :-) You might try setting up a view that only does recursive resolution and RPZ, and configure the per-client views to forward to the RPZ view. It's probably also worth configuring a small cache size limit in the per-client views to avoid too much duplication. Self-forwarding won't have amazingly good performance but you only need to worry about that if you are running at many thousands of queries per second. Tony. -- f.anthony.n.finchhttps://dotat.at/ Forth, Tyne: North or northeast 3 to 5. Slight or moderate. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named UDP retransmit timeouts ?
Jason Vas Dias wrote: > > Please can anyone advise the best way to optimize named's > UDP timeout settings for caching-only local resolver usage > over a slow network link - I can't seem to find any in the > Bv9ARM document specifically describing how named > implements UDP re-transmits - please could someone > point me at the right pages or place to look, besides > the source code, which I am reading now, if there are any ? I remember being surprised a while back that the retry intervals and timeouts were more hard-coded than I expected. (But, be warned! I have not refreshed my memory.) The rough idea is that there's a certain amount of co-design between the libc stub resolver (which back in the day came from BIND) and the recursive server. IIRC, the libc resolver has a query timeout of 10s and retries three times (so the overall timeout is about half a minute), and named's resolver has a timeout of about 3s and also retries 3 times, which neatly fits inside libc's 10s timeout. At least that's what my memory tells me, but it may be wrong. But, I think you will not be successful fixing your problems by tweaking DNS software. One of the problems with DNS as a protocol is that its transport layer is very simple and very stupid, so if the underlying network has problems, the DNS isn't able to fight its way through. > My problem is that at home my whole internet goes through > one 100M CAT-6 ethernet cable to a GSM 3G/4G modem (90% 3G WCDMA) , > it seems no more than about 128 kilobyte/sec download & less upload > bandwidth is available, whenever my browser decides to download > something large (like a JavaScript blob) , then DNS requests > start timing out, the browser keeps re-issuing its requests, > and similar nasty feedback situations occur when the GSM > modem's DHCP lease expires and it has to re-setup its NAT for > the ethernet link, so all UDP requests time out for about > 10 seconds, building up quite a backlog. Ugh, that sounds horrible. I think the basic problem is that TCP is very aggressive about filling up whatever bandwidth it thinks might be available, but the DNS is not, and TCP's congestion control algorithms will happily overwhelm a comparatively reticent protocol like the DNS. You probably also have buffer bloat, which makes these problems worse. (check out https://www.bufferbloat.net/ for LOTS of information) I am lucky enough that I haven't needed to deal with your problems myself, so the best I can do is give you a few hints, but no specific advice. The main idea is to prevent your TCP flows from overwhelming your uplink, and/or from interfering with DNS traffic. You can (with the right know-how) do this with some stunt network configuration on your Linux gateway. * Use traffic classification and priority queueing to ensure that DNS packets can jump ahead of everything else. This probably won't be enough by itself because of buffer bloat. * You can use traffic shaping to ensure that the aggregate traffic from your Linux box never tries to over-fill your uplink. Years and years ago a friend of mine did this to avoid buffer bloat in their cable modem. * Configure FQ-CoDel on your Linux gateway. This is a queueing algorithm specifically designed to avoid buffer bloat and to make TCP back off before everything becomes terrible. That's approximately everything I know about tackling your problem, so I hope it points you in the right direction... Tony. -- f.anthony.n.finchhttps://dotat.at/ Biscay: Cyclonic in far north, otherwise westerly or southwesterly, 4 to 6, occasionally 7 in north. Slight or moderate becoming moderate or rough. Squally thundery showers. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named-checkzone as library?
Felipe Gasper wrote: > > Is there any public code interface that exposes named-checkzone’s > functionality? > I’d specifically like to have numeric error codes rather than strings. It isn't easy to do that, I'm afraid. There are two places that don't do what you want. The source for named-checkzone is in https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/check The file named-checkzone.c has the setup and option handling, and check-tool.c has some of the zone checks - but not all. It deals with things like using the system resolver to check CNAME or MX records that point out of the zone. There are also a load of checks in lib/dns/zone.c - look for integrity_checks() and the various zone_check_*() functions. https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/dns/zone.c Both lib/dns/zone.c and bin/check/check-tool.c report their findings by logging; there isn't an intermediate error code that might describe the problem. And BIND's error codes are simple errno-style numbers: they can't say multi-parameter things like "foo.dotat.at/MX points to bar.dotat.at which is a CNAME". Tony. -- f.anthony.n.finchhttps://dotat.at/ North Utsire, South Utsire: Variable 2 to 4. Slight or moderate. Fog patches later. Moderate or good, occasionally very poor later. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Managing localhost
Grant Taylor via bind-users wrote: > On 6/21/21 11:00 AM, Tony Finch wrote: > > That advice is out of date: nowadays you should not put any localhost > > entries in the DNS, because it can cause problems for web browser security. > > Modern software should suppress queries for localhost so they never reach > > the DNS. > > If I'm understanding the problem correctly, it seems to come down to anything > involving localhost /except/ fully qualified localhost.(implicit null). Correct. As I mentioned in the blog post (link repeated below), I did some data collection to verify that dropping the localhost subdomains would be safe: answer, yes, there were basically no localhost queries. I used to have a bunch of zones related to special-use domain names and IP addresses, but after BIND 9.12 added support for DNSSEC-based NXDOMAIN synthesis, I deleted them all. This means that (strictly speaking) my servers don't conform to RFC 6761's requirements for localhost, but (a) I can say that it is BIND's bug rather than mine, and (b) it doesn't matter anyway because the query traffic is negligible. > > https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html > > https://datatracker.ietf.org/doc/html/rfc6761#section-6.3 Tony. -- f.anthony.n.finchhttps://dotat.at/ Faeroes: Variable 2 to 4, becoming southwest 5 to 7. Slight or moderate, becoming moderate or rough. Occasional rain later. Good, occasionally moderate later. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Managing localhost
techli...@phpcoderusa.com wrote: > > This book : > https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html says I > should manage the localhost within my zone (SOA) and reverse lookup / PTR. That advice is out of date: nowadays you should not put any localhost entries in the DNS, because it can cause problems for web browser security. Modern software should suppress queries for localhost so they never reach the DNS. https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html https://datatracker.ietf.org/doc/html/rfc6761#section-6.3 Tony. -- f.anthony.n.finchhttps://dotat.at/ no one shall be enslaved by poverty, ignorance, or conformity ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND RPz with IPv6
Manish Rane wrote: > > Would be keen to know if BIND RPZ supports IPv6? Yes, see https://bind9.readthedocs.io/en/v9_16_6/reference.html#rpz Tony. -- f.anthony.n.finchhttps://dotat.at/ sovereignty rests with the people and authority in a democracy derives from the people ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using RRL to for TC=1 on all queries
John Kristoff wrote: > Has anyone configured BIND to force TC=1 responses on all queries using > RRL?I'd like to do this for some experimentation and measurement > work, but maybe this just isn't the right tool for that job? > > I've tried a number of configurations (e.g. slip=1, rate=0) and I can't > seem to make this work. Perhaps it is not possible. As far as I know, RRL will only truncate responses that exceed the limit, and the minimum limit is 1. (Zero is interpreted as no limit.) So RRL will leak at least one non-truncated response per second. RPZ has a tcp-only action which truncates UDP responses, so if you set up an RPZ that matches everything, that should allow you to do what you want. Tony. -- f.anthony.n.finchhttps://dotat.at/ Shannon, South Rockall: Northeasterly 5 or 6, occasionally 7 in Shannon. Moderate or rough. Showers at first. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
PGNet Dev wrote: > > With a NOTIFY, something like _your_ old listener > > nsnotifyd: handle DNS NOTIFY messages by running a command > https://dotat.at/prog/nsnotifyd/ > > Don't know yet how dusty that is, or relevant to current bind 9.16+, etc. -- > -- but the general 'respond immediately to a NOTIFY' sounds quite useful. Maaybe. Bare NOTIFY can say which zone's keys have changed, but not what the state transition is, so it isn't what I would consider to be a complete solution. However, NOTIFY as specified is a slightly odd protocol - I say "as specified" because no-one implements the odd parts, for good reasons. It allows the initiator to include records in the answer section as a "hint" about what has changed. There's no security, and no provision for transmitting more than one rrtype at a time, or for transmitting the new serial number, so it's fairly useless :-) It also says that future revisions might specify what it means to have a non-zero number of records in the authority and/or additional section. So I think it might be worth using these odd parts for a more complete NOTIFY-for-keys, something like opcode = NOTIFY ; question section qtype = DNSKEY qname = ; additional section name = type = TXT rdata = And nsnotifyd would need a little hacking to grab the state transition code out of the packet. (nsnotifyd is adequate as it is - it works, its users have not reported bugs - but it is based on very old C resolver APIs for parsing DNS packets, so it should only be allowed to talk to friends.) https://datatracker.ietf.org/doc/html/rfc1996 (I remember NOTIFY's RFC number because it is the RFC whose number matches its year of publication.) Tony. -- f.anthony.n.finchhttps://dotat.at/ an equitable and peaceful international order ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
Matthijs Mekking wrote: > > A brief summary. Folks that are interested in the reasons why can read > up and discuss here: > >https://gitlab.isc.org/isc-projects/bind9/-/issues/1890#note_220217 So the fundamental design issue here is related to edge-triggered vs. level-triggered activities, and which is easier to implement both for named and for the hostmaster's scripts. With an edge-triggered design you have to avoid falling into the trap of assuming that exactly-once is possible (it isn't!) so you need a closed feedback loop with retries. Specifically, for key management, named needs to be able to say, I have changed the state of this key, and keep saying that at every key refresh interval until some script confirms that it has done what it needs to do, before named moves on to the next state. (This applies to changes like newly created keys that need to be saved, as well as CDS state changes.) How should named say that a key has changed? It's a multithreaded program so it can't fork (not without a single-threaded helper process) so maybe it should fire off a message to a socket that the script machinery can listen to. (Maybe abuse NOTIFY for the purpose?) The feedback loop can be closed using an rndc command. The questions for a level-triggered design are more to do with introspection and performance. Introspection: how can I find out the state of the keys and the state of the world, detect if there is a mismatch, and know what needs to be done to get the world to match the keys? Performance: do I have to do this check every hour (or whatever the key maintenance interval is) for every zone, or is there some way to avoid futile repeated work? In a level-triggered design it must still be possible to configure named not to move on to the next state without confirmation from the script that it is safe to do so, e.g. using rndc, same as is needed in an edge-triggered design. In my case I'm storing keys in a git repository, encrypting the private parts with gpg, so I need to know about all key state changes, not just CDS changes. I can implement a level-triggered design using something like `git status` and/or `git diff` to detect mismatches (assuming my script only commits to the git repository when it is sure it has updated the world as required). That will perform OK at my small scale, but I'm not sure if I have the necessary introspection tools - I guess I'll have to grovel around in the guts of the key files to find out what needs doing? An edge-triggered design would be a bit easier since my script would just receive an instruction and act on it in an idempotent manner. No need for it to woek out what has changed or what needs doing, and it would clearly scale per change rather than per zone. Tony. -- f.anthony.n.finchhttps://dotat.at/ St Davids Head to Great Orme Head, including St Georges Channel: South or southwest 4 or 5, occasionally 6 near Anglesey, becoming variable 2 to 4 later. Slight, occasionally moderate. Fair at first, then occasional rain or drizzle. Moderate or good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DOH or DOT Forwarder in BIND and is DOH GA?
Walter H. via bind-users wrote: > > DOH/DOT is dead; > > use DNSSEC instead and no troubles; No. DNSSEC is about data integrity. It allows me to host my zones with a collection of semi-trusted third parties without having to worry about them changing my DNS records. It allows clients to be sure they got the correct data when querying my zones. But DNSSEC does not provide any confidentiality, and it doesn't protect the protocol parts of DNS packets such as the RCODE and the EDNS options. DoH and DoT are the opposite. They provide better confidentiality (network middleboxes can't see your queries) and better transport integrity (active attackers can't mess with things like EDNS options), but they don't authenticate the contents of DNS records. It is wrong to say that one is better than the other: they are orthogonal. It's good to deploy either of them, and better to deploy both. Tony. -- f.anthony.n.finchhttps://dotat.at/ Viking, North Utsire: Southwesterly, veering westerly later, 4 to 6. Moderate, occasionally rough later. Rain, showers later. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
PGNet Dev wrote: > > fyi, perhaps keep an eye on this: > > https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11 hmm, maybe, but it's my Spock eye with a single arched eyebrow Tony. -- f.anthony.n.finchhttps://dotat.at/ Thames, Dover: Southwest 4 to 6. Smooth or slight becoming slight, occasionally moderate later in Thames. Fog banks. Moderate to very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?
PGNet Dev wrote: > > Has anyone here on-list figured out how to hook bind's internal signing > process to *trigger* and external script to exec those API pushes? I have not, and I also want to be able to do this, and I also want scripting hooks for whenever any keys change so that I can stash them somewhere safer. Tony. -- f.anthony.n.finchhttps://dotat.at/ Rockall, Malin, Hebrides: Southwest veering west, 4 to 6, occasionally 7 at first. Rough, but slight or moderate in southeast Malin and southeast Hebrides. Rain with fog patches, showers later. Moderate or good, occasionally very poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: reverse lookup for RFC1918 in view failed
MAYER Hans wrote: > I can see why the behaviour of your server is confusing! I'll explain what is happening in detail below, but here's the basic idea: Each view in a configuration is separate from the others: `named` first chooses which view to use (based on match-clients etc.) then handles the query purely within that view. If a zone is only configured in one view then that zone configuration will not be used to answer queries that are handled by another view. By itself, that basic idea isn't enough to explain what's happening with your server, so let's look at the details, then I'll outline some solutions. > Now the behaviour is the following: When I query from the local IPv6 or > IPv4 network with „dig -x“ for an IP address I get back „status: > NXDOMAIN“ In this case your query is matching the "intern" view, which doesn't know about your RFC 1918 reverse DNS zone, so it resolves the query using the public DNS, which says NXDOMAIN. > But when I do the same on the server itself using the loopback addresses > for IPv6 or IPv4 it works fine. It also works, if the query comes from > the Internet over IPv4 with NAT or with the public IPv6 address. In these cases your query is reaching the "fueralle" view, which does know about your reverse DNS zone. > If I query „normal forward“ for an IP with a given name then it works in > any case and from every location. This is interesting because the > reverse lookup zone and the normal forward zone are both in the same > view „fueralle“. This is where it gets complicated! There are two cases: When you query your forward zone from an external IP address, or from a loopback IP address, the query is handled by the "fueralle" view, which knows about your forward zone, so it can answer the query. When you query from an internal IP address, it is handled by the "intern" view which doesn't know about your forward zone. So it does normal recursive resolution, which (I guess!) eventally tells the server to query itself via the public NAT or IPv6 addresses, so the recursive query is answered by the "fueralle" view. If you turn on query logging (and if my guess is right) you should see two entries in the query log for this last kind of query, one in the "intern" view, and a matching one in the "fueralle" view. To make your views behave more consistently, the solution is to make sure that each view knows about all the zones that it needs to. So your "intern" view should have your forward zone and your RFC 1918 reverse zone, and your "fueralle" view should only have your forward zone (because you don't want to publish a private zone on a public server). There are a couple of ways to make the forward zone appear in both views. You can use the "in-view" zone configuration option, which makes this view re-use a zone configuration from another view. You can continue to rely on the resolver, but that is less reliable because it will not work if/when your network loses external connectivity. What you must not do is simply copy the same primary or secondary zone configuration into multiple views: if you do that, you will have multiple zone configurations trying to use the same files, and they will conflict with each other. Tony. -- f.anthony.n.finchhttps://dotat.at/ Plymouth, Biscay: Variable 2 to 4. Slight or moderate. Mainly fair. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 Feature Request: inheritance-policy
JW λ John Woodworth wrote:
> Greetings, I would like to request a new feature which I hope will make
> management of the 'allow' match-lists a tad easier.In short, an option
> such as 'allow-transfer' in view or zone contexts could extend the
> match-list as defined in the options section.
You can sort of do what you want already, by defining named ACLs. ACLs can
refer to named ACLs: you can include a named ACL or exclude it. For
example, in my production config, I have some acl clauses roughly like the
ones outlined below.
I like named ACLs and named "masters" lists because they allow our config
generation scripts to use symbolic names to describe a zone's config:
query and xfer ACLs, upstream xfer sources, downstream notify targets. And
when I look at the generated config I see the same symbolic names, so I
have a reasonably consistent and simple vocabulary from the source of all
knowledge through to the run-time config. (And the logs when I have
persuaded the other end to do TSIG!)
acl cudn {
# cambridge university data network address ranges
};
acl mythic {
# mythic beasts xfer and auth servers
};
acl secondaries {
cudn;
mythic;
# some xfers allowed by key instead of address
key tsig-maths;
key tsig-imperial;
};
zone cam.ac.uk {
# blah blah
allow-query { any; };
allow-transfer { secondaries; };
};
zone private.cam.ac.uk {
# etc usw
allow-query { cudn; };
allow-transfer { cudn; };
};
Tony.
--
f.anthony.n.finchhttps://dotat.at/
work to the benefit of all___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
Stoffel, John (TAI) wrote:
>
> And it does dump some errors too, which hopefully will give me an idea
> of where my crappy bad record is located, and no use hiding crap:
yuck, this looks like no fun...
> www.cisco.toshiba.com. 3600IN CNAME redirect.toshiba.com.
> www.cisco.toshiba.com. 3600IN RRSIG CNAME 8 4 3600 20210517093721
> 20210507083721 38628 t
> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN
> hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ
> C6zJn9HHdC9o2dwBoGpknTwJM
> DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM=
> ;; Got bad packet: bad bitmap
> 16358 bytes
does it print more hexdump? who knows where the problem might be in 16KB
of wire-format DNS...
I would try another DNS AXFR client that might not give up so easily, e.g.
if you have a handy copy of perl and Net::DNS, put your Windows DNS server
IP address into this one-liner instead of 127.0.0.1
perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new();
$r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { $rr->print
}'
The bit of the hexdump you pasted shows another similar CNAME and its
RRSIG, so it isn't very enlightening.
> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73 Ftos
headerRR counts qname = zone name
> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69 hiba.com..ci
00fc = axfr
> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10 tibank..
backpointer to zone = c00c 0005 = cname
citibank looks like it follows cisco alphabetically which suggests the
zone transfer might be in canonical order, which could perhaps make it
easier to find the stray NXT / TYPE30 record(s)
> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00 ...redirect.
cname target c01d = backpointer to citibank
> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e
2e = rrsig type covered = 0005 (cname)
> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68 .`.9Q`..A...tosh
> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54 iba.com2..*T
> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae e..(A..`
etc.
Tony.
--
f.anthony.n.finchhttps://dotat.at/
Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight
or moderate in Fisher, smooth or slight in German Bight. Showers, fog
patches. Moderate, occasionally very poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.
Stoffel, John (TAI) wrote: > failed while receiving responses: bad bitmap > > None of my googling has given me any hints on what this error could be. I had to look at the source, which told me it's to do with NXT records which are super obsolete, so I wonder what weird stuff is in the zone that might cause this. (The NXT record was a predecessor of NSEC; NXT was badly designed so it is unable to support all possible DNS RR types, which is why it needed replacing.) $ rg 'bad bitmap' lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ $ rg BADBITMAP lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP (ISC_RESULTCLASS_DNS + 94) lib/dns/rdata/generic/nxt_30.c:154: return (DNS_R_BADBITMAP); lib/dns/result.c:137: "bad bitmap",/*%< 94 DNS_R_BADBITMAP */ lib/dns/result.c:278: "DNS_R_BADBITMAP", Tony. -- f.anthony.n.finchhttps://dotat.at/ Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5 becoming variable 2 to 4, then northerly 5 to 7 later in Viking and northern North Utsire. Moderate or rough in Viking and northern North Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate or good, occasionally very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline signing fails dnsviz test.
Dan Egli wrote: > > Still not working for me. The dig doesn't report anything, and I don't HAVE a > keyfile since i'm using inline signing. Or does inline signing still require a > key to be generated? Yes, you need to do your own key management with inline-signing using dnssec-keygen. The new dnssec-policy feature can do automatic key management for you. Tony. -- f.anthony.n.finchhttps://dotat.at/ Lundy, Fastnet: Southwest 5 to 7, backing southeast 4 to 6 for a time. Moderate or rough, occasionally very rough in southwest Fastnet. Thundery rain. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline signing fails dnsviz test.
Dan Egli wrote: > > Where do I get the DS record, since i'm using bind's inline signing? Use the dnssec-dsfromkey tool, e.g. from a key file (make sure it's the KSK file) $ grep This Kcam.ac.uk.+013+32840.key ; This is a key-signing key, keyid 32840, for cam.ac.uk. $ dnssec-dsfromkey -2 Kcam.ac.uk.+013+32840.key cam.ac.uk. IN DS 32840 13 2 2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85 or from your DNSKEY RRset (safest to run this on your primary to be sure the keys aren't mangled) $ dig cam.ac.uk dnskey | dnssec-dsfromkey -2 -f - cam.ac.uk cam.ac.uk. IN DS 32840 13 2 2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85 Tony. -- f.anthony.n.finchhttps://dotat.at/ Berwick upon Tweed to Whitby: South backing southeast, 3 to 5, occasionally 6 at first. Slight or moderate becoming slight. Showers, perhaps thundery later. Good occasionally moderate later. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Update DNSSEC Zone
Peter Fraser wrote: > > I am using bind-9.14.x and here are the DNSSEC related entries in the zone. > > auto-dnssec maintain; > update-policy local; > key-directory “zones/domain-keys”; How you go about this depends on whether your configuration enables `inline-signing` or not. If it has inline-signing, you should see in the filesystem that each zone file has .signed (and possibly .jnl) files alongside. You can update the zone using (edit the non-.signed zone file) rndc reload If it does not have inline-signing I prefer to use `nsupdate` to update the zones, usually with my `nsdiff` or `nsvi` tools. Or you can, rndc freeze (edit the zone file) rndc thaw https://dotat.at/prog/nsdiff/ Tony. -- f.anthony.n.finchhttps://dotat.at/ Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally moderate in east, becoming very rough in west. Thundery showers. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Log queried forwarder IP address
Levente Birta wrote: > > I have a caching resolver. Is it possible to log the IP address of the queried > forwarder without too much overhead? dnstap might be what you want, but it's a bit intricate. Tony. -- f.anthony.n.finchhttps://dotat.at/ Irish Sea: Northwesterly 4 to 6, occasionally 7 in north. Slight or moderate. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: where are the testing docs ?
Dennis Clarke via bind-users wrote: > > Hey there. I looked in the README and I dont see an INSTALL file at all > so I have to assume that the testing docs exist somewhere. Have a look at https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system There are some more notes in: https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev Tony. -- f.anthony.n.finchhttps://dotat.at/ disperse power, foster diversity, and nurture creativity ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to return REFUSED
Axel Rau wrote:
> I have,
>
> allow-query { any; };
> allow-query-cache { recursive-users; };
> allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is
> recursive?
Weird! I think your config should do what you want so I wonder why it
isn't working. Your server is responding to the problem queries with a
referral from the root zone, so have you configured your server with a
local authoritative copy of the root?
There's a broader issue here:
Usually when you have a server that is providing recursive service to
anyone, it is best to set the allow-query ACL to cover just your users, so
everyone else gets REFUSED.
This means that your recursive server cannot also be used as an
authoritative server advertised in NS records. Your public authoritative
servers should be authoritative-only and not offer recursion to anyone.
> PS: I want to minimize the responses to this amplification attack:
Ooh, RRSIG queries are fun. They are like a stealth ANY query.
BIND has several tools for dealing with this kind of junk:
* RRL is very effective
* minimal-any also minimizes responses to RRSIG queries
* minimal-responses can also help to reduce packet sizes
Your server is responding with a referral from the root, so minimal-any
won't have any effect on the response. And because it's a referral, the
glue etc. is not optional, so there's nothing that minimal-responses can
omit. So in your situation the most useful things to do would be:
* tighten up your allow-query ACL
* if you can't do that, use RRL (you can add recursive-users to the
exempt-clients list)
* configure separate views for recursive-users and others; do not
include the root zone in your external view
Tony.
--
f.anthony.n.finchhttps://dotat.at/
The Minch: North 6 or 7, backing northwest 3 to 5. Rough or very rough
at first northeast of skye, otherwise slight or moderate. Wintry
showers. Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: REST API for recursive queries
Roee Mayerowicz wrote: > I have ~700k (and growing) domain names that should be resolved daily. > I'm trying to make it efficient as possible using the recursive BIND > server (do you know a better option?), the goal is to get 2000 queries > per second with minimum server\s cost. I do bulk lookups on that kind of scale when I am preparing a recursive server to go into production. I use this small (250 line) program as a front end to adns that works the way I like. It can easily manage thousands of queries per second. https://git.uis.cam.ac.uk/x/uis/ipreg/adns-masterfile.git (That URL may stop working within the next few months because we're moving to GitLab and my old git server will be shut down, though I would like to find somewhere to host redirection tombstones...) Tony. -- f.anthony.n.finchhttps://dotat.at/ North Foreland to Selsey Bill: Westerly 5 or 6, decreasing 3 or 4, becoming variable 2 to 4 later. Slight or moderate, becoming slight later. Showers, occasional rain later. Moderate or good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: REST API for recursive queries
Petr Menšík wrote: > Because BIND uses DNS protocol only and not any dbus or former lwres > protocol, you can count only querying -t ANY for single name as > something similar. ANY queries don't necessarily give you all the records :-) In situations where a DNS client wants to do multiple queries at once, it can either send a load of UDP queries then wait for the answers, or if it has a TCP connection open, write all the queries in one go, then read the answers. There's not really much need for fancy features to support multiple questions when you can do hundreds of concurrent queries with one or two sockets. Happy Eyeballs version 2 requires concurrent DNS queries https://tools.ietf.org/html/rfc8305#section-3 I like to use `adns` for bulk concurrent queries http://www.chiark.greenend.org.uk/~ian/adns/ Much newer is getdns which has a more JSON-friendly design. https://getdnsapi.net/ Tony. -- f.anthony.n.finchhttps://dotat.at/ Biscay: West or northwest 5 or 6, becoming variable 2 to 4 later. Moderate or rough, becoming moderate. Rain at first. Good, occasionally moderate. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
Edwardo Garcia wrote: > > So you mean to say when it print out > > IN DS 45701 13 1 5422E9... > IN DS 45701 13 2 qwertyE9... > > we never needed 45701 13 1 5422E9 only 45701 13 2 qwertyE9 ? Exactly, yes! > and we only need run > > dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f - guiltyparty.net > > and enter in just that one entry? 45701 13 2 qwertyE to the DS in domain > reg? Correct! > and we have been upload both all this years was wrong ? Well, not wrong, but unnecessary. The tools generally encouraged everyone to publish both SHA1 and SHA2 DS records even though just SHA2 has been enough for more than 10 years and SHA1 has had known weaknesses for even longer. > hrmm, now I start to understand why not many use DNSSEC so confusing to > those who not do this every day, or so many instructions around nobody > knows what works > > But we getting there :-> Yes, slowly... Tony. -- f.anthony.n.finchhttps://dotat.at/ Shannon, Rockall: Variable 4 or less, becoming southwest 3 to 5 later. Slight, occasionally moderate in Rockall and at first in Shannon. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
Edwardo Garcia wrote: > One thing I note, all check say everything is good, but when using dnsviz, > it says secure, shows the ecd... but also puts up warnings that I am using > alg 13 but digest 1 (sha1), which is not allowed, I guess the "digest 1" is referring to your DS records. In my guide I said, get the DS record for the new algorithm like this: dnssec-dsfromkey -2 Kbotolph.cam.ac.uk.+013+Y The -2 option forces SHA-2 and avoids the deprecated SHA-1 hash. Old versions of BIND by default print both SHA1 and SHA2 DS records, and it's relatively common for zones to have both kinds of DS record in their delegation. SHA1 DS records are now discouraged so it's best to replace them with SHA2, or just delete them if you have both kinds of DS record. Tony. -- f.anthony.n.finchhttps://dotat.at/ harness technological change to human advantage ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
@lbutlr wrote: > > I update the last of my zones over a month ago and they are still > showing alg-7. > > I'm sure I missed a step on these specific domains, but there are only a > handful that are still using alg-7 and many more that are now on alg-13 > only. Hmm, curious! If you have swapped the DS records already, then all that is left to do is remove the remains of the old algorithm. Have a look at the keys for the problem zones like this: grep ^ Kexample.com.*.key The algorithm 7 keys should all have inactive and delete times. If some of the times are missing then you can fix it by re-doing the "decommission old algorithm" step in my notes. It should get cleaned up immediately. https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html If that doesn't fix it, then the problem is elsewhere... Tony. -- f.anthony.n.finchhttps://dotat.at/ Forties, Cromarty, Forth: North or northeast 2 to 4. Slight occasionally moderate. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)
Robert M. Stockmann wrote: > > Does bind 9 need C11 atomics ? Yes. BIND used to have its own atomic implementation but that kind of code is tricky and arcane, so it's better to use the standard implementations in the C library. It is not just a matter of the hardware BIND runs on: atomics rely on memory barriers that the compiler needs to know about, so that it does not move code out of a critical section when reordering things for optimization. And BIND is always multi-threaded and pre-emption can happen at any time even on a single CPU. Tony. -- f.anthony.n.finchhttps://dotat.at/ champion the freedom, dignity, and well-being of individuals ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
Edwardo Garcia wrote: > > One question however it talk about longest TTL, does this mean also root > TLD zones (.com, .net) which from memory are 48 hours, so before we delete > old keys we need wait 48 hours, even though our zone TTL was 24 ? When you are waiting after adding and signing with the new keys and before swapping the DS records, it's only the longest TTL in your own zone that matters. In my notes I call this the "child TTL" because the root and TLD etc. don't matter. https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html When you're waiting for the DS TTL it's only the TTL of that particular record that matters. (It's in the parent zone so I called it the parent TTL.) To be sure you are getting the right number you will need something like: dig +ttlunits example.com ds @$(dig +short com ns | head -1) i.e. pick one of the nameservers of the parent zone and ask it for your zone's DS record, so you don't get mislead by decremented cached TTLs. Note the DS TTL is often not the same as the parent NS or glue TTL. > Thank you, wow much much easy than I hoped for :-) I'm happy it helped! Tony. -- f.anthony.n.finchhttps://dotat.at/ Biscay: North, backing northwest later, 2 to 4, occasionally 5 later in east. Slight. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
Edwardo Garcia wrote: > > Many year ago we set up DNSSEC, our key were generated with sha1 as was > recommended way back all them years. We too are not DNSSEC guru, so some > answer may be simple Well, you are going to do an algorithm rollover, which is one of the more tricky things you can do with DNSSEC. So, plan to do some testing, a trial run, with a spare zone that you can break without worrying. If you like to understand things by getting an idea of the wider context then there are a couple of RFCs on the general subject of key rollovers. The parts that are most relevant are the algorithm rollover section in RFC 6781 and the double-KSK section in RFC 7583. https://tools.ietf.org/html/rfc6781 https://tools.ietf.org/html/rfc7583 DNSSEC has got easier since those RFCs were written, so you might as well just skip to the howto bits below :-) It turns out, I wrote most of this reply over a year ago... > Also we use ZSK -b 1024 and KSK -b 4096 > even modern google from apnic show example ZSK of only 1024? is this still > secure? The current recommendation for DNSSEC algorithms is: * you already know you want to choose something based on sha256 - it's secure enough, so there's no need for bigger hashes * ecdsa-p256-sha256 (13) is the best choice, because it is widely supported and produces small signatures * if you must use RSA, use 2048 bit keys for both zsk and ksk. 1024 bits is not secure; 2048 has a roughly comparable security level to sha256 (112ish bits vs 128 bits); 4096 is big and slow and probably not worth the cost * I would like to be able to deploy ed25519 (a better elliptic curve than p256) but it is not yet supported well enough > Is best practise for doing this, replacing the keys completely, more or > less like start fresh again? > > We do use inline signing and automatic maintain. I did a wholesale algorithm rollover from RSASHA1 to p256 around the end of 2019 and I wrote an algorithm rollover guide for colleagues in other parts of our university who run their own DNS. It's basically three steps with lots of waiting in between: https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html The "Semi-automated DS updates" section probably isn't relevant to you, and the "Future" section has been made obsolete by dnssec-policy. But the rest of it should guide you through the essentials. (Also, the RIPE NCC does now support CDS records.) And use these DNS checking services to verify that it is working as expected: https://dnsviz.net/ https://zonemaster.net/ Tony. -- f.anthony.n.finchhttps://dotat.at/ Rattray Head to Berwick upon Tweed: North or northeast 4 or 5, occasionally 3 later. Slight or moderate. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Per server instance vs central / shared / redundant instances of BIND
Grant Taylor via bind-users wrote: > > Do you think that per (mail) server instances of BIND are worth the additional > administrative overhead as compared to more central shared instances? Yes, that's what I did when I was doing mail things. There are a few reasons: reduce load on the shared central resolvers; reduce the latency of anti-spam blocklist lookups; better fate-sharing between the SMTP and DNS parts of the mail service. There's not much overlap between the kinds of queries done by mail servers and other DNS users, so there's limited benefit from sharing a single cache. There probably is benefit from sharing a DNS cache between multiple mail servers, but from my point of view it was easier to have one kind of machine that does SMTP + DNS than two different flavours of machine. (The admin effort is per flavour, not per server.) Tony. -- f.anthony.n.finchhttps://dotat.at/ Cape Wrath to Rattray Head including Orkney: Northeast 3 to 5 backing north 3 or 4. Slight or moderate. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re[2]: Configuring the location of named .jnl files
Anders Löwinger wrote: > Ivan Avery Frey wrote: > > > >We are only using update to provision the acme challenge as described > >by RFC 8555 8.4. Nothing else. > > Acme follows CNAMEs. I've redirected all challenges to my domains to a > separate subdomain, which allows dynamic updates. Works great! Yes, there's an item about this on the EFF blog: https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation I wrote a followup which might be of interest on this list even though it isn't relevant to this specific problem: https://fanf.dreamwidth.org/123294.html Tony. -- f.anthony.n.finchhttps://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Configuring the location of named .jnl files
Ivan Avery Frey wrote:
> I'm trying to obtain certificates from Let's Encrypt using the DNS-01
> challenge method.
>
> I just want to confirm that there is no option to configure the
> directory for the .jnl files independently of the zone files.
You have had a bunch of helpful replies already, but your question
suggests to me that you might be making things more difficult than they
need to be. I have tried out configurations with non-default journal names
and I've decided it's more trouble than it is worth. For example, I added
the -J option to named-compilezone to improve support for custom journal
names, but the -j option for default journals is significantly more
convenient. And it's much nicer when I don't have journal options in every
zone{} clause in my config.
I know what they say about assuming, but I'm going to guess that you want
to put the jounal in a different directory because `named` complained that
it did not have write access to the directory containing your zone file.
If I'm right, you will soon find that `named` also wants to overwrite your
zone file, and the message I sent yesterday will probably be helpful:
https://lists.isc.org/pipermail/bind-users/2021-April/104472.html
Tony.
--
f.anthony.n.finchhttps://dotat.at/
Dover, Wight, Portland, Plymouth, North Biscay: Easterly or
northeasterly 5 to 7, decreasing 3 or 4 later, then becoming variable
later. Slight or moderate, becoming smooth or slight, occasionally
rough at first in Plymouth and north Biscay. Fair. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Using RNDC to control remote access to my BIND server
Anand Buddhdev wrote: > Anand's advice is good, as usual :-) But a small pedantic point: > The DNS protocol itself has recently been updated to allow for > encryption, using DTLS (DNS-over-TLS). DTLS usually means "datagram TLS", i.e. TLS-over-UDP (RFC 6347). There's a spec for DNS-over-DTLS (RFC 8094) but I have not seen much enthusiasm for deploying it: DTLS combines all the disadvantages of UDP with all the disadvantages of TLS. (Or worse: DTLS has a more complicated state machine than normal TLS so there have been a bunch of DTLS-specific vulnerabilities which makes me very reluctant to deploy it.) There is a lot more enthusiasm for DNS-over-TLS (aka DoT) and DNS-over-HTTPS (aka DoH), and maybe in the future DNS-over-QUIC. But right now, none of these are particularly easy to get working as transports for UPDATE, and as Anand said, it usually isn't necessary. I'm looking forward to zone transfers over TLS, because public key authentication (with client certificates) is a bit easier to deploy between different organizations than TSIG secret key authentication. There's not such a clear benefit for UPDATE-over-TLS where I'm sitting, apart from the neatness of having all authenticated traffic over TLS. Tony. -- f.anthony.n.finchhttps://dotat.at/ Bailey: Northeast 5 to 7. Moderate or rough. Showers at first. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate and zone files, was Re: Using RNDC to control remote access to my BIND server
Paul Kosinski via bind-users wrote: > A couple of years ago, I tried using nsupdate to modify a dynamic (DHCP) > IP address for my very simple domain. It worked, except that it totally > messed up the organization of the zone file. Since the file only has 44 > active lines (which are organized logically), I maintain it by hand. > After nsupdate made the one line change, the zone file became > unmaintainable. > > Was this a bug in nsupdate, or does nobody try to understand their zone > files. When you have a zone that accepts dynamic updates, then its zone file is owned by `named`, and `named` will rewrite the file to incorporate updates, which (as you saw) also strips out comments and canonicalized the formatting. This is often surprising and upsetting to people who are new to dynamic updates - you are not alone! Basically, if you are doing dynamic updates, then the source of truth for your zone needs to be somewhere else, not the zone file used by `named`. (For example, at my work our zones are stored in a database and edited with a web front end.) I have some scripts which allow you to maintain your zone file however you want, and push any differences into `named` using `nsupdate`, so you never need to touch the zone files that it owns. https://dotat.at/prog/nsdiff/ Tony. -- f.anthony.n.finchhttps://dotat.at/ Lyme Regis to Lands End including the Isles of Scilly: Easterly or northeasterly 5 to 7, occasionally 4 in east. Moderate or rough. Fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using RNDC to control remote access to my BIND server
Greg Donohoe wrote: > I have created a CI/CD pipeline in order to amend zone files using nsupdate > based on a front end user request. This portion of the pipeline is working > as expected so now I want to be able to connect from my pipeline runner to > my remote BIND staging server and update the zone files on there with my > newly updated zone file. If you want to make the same change on the remote server that you made locally, can't you use nsupdate again but point it at the remote server? Or is there something more complicated going on? Use ddns-keygen to create a TSIG authentication key and add the key to the allow-update ACL on the remote server. (You can also add your own TSIG keys to allow remote control with `rndc -s`, but it sounds to me like rndc is a red herring.) There's also my `nsdiff` program https://dotat.at/prog/nsdiff/ which can make a zone on a remote server look like a local zone file using nsupdate. Tony. -- f.anthony.n.finchhttps://dotat.at/ North Utsire, South Utsire: Northerly or northwesterly 4 to 6, occasionally 7 at first in eastern South Utsire. Rough at first in eastern South Utsire, otherwise moderate. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Ask for automated KSK roll with DS checking
Matthijs Mekking wrote: > On 15-04-2021 16:35, Bob Harold wrote: > > > > If BIND holds both the child and parent zone, will it add the DS record > > at the correct time? Or do I still need to write scripts to update the > > DS records in all my sub-zones? And is there some signal from BIND at > > the time the DS record should be written, or do i need to calculate the > > right time? > > Currently you still have to write scripts to update DS records in all > your parent zones. > > The CDS/CDNSKEY records are published in the child zones that indicate > the DS should be published, so I would script against that. > > Then when the DS is seen in the parent, call the rndc dnssec -checkds > published/withdrawn command. dnssec-cds can tell you what the parental DS record(s) should be. It can maintain a dsset file for each child zone that you can $INCLUDE in the parent. It's fairly bare so it needs to be wrapped with a script that does the necessary queries and updates. I don't know if the dnssec-policy stuff includes timing parameters or checks to protect against parental publication delays; if not then the wrapper script will have to keep track of time or poll the parent servers or something. Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle: South 3 to 5, occasionally 6 later. Slight or moderate, becoming rough later in west. Fair. Good.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Preventing a particular type of nameserver abuse
Peter Coghlan wrote: > > I wouldn't describe it as background radiation or probes. It doesn't seem > to be caused by misconfigured or faulty resolvers or anything of that nature. Hmm, maybe air pollution would be a better metaphor? What I mean is the kind of continuous low levels of abuse that's definitely harmful in aggregate, but it's not clear who is responsible or what can be done about it. These sl/IN/ANY queries are exactly the kind of thing I had in mind. > It is possible for me to apply filtering that catches most or maybe all of > this but this only fixes the problem on my server and does nothing to prevent > the abuse of lots of other servers out there. Yeah, it's a wicked problem. There's very little one can do as a server operator except for relatively limited mitigations. The real fix is to trace back the traffic and do malware analysis of the sources and all that fun forensic blue team stuff that is a very long way away from my job or abilities :-) Before DNS I did anti-spam stuff for several years so I have had to make peace with protecting my systems and users from the worst of the abuse, without being in a position to do much about the causes, other than helping to keep our networks clean. > Instead, isn't it the case that bind knows what domains it is authoritative > for (or which ones it is supposed to be authoritative for) and bind is > therefore in the ideal position to know which queries are abusive and which > are not rather than wrapping kludgy filtering mechanisms around it? Not always, sadly, because of misconfigured (lame) delegations. See the earlier messages from me and Ondřej - https://lists.isc.org/pipermail/bind-users/2021-April/104408.html https://lists.isc.org/pipermail/bind-users/2021-April/104423.html > If there is a resistance to having bind ignore the abusive queries > altogether, could we at least have something like "errors-per-minute 1" > which would reduce the problem by a factor of 60 compared with > "errors-per-second 1"? "errors-per-hour 1" would be even better still :-) There is probably something that might improve things, but I'm not sure what it is. I think the minimum RRL rate of 1 per second might be intended to work with resolver retry times. I'm wary of suppressing error responses without thinking through the possible consequences. Tony. -- f.anthony.n.finchhttps://dotat.at/ Viking, North Utsire, South Utsire, Forties: Northerly or northwesterly 3 to 5, becoming variable 3 or less later. Moderate becoming slight. Showers. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Preventing a particular type of nameserver abuse
sth...@nethelp.no wrote: > > Agree that you should be able to ignore them. But as a practical matter, > ignoring them *may* result in the question being asked again and again, > while REFUSED *may* stop the client from asking more. REFUSED leads to retries too: if the client is a legit resolver it will retry using the other authoritative servers. For example, when I changed private.cam.ac.uk from refusing external queries to replying with an empty answer, the load on our auth servers dropped by half. Retries following REFUSED are also one reason why the RFC 8482 minimal-any option is not refuse-any: when an ANY attack is bouncing off a recursive server, the authoritative server can reduce the power of the attack by returning a small cacheable answer. This reduces the load on the authoritative servers (no retries), and on the recursive servers (no need to recurse and retry), and reduces the volume of the attack traffic. Probe traffic like these sl/IN/ANY queries is a very different matter. I wouldn't expect any kind of reasonable behaviour, so it makes sense to drop the queries as early as possible. Tony. -- f.anthony.n.finchhttps://dotat.at/ North Fitzroy, Sole: Easterly or southeasterly 4 to 6. Moderate or rough. Showers at first in northwest Fitzroy, otherwise fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Preventing a particular type of nameserver abuse
Anand Buddhdev wrote: > > A legitimate client, following a normal chain of referrals, has *no* > reason to query a server for zones it is not authoritative for. That's true for cases like .sl and other domains whose delegations are set up correctly, but if a server is accidentally lame then it's helpful to return REFUSED so that resolvers don't have to wait for a timeout before trying other servers. A quick REFUSED will also avoid messing up the resolver's per-server statistics that might interfere with queries for authoritative zones. Tony. -- f.anthony.n.finchhttps://dotat.at/ Southwest Fitzroy: Southeasterly 5 to 7, becoming variable 2 to 4 at times in south. Moderate or rough, occasionally slight in south. Thundery showers, fog patches. Moderate, occasionally very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Preventing a particular type of nameserver abuse
Peter Coghlan wrote: > > I have a nameserver which is authoritative for three or four domain names. > It receives around 1000 queries per day that could be regarded as plausably > legitimate. It receives around ten times that number of absive queries per > day from presumably spoofed ip addresses, the vast majority of them IN ANY > queries for the "sl" domain or for the root nameservers all of which my > nameserver responds to with return code 5 ie refused. There have been several helpful replies, but to be honest I wouldn't spend too much effort on low levels of abuse unless you want to use it as a learning exercise. (I would care if it was multiple abusive queries per second...) > I have tried "errors-per-second 1" and this seems to reduce the abuse > by about four fifths but one fifth of it still manages to get through > and I don't find this acceptable. RRL is designed to avoid interfering with legitimate traffic, but that does mean that some abuse traffic leaks through. Its aim is to stop amplification, so that the attackers don't get any benefit from abusing your server. But it sounds to me like your problem traffic is more like background radiation (e.g. probes) than active abuse; if so it's likely that RRL will not deter them. > Instead, when I notice particularly heavy abuse of my nameserver, > I apply packet filtering to prevent the abusive queries from reaching > my nameserver and therefore to prevent it responding to them. If all the problem traffic is sl. IN ANY, then I suggest permanently leaving in place a filter to drop those queries. Use a string match rule, like Grant Taylor suggested, but match the queries instead of the responses, so they don't clutter your query logs. Tony. -- f.anthony.n.finchhttps://dotat.at/ Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate becoming rough. Fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forwarding zone setup from a BIND slave (without recursion?)
Mark Andrews wrote: > > On 8 Apr 2021, at 00:37, Tony Finch wrote: > > > > Forward zones require the upstream server to be recursive too. > > More correctly, the upstream server has to serve the entire namespace being > forwarded if it does not off recursion to the client for forwarding to > work. I thought forwarding expected the target server to resolve CNAMEs? If so, any out-of-zone CNAMEs in the target namespace would cause problems. Tony. -- f.anthony.n.finchhttps://dotat.at/ Cape Wrath to Rattray Head including Orkney: Southwesterly 6 to gale 8, occasionally 5 at first in east, then veering westerly or northwesterly 7 to severe gale 9 later. Moderate or rough, becoming very rough or high in north. Rain at times, squally snow showers later. Moderate or good, occasionally very poor later. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forwarding zone setup from a BIND slave (without recursion?)
Chuck Aurora wrote: > > A stub or static-stub zone would not require recursion. In that case > named is asking for authoritative data from upstream. But type > forward zones indeed cannot work if recursion is disabled. Be careful in this kind of situation to be very clear about which client or server is doing what: in this case, it isn't clear what doesn't require recursion for stub or static stub. All three types of zone configuration (stub, static stub, and forward) are only useful on a server that is providing recursive service. Forward zones require the upstream server to be recursive too. Stub and static-stub expect the upstream server to be authoritative; the stub server list is a hint that gets replaced by the authoritative server list from the zone (a bit like the root hints) whereas static-stub only uses the configured upstream servers. > > What I've learned from this list is that you should split > > authoritative and recursive service. > > I would suggest that as a general best practice, but not an absolute > one. There's nothing wrong with having internal-only authoritative > zones on your recursive resolver. The potential problem comes when > you're a globally-published NS for your zones; having recursion > enabled can make you vulnerable to more possible attacks. Right: the rule is that authoritative servers listed as targets of NS records should be authoritative-only; it's OK if recursive servers have authoritative copies of zones: it can make them more resilient to outages, though it does slightly weird things to DNSSEC validation. Tony. -- f.anthony.n.finchhttps://dotat.at/ Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4, then southwest 4 to 6 later. Very rough at first in north, otherwise moderate or rough. Snow showers, then rain for a time later. Good, occasionally very poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: replication time for dynamic records from primary to secondary servers
Cuttler, Brian R (HEALTH) via bind-users wrote: > > I don't think the issue I'm having is related to notify message not > being reacted to nor zone transfer requests not being sent to answered. It's worth checking the logs to make sure that they agree with what you expect. > What I think I'm seeing is DHCP updating the DNS primary, which works > correctly, but I don't believe it updates the SOA serial number nor > sends a notify message. The server is required (by RFC 2136 section 3.6) to update the serial number after an UPDATE. I would not expect any delay unless the server is in the middle of a lot of updates and has reached a notify or transfer rate limit - the logs should tell you if that has happened, or if there are any ACL-related problems. Tony. -- f.anthony.n.finchhttps://dotat.at/ Gibraltar Point to North Foreland: Northeasterly backing northwesterly 3 or 4, occasionally 5 at first, backing southwesterly 4 to 6 later. Slight or moderate, becoming mainly slight. Fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local resolution first and then public resolution for "google.com" domain
Matus UHLAR - fantomas wrote: > > note that for this kind setup, using dnsmasq with two forwarders and > www.google.com > overriden through /etc/hosts would be easier solution. Or a response policy zone, if you don't want to switch software https://bind9.readthedocs.io/en/v9_16_13/reference.html#rpz Tony. -- f.anthony.n.finchhttps://dotat.at/ Forties, Cromarty, Forth: Northeast 5 to 7, backing north 3 to 5. Slight or moderate. Rain at first. Good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: resolv.conf question / timeout behaviour
Tom Preissler wrote: > > at my work place we have a three resolver setup in /etc/resolv.conf. > > We had sometimes, though rarely, response times for DNS like 14000ms, > due to the fact that the *first* listed resolver is down for maintenance > reasons. Sadly the traditional unix stub resolver behaves REALLY BADLY if any of its servers are unavailable. It does not keep enough information about server performance and isn't really designed to be able to do that. The resolv.conf tuning options are too coarse to help in any meaningful way. Because of this, if it's important for you to avoid multi-second DNS lookup times (and it usually is!), you need to design your system so that the libc resolver never tries to talk to a DNS server that isn't available. As Matus Uhlar said, one way is to run a resolver daemon (e.g. BIND configured to forward to your recursive servers) on each machine. Resolver daemons are better able to keep track of which server is up, and they are less likely to be unavailable when the client software needs them since they are on the same machine. Most operating systems have resolver daemons now; it's bascially only oldskool unix that needs extra setup. Another way is a high availability setup for your recursive servers. I use keepalived (my servers are on a resilient layer 2 network that spans multiple locations); or you can use anycast if you need to do failover at layer 3. Of course, you can do both :-) Tony. -- f.anthony.n.finchhttps://dotat.at/ Faeroes: North backing west 5 or 6, decreasing 3 or 4 for a time. Moderate or rough. Fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: replication time for dynamic records from primary to secondary servers
Cuttler, Brian R (HEALTH) via bind-users wrote: > > We are seeing a delay in the primary DNS server updating the secondary > and would like to shorten that interval. This is probably due to NOTIFY messages not working. NOTIFY is the mechanism that allows primary servers to tell secondaries to get the latest version of a zone promptly. I wrote some notes on debugging slow zone transfers a couple of weeks ago: https://lists.isc.org/pipermail/bind-users/2021-March/104278.html Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle: North 5 or 6, decreasing 3 or 4, then backing northwest 4 or 5 later. Moderate or rough, becoming slight or moderate. Mainly fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure
alcol alcol wrote: > seriously? is like linux/unix FAQ 😄 Please, if you can't be helpful, don't reply at all. We all have to learn somehow, and the best way to show your knowledge is to share it generously. Tony. -- f.anthony.n.finchhttps://dotat.at/ Trafalgar: Easterly 6 to gale 8 in southeast, otherwise mainly northeasterly 4 to 6. Moderate or rough. Thundery showers. Good, occasionally moderate. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure
Paul Cizmas wrote: > ~$ named -v > BIND 9.9.7-P3 (Extended Support Version) What's probably happening here is that the BIND on your $PATH isn't necessarily the BIND that homebrew installed and (hopefully) is running. You can run `dig @localhost version.bind ch txt` to see what the running server reports as its version. You can run `which named` to find out where it is finding 9.9.7. If you run `rndc status` it should fail, because of the mismatched installations (I expect your 9.9.7 will not look for the rndc key in the same place as 9.16.3) but `/usr/local/opt/bind/sbin/rndc status` ought to work and tell you about the running 9.16.3. Tony. -- f.anthony.n.finchhttps://dotat.at/ Great Orme Head to the Mull of Galloway: Southwest veering west 6 to gale 8, backing southwest 5 to 7 later. Moderate, occasionally rough. Squally showers, rain later. Good, occasionally moderate. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to stop and remove BIND 9.9.7-P3 on Mac OS X High Sierra 10.13.6?
Paul Cizmas wrote: > > but it appears that “service” must be replaced by something else Yes: init on macOS is called launchd, and the service control program is called launchctl, which has a reasonably useful man page. Tony. -- f.anthony.n.finchhttps://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Southerly or southwesterly, veering westerly for a time, 5 to 7, occasionally 4 later. Slight or moderate. Rain or squally showers. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Temporarily no name resolution using second/virtual ip address
Jonathan via bind-users wrote: > It makes no difference from which subnet the queries come from. For > testing I used a server in the same subnet like my DNS is, so there is > no firewall or NAT in between. I also captured the network traffic of > the DNS-Server and -Client. All I can see is, that the server receives > the query from the client, but no response is sent from the server. When > I run dig with the +tcp option, all of the queries will be answered. Do you have a firewall configured on the server itself? If so does it have the correct idea about which ports and addresses BIND is listening on? The other possibility is reverse path filtering - Linux tries to ensure that packets don't traverse an interface with unexpected addresses. I had to turn it off on my recursive servers because they have interfaces on two different VLANs. Dunno if it could cause problems with just one subnet in play. set sysctl net.ipv4.conf.XXX.rp_filter=2 where XXX is all, default, and whatever your ethernet interface is named. Tony. -- f.anthony.n.finchhttps://dotat.at/ North Utsire, South Utsire: Southwesterly 5, backing southerly 6 or 7, occasionally gale 8 in North Utsire. Moderate or rough. Showers. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone transfer is happening intermittently between slave and master bind
Prasanna Mathivanan (pmathiva) via bind-users wrote: > > I couldn’t find anything from logs (checked both xfer and messages) The best way to find out if a secondary server thinks a zone is out-of-date is to look at the notify log messages. On the primary you'll see something like 17-Mar-2021 12:36:28.311 notify: info: zone cam.ac.uk/IN: sending notifies (serial 1615984588) and on a secondary you will see 17-Mar-2021 12:36:28.812 general: info: zone cam.ac.uk/IN/main: notify from 2001:630:212:8::d:aa#43432: serial 1615984588 followed by xfer-out (on the primary) and xfer-in (on the secondary). The xfer messages tell you how much of the zone was transferred but not the serial number. or if the zone is in sync you will see 17-Mar-2021 12:20:36.985 general: info: zone cl.cam.ac.uk/IN/main: notify from 128.232.0.19#44340: zone is up to date If the log messages do not match up like this then something isn't working properly, such as the allow-notify ACL on the secondary - check there aren't any erroneous "refused notify from..." messages in the secondary's logs. You can run `rndc notify` on the primary to trigger it on demand, which can make debugging a bit more convenient. You can use `rndc zonestatus` on the primary and secondary to see what they think the serial numbers are, so you know whether the notify should trigger a transfer or not. Tony. -- f.anthony.n.finchhttps://dotat.at/ Wight, Portland, Plymouth: Northwest veering north or northeast, 3 to 5. Slight or moderate. Mainly fair. Mainly good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: sub-zone on the same server but in different backend - how?
lejeczek via bind-users wrote:
>
> Have a zone on a server, say:
>
> - the.zone
>
> with "flat" files being the backend for it. Now wanting to have:
>
> - sub.the.zone
>
> served by the same BIND server, but stored in.. "SQL" backend.
>
> How... well how to make that work if at all possible?
> I'd hope it can be done with some "trickery" in config/zone files if it is not
> 'easy-peasy'
It's easy if you think about it the right way :-)
That is, there are two separate things that you need to do to set up a
zone:
* In the DNS, in the contents of the parent and child zones, you need to
set up the proper NS records at the delegation point in the parent
zone, and at the apex of the child zone. (Plus whatever other records
your delegation might need, such as nameserver A/ records and
DNSSEC)
* On the servers, configure your DNS software to host the zone.
This is true regardless of how your zones are stored or how your DNS
software is configured.
So for example, if I have a parent zone (e.g. dotat.at) with an
experimental delegation (e.g. ed25519.dotat.at) and the child zone is only
hosted on the primary server, I just put that server in the NS records,
e.g.
ed25519.dotat.at. NS onyx.dotat.at.
in both parent and child zones.
That's the first point dealt with.
Regarding the second point, in my example the two zones have very similar
zone{} configurations: they both use "raw" files on disk. But they could
use different storage back-ends if I wanted. For that I would need a dlz{}
or dyndb{} clause to configure the backend. I haven't tried either of them
myself, so I haven't talked about how you actually get the data into a
SQL backend - this is as far as I can help :-)
Tony.
--
f.anthony.n.finchhttps://dotat.at/
Malin, Hebrides, Bailey: South 4 or 5, veering west or northwest 5 to 7,
occasionally gale 8 later except in Malin. Moderate or rough, occasionally
very rough in north Bailey. Rain and fog patches. Moderate, occasionally
very
poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Authority and forwarding, but not recursion/iteration
Marki wrote: > > But if you need granular filtering, that could become a lot of views... Yes, I think RPZ is really designed to be a ban hammer for dealing with abuse, rather than a general-purpose access control mechanism. If you need to get really fancy then you should look at dnsdist which can be programmed in Lua. Tony. -- f.anthony.n.finchhttps://dotat.at/ Fitzroy: Westerly 4 to 6 in south, otherwise 7 to severe gale 9. Rough in south, otherwise very rough or high. Showers, squally in north. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Authority and forwarding, but not recursion/iteration
Marki wrote: > > Concerning static-stub: Using a (bogus) forwarder together with "forward > first" (default) seems to work (Note: using "forward only" gives SERVFAIL). > All outside requests get a SERVFAIL even with "forward first" but that's an > esthetic problem. Yes, SERVFAIL is ugly - I should have mentioned that. > I'm not sure about the flexibility of RPZ; it doesn't seem that I can > have rules like "client 1.2.3.4 is allowed to look up example.com but > client 1.2.3.5 is not". You can have multiple response-policy zones, which are matched in the order they are listed in the configuration. You could perhaps have a zone listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for non-sandboxed clients, then have a zone containing QNAME triggers (with liberal use of wildcards) and PASSTHRU policy (again) for just the permitted internal names, and finally a catch-all zone (wildcard to match any qname) with an NXDOMAIN policy to deny external names for sandboxed clients. (You can equally well combine the first two into a single zone, depending on whether you want more single-purpose RPZs or fewer multi-purpose ones.) Tony. -- f.anthony.n.finchhttps://dotat.at/ Forties, Cromarty, Forth: South or southeast 5 to 7, increasing gale 8 or severe gale 9 for a time. Slight or moderate, becoming rough later, occasionally very rough except in Forth. Rain. Good, becoming moderate or poor for a time. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Authority and forwarding, but not recursion/iteration
Marki wrote:
>
> I am seeking a combination of either a combined configuration on one, or a
> config of several different DNS servers together to achieve the following:
>
> * Some clients should be able to resolve authoritative local zones as well as
> some forwarded zones.
>
> * Other clients should be able to resolve all of that _plus_ be able to make
> recursive queries to the internet (or use a global forwarder).
In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)
It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.
[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]
When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)
[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]
Your question is now, how to provide a restricted recursive service?
The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.
I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.
You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):
forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};
then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.
Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)
Tony.
--
f.anthony.n.finchhttps://dotat.at/
Irish Sea: South or southwest 4 to 6, increasing 7 to severe gale 9 for a
time. Slight or moderate, becoming rough or very rough for a time. Rain.
Moderate occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
