Re: Nsupdate and TTL
> 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. -- 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: Vim Syntax, New Release for ISC Bind named.conf 5.16
On 4/22/20 12:32 PM, Steve Egbert wrote:
Hello, Bind-Users,
Hi,
This is my 2nd post (in 19 years).
Welcome.
I'm announcing the release of ISC Bind v9.16 named.conf syntax file for
Vim editor.
Thank you!
The color scheme is derived from default Vim highlights using your own
color scheme.
:-)
Have it, folks! I hope you enjoyed it as much as I did
Where would you like bug reports sent to? GitHub, your email, elsewhere?
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 { ... };
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic 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: Nsupdate and TTL
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 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
Nsupdate and TTL
What is the proper syntax gor changing the TTL on a zone with nsupdate? Does the existence of $TTL 86400 in the domain.conf file override nssupdate’s attempts to change the TTL? # nsupdate -k /path/to/key > zone example.com > ttl 3600 > send > ^d No errors, but no change in the TTL. -- "I know she's in there," said Verence, holding his crown in his hands in the famous Ai-Se-or-Mexican-Bandits-Have-Raided-Our-Village position ___ 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
I'm slowly working on a dialog with the Vim maintainer. But before I do that "final" submission, it would make sense to vet this a bit more solidly before I 'mainstream' this. On 4/22/20 3:25 PM, Evan Hunt wrote: On Wed, Apr 22, 2020 at 02:32:51PM -0400, Steve Egbert wrote: I'm announcing the release of ISC Bind v9.16 named.conf syntax file for Vim editor. Oh, thank you *so much*! That itch needed scratching for a long, long time. :) Are you planning to submit this upstream to vim, by any chance? ___ 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
On Wed, Apr 22, 2020 at 02:32:51PM -0400, Steve Egbert wrote: > I'm announcing the release of ISC Bind v9.16 named.conf syntax file for > Vim editor. Oh, thank you *so much*! That itch needed scratching for a long, long time. :) Are you planning to submit this upstream to vim, by any chance? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
I haven't worked on the zone syntax file yet. It hasn't changed since v9.5 days. That should be my next subproject. (Which should go by rather quickly given that I've a mastery on Vim syntax, I hope). S. On 4/22/20 2:50 PM, Hugo Salgado wrote: Thanks a lot Steve, works like a charm! It's nice to have well formatted SSHFP records at last! :) Regards, Hugo Salgado On 14:32 22/04, Steve Egbert wrote: Hello, Bind-Users, This is my 2nd post (in 19 years). I'm announcing the release of ISC Bind v9.16 named.conf syntax file for Vim editor. Yeah, the last one is the Vim stock 'named.conf' syntax and probably works marginally today as it was written for Bind 9.4-9.5. No auto-installer yet. I'll take pull request for that if you think it's worth it. https://github.com/egberts/vim-syntax-bind-named.git Or you can execute: git clone https://github.com/egberts/vim-syntax-bind-named.git The color scheme is derived from default Vim highlights using your own color scheme. Have it, folks! I hope you enjoyed it as much as I did Cordially, S. Egbert ___ 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 ___ 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
Thanks a lot Steve, works like a charm! It's nice to have well formatted SSHFP records at last! :) Regards, Hugo Salgado On 14:32 22/04, Steve Egbert wrote: > Hello, Bind-Users, > > > This is my 2nd post (in 19 years). > > I'm announcing the release of ISC Bind v9.16 named.conf syntax file for Vim > editor. > > Yeah, the last one is the Vim stock 'named.conf' syntax and probably works > marginally today as it was written for Bind 9.4-9.5. > > No auto-installer yet. I'll take pull request for that if you think it's > worth it. > > https://github.com/egberts/vim-syntax-bind-named.git > > Or you can execute: > > git clone https://github.com/egberts/vim-syntax-bind-named.git > > The color scheme is derived from default Vim highlights using your own color > scheme. > > Have it, folks! I hope you enjoyed it as much as I did > > > Cordially, > > S. Egbert > ___ > 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 > signature.asc Description: 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
Vim Syntax, New Release for ISC Bind named.conf 5.16
Hello, Bind-Users, This is my 2nd post (in 19 years). I'm announcing the release of ISC Bind v9.16 named.conf syntax file for Vim editor. Yeah, the last one is the Vim stock 'named.conf' syntax and probably works marginally today as it was written for Bind 9.4-9.5. No auto-installer yet. I'll take pull request for that if you think it's worth it. https://github.com/egberts/vim-syntax-bind-named.git Or you can execute: git clone https://github.com/egberts/vim-syntax-bind-named.git The color scheme is derived from default Vim highlights using your own color scheme. Have it, folks! I hope you enjoyed it as much as I did Cordially, S. Egbert ___ 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: NAT and Question Section Mismatch
Thank you to everyone taking the time to reply and provide guidance with this problem. Our cisco guy turned off alg on the nat for dns and our reverse dns lookups are now working properly. Just to follow up, found this after searching using Ondřej Surý's description and Reindl Harald's replies. Amazing that cisco actually mentioned it in a document: NAT DNS ALG Support NAT application awareness includes support for the Domain Name System (DNS). An application-level gateway (ALG) translates IP addresses and port numbers embedded in the DNS payload when a NAT mapping is processed. With CSCuc05660, for DNS payloads that are address-translated, the DNS time to live (TTL) value in CNAME entries is passed through. Before CSCuc05660 and before support for the ip nat service dns-reset-ttl command was added, the TTL value in the CNAME entries was reset by default. > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > Reindl Harald > Sent: Tuesday, April 21, 2020 7:37 PM > To: bind-users@lists.isc.org > Subject: Re: NAT and Question Section Mismatch > > > > Am 21.04.20 um 21:30 schrieb Ondřej Surý: > > There was a setting in Cisco which would handle the host behind the > > NAT differently when the DNS traffic passed the matching NAT. > > > > I found a bug in the Cisco devices more than 10+ years ago when it > > would mangle the TTL to `0`. I don’t really remember the details > > though, but it’s not only the `ip inspect` that might be at fault. > > cisco dns ALG even mangles the TTL of CNAMES within a zone-transfer which > was the reason to set up a vpn peer to avoid zero TTLs on public slaves > > no ip nat service alg tcp dns > no ip nat service alg udp dns > ___ > 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 > ___ 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: NAT and Question Section Mismatch
Carl, The output from the tcpdumps on both machines. >From my local: 226 13.386290 172.16.1.10372.162.32.4 DNS 107 Standard query 0x8148 PTR 3.32.162.72.in-addr.arpa OPT 227 13.405397 72.162.32.4 172.16.1.103DNS 93 Standard query response 0x8148 Refused PTR 17.1.1.10.in-addr.arpa OPT 307 18.385705 172.16.1.10372.162.32.4 DNS 107 Standard query 0x8148 PTR 3.32.162.72.in-addr.arpa OPT 308 18.402629 72.162.32.4 172.16.1.103DNS 93 Standard query response 0x8148 Refused PTR 17.1.1.10.in-addr.arpa OPT 357 23.386698 172.16.1.10372.162.32.4 DNS 107 Standard query 0x8148 PTR 3.32.162.72.in-addr.arpa OPT 358 23.404178 72.162.32.4 172.16.1.103DNS 93 Standard query response 0x8148 Refused PTR 17.1.1.10.in-addr.arpa OPT 492 35.373711 172.16.1.10372.162.32.4 DNS 107 Standard query 0xa388 PTR 5.32.162.72.in-addr.arpa OPT 493 35.391667 72.162.32.4 172.16.1.103DNS 149 Standard query response 0xa388 No such name PTR 5.32.162.72.in-addr.arpa SOA ns.iotis.org OPT 541 44.408527 172.16.1.10372.162.32.4 DNS 107 Standard query 0x2e67 PTR 6.32.162.72.in-addr.arpa OPT 542 44.426670 72.162.32.4 172.16.1.103DNS 92 Standard query response 0x2e67 Refused PTR 6.1.1.10.in-addr.arpa OPT 634 49.408293 172.16.1.10372.162.32.4 DNS 107 Standard query 0x2e67 PTR 6.32.162.72.in-addr.arpa OPT 635 49.427719 72.162.32.4 172.16.1.103DNS 92 Standard query response 0x2e67 Refused PTR 6.1.1.10.in-addr.arpa OPT 689 54.408297 172.16.1.10372.162.32.4 DNS 107 Standard query 0x2e67 PTR 6.32.162.72.in-addr.arpa OPT 690 54.425286 72.162.32.4 172.16.1.103DNS 92 Standard query response 0x2e67 Refused PTR 6.1.1.10.in-addr.arpa OPT 755 62.891404 172.16.1.10372.162.32.4 DNS 108 Standard query 0xd77a PTR 18.32.162.72.in-addr.arpa OPT 756 62.908737 72.162.32.4 172.16.1.103DNS 192 Standard query response 0xd77a PTR 18.32.162.72.in-addr.arpa PTR badmx.iotis.org NS ns2.iotis.org NS ns.iotis.org A 72.162.32.3 A 72.162.32.4 OPT >From the dns server: 07:15:07.565369 IP 24.181.4.204.22196 > 10.1.1.25.53: 33096 [1au] PTR? 17.1.1.10.in-addr.arpa. (63) 07:15:07.565984 IP 10.1.1.25.53 > 24.181.4.204.22196: 33096 Refused- 0/0/1 (51) 07:15:12.562543 IP 24.181.4.204.22196 > 10.1.1.25.53: 33096 [1au] PTR? 17.1.1.10.in-addr.arpa. (63) 07:15:12.563134 IP 10.1.1.25.53 > 24.181.4.204.22196: 33096 Refused- 0/0/1 (51) 07:15:17.563820 IP 24.181.4.204.22196 > 10.1.1.25.53: 33096 [1au] PTR? 17.1.1.10.in-addr.arpa. (63) 07:15:17.564464 IP 10.1.1.25.53 > 24.181.4.204.22196: 33096 Refused- 0/0/1 (51) 07:15:29.551545 IP 24.181.4.204.10307 > 10.1.1.25.53: 41864 [1au] PTR? 5.32.162.72.in-addr.arpa. (65) 07:15:29.552158 IP 10.1.1.25.53 > 24.181.4.204.10307: 41864 NXDomain*- 0/1/1 (107) 07:15:38.586430 IP 24.181.4.204.44420 > 10.1.1.25.53: 11879 [1au] PTR? 6.1.1.10.in-addr.arpa. (62) 07:15:38.586935 IP 10.1.1.25.53 > 24.181.4.204.44420: 11879 Refused- 0/0/1 (50) 07:15:43.587602 IP 24.181.4.204.44420 > 10.1.1.25.53: 11879 [1au] PTR? 6.1.1.10.in-addr.arpa. (62) 07:15:43.588026 IP 10.1.1.25.53 > 24.181.4.204.44420: 11879 Refused- 0/0/1 (50) 07:15:48.584994 IP 24.181.4.204.44420 > 10.1.1.25.53: 11879 [1au] PTR? 6.1.1.10.in-addr.arpa. (62) 07:15:48.585537 IP 10.1.1.25.53 > 24.181.4.204.44420: 11879 Refused- 0/0/1 (50) 07:15:57.068551 IP 24.181.4.204.44089 > 10.1.1.25.53: 55162 [1au] PTR? 18.32.162.72.in-addr.arpa. (66) 07:15:57.069188 IP 10.1.1.25.53 > 24.181.4.204.44089: 55162*- 1/2/3 PTR badmx.iotis.org. (150) I'm sending the above to our cisco guy, I had already assumed it is the nat as I had noticed yesterday that it was only affecting actual nated hosts. John > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Carl > Byington via bind-users > Sent: Tuesday, April 21, 2020 6:17 PM > To: bind-users@lists.isc.org > Subject: RE: NAT and Question Section Mismatch > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Tue, 2020-04-21 at 14:08 -0400, John Wiles wrote: > ;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN > > tcpdump is your friend. > > Dump the outgoing packets from your home connection to see exactly what > you are sending for: > > dig 3.32.162.72.in-addr.arpa ptr @72.162.32.4 +nodnssec +norecur > > Dump the incoming packets at your dns server to see what it is receiving for > that command. Any differences are probably generated by the cisco. > Dump the outgoing packets from your dns server, and the incoming packets > at your home connection also. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > >
Re: Strange log messages
Lars Kollstedt wrote: > > what do the following messages in loose combination mean?: > > Apr 22 09:23:01 resolver1 named[1201]: validating ip6.arpa/SOA: got insecure > response; parent indicates it should be secure This means there is a DS record for ip6.arpa in the .arpa zone, but there were no RRSIG records in the response to the ip6.arpa SOA query. > I'm seeing this on all our resolvers and for a longer time already. The BIND > version I am running is currently 1:9.11.3+dfsg-1ubuntu1.11. This might be an instance of a bug that Mark mentioned last week: https://lists.isc.org/mailman/htdig/bind-users/2020-April/102982.html 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...) Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight, Humber: East or northeast 4 or 5, occasionally 6 at first. Moderate. 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
Strange log messages
Hi, what do the following messages in loose combination mean?: Apr 22 09:23:01 resolver1 named[1201]: validating ip6.arpa/SOA: got insecure response; parent indicates it should be secure [...] Apr 22 09:32:23 resolver1 named[1201]: validating in-addr.arpa/SOA: got insecure response; parent indicates it should be secure [...] Apr 22 09:36:08 resolver1 named[1201]: validating ./SOA: got insecure response; parent indicates it should be secure Theses are the only messages where I get "got insecure response; parent indicates it should be secure". DNSSEC currently seems to work properly, but there was a bit strange behavior with `dig +tries=6 +tcp +sigchase +trusted- key=/usr/share/dns/root.key SOA `, yesterday night that hint me to this strange message. I'm seeing this on all our resolvers and for a longer time already. The BIND version I am running is currently 1:9.11.3+dfsg-1ubuntu1.11. Anyone else seeing this messages, too? ;-) 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
