Re: DNSSEC signing of an internal zone gains nothing (unless??)
On 01. 08. 22 18:15, John W. Blue via bind-users wrote: As some enterprise networks begin to engineer towards the concepts of ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC signing of an internal zone. Granted, it has long been considered unwise by DNS pro’s with a commonly stated reason that it increasing the size of the zone yadda, yadda, yadda. While that extra overhead is true, it is more accurate to say that if internal clients are talking directly to an authoritative server the AD flag will not be set. You will only get the AA flag. So there is nothing to be gained from signing an internal zone. However, I have not tested it yet, I would assume that if a non-authoritative internal server was queried it would be able to walk the chain of trust and return AD. Thoughts? I think it's worth reading https://datatracker.ietf.org/doc/html/draft-krishnaswamy-dnsop-dnssec-split-view Keep in mind it is 15 years old, but it will give you an idea about various points of view. -- 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: DNSSEC signing of an internal zone gains nothing (unless??)
On Wed, Aug 03, 2022 at 04:49:35PM +1000, Mark Andrews wrote: ! Additionally authoritative servers for a zone are supposed to answer queries with RD=1 set with RA=0 if the client is not being offered recursion. REFUSED is the wrong answer of the query name involves zones you serve. Only if you are a recursive only server should you be considering REFUSED. I am seeing queries for example.com (literally). I didn't talk about people querying my own domains. Those seem to get their answer, plus "recursion desired but ..." -- PMc -- 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 signing of an internal zone gains nothing (unless??)
On Tue, Aug 02, 2022 at 02:04:22PM -0400, Timothe Litt wrote:
! On 02-Aug-22 13:18, Peter wrote:
! > On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:
! > !
! > ! On 02-Aug-22 11:09,bind-users-requ...@lists.isc.org wrote:
! > !
! > ! > | Before your authoritative view, define a recursive view with the
internal
! > ! > ! zones defined as static-stub, match-recursive-only "yes", and a
! > ! > ! server-address of localhost.
! > ! >
! > ! > Uh? Why before?
! > !
! > ! Because each request attempts to match the views in order. You want the
! > ! stub view to match recursive requests. The non-RD requests will fall thru
! > ! to the internal zone and get the authoritative data.
! >
! > Ahh, I see. But this does not work so well for me, because I have the
! > public authoritative server also in the same process. And from the
! > Internet will come requests with RD flag set, and these must get a
! > REFUSED ("recursion desired but not available").
! >
! > So I considered it too dangerous to select views depending on the RD
! > flag being present or not, and resolve this with a slightly different
! > ordering of the views.
! >
! > -- PMc
!
! Order matters, and changing it will change behaviors.
That is obvious.
! The server doesn't select ONLY on the RD flag. It also selects on IP address
!and/or TSIG keys. The RD flag is only used to select between the recursive and
!authoritative view pairs for MATCHING CLIENTS.
Fine.
! So you should order the views as I showed.
That's not going to work with me. I posted the description of
my approach, so either you provide evidence of why my logic is
flawed, or You stop telling me that I should obey You.
I devised my logic, and it is well possible that it is flawed,
but if so, then I want to understand the exact flaw, and learn
and improve.
! The public clients will fail the "match-clients" clause of the internal views
!regardless of the RD because of their IP addresses. They will fall thru to the
!r-external view. That will also fail unless they are listed clients. So
!again, they fall thru to the external view. That has recursion no - which
!means that RD will return REFUSED.
Fine. Same here.
! The only danger comes from failing to properly setup the client matching ACLs,
!or from making changes to the logic without understanding how it works.
Mistakes can happen, e.g. when in a hurry.
! Instead of guessing, use what I provided and test it. It
Re: DNSSEC signing of an internal zone gains nothing (unless??)
Additionally authoritative servers for a zone are supposed to answer queries with RD=1 set with RA=0 if the client is not being offered recursion. REFUSED is the wrong answer of the query name involves zones you serve. Only if you are a recursive only server should you be considering REFUSED. -- Mark AndrewsOn 3 Aug 2022, at 04:04, Timothe Litt wrote:
On 02-Aug-22 13:18, Peter wrote:
On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:
!
! On 02-Aug-22 11:09, bind-users-requ...@lists.isc.org wrote:
!
! > | Before your authoritative view, define a recursive view with the internal
! > ! zones defined as static-stub, match-recursive-only "yes", and a
! > ! server-address of localhost.
! >
! > Uh? Why before?
!
! Because each request attempts to match the views in order. You want the
! stub view to match recursive requests. The non-RD requests will fall thru
! to the internal zone and get the authoritative data.
Ahh, I see. But this does not work so well for me, because I have the
public authoritative server also in the same process. And from the
Internet will come requests with RD flag set, and these must get a
REFUSED ("recursion desired but not available").
So I considered it too dangerous to select views depending on the RD
flag being present or not, and resolve this with a slightly different
ordering of the views.
-- PMc
Order matters, and changing it will change behaviors.
My example combines the internal and public servers into one bind instance. It provides recursive and authoritative service to internal clients; the recursive view will set AD. For external clients, it is authoritative - but there is provision for known clients to get recursive service (with AD). Such clients would be excluded from matching the "*internal" views. You might use this for DMZ systems, or for management tools (e.g. if you want to AXFR the external view.)
My public authoritative server(s) are the "external" view.
The server doesn't select ONLY on the RD flag. It also selects on IP address and/or TSIG keys. The RD flag is only used to select between the recursive and authoritative view pairs for MATCHING CLIENTS.
So you should order the views as I showed.
The public clients will fail the "match-clients" clause of the internal views regardless of the RD because of their IP addresses. They will fall thru to the r-external view. That will also fail unless they are listed clients. So again, they fall thru to the external view. That has recursion no - which means that RD will return REFUSED.
The only danger comes from failing to properly setup the client matching ACLs, or from making changes to the logic without understanding how it works.
Instead of guessing, use what I provided and test it. It works. It has worked for many years. Once you have tested it and completely understand it, THEN make changes. Carefully. And test them.
This technique is straightforward if you completely understand what it's doing, but if you make assumptions you are likely to get into trouble.
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users
OpenPGP_signature
Description: Binary data
--
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 signing of an internal zone gains nothing (unless??)
On 02-Aug-22 13:18, Peter wrote:
On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:
!
! On 02-Aug-22 11:09,bind-users-requ...@lists.isc.org wrote:
!
! > | Before your authoritative view, define a recursive view with the internal
! > ! zones defined as static-stub, match-recursive-only "yes", and a
! > ! server-address of localhost.
! >
! > Uh? Why before?
!
! Because each request attempts to match the views in order. You want the
! stub view to match recursive requests. The non-RD requests will fall thru
! to the internal zone and get the authoritative data.
Ahh, I see. But this does not work so well for me, because I have the
public authoritative server also in the same process. And from the
Internet will come requests with RD flag set, and these must get a
REFUSED ("recursion desired but not available").
So I considered it too dangerous to select views depending on the RD
flag being present or not, and resolve this with a slightly different
ordering of the views.
-- PMc
Order matters, and changing it will change behaviors.
My example combines the internal and public servers into one bind instance. It provides
recursive and authoritative service to internal clients; the recursive view will set AD.
For external clients, it is authoritative - but there is provision for known clients to
get recursive service (with AD). Such clients would be excluded from matching the
"*internal" views. You might use this for DMZ systems, or for management tools
(e.g. if you want to AXFR the external view.)
My public authoritative server(s) are the "external" view.
The server doesn't select ONLY on the RD flag. It also selects on IP address
and/or TSIG keys. The RD flag is only used to select between the recursive and
authoritative view pairs for MATCHING CLIENTS.
So you should order the views as I showed.
The public clients will fail the "match-clients" clause of the internal views
regardless of the RD because of their IP addresses. They will fall thru to the
r-external view. That will also fail unless they are listed clients. So again, they
fall thru to the external view. That has recursion no - which means that RD will return
REFUSED.
The only danger comes from failing to properly setup the client matching ACLs,
or from making changes to the logic without understanding how it works.
Instead of guessing, use what I provided and test it. It works. It has worked
for many years. Once you have tested it and completely understand it, THEN
make changes. Carefully. And test them.
This technique is straightforward if you completely understand what it's doing,
but if you make assumptions you are likely to get into trouble.
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
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
Re: DNSSEC signing of an internal zone gains nothing (unless??)
On Tue, Aug 02, 2022 at 05:51:28AM -0400, Timothe Litt wrote:
! You can get the AD flag set, with a bit of extra work. I've done this for
! years.
Thanks for Your message, Timothe.
After investigating the matter, I had figured out a similar approach -
but didn't know if this is a recommended or commonly used way. There
is only a paper somewhere in the depths of ISC describing how to do
that for a root-slave. Anyway, it appears to work.
I finally created 6-way servers by using some extra addresses on lo0
(auth+recursing for root+intranet+public) and then found the result
suitable structured and maintainable.
! Before your authoritative view, define a recursive view with the internal
! zones defined as static-stub, match-recursive-only "yes", and a
! server-address of localhost.
Uh? Why before?
My approach so far:
view "rootslave" {
match-clients { fdff::1; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;
};
view "intraslave" {
match-clients { fdff::2; key "slave1"; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;
};
view "extraslave" {
match-clients { key "slave1extra"; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;
};
view "guest" {// public WLAN etc.
match-clients { ... };
// not yet deployed, needs clarification
};
view "desktop" {// user devices
match-clients { ... };
};
view "intra" {
match-clients { };
};
view "public" { // external sites allowed to use recursing
match-clients { ... } ;
// not yet deployed, needs evaluation
};
view "external" { // fall-through
match-clients { any; } ;
allow-query-cache { none; };
allow-recursion { none; };
recursion no;
zone "." { // is this necessary? (something didn't work without)
type hint;
file "/usr/local/etc/namedb/named.root";
};
};
Sure this could also be done by running 2 or 3 instances, and probably
more safe - but where would be the fun then?
-- PMc
--
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 signing of an internal zone gains nothing (unless??)
On 01-Aug-22 12:15, John W. Blue wrote:
While that extra overhead is true, it is more accurate to say that if
internal clients are talking directly to an authoritative server the
AD flag will not be set. You will only get the AA flag. So there is
nothing to be gained from signing an internal zone.
You can get the AD flag set, with a bit of extra work. I've done this
for years.
The question of whether the client resolver does/should trust the AD
flag is situation dependent.
Before your authoritative view, define a recursive view with the
internal zones defined as static-stub, match-recursive-only "yes", and
a server-address of localhost. In the authoritative view, you can share
the cache (attach-cache) with the recursive view.
It's pretty straightforward to automate keeping the static-stub list in
sync - I keep it in a separate .conf file.
e.g. this outline (the order matters, views are selected first-match)
|view||"r-internal" in {||
|| match-clients {...};
||match-recursive-only yes;
||recursion yes;
-- standard config --
};|
|/* Included */||
|||
|||-- trusted-keys --
zone||"example.net" in {||
type static-stub;
server-addresses {127.0.0.1; };
|| };|
|}:|
|view||"internal" in {||
||attach-cache "r-internal";
||recursion no;|
| --- standard config --|
|/* included */
|
| zone "example.net" in {
||auto-dnssec maintain;
||type master;
file ...;|
|--standard config--
};|
|||};|
|view "r-external" in { /* if you allow external recursion, or use acls
to fake external clients */
|
|...|
|};|
|view "external" in {|
|...|
|};
|
A script along the lines of:
|perl -e'while(<>){/^\s*zone/ && print $_," type static-stub;\n
server-addresses { 127.0.0.1; }; \n}; \n"}' >internal_stub_zones.conf|
will generate the static-stub declarations.
Of course, depending on how you add/remove zones, YMMV.
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
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
Re: DNSSEC signing of an internal zone gains nothing (unless??)
DNSSEC is designed to be validated in the application. That applies equally to internal zones as it does to external zones. One procedure for them all. -- Mark Andrews > On 1 Aug 2022, at 11:15, John W. Blue via bind-users > wrote: > > > As some enterprise networks begin to engineer towards the concepts of > ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC signing of > an internal zone. > > Granted, it has long been considered unwise by DNS pro’s with a commonly > stated reason that it increasing the size of the zone yadda, yadda, yadda. > > While that extra overhead is true, it is more accurate to say that if > internal clients are talking directly to an authoritative server the AD flag > will not be set. You will only get the AA flag. So there is nothing to be > gained from signing an internal zone. > > However, I have not tested it yet, I would assume that if a non-authoritative > internal server was queried it would be able to walk the chain of trust and > return AD. > > Thoughts? > > John > -- > 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: DNSSEC signing of an internal zone gains nothing (unless??)
Let's flip this on it's head. On 8/1/22 10:15 AM, John W. Blue via bind-users wrote: As some enterprise networks begin to engineer towards the concepts of ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC signing of an internal zone. So why shouldn't the internal zone(s) be signed? Granted, it has long been considered unwise by DNS pro’s with a commonly stated reason that it increasing the size of the zone yadda, yadda, yadda. Are we really going to let the storage capacity / memory consumption of the DNS server dictate the security posture? If anything, it seems like this is a justification to upgrade the DNS server. }:-) While that extra overhead is true, it is more accurate to say that if internal clients are talking directly to an authoritative server the AD flag will not be set. You will only get the AA flag. So there is nothing to be gained from signing an internal zone. An argument could be made that this seems like an excuse to not sign zones. However, I have not tested it yet, I would assume that if a non-authoritative internal server was queried it would be able to walk the chain of trust and return AD. I would expect so. Thoughts? Yes; sign the internal zone(s). Upgrade the servers to hold the (somewhat) larger zone(s) if you need to. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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
Re: DNSSEC signing of an internal zone gains nothing (unless??)
Don’t mix functions - separate your recursive and your authoritative (internal) servers. Then you can have the AD from the resolver. That said, the AD from the resolver means something only if the last mile is trusted. But DNSSEC also asserts the integrity of the zone in case it’s transferred to secondaries, or provided by a secure signing system, etc… 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 1. 8. 2022, at 18:40, John W. Blue via bind-users > wrote: > > And that is my point .. show me your +dnssec dig against an internal > authoritative server that has AD set. > > John > > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Grant > Taylor via bind-users > Sent: Monday, August 1, 2022 11:29 AM > To: bind-users@lists.isc.org > Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??) > >> On 8/1/22 10:15 AM, John W. Blue via bind-users wrote: >> While that extra overhead is true, it is more accurate to say that if >> internal clients are talking directly to an authoritative server the >> AD flag will not be set. You will only get the AA flag. So there is >> nothing to be gained from signing an internal zone. > > I feel like that's an unacceptably big if. It also precludes clients from > doing client side DNSSEC validation. > > Finally, why hold internal systems to a lower security standard than external > systems? > > > > -- > Grant. . . . > unix || die > > -- > 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: DNSSEC signing of an internal zone gains nothing (unless??)
Also John .. how SSHA and TLSA be used if the internal zone fails validation? John -Original Message- From: John Franklin [mailto:frank...@sentaidigital.com] Sent: Monday, August 1, 2022 12:45 PM To: John W. Blue Cc: bind-users@lists.isc.org Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??) On Aug 1, 2022, at 12:15, John W. Blue via bind-users wrote: > > As some enterprise networks begin to engineer towards the concepts of > ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC signing of > an internal zone. > > Granted, it has long been considered unwise by DNS pro’s with a commonly > stated reason that it increasing the size of the zone yadda, yadda, yadda. > [snip] > Thoughts? DNSSEC enables use of certain security RRs, such as SSHA and TLSA, which can be used as part of a zero trust solution in DevOps pipelines. It’s also good practice managing DNSSEC before deploying it in public production sites. jf -- John Franklin frank...@sentaidigital.com -- 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 signing of an internal zone gains nothing (unless??)
Keep in mind that the discussion is limited to an internal zone only. Running authoritative and recursive at the same time cannot be labeled as a “terribly bad practice”: https://kb.isc.org/docs/bind-best-practices-recursive “administrators may, for convenience, choose to serve some internal-only zones authoritatively from their recursive servers” John From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark Elkins via bind-users Sent: Monday, August 1, 2022 1:12 PM To: bind-users@lists.isc.org Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??) Hmmm - might be saying the wrong thing but... .SE was DNSSEC Signed waaay before the root, so if living in Sweden, one would prep your DNSSEC aware resolver with the DS Key of the .SE Zone. DNSSEC then worked for .SE domains. Perhaps do the same? I do get confused further down in this email when one says you'll get back an "AA" flag in the answer. That will only happen if you ask the Authoritative Server for the domain you are looking in. That shouldn't be a Recursive server. It is terribly bad practice to have a BIND server running in both Authoritative and Recursive mode at the same time - should be two separate instances of BIND. On 8/1/22 7:51 PM, John W. Blue via bind-users wrote: Also do not disagree. However, the intent of the thread is to talk about the lack of an AD flag from a non-public internal authoritative server. Based upon what I am seeing only the AA flag is set. John -Original Message- From: John Franklin [mailto:frank...@sentaidigital.com] Sent: Monday, August 1, 2022 12:45 PM To: John W. Blue Cc: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??) On Aug 1, 2022, at 12:15, John W. Blue via bind-users <mailto:bind-users@lists.isc.org> wrote: As some enterprise networks begin to engineer towards the concepts of ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC signing of an internal zone. Granted, it has long been considered unwise by DNS pro’s with a commonly stated reason that it increasing the size of the zone yadda, yadda, yadda. [snip] Thoughts? DNSSEC enables use of certain security RRs, such as SSHA and TLSA, which can be used as part of a zero trust solution in DevOps pipelines. It’s also good practice managing DNSSEC before deploying it in public production sites. jf -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za<mailto:m...@posix.co.za> Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za -- 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 signing of an internal zone gains nothing (unless??)
Hmmm - might be saying the wrong thing but... .SE was DNSSEC Signed waaay before the root, so if living in Sweden, one would prep your DNSSEC aware resolver with the DS Key of the .SE Zone. DNSSEC then worked for .SE domains. Perhaps do the same? I do get confused further down in this email when one says you'll get back an "AA" flag in the answer. That will only happen if you ask the Authoritative Server for the domain you are looking in. That shouldn't be a Recursive server. It is terribly bad practice to have a BIND server running in both Authoritative and Recursive mode at the same time - should be two separate instances of BIND. On 8/1/22 7:51 PM, John W. Blue via bind-users wrote: Also do not disagree. However, the intent of the thread is to talk about the lack of an AD flag from a non-public internal authoritative server. Based upon what I am seeing only the AA flag is set. John -Original Message- From: John Franklin [mailto:frank...@sentaidigital.com] Sent: Monday, August 1, 2022 12:45 PM To: John W. Blue Cc: bind-users@lists.isc.org Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??) On Aug 1, 2022, at 12:15, John W. Blue via bind-users wrote: As some enterprise networks begin to engineer towards the concepts of ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC signing of an internal zone. Granted, it has long been considered unwise by DNS pro’s with a commonly stated reason that it increasing the size of the zone yadda, yadda, yadda. [snip] Thoughts? DNSSEC enables use of certain security RRs, such as SSHA and TLSA, which can be used as part of a zero trust solution in DevOps pipelines. It’s also good practice managing DNSSEC before deploying it in public production sites. jf -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za <https://ftth.posix.co.za> OpenPGP_0xB6FA15470B82C101.asc Description: application/pgp-keys 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
Re: DNSSEC signing of an internal zone gains nothing (unless??)
On 8/1/22 11:51 AM, John W. Blue via bind-users wrote: However, the intent of the thread is to talk about the lack of an AD flag from a non-public internal authoritative server. Based upon what I am seeing only the AA flag is set. There are multiple reasons to sign zones. The existence of the AD flag is only one of them. IM(NS)HO, the lack of an AD flag from an authoritative server is not in and of itself a reason to not sign zones; internal or otherwise. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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
RE: DNSSEC signing of an internal zone gains nothing (unless??)
Also do not disagree. However, the intent of the thread is to talk about the lack of an AD flag from a non-public internal authoritative server. Based upon what I am seeing only the AA flag is set. John -Original Message- From: John Franklin [mailto:frank...@sentaidigital.com] Sent: Monday, August 1, 2022 12:45 PM To: John W. Blue Cc: bind-users@lists.isc.org Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??) On Aug 1, 2022, at 12:15, John W. Blue via bind-users wrote: > > As some enterprise networks begin to engineer towards the concepts of > ZeroTrust, one item caught me unaware: PM’s asking for the DNSSEC signing of > an internal zone. > > Granted, it has long been considered unwise by DNS pro’s with a commonly > stated reason that it increasing the size of the zone yadda, yadda, yadda. > [snip] > Thoughts? DNSSEC enables use of certain security RRs, such as SSHA and TLSA, which can be used as part of a zero trust solution in DevOps pipelines. It’s also good practice managing DNSSEC before deploying it in public production sites. jf -- John Franklin frank...@sentaidigital.com -- 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 signing of an internal zone gains nothing (unless??)
And that is my point .. show me your +dnssec dig against an internal authoritative server that has AD set. John -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Grant Taylor via bind-users Sent: Monday, August 1, 2022 11:29 AM To: bind-users@lists.isc.org Subject: Re: DNSSEC signing of an internal zone gains nothing (unless??) On 8/1/22 10:15 AM, John W. Blue via bind-users wrote: > While that extra overhead is true, it is more accurate to say that if > internal clients are talking directly to an authoritative server the > AD flag will not be set. You will only get the AA flag. So there is > nothing to be gained from signing an internal zone. I feel like that's an unacceptably big if. It also precludes clients from doing client side DNSSEC validation. Finally, why hold internal systems to a lower security standard than external systems? -- Grant. . . . unix || die -- 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 signing of an internal zone gains nothing (unless??)
On 8/1/22 10:15 AM, John W. Blue via bind-users wrote: While that extra overhead is true, it is more accurate to say that if internal clients are talking directly to an authoritative server the AD flag will not be set. You will only get the AA flag. So there is nothing to be gained from signing an internal zone. I feel like that's an unacceptably big if. It also precludes clients from doing client side DNSSEC validation. Finally, why hold internal systems to a lower security standard than external systems? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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
