Re: DoT forwarding from BIND9

[Petr Špaček]

On 14. 12. 22 16:55, Petr Menšík wrote:

Hi Vicky.

Excellent, thank you for the issue link.

Is backport to 9.18 decided already? Would it appear on minor updates in 
9.18.x line? I see comment it needs some missing feature. Is that 
temporary issue or already decided? It seems to be important 
prerequisite for Zero Trust initiative implementation.


On 12/14/22 16:16, Victoria Risk wrote:

Petr,

You didn’t miss it, we don’t have it yet. 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3726


Currently we don't plan backport of this feature. It is an invasive 
change and v9.18 is in its "stable years" now.


FTR you can gather this information from Gitlab:
If you look at "Labels" in the sidebar on the right you can notice green 
"v9.19" label and no green "v9.18" label. That indicates that we do not 
plan to backport it to v9.18 branch.


(Also, if you hover your cursor over individual labels it will give you 
more wordy description of their meaning.)


HTH.

--
Petr Špaček
--
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: [KASP] setup KASP in master / slave architecture

[adrien sipasseuth]

Hi,

Ok, I got confused, no need for the keys on the slavs actually.

On the other hand, my slaves should generate the .signed, .signed.jnl and
.jbk files of my zones, no? currently it is not my case, should I copy them
from the master?

moreover, when I test a "dig A" I don't have the associated RRSIG when I do
my "dig A" on a slave while on the master I do.

Regards,
Adrien

Le lun. 12 déc. 2022 à 12:59, Darren Ankney  a
écrit :

