Re: Determine parental-agents automatically

[vom513]

> On Feb 27, 2023, at 8:07 AM, Matthijs Mekking  wrote:
> 
> Consider your feature request applied ;)
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3901

Wow - that’s great news.  Until that’s fully baked / released I have a pretty 
simple script I use to do this.  I generate a file per parent zone, and 
$INCLUDE it where needed.

https://github.com/vom513/vom-scripts/tree/master/generate-parental-agents

You will likely need to change some of the variables near the top to suit your 
needs.  Also you may want to comment out the end parts that do the diff and 
emailing if you don’t care about that.  Emails should be extremely infrequent, 
but personally I’d like to know if/when they change,
-- 
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 remove RR from dnssec policy signed zone ?

[vom513]

> On Dec 15, 2022, at 11:31 PM, Mark Andrews  wrote:
> 
> Stop freezing the zone.  Use nsupdate to update the zone.  Add a record back 
> in at the name using nsupdate.  Then remove using nsupdate.  If you really 
> want to edit the zone by hand use ‘inline-signing yes;’.
> 

Yes, this is exactly what I did a short time after posting to the list :/  
nsupdate worked exactly as expected.  I was “doing surgery” on the signed file. 
 Obviously ended in disappointment.  

For some reason I had it stuck in my head that inline-signing was mutually 
exclusive with dnssec-policy.  That was my missing piece.  Thanks.

-- 
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

How to remove RR from dnssec policy signed zone ?

[vom513]

* Sorry to spam the list guys, just really pulling my hair out with some 
aspects of this migration I’ve done...

Seems like a simple question ?  And maybe it is but I’m just way off track.

I have a DNSSEC signed zone (dnssec-policy).  It’s also dynamic.  So to make a 
change (in this case remove a record) - I freeze the zone, edit the file (and 
up the serial properly), and thaw the zone.

What seems to be happening is (I guess ?) there is some stale nsec3 record ?  
When I remove the RR and it’s RRSIG, other validating resolvers report SERVFAIL 
for the removed RR.  On bind itself I get:

expected covering NSEC3, got an exact match

So it seems like it’s hitting something in the nsec3 chain that’s not there ? 
Or the record is gone now (it is) and this has left a “gap” in the NSEC3 chain 
?  I would expect/want to get an NXDOMAIN and NSEC3 records returned.  I feel 
like I’m getting something out of whack with BIND’s key/signature/nsec state.

Is there some trick to removing an RR in a zone like this ?  I can’t believe it 
would be so difficult.
-- 
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-policy - any way to force bind to resign all records ?

[vom513]

Sorry to self-reply…

I’m still getting used to dnssec-policy.  With the RRSIGs directly in the zone 
file now I was having some trouble.  I think I got it now - I needed to change 
the TTL on a given RR, and delete the RRSIG for that RR.  Lather, rinse, repeat 
for any/all other RR’s.  BIND will make new RRSIGs for these “new” RRs (new by 
virtue of having a diff TTL and no RRSIG…)  I think it makes sense now - but I 
welcome any other clarification or comments.  

Sorry for the noise.  Thanks.
-- 
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

dnssec-policy - any way to force bind to resign all records ?

[vom513]

Hello,

I changed one of my domains over to dnssec-policy today (in a “nuclear” 
fashion) - but everything went surprisingly well.  Previous to this, I had 
lowered all my TTLs to hopefully help with this process or any errors/mistakes 
I might make.

I then went to put the TTLs back to their normal higher value.  What I wasn’t 
aware of - is the now discrepancy between the RR TTL and RRSIG TTL.  DNZviz 
validates all the way down just fine - but I get errors on my top level common 
RR’s due to this mismatch.

I assume over time as BIND resigns nodes, these will all get in sync ?

In the meantime - is there any way to “force” BIND to resign everything ?  I’m 
not seeing an rndc command that looks to do this.  Looks like all the dnssec 
policy commands are under “rndc dnssec ”.  The other commands are 
obviously for the “old” way of signing.

So is there a way to do this ?  Or do I just need to wait ?

Thanks.
-- 
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: parental-agents clause - IP address only ?

[vom513]

