Re: Should I set parental-agents to localhost?

[Nick Tait via bind-users]

Hi Björn.

Not sure if my (late) reply is any use to you, but yes my understanding 
is that you could use localhost as the parental agent in the cases where 
(a) the local machine also hosts the parent zone, or (b) it is a 
recursive resolver. In the latter case the DNSSEC responses would be 
validated (assuming of course that the local resolver does DNSSEC 
validation).


As I understand there are two schools of thought for configuring 
parental-agents:


1. You could explicitly specify all of the parent zone name servers. In
   that case all the servers are queried and the KSK rollover proceeds
   once all servers are publishing the new DS record.
2. You could specify a validating recursive resolver. In that case only
   one authoritative name server will be queried (you won't know which)
   and the recursive resolver validates the response, and the KSK
   rollover proceeds if that server is publishing the new DS record.

I suppose the theoretical risk with #1 is that because the responses 
from the authoritative servers aren't validated, it would be possible 
for a MITM to trick BIND into thinking that the new DS records had been 
published before they actually had, which could lead to a situation 
where you complete the KSK roll-over early and invalidate your zone?


Also please note that BIND 9.19 introduces a new option:

/*checkds*/

   *Grammar: *|checkds ( explicit |  );|

   *Blocks: *zone (primary, secondary)

   *Tags: *dnssec

   Controls whether |DS| queries are sent to parental agents.

   If set to |yes|, DS queries are sent when a KSK rollover is in
   progress. The queries are sent to the servers listed in the parent
   zone’s NS records. This is the default if there are no
   |parental-agents|
   

   configured for the zone.

   If set to |explicit|, DS queries are sent only to servers explicitly
   listed using |parental-agents|
   
.
   This is the default if there are parental agents configured.

   If set to |no|, no DS queries are sent. Users should manually run
   |rndc dnssec -checkds|
   

   with the appropriate parameters to signal that specific DS records
   are published and/or withdrawn.

Nick.


On 11/09/23 23:52, Björn Persson wrote:

Hello, I'm trying to configure automatic KSK (or CSK) rollover. I'm
confused about how to poll securely for DS records.

Section 5.1.2.1 of the BIND 9 Administrator Reference Manual says:

| [parental-agents] needs to be a trusted server, because BIND does not
| validate the response.

and section 8.2.26.1 says:

| The DS response is not validated so it is recommended to set up a
| trust relationship with the parental agent. For example, use TSIG to
| authenticate the parental agent, or point to a validating resolver.

I don't think the registry wants to exchange TSIG keys with every
domain holder. A validating resolver seems much more achievable. My
master server is also the validating resolver of its host. Can I set
parental-agents to localhost to make BIND ask itself to validate the DS
response? Or would it still do the lookup in the same non-validating
way? Or would it enter infinite recursion? Must the validating resolver
be a different name server from the master server that performs the key
rollover?

Björn Persson
-- 
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: Stop leaking queries for RFC 1918 zones

[Mark Andrews]

The option is enabled by default however if you forward all queries then the 
automatic zones won’t be created and the forwarder is responsible for 
filtering. This is done like this because lots of people use forwarding to get 
to the internal servers that serve these zones. 

Just create empty zones in named.conf. If the automatic creation doesn’t work 
with the rest of your configuration.

The log messages are there to tell you that queries are still leaking. 

Given your other questions about 10.in-addr.arpa I would really set it up and 
delegate based on which address blocks are assigned to whom.  Allow the zone to 
be transferred to any 10.0.0.0/8 address by default. Add in other server 
address or TSIG keys as different departments request access to it.  Start with 
an empty zone and delegations for the addresses you are using yourself and 
build up from there.  Turn off forwarding in this zone’s configuration by using 
an empty forwarders clause ( forwarders { /* empty */ }; ). 

I know you said this was a lost cause but it doesn’t have to be 100% perfect. 
It can be built up over time.

-- 
Mark Andrews

> On 23 Sep 2023, at 02:45, John Thurston  wrote:
> 
> 
> The global/view option
> 
> empty-zones-enable yes; 
> 
> isn't behaving as I expected. 
> 
> I had expected that it would cause empty "RFC 1918" zones to be created for 
> those zones for which there were not local zones defined. That is, if there 
> were no local zones of this type defined, it would create all the required 
> empty zones. But if 10.in-addr.arpa was defined locally, it would skip that 
> but define the rest of them.
> 
> After looking at my logs, and seeing that I'm leaking RFC 1918 queries, I see 
> my expectations were wrong.
> 
> Is explicitly defining the remaining empty zones the best way to correct this?
> 
> Or maybe add the un-used RFC 1918 zones to our RPZ?
> 
> -- 
> --
> Do things because you should, not just because you can. 
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
> -- 
> 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: Change in zone file formatting after enabling allow-update (lot´s of $ORIGIN)

[Jan-Piet Mens]

After the first automated
name change, my zone file was unformatted. I lost the comments and more
than 500 occurrences of the ORIGIN parameter were inserted.


Configuring dynamic DNS updates on a zone means that named takes control over
how the zone file is (periodically) rewritten to disk. There is no way to
inhibit this. Note also, that the zone file must not be edited by hand without
prior `rndc freeze' and subsequent `rndc thaw', and note that freezing a zone
forbids updates.

As a side note I'd like to recommend using the much more granular `update
policy' on the zone.

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

Stop leaking queries for RFC 1918 zones

[John Thurston]

The global/view option

   empty-zones-enable yes;

isn't behaving as I expected.

I had expected that it would cause empty "RFC 1918" zones to be created 
for those zones for which there were not local zones defined. That is, 
if there were no local zones of this type defined, it would create all 
the required empty zones. But if 10.in-addr.arpa was defined locally, it 
would skip that but define the rest of them.


After looking at my logs, and seeing that I'm leaking RFC 1918 queries, 
I see my expectations were wrong.


Is explicitly defining the remaining empty zones the best way to correct 
this?


Or maybe add the un-used RFC 1918 zones to our RPZ?

--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
-- 
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

Change in zone file formatting after enabling allow-update (lot´s of $ORIGIN)

[Guilherme Torres]

Hello!

I´m using Bind 9.11 .

I´m automating my dns server with ansible (nsupdate module). To do this I
enabled the configuration directive allow-update. After the first automated
name change, my zone file was unformatted. I lost the comments and more
than 500 occurrences of the ORIGIN parameter were inserted.

In short, the automation worked, but the zone file was more difficult for
humans to understand.

Is there any way to keep the original zone file (without $ORIGIN parameter
and with comments) in this case?

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: Intent and implementation of dig's +crypto option

[Anand Buddhdev]

On 22/09/2023 15:03, Marco Davids (SIDN) via bind-users wrote:

Hi Marco,

It reminded me that that there is such thing as a .digrc file, that 
perhaps not all of the readers are familiar with.


Mine has this content:

+bufsize=1232
+dnssec
+nocrypto
+multi
-t 

It serves me well, mostly. Sometimes it bites me as well.


I am also aware of .digrc, and choose not to use it. Putting options 
into .digrc has the effect that the output of dig doesn't show me which 
options were used. This can be a source of great confusion when trying 
to figure out why dig is behaving a certain way.


My preferred method uses shell aliases:

alias d='dig -r +noclass +nocookie +nocrypto +nsid +retry=0'
alias k='kdig +noclass +nocrypto +nsid +noretry'

The benefit of this (at least with dig) is that the options are all 
shown in the command section of the output, eg:


% d ripe.net mx

; <<>> DiG 9.18.19 <<>> -r +noclass +nocookie +nocrypto +nsid +retry 
ripe.net mx

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57653
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

With my shell alias, I can always add options, and they override the 
previous ones. So I can add +crypto if I want to see the hashes. And 
when I want to avoid my alias altogether, for default behaviour, I just 
run "dig" or "kdig".


Regards,
Anand
--
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: Intent and implementation of dig's +crypto option

[Bob Harold]

On Fri, Sep 22, 2023 at 8:46 AM Anand Buddhdev  wrote:

> Hi folks,
>
> I wanted to open a GitLab issue about this, but then thought it might be
> nice to have a discussion to hear the views of users.
>
> dig 9.18.19's man page says:
>
>+crypto, +nocrypto
>  This option toggles the display of cryptographic fields in DNSSEC
>  records. The contents of these fields are unnecessary for debugging
>  most DNSSEC validation failures and removing them makes it easier to
>  see the common failures. The default is to display the fields. When
>  omitted, they are replaced by the string [omitted] or, in the DNSKEY
>  case, the key ID is displayed as the replacement,
>  e.g. [ key id = value ].
>
> When I query using dig, and use the combination "+nocrypto +dnssec" then
> dig suppresses the crypto material for DNSKEY, DS and RRSIG records.
> This is in agreement with the man page.
>
> But when I query for the newly introduced ZONEMD record, dig also hides
> the hash. In my opinion, ZONEMD is not a DNSSEC-related record, and so
> its hash should not be hidden (according to the man page).
>
> On the other hand, the hash displayed for ZONEMD, like with hashes of DS
> records, is not especially useful for eyeballing. For me, it is enough
> to see that there's a ZONEMD record, but I don't need to see all the hex
> (which is only needed by code that actually wants to verify it). So I'm
> actually fine with the ZONEMD hash being suppressed, but the man page
> needs to be updated.
>
> In a similar way, the hashes displayed in TLSA and similar records could
> also be suppressed, but dig currently doesn't.
>
> Do you think that dig should be adjusted to suppress cryptographic
> material from other records such as TLSA, SSHFP, CDNSKEY, CDS, etc, and
> the man page updated to reflect this?
>
> Regards,
> Anand Buddhdev
> --
>
> Just my opinion, but I would like it to apply to all crypto fields.

And that's a useful option, I had not been using it, but I will now, thanks.

-- 
Bob Harold
-- 
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: Intent and implementation of dig's +crypto option

[Marco Davids (SIDN) via bind-users]

Hi Anand,

Op 22-09-2023 om 14:46 schreef Anand Buddhdev:

Do you think that dig should be adjusted to suppress cryptographic 
material from other records such as TLSA, SSHFP, CDNSKEY, CDS, etc, and 
the man page updated to reflect this?


Great discussion! I don't have any strong opinions just yet.

But when you wrote this:

> When I query using dig, and use the combination "+nocrypto +dnssec"

It reminded me that that there is such thing as a .digrc file, that 
perhaps not all of the readers are familiar with.


Mine has this content:

+bufsize=1232
+dnssec
+nocrypto
+multi
-t 

It serves me well, mostly. Sometimes it bites me as well.

In general I'm happy with it.

Best regards,

--
Marco Davids
Research Engineer

SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids
https://mastodon.social/@marcodavids | Matrix: @marco:sidnlabs.nl
Nostr: 11ed01ff277d94705c2931867b8d900d8bacce6f27aaf7440ce98bb50e02fb34



OpenPGP_signature
Description: OpenPGP digital signature
-- 
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

Intent and implementation of dig's +crypto option

[Anand Buddhdev]

Hi folks,

I wanted to open a GitLab issue about this, but then thought it might be 
nice to have a discussion to hear the views of users.


dig 9.18.19's man page says:

  +crypto, +nocrypto
This option toggles the display of cryptographic fields in DNSSEC
records. The contents of these fields are unnecessary for debugging
most DNSSEC validation failures and removing them makes it easier to
see the common failures. The default is to display the fields. When
omitted, they are replaced by the string [omitted] or, in the DNSKEY
case, the key ID is displayed as the replacement,
e.g. [ key id = value ].

When I query using dig, and use the combination "+nocrypto +dnssec" then 
dig suppresses the crypto material for DNSKEY, DS and RRSIG records. 
This is in agreement with the man page.


But when I query for the newly introduced ZONEMD record, dig also hides 
the hash. In my opinion, ZONEMD is not a DNSSEC-related record, and so 
its hash should not be hidden (according to the man page).


On the other hand, the hash displayed for ZONEMD, like with hashes of DS 
records, is not especially useful for eyeballing. For me, it is enough 
to see that there's a ZONEMD record, but I don't need to see all the hex 
(which is only needed by code that actually wants to verify it). So I'm 
actually fine with the ZONEMD hash being suppressed, but the man page 
needs to be updated.


In a similar way, the hashes displayed in TLSA and similar records could 
also be suppressed, but dig currently doesn't.


Do you think that dig should be adjusted to suppress cryptographic 
material from other records such as TLSA, SSHFP, CDNSKEY, CDS, etc, and 
the man page updated to reflect this?


Regards,
Anand Buddhdev
--
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