>
>
> the keys are generated on the master but not on the slaves.
> so I don't understand how the slaves can read their zone file which ends
> in ".signed" because they don't have the keys ? (but it's work with dig, i
> see DS with the right ZSK)
>
> Regards
>
> Adrien
>
>
> Because the zone is signed with DNSSEC but not encrypted.  DNSSEC is only
> providing authentication of the source of the zone, not hiding the contents
> (https://www.rfc-editor.org/rfc/rfc4033).  For the primary -> secondary
> zone transfer, you should setup TSIG authentication if you haven’t already
> to ensure that only your secondary can perform a zone transfer (
> https://www.rfc-editor.org/rfc/rfc2931 and
> https://bind9.readthedocs.io/en/v9_18_9/chapter7.html#tsig).
> --
> 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: [KASP] setup KASP in master / slave architecture

[Darren Ankney]

I have a simple “mylocal” zone setup with a primary and secondary server.

my primary has this .jnl file:

mylocal.jnl

My secondary has this similar .jnl file:

mylocal.saved.jnl

which I believe was distributed via zone transfer.  You find no such similar 
files on your secondary?

If you 

dig @ .. A +dnssec +multiline

where  is the IP of your recursive server and .. 
is something in the domain you are trying to verify the DNSSEC is working.

Does your flags line look something like this? 

;; flags: qr rd ra ad;

Per the manual:

The important detail in this output is the presence of the ad flag in the 
header. This signifies that BIND has retrieved all related DNSSEC information 
related to the target of the query (ftp.isc.org) and that the answer received 
has passed the validation process described in How Are Answers Verified?. We 
can have confidence in the authenticity and integrity of the answer, that 
ftp.isc.org really points to the IP address 149.20.1.49, and that it was not a 
spoofed answer from a clever attacker.


https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#using-dig-to-verify

My “flags” line does not show the “ad” flag as this is just a set of private 
servers on a local lan. I can’t submit the DNSSEC details upstream as described 
here:

https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#uploading-information-to-the-parent-zone

> On Dec 15, 2022, at 12:05 PM, adrien sipasseuth  
> wrote:
> 
> Hi,
> 
> Ok, I got confused, no need for the keys on the slavs actually.
> 
> On the other hand, my slaves should generate the .signed, .signed.jnl and 
> .jbk files of my zones, no? currently it is not my case, should I copy them 
> from the master?
> 
> moreover, when I test a "dig A" I don't have the associated RRSIG when I do 
> my "dig A" on a slave while on the master I do.
> 
> Regards,
> Adrien
> 

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

plugin_version

[Marcus Kool]

Hi,

I have written a plugin for named and was wondering what the policy behind the 
usage of plugin_version() is and what kind of compatibility check it intends to 
perform.

It is common for plugins to use query_ctx_t and its members fname, view, client 
(client.message, client.query) etc.
Since these data structures may change between (patch) versions, a plugin 
compiled for version A can get a SEGV signal because a data structure changed 
and the plugin is used inside named version B.
I have little experience with data structure changes of named and observed only the addition of refresh_rrset in query_ctx (somewhere between 9.16.1 and 9.16.35) which did not cause an issue since its 
1-byte size did not change offsets of most members inside the query_ctx struct.


In our plugin, plugin_register() checks for the major and minor version number in named_g_version so a plugin compiled with 9.16.x refuses to initialize inside a 9.18.y named process and vice versa.  
But I have the impression that this might not be a 100% guarantee that all is well.


Because we like to release as few as possible versions of the plugin I have a second question: how can we be sure that a plugin compiled with 9.X.1 will have no issues accessing named data structures 
for all patch versions of 9.X?


Thanks,

Marcus


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

[Ondřej Surý]

Hi Marcus,

I am afraid that we can’t provide any guarantees about the BIND 9 internal 
libraries. We made a decision to drop the layers and layers of compatibility 
for the sake of maintainability.

That said, once the release is pronounced ESV (roughly a year from initial 
release), we try to minimize changes to that branch, but it could still happen 
if needed by a security fix.

As for the binary compatibility, there’s no guarantee whatsoever, I think you 
need to match the full version to check whether the plug-in should be loaded.

Honestly, the best way how to keep the plug-in that’s useful for wider audience 
maintained would be to contribute it to the BIND 9 with a promise that the 
authors will keep helping maintaining the plug-in. (We would like to avoid the 
situations where the author just dumps the code on us and don’t care anymore - 
there’s associated maintenance cost with any new feature.)

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 15. 12. 2022, at 20:10, Marcus Kool  wrote:
> 
> 
> Hi,
> 
> I have written a plugin for named and was wondering what the policy behind 
> the usage of plugin_version() is and what kind of compatibility check it 
> intends to perform.
> 
> It is common for plugins to use query_ctx_t and its members fname, view, 
> client (client.message, client.query) etc.
> Since these data structures may change between (patch) versions, a plugin 
> compiled for version A can get a SEGV signal because a data structure changed 
> and the plugin is used inside named version B.
> I have little experience with data structure changes of named and observed 
> only the addition of refresh_rrset in query_ctx (somewhere between 9.16.1 and 
> 9.16.35) which did not cause an issue since its 1-byte size did not change 
> offsets of most members inside the query_ctx struct.
> 
> In our plugin, plugin_register() checks for the major and minor version 
> number in named_g_version so a plugin compiled with 9.16.x refuses to 
> initialize inside a 9.18.y named process and vice versa.  But I have the 
> impression that this might not be a 100% guarantee that all is well.
> 
> Because we like to release as few as possible versions of the plugin I have a 
> second question: how can we be sure that a plugin compiled with 9.X.1 will 
> have no issues accessing named data structures for all patch versions of 9.X?
> 
> Thanks,
> 
> Marcus
> 
> 
> 
> 
> 
> -- 
> 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: plugin_version

[Marcus Kool]

Hi Ondrej,

yeah, I was kinda expecting "no guarantees", but isn't the plugin_version() 
function a good method candidate to enforce compatibility?
I mean, isn't increasing NS_PLUGIN_VERSION when a (plugin visible) data 
structure changes, a good way to enforce that only compatible plugins are used?

Thanks,

Marcus


On 15/12/2022 19:32, Ondřej Surý wrote:

Hi Marcus,

I am afraid that we can’t provide any guarantees about the BIND 9 internal 
libraries. We made a decision to drop the layers and layers of compatibility 
for the sake of maintainability.

That said, once the release is pronounced ESV (roughly a year from initial 
release), we try to minimize changes to that branch, but it could still happen 
if needed by a security fix.

As for the binary compatibility, there’s no guarantee whatsoever, I think you 
need to match the full version to check whether the plug-in should be loaded.

Honestly, the best way how to keep the plug-in that’s useful for wider audience maintained would be to contribute it to the BIND 9 with a promise that the authors will keep helping maintaining the 
plug-in. (We would like to avoid the situations where the author just dumps the code on us and don’t care anymore - there’s associated maintenance cost with any new feature.)


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 15. 12. 2022, at 20:10, Marcus Kool  wrote:



Hi,

I have written a plugin for named and was wondering what the policy behind the 
usage of plugin_version() is and what kind of compatibility check it intends to 
perform.

It is common for plugins to use query_ctx_t and its members fname, view, client 
(client.message, client.query) etc.
Since these data structures may change between (patch) versions, a plugin 
compiled for version A can get a SEGV signal because a data structure changed 
and the plugin is used inside named version B.
I have little experience with data structure changes of named and observed only the addition of refresh_rrset in query_ctx (somewhere between 9.16.1 and 9.16.35) which did not cause an issue since 
its 1-byte size did not change offsets of most members inside the query_ctx struct.


In our plugin, plugin_register() checks for the major and minor version number in named_g_version so a plugin compiled with 9.16.x refuses to initialize inside a 9.18.y named process and vice 
versa.  But I have the impression that this might not be a 100% guarantee that all is well.


Because we like to release as few as possible versions of the plugin I have a second question: how can we be sure that a plugin compiled with 9.X.1 will have no issues accessing named data 
structures for all patch versions of 9.X?


Thanks,

Marcus



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

[Ondřej Surý]

I believe that `NS_PLUGIN_VERSION` is reserved for situations
where the **plugin** API itself changes. But I agree with you that
the current situation where the query_ctx_t struct members are
accessed directly isn't ideal.

My recommendation would be to recompile the plugin together
with each new BIND 9 version.

I am open to any suggestions, but I think the having a GitLab
issue would be a better venue to record any ideas around the
plugin system.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.



> On 15. 12. 2022, at 21:47, Marcus Kool  wrote:
> 
> Hi Ondrej,
> 
> yeah, I was kinda expecting "no guarantees", but isn't the plugin_version() 
> function a good method candidate to enforce compatibility?
> I mean, isn't increasing NS_PLUGIN_VERSION when a (plugin visible) data 
> structure changes, a good way to enforce that only compatible plugins are 
> used?
> 
> Thanks,
> 
> Marcus
> 
> 
> 
> On 15/12/2022 19:32, Ondřej Surý wrote:
>> Hi Marcus,
>> 
>> I am afraid that we can’t provide any guarantees about the BIND 9 internal 
>> libraries. We made a decision to drop the layers and layers of compatibility 
>> for the sake of maintainability.
>> 
>> That said, once the release is pronounced ESV (roughly a year from initial 
>> release), we try to minimize changes to that branch, but it could still 
>> happen if needed by a security fix.
>> 
>> As for the binary compatibility, there’s no guarantee whatsoever, I think 
>> you need to match the full version to check whether the plug-in should be 
>> loaded.
>> 
>> Honestly, the best way how to keep the plug-in that’s useful for wider 
>> audience maintained would be to contribute it to the BIND 9 with a promise 
>> that the authors will keep helping maintaining the plug-in. (We would like 
>> to avoid the situations where the author just dumps the code on us and don’t 
>> care anymore - there’s associated maintenance cost with any new feature.)
>> 
>> 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 15. 12. 2022, at 20:10, Marcus Kool  
>>>  wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I have written a plugin for named and was wondering what the policy behind 
>>> the usage of plugin_version() is and what kind of compatibility check it 
>>> intends to perform.
>>> 
>>> It is common for plugins to use query_ctx_t and its members fname, view, 
>>> client (client.message, client.query) etc.
>>> Since these data structures may change between (patch) versions, a plugin 
>>> compiled for version A can get a SEGV signal because a data structure 
>>> changed and the plugin is used inside named version B.
>>> I have little experience with data structure changes of named and observed 
>>> only the addition of refresh_rrset in query_ctx (somewhere between 9.16.1 
>>> and 9.16.35) which did not cause an issue since its 1-byte size did not 
>>> change offsets of most members inside the query_ctx struct.
>>> 
>>> In our plugin, plugin_register() checks for the major and minor version 
>>> number in named_g_version so a plugin compiled with 9.16.x refuses to 
>>> initialize inside a 9.18.y named process and vice versa.  But I have the 
>>> impression that this might not be a 100% guarantee that all is well.
>>> 
>>> Because we like to release as few as possible versions of the plugin I have 
>>> a second question: how can we be sure that a plugin compiled with 9.X.1 
>>> will have no issues accessing named data structures for all patch versions 
>>> of 9.X?
>>> 
>>> Thanks,
>>> 
>>> Marcus
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> 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

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

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: How to remove RR from dnssec policy signed zone ?

[Mark Andrews]

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;’.

> On 16 Dec 2022, at 14:39, vom513  wrote:
> 
> * 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Behavior of port tag in options clause is ambiguous

[Vikas Sharma]

Hi Team,

we have following configuration in my named.conf
where i named process on primary DNS is listening on port 15010.
whereas secondary DNS is running on port 53.
All Notification to secondary DNS is forwarded on destination port 53 from
primary DNS.

Now when i add tag port 15010 in options clause on primary DNS, then i see
some notification message being forwarded to secondary DNS to dest port
15010. these messages are in addition to notification to secondary DNS with
dest port 53.
changing port value form 15010 to 20598 sends notification to secondary
DSN on dest port 20598 in addition to notification to secondary on port 53.

i have a firewall on secondary DNS which is rejecting all packets on port
15010/20598.
i see that all my data is populated on secondary DNS without any problem
due to notifications to secondary DNS on port 53.

query is why named is sending notification to secondary DNS on port
15010/20598 when regular notification is also going to secondary DNS on
port 53.


acl theAllServers {
 thePrimary;
 theSecondary;
 localhost;
};

options {
 directory "/var/opt/named";
 pid-file "/var/opt/run/named.pid";
 allow-transfer { theAllServers; };
 allow-query { any; };
 zone-statistics no;
 notify yes;
 max-cache-size 14297m;
 max-journal-size 1048576;
 port 15010;   #=> used 20598
as well instead of 15010;
 listen-on port 15010 { 127.0.0.1; };
 also-notify {
 10.1.2.4 port 53;
 10.1.2.5 port 53;
 };
};

Best Regards,
Vikas Sharma
-- 
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: Behavior of port tag in options clause is ambiguous

[Ondřej Surý]

Hi,

there’s really nice documentation for BIND 9, and it’s even online and have a 
section on the “port”: 
https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-port

Also don’t limit the outgoing ports to a single number - that’s a bad security 
practice, you should be using the full range if possible.

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 16. 12. 2022, at 7:26, Vikas Sharma  wrote:
> 
> 
> Hi Team,
>  
> we have following configuration in my named.conf
> where i named process on primary DNS is listening on port 15010.
> whereas secondary DNS is running on port 53.
> All Notification to secondary DNS is forwarded on destination port 53 from 
> primary DNS. 
>  
> Now when i add tag port 15010 in options clause on primary DNS, then i see 
> some notification message being forwarded to secondary DNS to dest port 
> 15010. these messages are in addition to notification to secondary DNS with 
> dest port 53.
> changing port value form 15010 to 20598 sends notification to secondary DSN 
> on dest port 20598 in addition to notification to secondary on port 53.
>  
> i have a firewall on secondary DNS which is rejecting all packets on port 
> 15010/20598.
> i see that all my data is populated on secondary DNS without any problem due 
> to notifications to secondary DNS on port 53.
>  
> query is why named is sending notification to secondary DNS on port 
> 15010/20598 when regular notification is also going to secondary DNS on port 
> 53.
>  
>  
> acl theAllServers {
>  thePrimary;
>  theSecondary;
>  localhost;
> };
>  
> options {
>  directory "/var/opt/named";
>  pid-file "/var/opt/run/named.pid";
>  allow-transfer { theAllServers; };
>  allow-query { any; };
>  zone-statistics no;
>  notify yes;
>  max-cache-size 14297m;
>  max-journal-size 1048576;
>  port 15010;   #=> used 20598 as 
> well instead of 15010;
>  listen-on port 15010 { 127.0.0.1; };
>  also-notify {
>  10.1.2.4 port 53;
>  10.1.2.5 port 53;
>  };
> };
> 
> Best Regards,
> Vikas Sharma
> -- 
> 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