RE: Re: Inquiry from Shimada

2022-05-11 Thread 嶋田信一郎 / SHIMADA，SHINICHIRO 
Dear Jason,

Thank you for your support.

Could you tell me the progress on my question below?

Can I understand following options do not work in BIND9.16.27?
・resolver-nonbackoff-tries
・resolver-retry-interval

Best Regards,
Shinichiro Shimada

From: 嶋田信一郎 / SHIMADA，SHINICHIRO
Sent: Friday, May 6, 2022 4:08 PM
To: ja...@isc.org; i...@isc.org; bind-users@lists.isc.org
Cc: 妹尾康弘 / Senoh，Yasuhiro ; 平石大二郎 / 
HIRAISHI，DAIJIRO 
Subject: RE: [!]Re: Inquiry from Shimada

Dear Jason,

Thank you for your response.
Your answer was helpful for me.

Kindly let me ask additional question.
Can I understand following options do not work in BIND9.16.27?
・resolver-nonbackoff-tries
・resolver-retry-interval

Best Regards,
Shinichiro Shimada


From: Jason Lasky mailto:ja...@isc.org>>
Sent: Thursday, April 28, 2022 7:25 AM
To: 嶋田信一郎 / SHIMADA，SHINICHIRO 
mailto:shinichiro.shimada...@hitachi-systems.com>>;
 i...@isc.org
Cc: 妹尾康弘 / Senoh，Yasuhiro 
mailto:yasuhiro.senoh...@hitachi-systems.com>>;
 平石大二郎 / HIRAISHI，DAIJIRO 
mailto:daijiro.hiraishi...@hitachi-systems.com>>
Subject: [!]Re: Inquiry from Shimada

Dear Shinichiro Shimada,

Thank you for contacting ISC.  Regarding your question below, I posed this to 
my Senior Engineer.  His feedback is as follows:
---
It turns out we have an open issue to add more detail on these options in the 
ARM:

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

However, I'm not sure when it will be addressed.  This is the very type of 
question that a
customer would ask us & get details on... so it is a good example of a ticket.
--
That said, I'm not sure whether or not you have interest in a BIND subscription 
with ISC.  I am attaching a data sheet for your review.
As a BIND subscriber you have priority for this types of requests.  If you let 
me know the approximate number of BIND servers you are running, I can give you 
budgetary pricing for subscriptions at each level (Bronze, Silver, and Gold).

If you are not interested in a BIND subscription, then ISC also offers free 
resources, such as our BIND Users Group:

The BIND Users Group:   
https://www.isc.org/bind-users-mailing-list/
https://lists.isc.org/mailman/listinfo/bind-users

You can post a message here:
bind-users@lists.isc.org


If you have any questions at all, I'm happy to discuss things further with you.

Kind Regards,
Jason


--

Jason Lasky

Partner Services

Internet Systems Corporation (ISC)

ja...@isc.org

+1 650.423.1452

On 4/25/22 10:10 PM, 嶋田信一郎 / SHIMADA，SHINICHIRO wrote:
To whom it may concern,

This is Shimada from DNS team in Hitachi, Ltd.

I would like to inquire on new function of BIND9.16.27.
Please tell me more about the options below.

・resolver-nonbackoff-tries
・resolver-retry-interval

I’ve already checked BIND 9.16 ARM but too short description to understand it.
Could you tell me how to use above in what kind of environment?
It would be helpful if you could introduce me to a link that contains 
information.

Best Regards,
Shinichiro Shimada



-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to

Re: Determining Which Authoritative Sever to Use

2022-05-11 Thread Grant Taylor via bind-users 

On 5/11/22 2:19 PM, Bob Harold wrote:

Not sure who set it up, but my DHCP servers have for some zones:

zone x.y.z.in-addr.arpa
{
     primary 10.2.3.4;
}


I'm assuming that is BIND's named.conf syntax.


Which I believe overrides the MNAME lookup.


Doesn't that just tell BIND where to initiate a zone transfer from?

I didn't think that it altered the zone contents in any way.

