Re: Troubleshooting scripted named startup

2022-12-28 Thread Philip Prindeville
That must have been it.  I spun a new package and installed in on my firewall, 
rebooted, and I'm not seeing the issue.


> On Dec 28, 2022, at 12:24 AM, Ondřej Surý  wrote:
> 
> Hi,
> 
> running latest upstream version first might save you some time, it’s this:
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2895
> 
> 
> Ondrej
> --
> 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 28. 12. 2022, at 1:51, Philip Prindeville 
>>  wrote:
>> 
>> Hi,
>> 
>> I notice that went Bind 9.18.7 comes up on OpenWRT, and I'm running it as a 
>> local resolver, resolution initially doesn't work and I get a lot of noise 
>> in /var/log/messages like:
>> 
>> Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature 
>> found
>> Dec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 
>> 193.0.14.129#53
>> Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature 
>> found
>> Dec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 
>> 198.97.190.53#53
>> Dec 27 17:27:12 OpenWrt named[13171]: validating org/DS: no valid signature 
>> found
>> Dec 27 17:27:12 OpenWrt named[13171]: no valid RRSIG resolving 'org/DS/IN': 
>> 202.12.27.33#53
>> Dec 27 17:27:12 OpenWrt named[13171]: broken trust chain resolving 
>> '_.linksys.pool.ntp.org/A/IN': 185.209.85.151#53
>> Dec 27 17:27:12 OpenWrt named[13171]: validating 0.linksys.pool.ntp.org/A: 
>> bad cache hit (org/DS)
>> Dec 27 17:27:12 OpenWrt named[13171]: broken trust chain resolving 
>> '0.linksys.pool.ntp.org/A/IN': 45.127.112.23#53
>> Dec 27 17:27:13 OpenWrt named[13171]: validating tabletcaptiveportal.com/A: 
>> bad cache hit (com/DS)
>> Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving 
>> 'tabletcaptiveportal.com/A/IN': 205.251.195.137#53
>> Dec 27 17:27:13 OpenWrt named[13171]:   validating syringanetworks.net/SOA: 
>> bad cache hit (net/DS)
>> Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving 
>> '_.voip.syringanetworks.net/A/IN': 66.232.66.3#53
>> Dec 27 17:27:13 OpenWrt named[13171]:   validating syringanetworks.net/SOA: 
>> bad cache hit (net/DS)
>> Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving 
>> '_._udp.voip.syringanetworks.net/A/IN': 66.232.66.3#53
>> Dec 27 17:27:13 OpenWrt named[13171]:   validating syringanetworks.net/SOA: 
>> bad cache hit (net/DS)
>> Dec 27 17:27:13 OpenWrt named[13171]: broken trust chain resolving 
>> '_sip._udp.voip.syringanetworks.net/SRV/IN': 66.232.66.3#53
>> 
>> Until I run a script that contains:
>> 
>> #!/bin/sh
>> 
>> rm -f /tmp/managed-keys.bind* /tmp/*.jnl
>> 
>> rndc managed-keys refresh
>> rndc managed-keys sync
>> 
>> /etc/init.d/named restart
>> 
>> And the "restart" command basically kills the old instance of the server, 
>> then restarts it.  Then the errors go away and everything works.
>> 
>> What does this point to as being wrong in the startup scripts so I can fix 
>> it?
>> 
>> Thanks,
>> 
>> -Philip
>> 
>> 
>> 
>> 
>> -- 
>> 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


Funky Key Tag in AWS Route53

2022-12-28 Thread Eric Germann via bind-users
I’m running bind 9.18.10 and having a hell of a time with AWS Route53 and 
DNSSEC.

I’m testing dnssec-policy and have algorithms 8, 13, and 15 set.  On the test 
domain I’m using, I wiped the old keys, deleted the DS records in the parent 
zone and basically started from scratch.

I started named and it created new .key/.private files in the key directory.  
My KSK is Kericgermann.photography.+008+32686.key and I run dnssec-dsfromkey 
and get a DS record.  I cut and paste that record in to Route53 DNSSEC config 
and it decodes the key tag as 22755 instead of 32686.

I get a DNSviz diagram that looks like this 
https://dnsviz.net/d/ericgermann.photography/dnssec/

In the diagram, .photography is looking for a key tag of 22755 instead of the 
correct 32686 for algorithm 8.

My question is

Is there any way to decode the DS record and see what key tag is actually 
encoded in it?  If it’s 32686 it’s an issue with Route53.  If it’s 22755 it’s 
an issue with dnssec-dsfromkey.

If anyone wants the DNSKEY for algorithm 8, ping me off list and I will share 
it with you in a private email.

Thoughts?


--
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann
Medium: https://ekgermann.medium.com 
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1









signature.asc
Description: Message signed with OpenPGP
-- 
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