Re: fixed rrset ordering - is this still a thing?
On 02/03/2024 11:36, Greg Choules wrote: Please don't encourage using "search" in resolv.conf or the Windows equivalent. Search domains make queries take longer, impose unnecessary load on resolvers and make diagnosis of issues harder because, when users say "it doesn't work" you have no idea what it was that didn't work. This is not necessarily the case. If you are running your own recursive resolvers that hold mirrors of the root zone, and if you only have a few search domains, the impact will be negligible. Then it is a question of ergonomics. I tried using separate subdomains for different interfaces on devices once and ran into exactly that problem. There's also the overhead of maintaining more zones than you really need. Using sub-domains doesn't mean you have to create separate zones. All the example names I gave could be included in the "example.com" zone. -- 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: fixed rrset ordering - is this still a thing?
Please don't encourage using "search" in resolv.conf or the Windows equivalent. Search domains make queries take longer, impose unnecessary load on resolvers and make diagnosis of issues harder because, when users say "it doesn't work" you have no idea what it was that didn't work. I tried using separate subdomains for different interfaces on devices once and ran into exactly that problem. There's also the overhead of maintaining more zones than you really need. My suggestion would be to replace the dot with a hyphen. That is, instead of: firewall1.example.com = Internet IP address firewall1.dmz.example.com = IP address on DMZ network firewall1.management.example.com = IP address on out-of-band management network do: firewall1-internet.example.com = Internet IP address firewall1-dmz.example.com = IP address on DMZ network firewall1-management.example.com = IP address on out-of-band management network You could even CNAME firewall1 to firewall1-management as this is (presumably) the interface that users and monitoring/management tools will want to reach by default. The hostname of the box is "firewall1" but each interface on it has a unique name, derived from the hostname plus a "-" suffix. Select a set of well known and used suffixes for your environment. If someone really wants to try and SSH to the Internet interface (though I don't understand why you would), they know the hostname and they know the suffix, so it's a simple matter of combining them. On Fri, 1 Mar 2024 at 21:11, Nick Tait via bind-users < bind-users@lists.isc.org> wrote: > On 02/03/2024 03:42, Mike Mitchell via bind-users wrote: > > Our networking team is in the habit of entering the IP address of every > network interface on a router under one name. The very first address > entry is their out-of-band management interface. "rrset-order fixed" is > used on their domain for address records, so they can ssh to the router > by name reliably and not have to worry about interfaces that are down > or that filter SSH. > > I wonder if an alternative (cleaner?) solution to your use case could be > to use different sub-domains for the different networks (network > interfaces)? For example: > > firewall1.example.com = Internet IP address > firewall1.*dmz*.example.com = IP address on DMZ network > firewall1.*management*.example.com = IP address on out-of-band management > network > > If you did this you could make use of DNS search domains to allow > different parts of the network to resolve the unqualified name "firewall1" > differently. E.g. If you "ssh firewall1" from a management host it could > expand that to firewall1.*management*.example.com? > > Nick. > -- > 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 > -- 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: fixed rrset ordering - is this still a thing?
On 02/03/2024 03:42, Mike Mitchell via bind-users wrote: Our networking team is in the habit of entering the IP address of every network interface on a router under one name. The very first address entry is their out-of-band management interface. "rrset-order fixed" is used on their domain for address records, so they can ssh to the router by name reliably and not have to worry about interfaces that are down or that filter SSH. I wonder if an alternative (cleaner?) solution to your use case could be to use different sub-domains for the different networks (network interfaces)? For example: firewall1.example.com = Internet IP address firewall1./dmz/.example.com = IP address on DMZ network firewall1./management/.example.com = IP address on out-of-band management network If you did this you could make use of DNS search domains to allow different parts of the network to resolve the unqualified name "firewall1" differently. E.g. If you "ssh firewall1" from a management host it could expand that to firewall1./management/.example.com? Nick. -- 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: Problem upgrading to 9.18 - important feature being removed
Hi there, On Fri, 1 Mar 2024, Petr ?pa?ek wrote: On 01. 03. 24 12:23, G.W. Haywood wrote: ... Maybe the lesson here is that if you're using BIND other than because it happened to come with your distro, then it's probably a good idea to keep an eye on this list to monitor the plans for development.? If it says that in the ARM, which IMO it probably should, I missed that too. ARM has warning like this: https://bind9.readthedocs.io/en/v9.18.15/reference.html#namedconf-statement-auto-dnssec If you have a proposal to improve it I'm all ears. That warning is (a) specific to this issue and (b) in section 8. I was thinking of something (a) more general and (b) in section 1 - where people might see it before the attention span gives out. :) Section 1.4.6 seems the obvious existing place to say something like "The BIND users' mailing list is the place for users to get help with BIND. In addition the developers use it to gauge opinion on proposals for changes to BIND's features. If you use BIND more than casually, it's a good idea to subscribe to the list. You can do this by..." -- 73, Ged. -- 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: Problem upgrading to 9.18 - important feature being removed
On Fri, 1 Mar 2024, Ondřej Surý wrote: I wanted to address this comment. We (the developers) don't remove the features out of convenience or because we have 'better idea'. It's a known problem with humans that the discipline to remove items is oftentimes lacking, and that humans will tend to solve problems or "improve" things by implementing additive rather than subtractive measures. It's enough of a mental schism to consider adding and removing items as equivalent to different processes IMO. A maintainable software can't look like Katamari[1]. With the former insight, this remark may look a little different than it otherwise would. ;-) Removing unused things is an honorable and admirable objective: keep up the good work. You come onto this mailing list and tell us about it, typically well in advance. I'm generally in favor of removing unused features; emphasis is of course on "unused". -- Fred Morris, internet plumber-- 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: fixed rrset ordering - is this still a thing?
Our networking team is in the habit of entering the IP address of every network interface on a router under one name. The very first address entry is their out-of-band management interface. "rrset-order fixed" is used on their domain for address records, so they can ssh to the router by name reliably and not have to worry about interfaces that are down or that filter SSH. We also have cases where redundancy is being configured but is not yet complete. In that case only the first IP is active. If we don't use "rrset-order fixed" we get complaints that connections take too long and there must be a network error. Mike Mitchell -Original Message- From: bind-users On Behalf Of Ondrej Surý Sent: Thursday, February 29, 2024 4:40 PM To: BIND Users Mailing List Subject: fixed rrset ordering - is this still a thing? EXTERNAL Hey, BIND 9 supports a fixed rrset ordering (that is keeping the order of the RRSets from the zone file). It has to be configured at the compile time, it takes more memory (to record that order) and it's a #ifdef all over the places. So, henceforth, my question - does anyone still uses that? And if yes, what are the use cases? I think BIND is the only server that actually supports this, so it doesn't feel like the DNS can't function without it. Thanks, Ondřej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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 -- 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: Problem upgrading to 9.18 - important feature being removed
On 01. 03. 24 12:23, G.W. Haywood wrote: Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' configurations? Is there a use case that is not (yet) covered by 'dnssec-policy'? Any other concerns? Please let us know. 8<-- To try to make this more positive, Maybe the lesson here is that if you're using BIND other than because it happened to come with your distro, then it's probably a good idea to keep an eye on this list to monitor the plans for development. If it says that in the ARM, which IMO it probably should, I missed that too. ARM has warning like this: https://bind9.readthedocs.io/en/v9.18.15/reference.html#namedconf-statement-auto-dnssec If you have a proposal to improve it I'm all ears. -- Petr Špaček Internet Systems Consortium -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01/03/2024 11:02, Jim Reid wrote: On 1 Mar 2024, at 10:37, Greg Choules via bind-users wrote: In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. Well said Greg! Leave it to the application to decide which is the best* address in the list of addresses returned from a DNS lookup. IMO the DNS (mostly) provides name-address mapping info and it’s up to whoever receives that info to decide how it gets processed and acted on. This is not a job for BIND or other DNS servers. * For some definition of best +1 -- 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: fixed rrset ordering - is this still a thing?
On 29 Feb 2024, at 21:39, Ondřej Surý wrote: > Hey, > > BIND 9 supports a fixed rrset ordering (that is keeping the order of the > RRSets from the zone file). It has to be configured > at the compile time, it takes more memory (to record that order) and it's a > #ifdef all over the places. > > So, henceforth, my question - does anyone still uses that? And if yes, what > are the use cases? > > I think BIND is the only server that actually supports this, so it doesn't > feel like the DNS can't function without it. I know that Solaris distribution enables it, but purely to be backward compatible. With what I don't know! -- 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: Problem upgrading to 9.18 - important feature being removed
Hi there, On Fri, 1 Mar 2024, Ond?ej Sur? wrote: On 26. 2. 2024, at 22:41, Al Whaley wrote: > A lot of pain and suffering in this world comes from people being > sure they have a 'better idea' and everybody needs to do whatever. > This feels a bit like that. ... ... ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement ... For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications ... And in this case I think it would be unfair to the developers not to mention that more than two years ago, before actually implementing this change, the developers did ask for comment and there was debate. If the OP took a part in that debate I missed it. 8<-- Date: Tue, 10 Aug 2021 10:02:59 +0200 From: Matthijs Mekking To: bind-users@lists.isc.org Subject: Deprecating auto-dnssec and inline-signing in 9.18+ Message-ID: Content-Type: text/plain; charset=utf-8; format=flowed Hi users, We are planning to deprecate the options 'auto-dnssec' and 'inline-signing' in BIND 9.18. The reason for this is because 'dnssec-policy' is the preferred way of maintaining your DNSSEC zone. Deprecating means that you can still use the options in 9.18, but a warning will be logged and it is very likely that the options will be removed in BIND 9.20. We would like to encourage you to change your configurations to 'dnssec-policy'. See this KB article for migration help: https://kb.isc.org/docs/dnssec-key-and-signing-policy Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' configurations? Is there a use case that is not (yet) covered by 'dnssec-policy'? Any other concerns? Please let us know. 8<-- To try to make this more positive, Maybe the lesson here is that if you're using BIND other than because it happened to come with your distro, then it's probably a good idea to keep an eye on this list to monitor the plans for development. If it says that in the ARM, which IMO it probably should, I missed that too. -- 73, Ged. -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
> On 1 Mar 2024, at 10:37, Greg Choules via bind-users > wrote: > > In summary, Do the hard work of traffic steering somewhere else and let your > DNS resolvers deliver the chosen answer. Don't make the resolvers themselves > try to do this on the basis of incomplete information. Well said Greg! Leave it to the application to decide which is the best* address in the list of addresses returned from a DNS lookup. IMO the DNS (mostly) provides name-address mapping info and it’s up to whoever receives that info to decide how it gets processed and acted on. This is not a job for BIND or other DNS servers. * For some definition of best -- 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: occasional SERVFAIL error
This is usually a symptom of child NS being broken. It works with empty cache because of the NS records in parent work, but then child NS take over and boom! -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 29. 2. 2024, at 15:20, Ludovit Koren wrote: > > I can get rid of it only after issuing: > > rndc flush -- 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: occasional SERVFAIL error
On 29.02.24 15:20, Ludovit Koren wrote: occasionally I get the following SERVFAIL error: dig www.jiscd.sk ; <<>> DiG 9.18.24 <<>> www.jiscd.sk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 35fe56eb9b5f3f22010065df34b4c313eedf839eac9d (good) ;; QUESTION SECTION: ;www.jiscd.sk. IN A ;; Query time: 17 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 28 14:27:16 CET 2024 ;; MSG SIZE rcvd: 69 I can get rid of it only after issuing: rndc flush Afterwards it works for uncertain time. Could it be I have a configuration problem of my server (I have prefetch 0 set in options section of my server)? Is it a problem of the authorized domain server? I have looked onto it manually, so far found nothing. rndc dumpdb could generate named output where you should be able to find out the culprit. the difference between current version of zone between ns1.gov.sk and ns2.gov.sk could affectg this problem. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question! -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
2nd $beverage consumed. I have never liked sortlist since I inherited it 16 years ago in my previous job. For me it suffers from at least one fundamental problem: - If a client, say at location "1", is given a bunch of sorted A records with the server at location "1" first, what does the client do when the server at location "1" is down? Clients come in many varieties. Some are capable of cacheing multiple answers, timing out and trying a different one, some are not. This leads to service reliability issues because, even though a perfectly healthy instance of the service may exist at site "2", clients (at site "1") are still told by DNS, go to site "1" The DNS service is not (by default) either application or client-aware. It just gives the answers you tell it to, whether they're working or not. If you want an efficient, reliable multi-site service, use load-balancers that can direct traffic from local clients to a local service instance, or use an application aware DNS server (I can think of one; I'm sure others exist) that monitors availability, delay and whatever other metrics are important and feeds the DNS resolvers with *the* answer they want them to give to a client at this moment in time. ECS would even allow said box to be aware of client location, to use as an additional metric when making this decision. In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. On Fri, 1 Mar 2024 at 10:12, G.W. Haywood wrote: > Hi there, > > On Fri, 1 Mar 2024, Matus UHLAR wrote: > > On 01.03.24 08:24, Ond?ej Sur? wrote: > > > The "sortlist" option allows to define a complicated rules when and > > > how to reorder the resource records in the responses. The same > > > caveats as with the "rrset-order" apply - relying on any specific > > > order of resource records in the DNS responses is wrong. > > > > > > We are not aware of any other (major) DNS server that would have > > > similar behaviour as this was never specified in the DNS protocol. > > > If you know of any software or hardware relying on any specific > > > order of the resource records in the DNS messages, it needs to > > > be reported as a bug to the respective vendor. > > > > I don't know about _requirement_, but I have used this option as poor > > man's way to implement geographically local IP addresses > > - to anyone return topologically closer IP addresses first, others next. > > Maybe I need more of my morning $beverage but this sort of thing seems > to me to militate against other - existing - efficiency mechanisms. > > Network performance isn't just about topology, there are things like > performance and load to consider. Might your tweaked responses just > send clients to a nearby but tragically overloaded server? > > My preference would be to let those people whose job it is to think > about this stuff - which, reading this list, clearly they do - get on > with their job. > > Observations welcome of course. > > -- > > 73, > Ged. > -- > 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 > -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
Hi there, On Fri, 1 Mar 2024, Matus UHLAR wrote: On 01.03.24 08:24, Ond?ej Sur? wrote: > The "sortlist" option allows to define a complicated rules when and > how to reorder the resource records in the responses. The same > caveats as with the "rrset-order" apply - relying on any specific > order of resource records in the DNS responses is wrong. > > We are not aware of any other (major) DNS server that would have > similar behaviour as this was never specified in the DNS protocol. > If you know of any software or hardware relying on any specific > order of the resource records in the DNS messages, it needs to > be reported as a bug to the respective vendor. I don't know about _requirement_, but I have used this option as poor man's way to implement geographically local IP addresses - to anyone return topologically closer IP addresses first, others next. Maybe I need more of my morning $beverage but this sort of thing seems to me to militate against other - existing - efficiency mechanisms. Network performance isn't just about topology, there are things like performance and load to consider. Might your tweaked responses just send clients to a nearby but tragically overloaded server? My preference would be to let those people whose job it is to think about this stuff - which, reading this list, clearly they do - get on with their job. Observations welcome of course. -- 73, Ged. -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01.03.24 08:24, Ondřej Surý wrote: The "sortlist" option allows to define a complicated rules when and how to reorder the resource records in the responses. The same caveats as with the "rrset-order" apply - relying on any specific order of resource records in the DNS responses is wrong. We are not aware of any other (major) DNS server that would have similar behaviour as this was never specified in the DNS protocol. If you know of any software or hardware relying on any specific order of the resource records in the DNS messages, it needs to be reported as a bug to the respective vendor. I don't know about _requirement_, but I have used this option as poor man's way to implement geographically local IP addresses - to anyone return topologically closer IP addresses first, others next. I found it especially nice because it doesn't matter which service are we using - if there are multiple IP's for _anything_, return topologically closer first. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... -- 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: Problem upgrading to 9.18 - important feature being removed
On 01. 03. 24 8:01, Ondřej Surý wrote: On 26. 2. 2024, at 22:41, Al Whaley wrote: A lot of pain and suffering in this world comes from people being sure they have a 'better idea' and everybody needs to do whatever. This feels a bit like that. A command that gives choice and real certainty would be great. Hi, I wanted to address this comment. We (the developers) don't remove the features out of convenience or because we have 'better idea'. A maintainable software can't look like Katamari[1]. Yes, sometimes we have better ideas (without the quotes) and we implement them, because they make things simpler, better, more stable, faster, ... add your own. Sometimes we even break things. But ultimately, the developers working on BIND 9 are just a few people and it's absolutely reasonable to remove rarely used features - especially if there's a replacement either in or out of BIND 9. Giving a choice is great, but then **who** will carry the costs of giving the choice? Maintaining all kind of knobs and options does come with burden and that burden might ultimately lead to a situation where all the time and resources are spent on maintaining those old features, and there's not enough left to add new improvements. For every decision we make, be it adding a new feature or removing an old feature, we do carefully consider the implications it has on the users, on the developers, and on the world as a whole. And it is kind of hurtful to imply that we do things just because "we know better" (paraphrasing). I want to add a math exercise. Assume: - BIND config has 300 statements - none are context-dependent - all statements have only yes/no options - all bugs are caused ONLY by combination two options - all bugs are 100 % reproducible and do not depend on data (cache, zones, RPZ rules etc.) Under these very simplistic assumptions we get roughly 300!/(300-2)! = 89 700 subsets of 2 statements. For these, we get 89 700 * 4 = 358 800 possibly problematic boolean combinations. Mere 358 800 config combinations to test! Piece of QA cake, obviously. -- Petr Špaček Internet Systems Consortium P.S. My combinatorics is really really rusty, but I think that even if I got it wrong by two orders of decimal magnitude you get the idea. -- 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: occasional SERVFAIL error
> Peter Davies writes: > Hi Ludovit, > It looks like you have two version of the jiscd.sk zone. > host -C jiscd.sk > Nameserver 2001:67c:1bd4:8080::20: > jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 > 604800 86400 > Nameserver 195.49.191.160: > jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 > 604800 86400 > Nameserver 2001:67c:1bd4:8080::10: > jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 > 604800 86400 > Nameserver 195.49.191.162: > jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 > 604800 86400 Hello Peter, I just reported one domain. Here is the listing of all 3 I am aware of: [root@graham /usr/home/koren]# host -C jiscd.sk Nameserver 195.49.191.162: jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024030100 7200 3600 604800 86400 Nameserver 195.49.191.160: jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 604800 86400 [root@graham /usr/home/koren]# host -C jishmsr.sk Nameserver 195.49.191.162: jishmsr.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 604800 86400 Nameserver 195.49.191.160: jishmsr.sk has SOA record ns1.gov.sk. gov.sk. 2024022600 7200 3600 604800 86400 [root@graham /usr/home/koren]# host -C isepvo.sk Nameserver 195.49.191.160: isepvo.sk has SOA record ns1.gov.sk. gov.sk. 2024022600 7200 3600 604800 86400 Nameserver 195.49.191.162: isepvo.sk has SOA record ns1.gov.sk. gov.sk. 2024022600 7200 3600 604800 86400 [root@graham /usr/home/koren]# The other 2 seem to have the same version and it still happens to them. Yes, it is on the same 2 authoritative NS. Regards, lk -- 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