Aside:  I'm not connecting the dots of what this has to do with the 
larger conversation, /unless/ you are thinking that it alters the zone 
contents or at least what's returned to clients querying this DNS server.




--
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: Determining Which Authoritative Sever to Use

2022-05-11 Thread Bob Harold 
On Wed, May 11, 2022 at 1:50 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> On 5/11/22 11:24 AM, Bob McDonald wrote:
> > It would seem that using an anycast cloud name (An anycast cloud
> > of the NS device IPs) for the MNAME might provide the same level of
> > distribution as per Windows.  However, again, you run into the issues
> > of forwarded updates.
>
> Another thing that I've seen discussed -- but haven't tested myself --
> is to play tricks like having the MNAME be it's own zone hosted on each
> DNS server wherein the zone resolves the MNAME to the local DNS server.
>
> This seems like a varient on anycasting, which operates on the IP layer.
>   Except this provides similar functionality at the DNS application layer.
>
> You could probably achieve similar results with an RPZ overriding the
> MNAME with the local server's IP address.
>
> }:-)
>
>
>
> --
> Grant. . . .
> unix || die
>
>
Not sure who set it up, but my DHCP servers have for some zones:

zone x.y.z.in-addr.arpa
{
primary 10.2.3.4;
}

Which I believe overrides the MNAME lookup.

-- 
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: Determining Which Authoritative Sever to Use

2022-05-11 Thread Grant Taylor via bind-users 

On 5/11/22 11:24 AM, Bob McDonald wrote:
It would seem that using an anycast cloud name (An anycast cloud 
of the NS device IPs) for the MNAME might provide the same level of 
distribution as per Windows.  However, again, you run into the issues 
of forwarded updates.


Another thing that I've seen discussed -- but haven't tested myself -- 
is to play tricks like having the MNAME be it's own zone hosted on each 
DNS server wherein the zone resolves the MNAME to the local DNS server.


This seems like a varient on anycasting, which operates on the IP layer. 
 Except this provides similar functionality at the DNS application layer.


You could probably achieve similar results with an RPZ overriding the 
MNAME with the local server's IP address.


}:-)



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

Determining Which Authoritative Sever to Use

2022-05-11 Thread Bob McDonald 
It's always an architectural choice to use anycast with your authoritative
zones. I'm speaking from purely a private network (inside) viewpoint. I
typically only use anycast for recursive DNS servers on my
private (internal) network.

That said, here are some thoughts. (This is my understanding only)

A default primary/secondary DNS zone setup as per the relevant RFCs
includes one primary DNS server name in the MNAME field of the SOA record
for that DNS zone. Following a non-Windows update procedure, a device
(client of DHCP server - specified by DHCP option 81) sends a DNS query for
the zone SOA record. It then sends a dynamic update to the
specified MNAME server found in the reply to the SOA record query.
Windows can be a bit different. If, for example, the zone to be updated is
an Active Directory integrated DNS zone then this applies; a DHCP client
sends a rDNS request for SOA to it's local DNS server. Because this is an
Active Directory integrated DNS zone, each DC running DNS places it's own
name in the MNAME field. Now the update request goes to the local DC
running DNS. This spreads out the update request workload. There is a more
convoluted process involving stepping through the NS records looking for a
valid update server if the update should fail. This also does not take into
account any security involved with said updates.
Going back to "normal" DNS setups. If the MNAME in the SOAis replaced with
another name, this is an example of a truly hidden master. Updates sent in
this case require allow-update-fowarding to be set to any. This may on the
surface seem like it will do the trick but unsecured (those without tsig or
gss-tsig)  update requests may be hard to troubleshoot. Forwarding the
update replaces the update origin IP with that of the secondary server that
forwards the request. It would seem that using an anycast cloud name (An
anycast cloud of the NS device IPs) for the MNAME might provide the same
level of distribution as per Windows. However, again, you run into the
issues of forwarded updates. More testing would need to be done to see if
secured updates actually identify the correct requester in the log files.

