RHEL, Centos, Fedora rpm 9.16.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpms, and build instructions. geoip support is not available, since geoip2 is not available in the epel repositories. libuv is in the EL7 epel repository; for EL6 a link is included to a source rpm. SELinux needs a custom policy, link included. This also fixes the issue with running bind on a machine in enforcing mode under KVM. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAl6h854ACgkQL6j7milTFsGK5ACfQWX+wNpzHH4u6JNHh51xXkSe QOUAn3jU9gvZMrztcO57agdTYB84sOJp =fw26 -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about expected recursive resolver behavior
Sarah Newman wrote: > What should happen when for a given domain: > > - The domain resolves via TCP but not UDP - UDP for this domain had no > response at all. I would expect the domain to be completely unresolvable: the resolver will only try TCP if it gets a truncated reaponse over UDP. > - That authoritative nameserver hosts other domains, and those domains > resolve via UDP. The lack of response for some domains might cause problems for the other domains if the resolver decides that the authoritative server is too broken to bother asking. Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: Variable 3 or less, increasing 4 at times. Moderate. Fair. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about expected recursive resolver behavior
On 4/23/20 12:41 PM, Chuck Aurora wrote: On 2020-04-23 14:16, Sarah Newman wrote: What should happen when for a given domain: - The domain resolves via TCP but not UDP - UDP for this domain had no response at all. - That authoritative nameserver hosts other domains, and those domains resolve via UDP. Do you have an example for this? I don't get the "no response on UDP" part. If the same nameserver is answering other queries on UDP, why wouldn't at least send a REFUSED reply? Perhaps REFUSED has been disabled somehow; that could be tested by querying it for other non-hosted zones, dig @ ns isc.org. Here is my example, but it's been fixed now: https://prgmr.com/blog/2020/04/23/debugging-freebsd-resolution-failure.html REFUSED hasn't been disabled. I bring this up because we had customers complaining about our resolvers not working and I don't know if we could/should have done better. --Sarah ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about expected recursive resolver behavior
On 2020-04-23 14:16, Sarah Newman wrote: What should happen when for a given domain: - The domain resolves via TCP but not UDP - UDP for this domain had no response at all. - That authoritative nameserver hosts other domains, and those domains resolve via UDP. Do you have an example for this? I don't get the "no response on UDP" part. If the same nameserver is answering other queries on UDP, why wouldn't at least send a REFUSED reply? Perhaps REFUSED has been disabled somehow; that could be tested by querying it for other non-hosted zones, dig @ ns isc.org. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question about expected recursive resolver behavior
What should happen when for a given domain: - The domain resolves via TCP but not UDP - UDP for this domain had no response at all. - That authoritative nameserver hosts other domains, and those domains resolve via UDP. I found https://www.isc.org/blogs/refinements-to-edns-fallback-behavior-can-cause-different-outcomes-in-recursive-servers/ but I'm not sure if this case is covered or not. --Sarah ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-users Digest, Vol 3427, Issue 1
On 4/23/20 3:39 AM, bind-users-requ...@lists.isc.org wrote:
Where would you like bug reports sent to? GitHub, your email, elsewhere?
Site: https://github.com/egberts/vim-syntax-bind-named
Issue: https://github.com/egberts/vim-syntax-bind-named/issues
```bash
git clone https://github.com/egberts/vim-syntax-bind-named.git
```
E.g. deny-answer-addresses and deny-answer-aliases don't highlight
properly when they have the except-from { ... } and this throws off the
rest of the file. Remarking except-froms returns normal syntax
highlighting.
deny-answer-addresses { ... } except-from { ... };
deny-answer-aliases { ... } except-from { ... };
Feh. Really thought I saw 'except from' as two separate Bind clause
keywords for the 'deny-answer-*' options.
Fixed it as 'exceptDASHfrom' and pushed it to said Github.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange log messages
Lars Kollstedt wrote: > One of the arpa-Nameservers 192.5.5.241, 2001:500:2::c which is the C-Root- > Server is shown to be not responsive for queries over UDP by DNSviz for a long > time. This is due to a stupid peering disagreement between a couple of very stubborn tier 1 transit providers. Tony. -- f.anthony.n.finchhttp://dotat.at/ Malin, Hebrides, Bailey: Variable mainly northeasterly 2 to 4, occasionally 5 in east Malin and east Hebrides. Slight or moderate in east Malin and east Hebrides, but elsewhere moderate throughout. Fair. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Vim Syntax, New Release for ISC Bind named.conf 5.16
Steve Egbert wrote: > I haven't worked on the zone syntax file yet. It hasn't changed since v9.5 > days. That should be my next subproject. That will be great! when I use nsvi, vim gets bright red and angry about lots of fun records like DS, SSHFP, URI, EUI48, and RFC 3597 custom records. Which makes the colouring rather less helpful than it should be! Tony. -- f.anthony.n.finchhttp://dotat.at/ Isle of Man: Variable mainly northeast 2 to 4. Smooth or slight. Fair. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nsupdate and TTL
Mark Andrews wrote: > > On 23 Apr 2020, at 07:20, Evan Hunt wrote: > > > > As far as I can recall, the only way to change a TTL in nsupdate is to > > delete the whole RRset and then add it back in the same transaction: There's actually a standard shortcut for TTL changes which is a consequence of the slightly unexpected UPDATE semantics that we discussed at the start of the month (https://lists.isc.org/mailman/htdig/bind-users/2020-April/102851.html) If an update message contains a new record with the same RDATA as an existing record, then the new record replaces the existing record. This is usually a no-op, because all the other fields in the record necessarily match - except if you are changing the TTL! So you can simply re-write an existing RRSet with a new TTL, without deleting anything. This has the great advantage of avoiding the contradictory ordering requirements that you get from apex NS records and CNAME records: to change a CNAME you must delete then add, but to (completely) change an apex NS RRset you must add then delete. nsdiff always does a delete then add so that it doesn't need special case code for one weird RRset. The apex NS RRset case is very rare - the only time I encounter it is when bootstrapping a zone from scratch, in which case I need a second run of nsdiff to get rid of my "empty" zone `NS localhost` record :-) > Also don’t forget to add a prerequisite section to ensure you are removing > the records you think you are. nsdiff takes another shortcut here: it only uses the SOA serial number as a prerequisite check, because if the serial number matches, then the zone hasn't changed from the source zone file that nsdiff was working from. nspatch includes an automatic retry loop in case the zone changes unexpectedly, which is safe so long as conflicting changes only happen from DNSSEC signing activity. http://dotat.at/prog/nsdiff/ Tony. -- f.anthony.n.finchhttp://dotat.at/ Forth, Tyne, Dogger: Northeast backing north later, 3 or 4. Slight. Fog patches later. Good, becoming poor or very poor later.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange log messages
Hi Tony, hi List, on Mittwoch, 22. April 2020 12:27:27 CEST Tony Finch wrote: > Older versions of BIND can fall back to non-DNSSEC queries for DNSSEC > zones. This can be more common if there is network disruption (I don't > know if the CenturyLink fibre cut issues have been resolved yet...) One of the arpa-Nameservers 192.5.5.241, 2001:500:2::c which is the C-Root- Server is shown to be not responsive for queries over UDP by DNSviz for a long time. I haven't found out which flags to set to reproduce this, yet. e.g. https://dnsviz.net/d/1.4.0.0.8.b.1.4.1.0.0.2.ip6.arpa/dnssec/ but dig DNSKEY arpa +tries=1 +dnssec +notcp @2001:500:2::c simply works for me, and all others I tried, too. Today there are also similar issues shown up with 193.0.9.2 and 2001:67c:e0::2 for ip6.arpa and 193.0.9.5 for 82.in-addr.arpa, I also can't reproduce them. So we're possibly not needing link saturation to trigger this. ;-) But when I understand this bug correctly, the issue is that bind9 is trying some combinations that simply won't work when trying DNS Protocol legacy in combination with DNSSEC. This causes unnecessary traffic and log messages but there are no invalid results cached due to this. The only case this can turn things worst is in combination with rate limiting or link saturation. The only thing that IMHO does'nt really fit into this is, how could the same message occur e.g. on 09:29:49, 09:29:56, 09:30:18, 09:34:02 and 09:35:39 when the TTL is 3600, refresh is 1800 and retry 900. From my understanding, the SOA-RR and its RRSIG should be cached once a successful combination was found, and there should be no further queries like this for at least 1800 seconds. Or are there DNS extensions causing this RR to be cached multiple times? I would expect such for www.google.de IN A or but not for in-addr.arpa IN SOA. ;-) I don't experience any delays when doing my troubleshooting queries, and I'm seeing the TTL properly decreasing when querying the resolver. Kind regards, Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: l...@man-da.de man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der man-da.de GmbH: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nsupdate and TTL
> On 23 Apr 2020, at 17:31, Petr Bena wrote: > > Hello, > > From my experience you don't need to delete whole set, I was actually doing > this quite recently and discovered and interesting behavior of BIND server - > last record you add will override the TTL value for a set. > > So if you add another NS record to a zone, all existing NS records will have > TTL overriden with the last one you add. Which is a side effect of BIND having a single TTL per RRset as I said below. To use UPDATE to change records on any DNS server please use the methods listed below. The UPDATE message is a bit larger but it is robust. Mark > On 23/04/2020 01:06, Mark Andrews wrote: >> >>> On 23 Apr 2020, at 07:20, Evan Hunt wrote: >>> >>> On Wed, Apr 22, 2020 at 03:04:38PM -0600, @lbutlr via bind-users wrote: # nsupdate -k /path/to/key > zone example.com > ttl 3600 > send > ^d No errors, but no change in the TTL. >>> "ttl 3600" just means "from now on assume I mean ttl 3600 in all the >>> records I send". You didn't actually send an update, so nothing changed.. >>> >>> As far as I can recall, the only way to change a TTL in nsupdate is to >>> delete the whole RRset and then add it back in the same transaction: >>> zone example.com ttl 3600 update del example.com in a update add example.com in a 192.0.2.1 update add example.com in a 192.0.2.2 update add example.com in a 192.0.2.3 send >> Also don’t forget to add a prerequisite section to ensure you are removing >> the records you think you are. >> >> zone example.com >> ttl 3600 >> prereq yxrrset example.com in a 192.0.2.1 >> prereq yxrrset example.com in a 192.0.2.2 >> prereq yxrrset example.com in a 192.0.2.3 >> update del example.com in a >> update add example.com in a 192.0.2.1 >> update add example.com in a 192.0.2.2 >> update add example.com in a 192.0.2.3 >> send >> >> Also note you can’t do it this way for the NS RRset at top of zone. You >> need to >> delete the NS RRs individually and then add them back without deleting all >> the >> NS at any point in the process as the NS RRset is required to always exist. >> >> Note: named only keeps a single TTL for a RRset so it will update the TTL on >> all >> the records when you add a new one with a different TTL but this is not part >> of >> the UPDATE RFC. >> > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nsupdate and TTL
Hello, From my experience you don't need to delete whole set, I was actually doing this quite recently and discovered and interesting behavior of BIND server - last record you add will override the TTL value for a set. So if you add another NS record to a zone, all existing NS records will have TTL overriden with the last one you add. On 23/04/2020 01:06, Mark Andrews wrote: On 23 Apr 2020, at 07:20, Evan Hunt wrote: On Wed, Apr 22, 2020 at 03:04:38PM -0600, @lbutlr via bind-users wrote: # nsupdate -k /path/to/key zone example.com ttl 3600 send ^d No errors, but no change in the TTL. "ttl 3600" just means "from now on assume I mean ttl 3600 in all the records I send". You didn't actually send an update, so nothing changed.. As far as I can recall, the only way to change a TTL in nsupdate is to delete the whole RRset and then add it back in the same transaction: zone example.com ttl 3600 update del example.com in a update add example.com in a 192.0.2.1 update add example.com in a 192.0.2.2 update add example.com in a 192.0.2.3 send Also don’t forget to add a prerequisite section to ensure you are removing the records you think you are. zone example.com ttl 3600 prereq yxrrset example.com in a 192.0.2.1 prereq yxrrset example.com in a 192.0.2.2 prereq yxrrset example.com in a 192.0.2.3 update del example.com in a update add example.com in a 192.0.2.1 update add example.com in a 192.0.2.2 update add example.com in a 192.0.2.3 send Also note you can’t do it this way for the NS RRset at top of zone. You need to delete the NS RRs individually and then add them back without deleting all the NS at any point in the process as the NS RRset is required to always exist. Note: named only keeps a single TTL for a RRset so it will update the TTL on all the records when you add a new one with a different TTL but this is not part of the UPDATE RFC. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