> On Dec 5, 2022, at 4:06 AM, Matthijs Mekking  wrote:
> 
> 'parental-agents' work the same as 'primaries'. It only supports addresses.
> 
> Listing them as domain names would technically be possible to implement, but 
> it requires an authoritative server to act as an resolver. Adding resolver 
> code to the path of an authoritative server is like crossing the streams. It 
> adds security risks that are unnecessary for an authoritative server, so I'd 
> rather not add such functionality.
> 

Thanks for the confirmation - and yes makes sense.

Also thanks to Timothe in this thread for the script inspiration.  I cooked my 
own up and tested it - works brilliant.  I also added some logic to email me if 
there is a diff from the last run.  Will be interesting to see how often there 
actually is.

-- 
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

parental-agents clause - IP address only ?

[vom513]

Hello all,

So I set up parental-agents lists for my zones, and actually got to see it work 
(awesome !).  bind detected the parent DS records and acted accordingly.

However, I currently have these lists configured using the IP (v4 only at the 
moment) addresses of the parent NS’es.  I tried inputting hostnames, and I got 
errors (i.e. syntax) every time.

I would prefer to put these in as hostnames.  While at a certain level in the 
tree these don’t change very often, they can and do.  I’d rather not have to 
keep track of these in this manner.

So my question - am I just mangling the syntax - or does this clause really 
only support IPs ?  I was thinking if so - perhaps the reason is some chicken 
vs. egg / security reason ?  I.e. not trusting the name (which would have to be 
itself resolved) ?

Thanks in advance for clue++
-- 
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: Struggling with dnssec-policy timers

[vom513]

> On Nov 28, 2022, at 3:12 PM, vom513  wrote:
> 
> Thanks for the reply and info…
> 
> I would have thought the CDS would be published before the key went active.  
> I.e. there would be a period of TWO DS’es at the parent (I’m assuming the 
> parent supports CDS/CDNSKEY which mine (registrar) does).
> 
> Since the new key goes active, CDS is published, and the old key is retired 
> at the same time - isn’t this going to cause a (lack of coverage/chain of 
> trust) problem ?  I’m really trying to get to a point of a “one command” 
> rollover.  I.e. no API, no uploading DS, etc.  I guess I’ll see tonight when 
> it happens, but I can’t help but feel when the clock strikes I’m going to be 
> missing DS for the new key at the parent.
> 

Sorry to self reply…

So it did “work” as you said Matthijs… I don’t think I necessarily need those 
timers (publish/retire-safety) that I tweaked.  I’d rather use as many bind 
defaults as possible.  I think a big part of my issue was misunderstanding 
“retired” status.  I nuked everything clean and will try this again once 
everything settles down.  Thanks for your patience with me and pointers.

PS: My registrar says they check CDS/CDNSKEY once a day.  Do you think that’s 
reasonable ?  I certainly appreciate them being cognizant/careful of too much 
load on their systems with too many frequent checks, but a day seems long to 
me...
-- 
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: Struggling with dnssec-policy timers

[vom513]

Thanks for the reply and info…

I would have thought the CDS would be published before the key went active.  
I.e. there would be a period of TWO DS’es at the parent (I’m assuming the 
parent supports CDS/CDNSKEY which mine (registrar) does).

Since the new key goes active, CDS is published, and the old key is retired at 
the same time - isn’t this going to cause a (lack of coverage/chain of trust) 
problem ?  I’m really trying to get to a point of a “one command” rollover.  
I.e. no API, no uploading DS, etc.  I guess I’ll see tonight when it happens, 
but I can’t help but feel when the clock strikes I’m going to be missing DS for 
the new key at the parent.

-- 
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

Struggling with dnssec-policy timers

[vom513]

Hello all,

I’m still having a really hard time understanding and getting my timings right. 
 At least I think I am (from the way I’m reading the status/logs/state files).

I let my current CSK get completely “omnipresent” for all it’s timers (I’m not 
even sure if this is really necessary…)  I did a rollover, and I’m very 
confused by the various timers I’m seeing.

FYI - I added:

publish-safety 1d;
retire-safety 1d;