In summary, there are SEVERAL methods to explore here and tons of options
within DNS and DHCP that might have some bearing on this also. Then there's
the holy war about the security of gss-tsig signed updates. Anyway, I've
been looking at this for the last decade. I'm sure I'll discover more along
the way.

Bob
-- 
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: After switching to "dnssec-policy", existing RRs are still signed with the "old" ZSK

2022-05-11 Thread Tom 




On 11.05.22 11:26, Mark Andrews wrote:

Signature-refresh determines when the RRSIGs will be replaced by looking at the 
expiration time and working backwards. New RRSIGs are generate Using 
signature-interval.


Ah, perfect. Thx.
--
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: bind 9.16.28 vrs. 9.18.2 (on freebsd) resolving foryoudecor.com

2022-05-11 Thread Michał Kępień 
> we observed a strange behaviour for the domain foryoudecor.com,
> when trying to resolve it using bind 9.18.2, using
> 
> dig -t mx foryoudecor.com
> 
> The bind log for 9.18.2 says:
> 
> May 11 12:00:14 ns named[96774]: fetch: foryoudecor.com/MX
> May 11 12:00:14 ns named[96774]: DNS format error from 61.129.70.40#53 
> resolving foryoudecor.com/MX for 193.105.105.1#27259: server sent FORMERR
> May 11 12:00:14 ns named[96774]: client @0x803bdcd60 193.105.105.1#27259 
> (foryoudecor.com): query failed (FORMERR) for foryoudecor.com/IN/MX at 
> query.c:7657
> 
> so the domain was not resolvable.
> 
> bind 9.16.28 resolves the MX for this domain.

The servers authoritative for foryoudecor.com return broken responses
(FORMERR + OPT) to EDNS queries.  This is a violation of RFC 6891
section 7.

BIND 9.18+ is more strict in processing such responses than the older
versions.  This is pointed out in the release notes for BIND 9.18.0: [1]

> - Previously, ``named`` accepted FORMERR responses both with and without
>   an OPT record, as an indication that a given server did not support
>   EDNS. To implement full compliance with :rfc:`6891`, only FORMERR
>   responses without an OPT record are now accepted. This intentionally
>   breaks communication with servers that do not support EDNS and that
>   incorrectly echo back the query message with the RCODE field set to
>   FORMERR and the QR bit set to 1. :gl:`#2249`

If you need a workaround for this particular domain, use the "server"
clause in named.conf to disable EDNS for its authoritative servers.

[1] https://bind9.readthedocs.io/en/v9_18_0/notes.html#notes-for-bind-9-18-0

-- 
Best regards,
Michał Kępień
-- 
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

bind 9.16.28 vrs. 9.18.2 (on freebsd) resolving foryoudecor.com

2022-05-11 Thread Kurt Jaeger 
Hello,

we observed a strange behaviour for the domain foryoudecor.com,
when trying to resolve it using bind 9.18.2, using

dig -t mx foryoudecor.com

The bind log for 9.18.2 says:

May 11 12:00:14 ns named[96774]: fetch: foryoudecor.com/MX
May 11 12:00:14 ns named[96774]: DNS format error from 61.129.70.40#53 
resolving foryoudecor.com/MX for 193.105.105.1#27259: server sent FORMERR
May 11 12:00:14 ns named[96774]: client @0x803bdcd60 193.105.105.1#27259 
(foryoudecor.com): query failed (FORMERR) for foryoudecor.com/IN/MX at 
query.c:7657

so the domain was not resolvable.

bind 9.16.28 resolves the MX for this domain.

I tried to find out if it's an DNSSEC issue, using

https://dnsviz.net/d/foryoudecor.com

But the result looks very confusing to me. Apparently, somewhere,
a DNS server 'qhm3' comes into play (yes, that's the whole dns server
name!).

What can I do to debug this?

-- 
p...@opsec.eu+49 171 3101372Now what ?
-- 
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: After switching to "dnssec-policy", existing RRs are still signed with the "old" ZSK