To the policy “default”.  Other than that and NSEC3, everything is using values 
from the “default” policy.  With this, it seems that my successor key will go 
active but CDS won’t be published until the same exact time.  This seems to 
defeat the purpose of doing an overlapping rollover.  I would think I would 
want CDS published before the new key goes active.  Is the old key going to 
keep being used for signing as well ?  I don’t think so because it’s retirement 
is also at this exact moment.

So simultaneously, it seems that I have:

- New key start to be used for signing
- CDS is published
- Old key is retired  

If I’m reading this right - did my timers screw this up ?  I would have 
hoped/assumed that the “default” policy would have timers arranged as such as 
there there *should* not be any gaps in coverage (assuming everything else goes 
swimmingly…)  I’ll be honest - I’m kind of feeling like an idiot because of how 
difficult this seems.

Can someone please set me straight ?  I can “nuke” this zone’s keys and state 
and start over (which I’ve done several times already).  It’s just getting a 
bit tiresome because of course when I do this all the various timers start over.

Here are my state files, 2 keys.  Current and a successor.  Thanks in advance.

—
; This is the state of key 3697, for acuity.tech.
Algorithm: 13
Length: 256
Lifetime: 0
Predecessor: 35731
KSK: yes
ZSK: yes
Generated: 20221127221000 (Sun Nov 27 17:10:00 2022)
Published: 20221127221000 (Sun Nov 27 17:10:00 2022)
Active: 20221128231500 (Mon Nov 28 18:15:00 2022)
PublishCDS: 20221128231500 (Mon Nov 28 18:15:00 2022)
DNSKEYChange: 20221127221000 (Sun Nov 27 17:10:00 2022)
ZRRSIGChange: 20221127221000 (Sun Nov 27 17:10:00 2022)
KRRSIGChange: 20221127221000 (Sun Nov 27 17:10:00 2022)
DSChange: 20221127221000 (Sun Nov 27 17:10:00 2022)
DNSKEYState: rumoured
ZRRSIGState: hidden
KRRSIGState: rumoured
DSState: hidden
GoalState: omnipresent

; This is the state of key 35731, for acuity.tech.
Algorithm: 13
Length: 256
Lifetime: 546573
Successor: 3697
KSK: yes
ZSK: yes
Generated: 20221122152527 (Tue Nov 22 10:25:27 2022)
Published: 20221122152527 (Tue Nov 22 10:25:27 2022)
Active: 20221122152527 (Tue Nov 22 10:25:27 2022)
Retired: 20221128231500 (Mon Nov 28 18:15:00 2022)
Removed: 20221209232000 (Fri Dec  9 18:20:00 2022)
DSPublish: 20221123043555 (Tue Nov 22 23:35:55 2022)
PublishCDS: 20221124153027 (Thu Nov 24 10:30:27 2022)
DNSKEYChange: 20221123163027 (Wed Nov 23 11:30:27 2022)
ZRRSIGChange: 20221124153027 (Thu Nov 24 10:30:27 2022)
KRRSIGChange: 20221123163027 (Wed Nov 23 11:30:27 2022)
DSChange: 20221125053555 (Fri Nov 25 00:35:55 2022)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: hidden

-- 
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-policy - CSK rollover help

[vom513]

> On Nov 21, 2022, at 3:29 AM, Matthijs Mekking  wrote:
> 
> Hi,
> 
> It is hard to see what the problem is without any configuration or state 
> information. Also, log level debug 3 gives you probably more useful logs when 
> investigating a problem.
> 
> Can you share (privately if you wish) the key **state** files, and the output 
> of 'rndc dnssec -status' for the given zone?

Yep, nothing top secret here.  Here is rndc dnssec -status as well as the state 
file.  Judging by the lifetime / retirement - looks like I have a 2 hour window 
after the rollover ?  I suppose I can/should tweak/increase this lifetime in 
the dnssec-policy ?

--
dnssec-policy: default-nsec3
current time:  Mon Nov 21 09:50:11 2022

key: 46697 (ECDSAP256SHA256), CSK
  published:  yes - since Wed Nov 16 22:07:32 2022
  key signing:yes - since Wed Nov 16 22:07:32 2022
  zone signing:   yes - since Wed Nov 16 22:07:32 2022

  Next rollover scheduled on Tue Nov 22 18:00:00 2022
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: omnipresent
  - zone rrsig: omnipresent
  - key rrsig:  omnipresent

; This is the state of key 46697, for acuity.tech.
Algorithm: 13
Length: 256
Lifetime: 511048
KSK: yes
ZSK: yes
Generated: 20221117030732 (Wed Nov 16 22:07:32 2022)
Published: 20221117030732 (Wed Nov 16 22:07:32 2022)
Active: 20221117030732 (Wed Nov 16 22:07:32 2022)
Retired: 20221123010500 (Tue Nov 22 20:05:00 2022)
Removed: 20221203021000 (Fri Dec  2 21:10:00 2022)
DSPublish: 20221118201223 (Fri Nov 18 15:12:23 2022)
PublishCDS: 20221118041232 (Thu Nov 17 23:12:32 2022)
DNSKEYChange: 20221117051232 (Thu Nov 17 00:12:32 2022)
ZRRSIGChange: 20221118041232 (Thu Nov 17 23:12:32 2022)
KRRSIGChange: 20221117051232 (Thu Nov 17 00:12:32 2022)
DSChange: 20221119221223 (Sat Nov 19 17:12:23 2022)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: omnipresent
--
-- 
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

dnssec-policy - CSK rollover help

[vom513]

Hello,

So I reconfigured one of my domains to use dnssec-policy.  I’m using the policy 
“default” + I’ve only added nsec3 stuff.  All other timers / params are from 
default.  Working fine / as expected.

Luckily for me this is a domain that I don’t use much.  So outages and mistakes 
are easily tolerable.

After a bumpy start, I have the zone “happy” - that is, fully signed, DS in 
parent, and all timers reading “omnipresent”.

I’m trying to use this ISC KB as a guide: 
https://kb.isc.org/docs/dnssec-key-and-signing-policy

So I decided to try a rollover.  So I did: rndc dnssec -rollover -key 12345 
-when 2022112223 example.com 

This now shows up as scheduled in rndc dnssec -status.

However, I expected BIND to create a successor CSK.  Nothing in the key dir, 
nothing in logs, nothing in rndc status.

The whole point of course is to have two “overlapping” keys, two DS’es, i.e. 
two chains of trust.  And then when everything is happy timer-wise, the old key 
(and DS) can go away.

Is BIND going to do this sometime before the actual rollover ?  Or is there 
something else I need to do ?  Speaking of this - what exactly happens at the 
rollover time ?

Thanks.


-- 
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

isc.org - error on KB article

[vom513]

ISC folks: can someone take a look at:

https://kb.isc.org/docs/dnssec-key-and-signing-policy

Seems one of the examples has a “-when” argument to rndc and the time is “1w”  

rndc seems to want MMDDHHMMSS (UTC) instead.

Thanks.



-- 
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

Migrating to dnssec-policy - existing "stack" of future keys ?

[vom513]

Hello,

I’m wanting to go ahead and look at migrating to dnssec-policy for my zones.  I 
currently use “auto-dnssec maintain” and “inline-signing yes”.  I also have a 
“stack” of ZSKs I made that all nicely overlap with their various date 
settings.  I think I made these out to sometime in 2024.

In addition to all the info here:

https://kb.isc.org/docs/dnssec-key-and-signing-policy

Do I need to / should I do something to this stack of keys ?  I was thinking 
maybe take the most “current” key, and remove his expiration etc.  Then (after 
a backup of course), delete the other future keys ?

In other words, I can’t imagine I’d want to mix the “old way” of managing these 
/ rollovers with the new.

Hopefully this makes sense.  Thanks for any guidance or insight.
-- 
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

9.16.27 (Raspberry PI package) - memory usage

[vom513]

Hello,

I have an rPi here at home running as a second DNS server to my main (non-rPi) 
bind instance.  The pi unfortunately only has 1G ram.  I’ve set max-cache-size 
to 50% and verified it took effect:

root@ns2:~# grep size /var/log/daemon.log
May  1 12:38:23 ns2 named[6295]: /etc/bind/named.conf.options:42: 
'max-cache-size 50%' - setting to 461MB (out of 922MB)