2022-05-11 Thread Mark Andrews 
Signature-refresh determines when the RRSIGs will be replaced by looking at the 
expiration time and working backwards. New RRSIGs are generate Using 
signature-interval. 

-- 
Mark Andrews

> On 11 May 2022, at 18:15, Tom  wrote:
> 
> Hi list
> 
> After switching from "semi-automatic"-signing to dnssec-policy (everything 
> identical, except new ZSK rollover) I have the following rndc output:
> 
> $ rndc dnssec -status example.ch
> dnssec-policy: 60d_zsk_rollover
> current time:  Wed May 11 09:54:55 2022
> 
> key: 45819 (ECDSAP256SHA256), KSK
>  published:  yes - since Mon Apr 27 08:00:01 2020
>  key signing:yes - since Mon Apr 27 08:00:01 2020
> 
>  No rollover scheduled
>  - goal:   omnipresent
>  - dnskey: omnipresent
>  - ds: omnipresent
>  - key rrsig:  omnipresent
> 
> key: 17242 (ECDSAP256SHA256), ZSK
>  published:  yes - since Mon May  9 16:25:59 2022
>  zone signing:   yes - since Mon May  9 17:30:59 2022
> 
>  Next rollover scheduled on Fri Jul  8 15:25:59 2022
>  - goal:   omnipresent
>  - dnskey: omnipresent
>  - zone rrsig: rumoured
> 
> key: 52021 (ECDSAP256SHA256), ZSK
>  published:  yes - since Mon Apr 27 08:00:01 2020
>  zone signing:   no
> 
>  Key is retired, will be removed on Mon Jul  6 09:05:01 2020
>  - goal:   hidden
>  - dnskey: omnipresent
>  - zone rrsig: unretentive
> 
> 
> 
> The ZSK 52021 is the old one (from semi-automatic), the ZSK 17242 is the new 
> one, which was created after reloading named while applying the new 
> dnssec-policy.
> 
> The current behavior I see is, that already existing RR are still signed with 
> the "old" key (52021) and newly created RR are signed with the new ZSK 
> (17242). Is this normal behavior and yes, after which time will the existing 
> RR also be signed with the new ZSK (17242)?
> 
> The dnssec-policy configuration looks like this:
> 
> dnssec-policy "60d_zsk_rollover" {
>signatures-refresh 5d;
>signatures-validity 14d;
>signatures-validity-dnskey 14d;
> 
>dnskey-ttl 3600s;
>publish-safety 1h;
>retire-safety 1h;
>purge-keys 10d;
> 
>keys {
>ksk lifetime unlimited algorithm ecdsap256sha256;
>zsk lifetime 60d algorithm ecdsap256sha256;
>};
> 
>zone-propagation-delay 300s;
>max-zone-ttl 86400s;
> 
>parent-propagation-delay 1h;
>parent-ds-ttl 3600;
>nsec3param iterations 0 optout no salt-length 0;
> };
> 
> 
> 
> Many thanks for hints/explanations.
> Best regards,
> Tom
> -- 
> 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

After switching to "dnssec-policy", existing RRs are still signed with the "old" ZSK

2022-05-11 Thread Tom 

Hi list

After switching from "semi-automatic"-signing to dnssec-policy 
(everything identical, except new ZSK rollover) I have the following 
rndc output:


$ rndc dnssec -status example.ch
dnssec-policy: 60d_zsk_rollover
current time:  Wed May 11 09:54:55 2022

key: 45819 (ECDSAP256SHA256), KSK
  published:  yes - since Mon Apr 27 08:00:01 2020
  key signing:yes - since Mon Apr 27 08:00:01 2020

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: omnipresent
  - key rrsig:  omnipresent

key: 17242 (ECDSAP256SHA256), ZSK
  published:  yes - since Mon May  9 16:25:59 2022
  zone signing:   yes - since Mon May  9 17:30:59 2022

  Next rollover scheduled on Fri Jul  8 15:25:59 2022
  - goal:   omnipresent
  - dnskey: omnipresent
  - zone rrsig: rumoured

key: 52021 (ECDSAP256SHA256), ZSK
  published:  yes - since Mon Apr 27 08:00:01 2020
  zone signing:   no

  Key is retired, will be removed on Mon Jul  6 09:05:01 2020
  - goal:   hidden
  - dnskey: omnipresent
  - zone rrsig: unretentive



The ZSK 52021 is the old one (from semi-automatic), the ZSK 17242 is the 
new one, which was created after reloading named while applying the new 
dnssec-policy.


The current behavior I see is, that already existing RR are still signed 
with the "old" key (52021) and newly created RR are signed with the new 
ZSK (17242). Is this normal behavior and yes, after which time will the 
existing RR also be signed with the new ZSK (17242)?


The dnssec-policy configuration looks like this:

dnssec-policy "60d_zsk_rollover" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;

dnskey-ttl 3600s;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;

keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 60d algorithm ecdsap256sha256;
};

zone-propagation-delay 300s;
max-zone-ttl 86400s;

parent-propagation-delay 1h;
parent-ds-ttl 3600;
nsec3param iterations 0 optout no salt-length 0;
};



Many thanks for hints/explanations.
Best regards,
Tom
--
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: "Length"-output in DNSSEC-Policy state-files vs. "Key Length"-output on dnsviz.net

2022-05-11 Thread Tom 

Hi Tony

Many thanks for your explanation!
Tom


On 10.05.22 10:46, Tony Finch wrote:

Tom  wrote:


I'm wondering about the value of the "Length"-field in the dnssec-policy
state-file output, which results in "Length: 256" for domains, which are
signed with algorithm 13 (ECDSAP256SHA256)


That's the size of the cryptographic modulus, i.e. the size of the numbers
in the guts of the cryptographic algorithm.


and the "Key length"-output for the domain on "dnsviz.net" (ZSK or KSK),
which results in "Key Length: 512".


For P-256 the public key needs two coordinates to identify the point on
the curve, so it's twice the nominal size of the algorithm.

DNSviz is not being entirely consistent here, because RSA public keys also
require a few more bits than their nominal size (for the public exponent),
but DNSviz shows their nominal size rather than the size of the public key
blob in the DNSKEY record.

(The public exponent is usually 65537, which is why RSA keys typically
start AwEAA rather than being completely random.)


--
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: DNS traffic tracking

2022-05-11 Thread Alex K 
On Mon, May 9, 2022 at 7:27 PM Fred Morris  wrote:

> On Mon, 9 May 2022, Alex K wrote:
> > [...]
> > The problem now is that I see sometime 700MB of DNS traffic for 2GB of
> > Internet browsing within one month.
>
> That's an eyebrow raiser. Tunneling, antivirus (or some other database
> using DNS as a key+value store), CDN? IoT fleet? Then comes the inevitable
> "...or traffic you don't want".
>
> Not clear on where the expensive link sits (between the caching resolver
> and clients, or between the caching resolver and the rest of the
> internet). Not sure what you're able to do politically or where things
> like privacy or "net neutrality" come into play, but it does seem to me
> that not burning precious bandwidth for ads might be a value-added
> service... if they're really watching cat videos.
>
The setup is edge device where a caching DNS server runs and where the
users are serviced -> satellite -> upstream DNS servers that can be either
public ones or my second level of caching DNS server depending on the
setup.  The expensive link is from the edge device to the next hop which is
through satellite, and depending on the satellite type may have low
allowance on the monthly traffic (4GB to 8GB max)

>
> I second the comment that Dnstap might be your best friend.
>
> There are technical considerations, but I think generally this is veering
> into the realm of what's possible (which is seldom actually technical);
> this includes your means and ability to analyze the DNS traffic. If you
> want to discuss further feel free to email me.
>
> Thanx for all the feedback. I will need to drill down and see what kind of
DNS traffic is that then perhaps implement some more secure firewalling
(find a way to block VPN over DNS) and rate limiting.
I was also thinking perhaps to have a preloaded RPZ list that will block
malware domains at the caching DNS server at the edge.

> --
>
> Fred Morris, internet plumber
>
> --
> 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