This guy only has maybe 10 zones (small internal dns, rdns, some rpz feed 
zones).  It also has the built-in/empty/rfc1918 zones.

After a day or so - I see that bind is using 800M+  It behaves like it’s using 
the default 90% max-cache-size setting.

I just saw another thread on the list related to memory issues, and I also did 
some of my own reading regarding internal memory allocation in 9.16 vs. 9.18.  
I don’t pretend to fully understand the details there…  The one thing that 
caught my eye was that the memory allocation changes were backported to 
9.16.25+.  I’m running "BIND 9.16.27-Raspbian (Extended Support Version) 
” - wouldn’t I have these backported changes ?

So my question is - if it’s not cache that’s eating memory - what else could it 
be ?  Is there something else that’s gradually eating memory that I’m not aware 
of ?

Is there anything I can do to further troubleshoot - or is the real solution to 
upgrade to 9.18+ and/or get a machine with more RAM ?

Thanks.
-- 
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 - adding large/split TXT record (2048 bit DKIM key)

[vom513]

Done:

https://gitlab.isc.org/isc-projects/bind9/-/issues/1907 


Thanks.

> On Jun 1, 2020, at 7:08 AM, Ondřej Surý  wrote:
> 
> I think it’s reasonable for nsupdate to do the chunking on itself. Patches 
> are always welcome, but if you can start by creating issue for us, it would 
> be very much welcome. I can’t offer you any timeframe, but at least it won’t 
> get lost.
> 
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
> 

___
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 - adding large/split TXT record (2048 bit DKIM key)

[vom513]

> On Jun 1, 2020, at 6:50 AM, Andreas S. Kerber  wrote:
> 
> Yeah, I had troubles with those 2048 bit DKIM records too. nsupdate will need 
> it like this:
> 
> server X.X.X.X
> zone ag-trek.de
> update add test.ag-trek.de. 86400 IN TXT"v=DKIM1; 
> k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3LmxUW2tnM07YbofiOGR3T6KS/BfHmyPYe0GOEEch/abeTjaL3OtuhmVmr4QMe2HV/6n5SBiVh4PE2wZxUcS2LMNbo5Hn7KO3UsTbIxCKuM6jvUpWtJPgC0uBGNkEARQVBSjW9pqYUQYkXzXLEULbu1AThgaUvCbVzWmvTQeEFXbBWP24O/"
>  
> "LkiprI+iKRskRv0qgIOV0CRm32tk4MP/IcZBdjZ3sHrg3myjVJPfSUBOUyISXKRtiwfIgPeCj4V97Q+psmHvnDz9EID0eZaKih8neroRBETYDLFYjd6Pv9JTqrY7jXOHhM4kmOZOUyNXEIz22JVuaNSJbtXzNWTKpyQIDAQAB"
> 
> 
> Break up the record in chunks of less than 255 byte, enclose each of these 
> parts with "" and feed nsupdate all of these chunks seperated with a space on 
> one line.

Thanks - that’s what I needed.  I have an ‘h=‘ tag as well, so I split mine 
into 3 “chunks”.
___
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

nsupdate - adding large/split TXT record (2048 bit DKIM key)

[vom513]

Hello,

Can anyone point me to an example of how to do this ?  I have a script that 
rotates my DKIM keys, and uses nsupdate to publish.  With 1024 bit - I must be 
getting by by the skin of my teeth…

When I try 2048 bit, the record is obviously longer.  All of my attempts of 
running it through the Rube Goldberg sed machine have failed - nsupdate chokes 
on format.

I see lots of blogposts on how to split long TXT records, but I specifically 
need the bits to make nsupdate happy.  The blogs all have these being entered 
by hand or through some web gui.  It’s nsupdate’s particulars that are eluding 
me.

Thanks in advance for any clue.

___
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: Constant errors concerning in-addr.arpa SOA (insecure response)

[vom513]

Sorry to self reply - I *think* I figured this out.  Looks like the messages I 
was seeing (at least to my eyes) make this seem like a true failure in the 
chain of recursion/validation.  Looks like it’s more benign - misconfigured 
auth servers for various in-addr.arpa zones hading out information erroneously 
(i.e. NOT what they were asked / have been delegated).

I was able to do this on one of my “clean” servers that I hadn’t observed the 
log messages on:

while true; do nmap -n -iR 10 -sL | grep "^Nmap scan" | awk '{print $5}' | 
while read ip; do dig -x $ip; done; sleep 5; done

I’m just using nmap to generate 10 random IPs, I’m not “scanning” anything…

That command managed to trigger the log message on my “clean” machine.  I think 
part of the issue is my mail server is simply much busier looking up rDNS as it 
gets SMTP connections, and is therefore more likely to trigger this log.

I don’t mean to pick on this network, but the following record/query seems to 
trigger this every time:

dig -x 106.62.177.136

And to see what caused it:

dig +trace -x 106.62.177.136

Notice the “IN-ADDR.ARPA” they give out (helpfully in all CAPS :)).

Sorry for the noise with this thread.  If anyone has a more in-depth 
explanation of bind’s behavior in this scenario I’d love to hear it because I 
don’t feel like I 100% understand it...
___
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

Constant errors concerning in-addr.arpa SOA (insecure response)

[vom513]

Hello all,

I've searched the list - and there is a thread from 7 years ago that seems to 
match what I am seeing:

https://lists.isc.org/pipermail/bind-users/2013-March/090003.html

I am seeing this on a fresh Debian 10 install, using the Debian bind9 packages 
(specifically as of this moment I have: BIND 9.11.5-P4-5.1+deb10u1-Debian 
(Extended Support Version) ).  I have stayed as close as possible 
to the vanilla shipped config.  So to that point - DNSSEC validation works fine 
out of the box.

I am getting this frequently:

May 30 14:15:33 orbital named[10379]:   validating in-addr.arpa/SOA: got 
insecure response; parent indicates it should be secure
May 30 14:19:47 orbital named[10379]:   validating in-addr.arpa/SOA: got 
insecure response; parent indicates it should be secure
May 30 14:19:58 orbital named[10379]:   validating in-addr.arpa/SOA: got 
insecure response; parent indicates it should be secure
May 30 14:23:12 orbital named[10379]:   validating in-addr.arpa/SOA: got 
insecure response; parent indicates it should be secure

Absolutely maddening.  This box is also my mail server, so it’s constantly 
doing reverse lookups, and hence frequently triggering this log...

I have two other boxes (one Debian 9, one Ubuntu (16.04 ?)).  Both also run 
bind 9.x - distro packages.  Neither of those boxes give me the frequent errors 
for in-addr.arpa.

I thought this was perhaps an MTU / frag (IPv6 ?) issue ?  I can ping 1500 
packets with DF from here to other places across the net.

I also ran a tcpdump filtering for the IP/IPv6 addresses of the 
[a-f].in-addr-servers.arpa… either I missed something or I’m not seeing it.  
Nothing stands out to me there.

No idea if this is red herring, or not, but I notice that b and c instances 
give back answers that are 200+  bytes larger than a,d,e,f:

vom@orbital:~$ for i in a b c d e f; do echo -n "$i: "; dig -4 +norecurse 
+dnssec @$i.in-addr-servers.arpa in-addr.arpa soa | grep rcvd: ; done
a: ;; MSG SIZE  rcvd: 309
b: ;; MSG SIZE  rcvd: 547
c: ;; MSG SIZE  rcvd: 547
d: ;; MSG SIZE  rcvd: 309
e: ;; MSG SIZE  rcvd: 313
f: ;; MSG SIZE  rcvd: 281
vom@orbital:~$ for i in a b c d e f; do echo -n "$i: "; dig -6 +norecurse 
+dnssec @$i.in-addr-servers.arpa in-addr.arpa soa | grep rcvd: ; done
a: ;; MSG SIZE  rcvd: 309
b: ;; MSG SIZE  rcvd: 547
c: ;; MSG SIZE  rcvd: 547
d: ;; MSG SIZE  rcvd: 309
e: ;; MSG SIZE  rcvd: 313
f: ;; MSG SIZE  rcvd: 281

Does anyone know what could be causing this ?  I feel like I’m missing a 
troubleshooting step.  I would love some clue on some specific dig commands I 
could run to recreate/diagnose this.

Thanks in advance - this is my “white whale” for this weekend...

___
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