from:"John W. Blue via bind\-users"

RE: Facing issues while resolving only one record

2023-08-30 Thread John W. Blue via bind-users

Recommend you turn off DNSSEC validation and see if it starts working.

If it does, then you know the issue is with how DNSSEC is configured on your 
server.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Blason R
Sent: Wednesday, August 30, 2023 8:20 AM
To: bind-users
Subject: Facing issues while resolving only one record

Hi all,

I have bind BIND 9.18.17-1+ubuntu22.04.1+isc+1-Ubuntu (Extended Support Version)
And I am facing this weird issue. Somehow 
eportal.incometax.gov.in site is not getting 
resolved through DNS.

I tried a lot but unfortunately the issue still persists.

Here are packet capture logs.

listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 
262144 bytes
18:47:19.56 ens18 In  IP 192.168.1.162.61110 > 192.168.1.133.53: 20+ A? 
eportal.incometax.gov.in. (42)
18:47:19.587705 ens18 Out IP 192.168.1.133.40263 > 208.67.222.222.53: 30627+% 
[1au] A? eportal.incometax.gov.in. (65)
18:47:19.599214 ens18 Out IP 192.168.1.133.44299 > 1.1.1.1.53: 62952+% [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:20.800736 ens18 Out IP 192.168.1.133.56154 > 8.8.8.8.53: 16152+% [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:21.573628 ens18 In  IP 192.168.1.162.53536 > 192.168.1.133.53: 21+ ? 
eportal.incometax.gov.in. (42)
18:47:21.576427 ens18 Out IP 192.168.1.133.55356 > 8.8.8.8.53: 57361+% [1au] 
? eportal.incometax.gov.in. (65)
18:47:22.002738 ens18 Out IP 192.168.1.133.33064 > 208.67.222.222.53: 16204+% 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:22.777934 ens18 Out IP 192.168.1.133.58739 > 208.67.222.222.53: 34205+% 
[1au] ? eportal.incometax.gov.in. (65)
18:47:23.20 ens18 Out IP 192.168.1.133.60920 > 9.9.9.9.53: 46145+% [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:23.584820 ens18 In  IP 192.168.1.162.53962 > 192.168.1.133.53: 22+ A? 
eportal.incometax.gov.in. (42)
18:47:24.405041 ens18 Out IP 192.168.1.133.56475 > 198.41.0.4.53: 12349 [1au] 
DNSKEY? incometax.gov.in. (57)
18:47:25.205136 ens18 Out IP 192.168.1.133.33517 > 192.36.148.17.53: 18768 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:25.237837 ens18 Out IP 192.168.1.133.43646 > 156.154.100.20.53: 28883 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:25.259888 ens18 Out IP 192.168.1.133.51762 > 59.160.103.171.53: 46716 
[1au] DNSKEY? incometax.gov.in. (57)
18:47:25.597312 ens18 In  IP 192.168.1.162.53963 > 192.168.1.133.53: 23+ ? 
eportal.incometax.gov.in. (42)
18:47:26.498891 ens18 Out IP 192.168.1.133.52631 > 125.16.225.122.53: 12762 
[1au] DNSKEY? incometax.gov.in. (57)

I feel this is something related to DNS RRKEY Record size?

Plus then I dumbdb on my server and went through cache using command
#rndc dumpdb -all

And here is the output

incometax.gov.in.   3422NS  
ns01.incometax.gov.in.
3422NS  
ns02.incometax.gov.in.
ns01.incometax.gov.in.  131 \-  ;-$NXRRSET
; ns01.incometax.gov.in. RRSIG NSEC ...
; ns01.incometax.gov.in. NSEC 
ns02.incometax.gov.in. A RRSIG NSEC
; incometax.gov.in. SOA 
ns01.incometax.gov.in. 
ns-admin.cpc.incometax.gov.in. 2023060970 
7200 3600 1209600 3600
; incometax.gov.in. RRSIG SOA ...
ns02.incometax.gov.in.  120 \-  ;-$NXRRSET
; ns02.incometax.gov.in. RRSIG NSEC ...
; ns02.incometax.gov.in. NSEC 
ns03.incometax.gov.in. A RRSIG NSEC
; incometax.gov.in. SOA 
ns02.incometax.gov.in. 
ns-admin.cpc.incometax.gov.in. 2023071447 
7200 3600 1209600 3600
; incometax.gov.in. RRSIG SOA ...
; ns01.incometax.gov.in [v6 TTL 131] [v4 
unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 120] [v4 
unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 131] [v4 
unexpected] [v6 nxrrset]
; ns02.incometax.gov.in [v6 TTL 120] [v4 
unexpected] [v6 nxrrset]
; ns01.incometax.gov.in [v6 TTL 131] [v4 
unexpected] [v6 nxrrset]
;

RE: host restriction

2023-05-15 Thread John W. Blue via bind-users

Zoltan,

There may be another way to make this work but this is what comes to my mine:  
acl’s in a view.

https://kb.isc.org/docs/aa-00851

# named.conf
acl google-is-good { 192.168.7.0/24; localhost; };
acl google-is-evil   { 192.168.8.0/24; };

view google-good {
match-clients { google-is-good; };
allow-recursion { any; };
forwarders {
8.8.8.8;
};
};

view google-evil {
match-clients { google-is-evil; };
allow-recursion { any; };
};

You *might* be able to whack the acl down to like a /28 or a /29 while keeping 
your DHCP scope at a /24.  This will allow you to perform view testing without 
needing to rip n replace DHCP configs.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kereszt 
Vezeték
Sent: Monday, May 15, 2023 1:58 PM
To: bind-users@lists.isc.org
Subject: host restriction

Hi Everybody

Can someone help me with the following problem ?
I have a dns server in my private network with a local domain. The dns server 
forward the public request to the google dns server . I wold like separate 
hosts in the inside network.
One group allow only the local host resolve, not forward to the 8.8.8.8 .Other 
group allow the local hosts resolve, and able to forward to the google dns 
server.
Are there any way to solve this problem with bind9 ?
Local subnet 192.168.1.0/24
192.168.1.10 allow forward to 8.8.8.8
192.168.1.11 allow forward to 8.8.8.8

192.168.1.20 disable forward 8.8.8.8
192.168.1.21 disable forward 8.8.8.8

Thank you
regards
Zoltan
-- 
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 error resolving gpo.gov ?

2023-03-24 Thread John W. Blue via bind-users

Petr,

Thanks for sharing that tidbit of info.  Off the top of your head do you know 
if that can be disabled?

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Petr 
Menšík
Sent: Friday, March 24, 2023 8:32 AM
To: bind-users@lists.isc.org
Subject: Re: DNSSEC error resolving gpo.gov ?

That is done also by bind 9.11, not only infoblox. It creates both digests on 
common operations.

On 3/14/23 16:23, John W. Blue via bind-users wrote:
> Keep in mind that SHA1 may not have been included by choice.
>
> If gpo.gov is using Infoblox there is a, what I like to call, Infoblox-ism in 
> play regarding DNSSEC where even if you choose RSA256 or RSA512 or whatever 
> it will create a SHA1.
>
> John
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
> Of Stephane Bortzmeyer
> Sent: Tuesday, March 14, 2023 10:17 AM
> To: Alexandra Yang
> Cc: bind-users@lists.isc.org
> Subject: Re: DNSSEC error resolving gpo.gov ?
>
> On Tue, Mar 14, 2023 at 11:08:28AM -0400,  Alexandra Yang 
>  wrote  a message of 154 lines which said:
>
>> I wonder if anyone can shed some light on this, our nameserver(BIND
>> 9.16.37 )keeps giving error on resolving gpo.gov and ns3.gpo.gov, 
>> here are the
>> errors:
> "DS record for zone gpo.gov with keytag 18496 was created by digest algorithm 
> 1 (SHA-1) which is deprecated."
> https://zonemaster.fr/en/result/9161c8485223705c
>
> --
> 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

--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

--
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 error resolving gpo.gov ?

2023-03-14 Thread John W. Blue via bind-users

Keep in mind that SHA1 may not have been included by choice.

If gpo.gov is using Infoblox there is a, what I like to call, Infoblox-ism in 
play regarding DNSSEC where even if you choose RSA256 or RSA512 or whatever it 
will create a SHA1.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Stephane Bortzmeyer
Sent: Tuesday, March 14, 2023 10:17 AM
To: Alexandra Yang
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC error resolving gpo.gov ?

On Tue, Mar 14, 2023 at 11:08:28AM -0400,  Alexandra Yang  
wrote  a message of 154 lines which said:

> I wonder if anyone can shed some light on this, our nameserver(BIND
> 9.16.37 )keeps giving error on resolving gpo.gov and ns3.gpo.gov, here 
> are the
> errors:

"DS record for zone gpo.gov with keytag 18496 was created by digest algorithm 1 
(SHA-1) which is deprecated."
https://zonemaster.fr/en/result/9161c8485223705c

--
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: Something other than port 53 is blocking the LAN based BIND9 Servers

2023-03-05 Thread John W. Blue via bind-users

Recommend you run tcpdump on the affected server:

tcpdump -n -i ethxxx port 53

This should give you a better lay of the land instead of observational 
troubleshooting.  If you do not see packets leaving then there is something on 
your side.

If you see port 53 packets leaving and not returning could be many things but 
at least you know your putting them out there.  Armed with that info you might 
be able to convince the ISP to dig (no pun intended .. okay intended) harder.

Good hunting.

John

Sent from Nine

From: Mike Lieberman 
Sent: Sunday, March 5, 2023 9:47 PM
To: bind-users@lists.isc.org
Subject: Something other than port 53 is blocking the LAN based BIND9 Servers

Hi, I am new here, but have been using BIND since 1994.

I am confused by the issue herein and maybe someone has an idea of at least 
what group I should be talking to.

I have a Debian based operation and my BIND9 servers run on Debian. BUT...

This is really about BIND as it interacts with my ISP supplied FTTH routers. 
There is apparent port blocking of the servers ONLY using their newer routers 
and not the older ones. I can't figure out which port is being blocked because 
UDP and TCP port 53 is open in all cases and works from any client (including a 
client application running from Terminal on a server). (Once again, my BIND 
servers work fine without errors.)

My ISP (PLDT Philippines) has had a FTTH router that allowed my three BIND 
servers to work flawlessly. It didn't require a whitelist on a firewall. And 
all clients could either use our LAN based DNS service or a public one. DIG and 
NSLOOKUP (yes I know is has been obsoleted, but net-tools still has it) works.

But older Router reached EoL and the ISP wanted to change it out to its new 
FTTH router. And that is when I hit a wall.

The newer router blocks my local BIND servers (ONLY not clients using 
downstream servers) from receiving anything from the Internet. OUR BIND servers 
still have the local networks, but nothing else.

So, with the new router, my clients can access a public DNS server downstream 
and get FQDN resolved. The new router allows remote DNS lookups but denies my 
local BIND servers access to resolve the same non-local addresses.

The ISP's EoL equipment is really no longer good for other reasons but I can't 
use the new one.

The question I need resolved by the proper group/forum is: What port or 
technology is doing the blocking? The ISP has no idea.

I have tried three of the new routers but all blocked my servers. I tried a 
replacement EoL router and that works. Without changing anything on the 
network, other than the physical router, it was like flipping a switch.
--
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: named out of swap on NetBSD/amd64

2023-02-11 Thread John W. Blue via bind-users

At the risk of stating the obvious .. have you tried 9.16.37 or 9.18.11?

While I am usually down for an off in the weeds hardcore root cause analysis of 
problem is nice to get a quick win with a different version.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jan 
Schaumann via bind-users
Sent: Saturday, February 11, 2023 7:14 PM
To: bind-users@lists.isc.org
Subject: named out of swap on NetBSD/amd64

Hi,

I have a local caching resolver running bind 9.16.30 on NetBSD/amd64 9.3.

I'm currently hitting it on localhost with approximately 200 qps, and it 
reliably gets killed after approximately 3 hours with "out of swap"
messages in dmesg.

The system in question is a Xen VPS with 6 GB RAM and
256 MB swap.

This seems similar to the issue reported here:
https://www.mail-archive.com/bind-users@lists.isc.org/msg30933.html

(There,
https://gitlab.isc.org/isc-projects/bind9/-/issues/3051
was listed as a possibly mitigating commit.)

No matter how much swap I add, it eventually runs out, so this seems to me to 
suggest a leak somewhere.

The relevant information about the system and version is below, but I was 
wondering what troubleshooting suggestions you might have.


$ /usr/pkg/sbin/named -V 
BIND 9.16.30 (Extended Support Version)  running on NetBSD amd64 
9.3 NetBSD 9.3 built by make with '--with-lmdb=no'
'--with-blacklist=yes' '--with-blocklist=no'
'--disable-native-pkcs11' '--without-libxml2'
'--without-libjson' '--with-readline' '--with-libtool'
'--sysconfdir=/usr/pkg/etc' '--localstatedir=/var'
'--with-openssl=/usr/pkg' '--with-python=no'
'--prefix=/usr/pkg' '--build=x86_64--netbsd'
'--host=x86_64--netbsd' '--mandir=/usr/pkg/man'
'--enable-option-checking=yes'
'build_alias=x86_64--netbsd'
'host_alias=x86_64--netbsd' 'CC=gcc' 'CFLAGS=-O2 -fPIC
-D_FORTIFY_SOURCE=2 -pthread -I/usr/include -I/usr/include/readline 
-I/usr/pkg/include'
'LDFLAGS=-Wl,-zrelro -pthread -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib 
-Wl,-R/usr/pkg/lib'
'LIBS=' 'CPPFLAGS=-I/usr/include
-I/usr/include/readline -I/usr/pkg/include'
'PKG_CONFIG=/usr/pkg/bin/pkg-config'
'PKG_CONFIG_PATH='
'PKG_CONFIG_LIBDIR=/usr/pkg/lib/pkgconfig:/usr/pkg/share/pkgconfig'
compiled by GCC 5.5.0
compiled with OpenSSL version: OpenSSL 1.1.1q  5 Jul 2022 linked to OpenSSL 
version: OpenSSL 1.1.1q  5 Jul 2022 compiled with libuv version: 1.44.1 linked 
to libuv version: 1.44.1 compiled with zlib version: 1.2.10 linked to zlib 
version: 1.2.10 threads support is enabled

default paths:
  named configuration:  /usr/pkg/etc/named.conf
  rndc configuration:   /usr/pkg/etc/rndc.conf
  DNSSEC root key:  /usr/pkg/etc/bind.keys
  nsupdate session key: /var/run/named/session.key
  named PID file:   /var/run/named/named.pid
  named lock file:  /var/run/named/named.lock

$ sudo rndc status
version: BIND 9.16.30 (Extended Support Version)  running on 
panix.netmeister.org: NetBSD amd64 9.3 NetBSD 9.3 boot time: Sat, 11 Feb 2023 
23:32:33 GMT last configured: Sat, 11 Feb 2023 23:32:34 GMT configuration file: 
/usr/pkg/etc/named.conf
(/var/chroot/named/usr/pkg/etc/named.conf)
CPUs found: 1
worker threads: 1
UDP listeners per interface: 1
number of zones: 127 (97 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 138/9900/1
tcp clients: 0/150
TCP high-water: 1
server is up and running


-Jan
--
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: Email migration and MX records

2023-01-03 Thread John W. Blue via bind-users

Hi Bruce,

It would be better to have an SMTP server return 421 "4.3.0" or 421 "4.7.0" 
while the migration is under way instead of bouncing the connection.  421 will 
tell all SMTP servers everywhere to "try again later".  The 421 error is a 
proven greylisting configuration.

Not knowing what is all involved with the actual migration, another option 
might be something as simple as putting the prod Barracuda server(s) into 
"maintenance mode".  If that will prevent the migration from happening perhaps 
Barracuda can spin up an SMTP server that only answers with 421.  Or, if you 
all are able, you could roll your own SMTP server to answer 421.

Obviously standard do-not-test-in-prod, don’t wing it and hope for the best .. 
have a step-by-step playbook disclaimers apply and there is nothing wrong with 
a lower TTL of 60 seconds or less to facilitate reverting.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce 
Johnson via bind-users
Sent: Tuesday, January 3, 2023 3:32 PM
To: bind-users@lists.isc.org
Subject: Email migration and MX records

We’re making an O365 tenant switchover for our domain (a subdomain of the 
arizona.edu domain) and moving from our Barracuda cloud email SMTP to the 
University’s tenant, but email cannot flow until the Arizona.edu O365 tenant 
can take over our email domain.

In anticipation I set our TTL for MX records quite low before the break (150 
seconds) so, but the process may take up to an hour (if everything goes well )

Will setting our mx record to a bogus address cause email to bounce on the 
sending end and eventually get retried later after the mx record has been 
properly set to the Universities main smtp MX address?

Or are we approaching this in the wrong way?  Basically our end result is we 
want to stop accepting email from anywhere until the whole process has been 
changed and we have established the correct route so email starts flowing 
correctly.

As it’s been explained to me the main campus tenant cannot start accepting 
email for our domain  until we’ve transferred the email domain between tenants, 
so we cannot just change the MX record in our DNS server to the University’s (a 
Cisco Ironport setup)

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

-- 
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: Add TXT records for SPF when CNAME exists in same sub-domain

2022-11-28 Thread John W. Blue via bind-users

RFC 1034

3.6.2 second paragraph:

“If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.”

There may be an updated RFC that states the same thing differently but it is a 
well-known DNS rule.

valimail.com’s blackbox might be able to get around it but I would not know for 
sure.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris 
Liesfield
Sent: Monday, November 28, 2022 6:03 PM
To: bind-users@lists.isc.org
Subject: Add TXT records for SPF when CNAME exists in same sub-domain

Hi All. Hopefully my terminology is correct and I make sense.

We have a main domain "something.com.au" with a few 
sub-domains, "this", "that", etc.

For all of our 'A' records in something.com.au, we 
have specified TXT records for SPF, however our sub-domains contain CNAMEs only.

It appears TXT and CNAME records for the same string/host cannot co-exist. We 
are able to specify an SPF record for the origin only in each sub-domain.

Open to any suggestions on how to get around this issue.

Thanks in advance.

$TTL 3600
@   IN  SOA  something.com.au. 
bofh.something.com.au. (
2022112901 ; serial
10800  ; refresh (3 hours)
3600   ; retry (1 hour)
604800 ; expire (1 week)
3600   ; minimum (1 hour)
)
NS  
ns1.something.com.au.
NS  
ns2.something.com.au.
MX  10 
mail.something.com.au.

; A Records

localhost   A   127.0.0.1
www   A   1.2.3.4
@ IN  A   1.2.3.4

; SPF records

; working without a problem.
www TXT "v=spf1 -all"

$ORIGIN this.something.com.au.
$TTL 3600   ; 1 hour
www CNAME   
stuff.somewhereelse.com.au.
@   CNAME   
stuff.somewhereelse.com.au.

; SPF records

; BIND considers this an invalid statement - no corresponding 'A' record - 
conflict with CNAME?
www TXT "v=spf1 -all"
; working without a problem.
@   TXT "v=spf1 -all"

$ORIGIN that.something.com.au.
$TTL 3600   ; 1 hour
www CNAME   
stuff.overthere.com.au.
@   CNAME   
stuff.overthere.com.au.

; SPF records

; BIND considers this an invalid statement - no corresponding 'A' record - 
conflict with CNAME?
www TXT "v=spf1 -all"
; working without a problem.
@   TXT "v=spf1 -all"

--
Chris.




-- 
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: Issue with dns resolution for www.ssa.gov

2022-09-01 Thread John W. Blue via bind-users

Sandeep,

Are you all using CISA's Protective DNS?  If so, there might be a ruleset that 
is causing problems.

If not, and I have not checked, but is DNSSEC for SSA working correctly?

John

Sent from Nine


From: "Bhangui, Sandeep - BLS CTR via bind-users" 
Sent: Thursday, September 1, 2022 3:11 PM
To: bind-users@lists.isc.org
Subject: Issue with dns resolution for www.ssa.gov

Hi

We are running Bind Version 9.16.31 on RHEL 7.X Server and things are working 
fine in general.

Having issue with DNS resolution for www.ssa.gov no other 
DNS issues reported at this time.

Our DNS server cannot seem to resolve www.ssa.gov using 
nslookup ( know this is an old utility and cannot be used much for 
troubleshooting), dig seems to respond properly.

Just curious what could be the issue is this on our DNS server as nslookup 
seems to work fine for lot of other sites that I used just to check if it 
responds correctly.

The VZ public NS which is listed as one of the NS under /etc/resolv.conf seems 
to respond to nslookup just fine.

I am not sure what more information I could include which could be helpful if 
anything else is needed please let me know and I will post it.

Thanks in advance.

Sandeep


# nslookup www.ssa.gov

;; Got SERVFAIL reply from 127.0.0.1, trying next server

Server: 198.6.1.1
Address:198.6.1.1#53

Non-authoritative answer:
www.ssa.gov canonical name = 
www.ssa.gov.edgekey.net.
www.ssa.gov.edgekey.net canonical name = 
e82396.dsca.akamaiedge.net.
Name:   e82396.dsca.akamaiedge.net
Address: 23.222.241.54
Name:   e82396.dsca.akamaiedge.net
Address: 23.222.241.58
Name:   e82396.dsca.akamaiedge.net
Address: 2600:1404:d400::687d:293
Name:   e82396.dsca.akamaiedge.net
Address: 2600:1404:d400::687d:289


Dig output from the same DNS server seems to give a response.

# dig www.ssa.gov

; <<>> DiG 9.16.31 <<>> www.ssa.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24578
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.ssa.gov.   IN  A

;; ANSWER SECTION:
www.ssa.gov.300 IN  CNAME   
www.ssa.gov.edgekey.net.
www.ssa.gov.edgekey.net. 9625   IN  CNAME   
e82396.dsca.akamaiedge.net.
e82396.dsca.akamaiedge.net. 20  IN  A   23.222.241.58
e82396.dsca.akamaiedge.net. 20  IN  A   23.222.241.51

;; Query time: 171 msec
;; SERVER: 198.6.1.1#53(198.6.1.1)
;; WHEN: Thu Sep 01 16:03:21 EDT 2022
;; MSG SIZE  rcvd: 146


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

2022-08-01 Thread John W. Blue via bind-users

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

2022-08-01 Thread John W. Blue via bind-users

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

2022-08-01 Thread John W. Blue via bind-users

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

2022-08-01 Thread John W. Blue via bind-users

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

DNSSEC signing of an internal zone gains nothing (unless??)

2022-08-01 Thread John W. Blue via bind-users

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

RE: your mail

2022-01-15 Thread John W. Blue via bind-users

Lol.  The footer joke was just to give you something legitimate to complain 
about.

*yawn*

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl 
Harald
Sent: Saturday, January 15, 2022 9:50 PM
To: bind-users@lists.isc.org
Subject: Re: your mail



Am 16.01.22 um 04:47 schrieb John W. Blue via bind-users:
> Lol.  I am not going to do that either.  Lol.

can you do us all a favor and stop writing useless mails to lists at saturday 
night?

that footer is for morons which send messages with "unsubscribe" to mailing 
lists all the time

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
> Of Reindl Harald
> Sent: Saturday, January 15, 2022 9:44 PM
> To: bind-users@lists.isc.org
> Subject: Re: your mail
> 
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: your mail

2022-01-15 Thread John W. Blue via bind-users

Lol.  I am not going to do that either.  Lol.

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl 
Harald
Sent: Saturday, January 15, 2022 9:44 PM
To: bind-users@lists.isc.org
Subject: Re: your mail

Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: your mail

2022-01-15 Thread John W. Blue via bind-users

/diverging tangent

I don't want to diminish any contribution to the good of the cause that anyone 
is willing to make but ... I am not going to stop top posting.

Personally, commentary about top posting is so 1997.  Perhaps it is also 
because I have reached an age where I just don't care anymore.

*shrug*

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of G.W. 
Haywood via bind-users
Sent: Saturday, January 15, 2022 9:29 AM
To: bind-users@lists.isc.org
Subject: Re: your mail

Please do not top post.  Some of us are on the digest list, and it makes 
trawling through all the unnecessary garbage very tedious, as well as prone to 
errors and misunderstandings.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: your mail

2022-01-15 Thread John W. Blue via bind-users

Not be ornery but honestly, for me, globs of text that is pasted into an email 
is TLDR because I cannot *do* anything with it.  So I skip it out of hand.

A real tcpdump packet capture is a file that can be loaded by wireshark and 
analyzed.

tcpdump -n -i  port 53 -w 

One from the client and one from the server is ideal.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Diego 
Garcia
Sent: Saturday, January 15, 2022 7:38 AM
To: bind-users@lists.isc.org
Subject: Re: your mail

hello.

really? my first post have a tcpdump capture packet, dig trace...

On Sat, Jan 15, 2022 at 2:14 PM G.W. Haywood via bind-users 
mailto:bind-users@lists.isc.org>> wrote:
Hi there,

On Sat, 15 Jan 2022, Diego Garcia wrote:

> Still with problems. That setup was running fine for few years.

But you changed something.

> Bind Server is on DMZ and doing NAT for the local net. Test Server is
> behing NAT
>
> Must have another problem
>
> I try this days a lot of things and nothing works,

Generally speaking, if you set things up right, BIND Just Works.  It
must be a couple of decades since I last had to fiddle with anything
to fix a broken BIND server.

It is not helpful to us if you tell us that you have tried a lot of things.
It would be much more helpful if you told us exactly what you have tried
and exactly what were the results.  You need to be methodical and precise.

> think in try reinstall but i preferred to know what happened and solve it

'Reinstall' to me means the sort of thing that you do if you're
working on a Windows box.  If you're using a real computer it's
usually much better to find out what's going wrong and fix it.

> ...
> network unreachable resolving 
> 'play.google.com/A/IN': 216.239.36.10#53
> ...

If you are getting 'network unreachable' messages then likely there's
something wrong with your network setup.  Before doing anything else,
you need to fix that.  It may or may not be a problem of your making,
but given that you said you are using BIND on a server in a DMZ then I
suspect that it is.  Using a DMZ will make things more complicated and
the faults will be more difficult to diagnose - especially for people
on mailing lists to whom you give little and very poor information.

It *looks* like BIND is trying to make queries but failing to connect
to anything to make them.

You do not appear to have acted on the good advice which was given to
you after your previous post.  Are you able to use tools like 'ping'
and 'traceroute' to diagnose network problems, also like Wireshark or
tcpdump to inspect network traffic?  These would be my first steps in
approaching this kind of problem.  You will need to know that packets
from the BIND server can go where they're supposed to go and replies
reach the server in good time.  You might also need to be able to see
exactly what BIND sends, where it sends it, exactly what it receives
(if anything) in reply to what it sends, and perhaps where the replies
come from.  If there are no replies, or the replies go to the wrong
place, you need to be able to show that and find out why.

What exactly are you trying to achieve which cannot be achieved by
simply using a public DNS service, or one provided by your ISP?

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: unresolvable pms.psc.gov, but google/cloudflare/unbound work

2021-08-22 Thread John W. Blue via bind-users

Your using the wrong tools to troubleshoot or investigate this error.

Instead of relying upon resolvers to provide situational awareness you need to 
inspect DNSSEC itself using dnsviz.net:

https://dnsviz.net/d/pms.psc.gov/dnssec/

psc.gov is giving the world ID 5089 when they need to handing out ID 180.

Recommend the pms.psc.gov admins give the psc.gov admins the correct hash.

Sent from Nine

From: Roger Hammerstein 
Sent: Sunday, August 22, 2021 9:45 AM
To: bind-users@lists.isc.org
Subject: unresolvable pms.psc.gov, but google/cloudflare/unbound work


pms.psc.gov appears to be unresolvable against bind9.16.19
and 9.11.34 because of dnssec issues.
But it resolves against Cloudflare's 1.1.1.1, Google's 8.8.8.8, and an Unbound
resolver that does dnssec-validation.

There's a ticket open with nih.gov to look into it, but is there anything that 
can
be changed with Bind to make this domain resolve in the meantime?

 (pms.psc.gov): query failed (SERVFAIL) for pms.psc.gov/IN/A at query.c:8678

https://dnsviz.net/d/pms.psc.gov/dnssec/
https://dnssec-analyzer.verisignlabs.com/pms.psc.gov

 dig a pms.psc.gov @8.8.8.8
pms.psc.gov.2852IN  CNAME   pms.ha.psc.gov.
pms.ha.psc.gov. 29  IN  A   156.40.178.24



dig a pms.psc.gov @8.8.8.8 +dnssec

;; ANSWER SECTION:
pms.psc.gov.2835IN  CNAME   pms.ha.psc.gov.
pms.psc.gov.2835IN  RRSIG   CNAME 8 3 3600 20210827000144 
20210821230144 5089 psc.gov. 
kpclRfRyBqaSGW6VrpkE4gP/QPfggKZTVb68npiosnt+4lIUglUxino5 
jQAqd9a1p8HbdHG63HPnfYYBq1bX9q/f11CVUmxXXJUbRBGTZBnDyATP 
LLI2GWSZ1at364O+C+iZozi8NpJNU4oTCfd3PLScFbOfSGbPyRfUzfvB AJc=
pms.ha.psc.gov. 29  IN  A   156.40.178.24
pms.ha.psc.gov. 29  IN  RRSIG   A 7 4 30 20210827185442 
20210820185442 21380 ha.psc.gov. 
w2XUqBVoBMtLv0qfc5xmccrpv+w2ukwGfaGJvthIKHXr2SdlAk3oQxve 
xyolEaj2zWn8Uj7lOsaZD8mewBMQ3iEEp8U96aFBslWV/ffEKL+H9oMM 
sUNU5KwNi7/Nk3KZuNc8R3xxuYTsSVdbu6ai1lQ6fmw2uWAoDP9YIqek 
jyo/0WFSXM+hxw/5WguijhilSRIywNgG3/6MY3ZmunPPafGTCTXigyex 
IBACJQJ+meD6vMi0YoRM17mwdD+7Buq2cb6LJyVYaQImh7M2gF8My75n 
lDns4PWEIx4bSW2uQQEPpB7MA9VI9y5CuVCmqC3wMZ2ow6G8pkaf18wv r/ucSQ==




I can sometimes get a servfail out of 8.8.8.8 with an any query
dig any pms.psc.gov @8.8.8.8 +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36332
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;pms.psc.gov.   IN  ANY
;; Query time: 5001 msec

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Sorry

2021-07-22 Thread John W. Blue via bind-users

I’m not judging but it sounds like to me what you are really describing is PTSD 
from installing Windows 7 and “upgrading” it to Windows 10.

:D

I too use Microsoft products but for infrastructure services facing the open 
Internet (like DNS) I only use BIND running on FreeBSD.

Not knowing exactly what you are trying to accomplish, I think if you were take 
one of those Core2 systems and install PfSense on it you would be very pleased.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Peter 
via bind-users
Sent: Thursday, July 22, 2021 2:43 PM
To: bind-users@lists.isc.org
Subject: Sorry


I have come to the conclusion that I am being punished!

I have moved heaven and earth to get 9.16.19 to work and only seem to work on 
another old system Core™2 Duo that I installed win 7 activated it then upgrade 
to win10 only that system work with 9.16.19 on another system I remove NICs 
uninstalled/reinstalled MS visual C++ and then to top it off my new system for 
DNS got fully reinstalled! With MediaCreationTool21H1 win 10 did 9.16.19 work 
on that with a simple config that worked on my old Core™2 Duo? No I have wasted 
hours trying to work out why this problem is happening to me...and I can only 
think of one reason I am being punished and the dark side of me is saying that 
the dev have coded bind not to work on my system they know about...yes that is 
crazy but I'm out of ideals short from building another system and buy another 
win10 key.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Best DNSSEC documentation for current version?

2021-06-21 Thread John W. Blue via bind-users

Hello Brett,

Have you seen the webinar videos on ISC's youtube channel?

https://www.youtube.com/user/ISCdotorg/search?query=DNSSEC

I would encourage you to attend them as they are presented.  One even had a 
VM's for the attendees to practice the information presented and ask questions.

John

From: bind-users  on behalf of Brett Delmage 

Sent: Monday, June 21, 2021 2:58 PM
To: bind-users
Subject: Best DNSSEC documentation for current version?

I am looking to read the best documentation on DNSSEC
configuration for the current versions on BIND.

Is this comprehensive and up to date?
https://bind9.readthedocs.io/en/latest/dnssec-guide.html

This doc does not refer to any version - Am I missing that? It seems that
this is an important detail to know when attempting to apply such a
document.

Is there anything else I have missed that isn't misleading, especially
with regard to key management, on the ISC site or elsewhere? Right now I
am feeling there are gaps in my knowledge and/or comprehension. I don ;t
want to get further confused.

Thanks for your tips!

Brett



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inline signing fails dnsviz test.

2021-05-10 Thread John W. Blue via bind-users

Hello Dan.

Does your registrar have the ability via a UI to place a DS record in the .name 
zone?

And if so, have you done that already?

John

Sent from Nine

From: Dan Egli 
Sent: Monday, May 10, 2021 12:20 AM
To: bind-users@lists.isc.org
Subject: Inline signing fails dnsviz test.

I tried to setup inline signing on my DNS server, and after reading the
results from DNSVIZ, i'd say I was PARTIALLY successful, but there still
seems to be a lot missing.

You can check the status on dnsviz yourself with the names
eglifamily.name and newideatest.site. Both resulted in nearly identical
responses, wtih a lot of warning and some errors. A few of those errors
I could blame on my backup DNS provider. You get what you pay for and
they are free. But not everything could be blamed on them.

I've attached a PNG of the output. Hopefully it comes through.
Meanwhile, here's the zone statements from my named.conf:

view "standard" IN {
 zone "eglifamily.name" {
 type master;
 file "pri/eglifamily.zone";
 allow-query { any; };
 allow-transfer {
   108.61.224.67; 116.203.6.3; 107.191.99.111;
185.22.172.112; 103.6.87.125; 192.184.93.99; 119.252.20.56;
31.220.30.73; 185.34.136.178; 185.136.176.247; 45.77.29.133;
116.203.0.64; 167.88.161.228; 199.195.249.208; 104.244.78.122;
2605:6400:30:fd6e::3; 2605:6400:10:65::3; 2605:6400:20:d5e::3;
2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 2a06:fdc0:fade:2f7::1;
2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3;
2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e;
2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3;
2001:19f0:6400:8642::3;
 };
//  also-notify { 1.2.3.4; }; // none for now
 allow-update { trusted; };
 key-directory "/var/bind/pri/keys";
 auto-dnssec maintain;
 inline-signing yes;
 };

 zone "newideatest.site" {
 type master;
 file "pri/newideatest.zone";
 allow-query { any; };
 allow-transfer {
   108.61.224.67; 116.203.6.3; 107.191.99.111;
185.22.172.112; 103.6.87.125; 192.184.93.99; 119.252.20.56;
31.220.30.73; 185.34.136.178; 185.136.176.247; 45.77.29.133;
116.203.0.64; 167.88.161.228; 199.195.249.208; 104.244.78.122;
2605:6400:30:fd6e::3; 2605:6400:10:65::3; 2605:6400:20:d5e::3;
2a01:4f8:1c0c:8122::3; 2001:19f0:7001:381::3; 2a06:fdc0:fade:2f7::1;
2a00:dcc7:d3ff:88b2::1; 2a04:bdc7:100:1b::3;
2401:1400:1:1201::1:7853:1a5; 2604:180:1:92a::3; 2403:2500:4000::f3e;
2a00:1838:20:2::cd5e:68e9; 2604:180:2:4cf::3; 2a01:4f8:1c0c:8115::3;
2001:19f0:6400:8642::3;
 };
//  also-notify { 1.2.3.4; }; // none for now
 allow-update { trusted; };
 key-directory "/var/bind/pri/keys";
 auto-dnssec maintain;
 inline-signing yes;
 };

--

Dan Egli
 From my Test Server

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Update DNSSEC Zone

2021-05-09 Thread John W. Blue via bind-users

Hi Peter ..

How do you know your DNSSEC is working to begin with?

Here is a URL that I prefer to use that will help answer that question:

https://dnsviz.net/

What you are looking for is your to zone to be “secure”.

Since you are an experienced BIND admin .. any clues to be found in the logs?  
grep for “unsigned”.

One option that appears to be missing from your conf file is:

zone "supercoolzonehere.com" IN {
inline-signing yes;
};

Which would achieve the result that you described below wherein a record is 
added and “rndc reload” is executed.

Good hunting.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Peter 
Fraser
Sent: Sunday, May 09, 2021 8:49 PM
To: bind-users@lists.isc.org
Subject: Update DNSSEC Zone

HI All,
I really would appreciate a pointer in the right direction. I took over a bind 
server recently. I am not new to bind. I have used it many times and honestly 
prefer it to windows dns but I have never worked with DNSSEC.  I have been 
reading all day and I still can’t figure out how to update the DNSSEC zone. Can 
anyone assist me please? I did see one site that said I could just put in 
regular A record entries and run rndc reload and that would resign the zone. I 
tried that but it didn’t work.

I am using bind-9.14.x and here are the DNSSEC related entries in the zone.

auto-dnssec maintain;
update-policy local;
key-directory “zones/domain-keys”;

Best Regards,
SI

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Name server delegation

2021-04-26 Thread John W. Blue via bind-users

Since "" is a subzone inside of the example.com zone the answer is yes, it 
can be delegated.

John

Sent from Nine

From: Karol Nowicki via bind-users 
Sent: Monday, April 26, 2021 10:24 AM
To: bind-users@lists.isc.org
Subject: Name server delegation

Hi

Its possible to delegate tld domain example.com to 1.1.1.1 name server and 
.example.com to 2.2.2.2 name server ?

Wys?ane z Yahoo Mail do iPhone
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Testing KASP, CDS, and .ch

2021-04-09 Thread John W. Blue via bind-users

Sorry .. clicked send too soon.

Found this via google:

https://docs.gandi.net/en/domain_names/advanced_users/dnssec.html

"You can not add DS keys as we compute it for you with the KSK or ZSK, then we 
send it to the registry."

So it looks like the owner of domainmail.ch must get the DS from Gandi???  I 
wouldn't know how that would work exactly but clearly a conversation is needed 
with Gandi.

Good hunting.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jim 
Popovitch via bind-users
Sent: Friday, April 09, 2021 2:12 PM
To: bind-users@lists.isc.org
Subject: Re: Testing KASP, CDS, and .ch

On Fri, 2021-04-09 at 19:05 +0000, John W. Blue via bind-users wrote:
> So the issue here is that the DS record that sit in .ch has an ID of 22048 
> but the domainmail.ch servers are telling the world that the correct ID is 
> 17870.
> 
> Thus the DNSSEC breakage.

Of course, however there is no 22048 id in Gandi (the Registrar), yet it 
appears in .ch, and 17870 is still Active (as of this moment in time).  

What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.

I know that I can make the domain validate by manually putting a
keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
to do that, no?

-Jim P.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Testing KASP, CDS, and .ch

2021-04-09 Thread John W. Blue via bind-users

The owner of domainmail.ch will need to give .ch an updated copy of the DS 
record that contains 17870.

Once that has been accomplished .ch will start telling the open internet to 
expect 17870 when talking to domainmail.ch.  When the open internet matches 
what it expects with what it gets then DNSSEC will be validated.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jim 
Popovitch via bind-users
Sent: Friday, April 09, 2021 2:12 PM
To: bind-users@lists.isc.org
Subject: Re: Testing KASP, CDS, and .ch

On Fri, 2021-04-09 at 19:05 +, John W. Blue via bind-users wrote:
> So the issue here is that the DS record that sit in .ch has an ID of 22048 
> but the domainmail.ch servers are telling the world that the correct ID is 
> 17870.
> 
> Thus the DNSSEC breakage.

Of course, however there is no 22048 id in Gandi (the Registrar), yet it 
appears in .ch, and 17870 is still Active (as of this moment in time).  

What I can't figure out is how/when does .ch query the CDS/CDNSKEY data.

I know that I can make the domain validate by manually putting a
keyid+data in Gandi, but the whole purpose of CDS/CDNSKEY is to not have
to do that, no?

-Jim P.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Testing KASP, CDS, and .ch

2021-04-09 Thread John W. Blue via bind-users

So the issue here is that the DS record that sit in .ch has an ID of 22048 but 
the domainmail.ch servers are telling the world that the correct ID is 17870.

Thus the DNSSEC breakage.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jim 
Popovitch via bind-users
Sent: Friday, April 09, 2021 1:58 PM
To: bind-users@lists.isc.org
Subject: Testing KASP, CDS, and .ch

Hello!

I've read the "Schacher 20200622 Support for and adoption of CDS in .ch and 
.li", and studied https://kb.isc.org/docs/dnssec-key-and-signing-policy, 
however I've hita brick wall: 

https://dnsviz.net/d/domainmail.ch/dnssec/

What am I missing?

I'm using the following policy and zone config: 

dnssec-policy "test" {
keys { csk lifetime P30D algorithm ECDSAP256SHA256; }; };

zone "domainmail.ch" {
type master;
file "/etc/bind/zone/domainmail.ch";
dnssec-policy "test";
};

Here are the info of the active keys:

/etc/bind/keys/Kdomainmail.ch.+013+22048.key
; This is a key-signing key, keyid 22048, for domainmail.ch.
; Created: 20210208192710 (Mon Feb  8 19:27:10 2021) ; Publish: 20210208192710 
(Mon Feb  8 19:27:10 2021) ; Activate: 20210208222710 (Mon Feb  8 22:27:10 
2021) ; Inactive: 20210310222710 (Wed Mar 10 22:27:10 2021) ; Delete: 
20210320233210 (Sat Mar 20 23:32:10 2021) ; SyncPublish: 20210208222710 (Mon 
Feb  8 22:27:10 2021)

/etc/bind/keys/Kdomainmail.ch.+013+17870.key
; This is a key-signing key, keyid 17870, for domainmail.ch.
; Created: 20210310202210 (Wed Mar 10 20:22:10 2021) ; Publish: 20210310202210 
(Wed Mar 10 20:22:10 2021) ; Activate: 20210310222710 (Wed Mar 10 22:27:10 
2021) ; Inactive: 20210409222710 (Fri Apr  9 22:27:10 2021) ; Delete: 
20210419233210 (Mon Apr 19 23:32:10 2021) ; SyncPublish: 20210310222710 (Wed 
Mar 10 22:27:10 2021)

/etc/bind/keys/Kdomainmail.ch.+013+04319.key
; This is a key-signing key, keyid 4319, for domainmail.ch.
; Created: 20210220012755 (Sat Feb 20 01:27:55 2021) ; Publish: 20210220012755 
(Sat Feb 20 01:27:55 2021) ; Activate: 20210220012755 (Sat Feb 20 01:27:55 
2021) ; Inactive: 20210221040633 (Sun Feb 21 04:06:33 2021) ; Delete: 
20210303051133 (Wed Mar  3 05:11:33 2021) ; SyncPublish: 20210221023255 (Sun 
Feb 21 02:32:55 2021)


-Jim P.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: underscores in A queries

2021-04-09 Thread John W. Blue via bind-users

It would seem that underscores is one of those characters in DNS that leads a 
double life.

RFC’s say that underscores are disallowed for use in hostnames but SRV records 
use it to indicate service type et al.  And then you have the 
acm-validations.aws geniuses who use it their hostnames to validate domain 
ownership to issue SSL certs never mind it that the format completely screws up 
the design and architecture of your subzones.

:/

(not a fan of Route53 BTW .. and now they say they can “do” DNSSEC.  lol)

So while there is more to talk about with underscores the real answer to your 
question is what do those records resolve to?  SIP or TCP or whatever?  Using 
the DNS query answer will provide the clue as to why those questions are being 
asked.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin K
Sent: Friday, April 09, 2021 1:28 PM
To: bind-users@lists.isc.org
Subject: underscores in A queries

Hi,

I've been parsing my query logs to watch for unusual/unexpected lookups, and I 
notice quite a few A queries with underscores, often in patterns like

_.domainname.com

often followed by

_.xyz.domainname.com

or

_.domainname.com.mydomain.com

Can someone tell me what these are and what the underscores mean?


thanks

Kevin

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Timeout setting

2021-03-25 Thread John W. Blue via bind-users

When I queried the authoritative server directly it worked:

;; QUESTION SECTION:
;111.250.179.17.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
111.250.179.17.in-addr.arpa. 86400 IN   PTR rn2-msbadger07105.apple.com.

;; Query time: 62 msec
;; SERVER: 17.47.176.10#53(17.47.176.10)

I would recommend that you too do a dig @ and see what you get.

If it works then you can start examining your on prim configs .. if it does not 
work then you need to be using wireshark to figure out what is happening to the 
traffic.

Either way you need to first break your troubleshooting into two parts .. on 
prim vs off prim and proceed from there.

Good hunting.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Julien 
Salort
Sent: Thursday, March 25, 2021 12:11 PM
To: bind-users@lists.isc.org
Subject: Timeout setting

Hello,


I have a VPS running postfix and bind9. Bind is used as a recursive resolver, 
in particular to be able to query anti-spam database.

Postfix is also configured to reject incoming connections from servers with no 
reverse dns.

It works great overall, but sometimes legitimate messages get rejected because 
the reverse dns query fails.

Here is an example (anonymized email and host address):

In mail.log:

450 4.7.1 Client host rejected: cannot find your reverse hostname, 
[17.179.250.111]; from=
to= proto=ESMTP helo=
(total: 1)

In named journal:

mars 02 01:14:20 example.com named[2756114]: client @0x7f3a0808c750
127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 
111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1)

mars 02 01:14:25 example.com named[2756114]: client @0x7f3a08079d00
127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query: 
111.250.179.17.in-addr.arpa IN PTR +E(0) (127.0.0.1)

mars 02 01:14:32 example.com named[2756114]: client @0x7f3a0808c750
127.0.0.1#43646 (111.250.179.17.in-addr.arpa): query failed (timed out) for 
111.250.179.17.in-addr.arpa/IN/PTR at query.c:6883

mars 02 01:14:32 example.com named[2756114]: client @0x7f3a000d5110
127.0.0.1#49520 (insideapple.apple.com): query: insideapple.apple.com IN MX + 
(127.0.0.1)


So there is a timeout.

Now if I try again:

$ dig -x 17.179.250.111 @localhost +short rn2-msbadger07105.apple.com.


So it seems that it is just that sometimes the query takes a bit longer...


Is there a general advice regarding timeout for bind?

Should I just choose a longer timeout? Or is there a reason for the default 
value?


I did not have such problems when I was using the ISP dns server instead 
of a local recursive resolver. So I was wondering if the configuration 
is sub-optimal somehow...


Thank you,


Cheers,


Julien


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Bind 9.11 serving up false answers for a single domain.

2021-02-11 Thread John W. Blue via bind-users

Most people like yourself that do not care about OS purity often are not 
obligated (granted super broad generalization) to explain their changes to an 
Enterprise Change Management Board (ECMB or similar) for deviations from a 
"standard image".

That is also 100% okay too.  Those types of shops/sysadmins also typically 
don't have a buckets of cash sitting around either so you work with makes sense 
and use the resources available to get it done.

The over-arching point is that the lowest common denominator for proper 
troubleshooting is that tcpdump is useful and it does not need to be sourced or 
installed.  It is ready to go out of the box for nearly all situations that 
could potentially be encountered.

Usually. 

Murphy's law of unintended consequences should always be account for.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of @lbutlr
Sent: Thursday, February 11, 2021 6:18 PM
To: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.

On 11 Feb 2021, at 16:38, John W. Blue via bind-users 
 wrote:
> I have found to tshark to be useful as well but the failing it has is that it 
> is generally not included in a unix OS distribution.

Is bind? I mean, I have to install a bunch of stuff right off on a new bistro 
just to get a useable (for me) system. And if it's Linux I often have to 
UNinstall some things as well. I don't care about the purity of the 
distributions software set.

-- 
Hey kids, shake it loose together the spotlight's hitting something
That's been known to change the weather we'll kill the fatted
calf tonight So stick around you're gonna hear electric music:
Solid walls of sound

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Bind 9.11 serving up false answers for a single domain.

2021-02-11 Thread John W. Blue via bind-users

I have found to tshark to be useful as well but the failing it has is that it 
is generally not included in a unix OS distribution.

Assuming anything referred to as "being in production" should also be following 
good change management protocols it makes sense to be fluent with tools that 
are readily accessible when a super fun session of 
all-of-sudden-troubleshooting breaks out.

We recently had issues with a vendor that (I won't mention any names but it 
rhymes with proofpoint) where they insisted that the error we were having was 
on our side of the fence.  They were basically unwilling to lift a finger to 
help.  Color me shocked because I thought that how only Microsoft rolled.  
Packet captures proved that it was a load balancing code issue on their side 
and only then were they compelled to take action.

Being able to correctly examine packets on the wire is a "must have" skillset 
to be an effective sysadmin.  It can save the day or save your butt.

@OP:  very curious as to where you are at now in your troubleshooting.  Status 
update?

John

-Original Message-
From: Paul Kosinski [mailto:b...@iment.com] 
Sent: Wednesday, February 10, 2021 10:37 PM
To: bind-users@lists.isc.org
Cc: John W. Blue
Subject: Re: Bind 9.11 serving up false answers for a single domain.

I rather prefer tshark to tcpdump: it's essentially the command line version of 
wireshark, and thus has wireshark's protocol "dissecting" abilities.

On Wed, 10 Feb 2021 22:20:08 +0000
"John W. Blue via bind-users"  wrote:

> Three words:  tcpdump and wireshark
> 
> It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and 
> flow .. pen and paper .. I could go on but …
> 
> Know them.  Love them.  They are your newest best friends.
> 
> 
> 
> Using tcpdump IMHO should be the first tool anyone uses when troubleshooting 
> seemly unexplainable DNS weirdness.
> 
> Knowing what is being put on the wire (or lack thereof) is critical since it 
> provides key factual data points that decisions can be made on.  When running 
> tcpdump on the DNS server I personally prefer this command:
> 
> tcpdump -n -i  -s 65535 -w 
> 
> dash n is telling tcpdump that you do not want it to resolve hostnames.  This 
> is an important option when doing DNS troubleshooting because you do not want 
> extra resolutions taking place.
> dash s is saying gimme the full packet.
> dash w is the name of the file you want the output saved in.
> 
> After starting the command, run several queries from a host and ctrl+c to 
> exit.
> 
> Once you get your file into wireshark now you can start slicing n dicing on 
> the data!
> 
> Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us
> 
> By using a filter of dns.flags.rcode == (number here) you can drive off into 
> the weeds and get super granular with sorting the data.  For example 
> “dns.flags.rcode == 2” will show you all of the server failures for queries.
> 
> It is hard to provide further guidance on what to do since what you find in 
> the pcap is only a starting point.
> 
> Good hunting!
> 
> As an aside I would like to mention that you do not need to travel home to 
> get situational awareness when the diggui.com website can be used instead.
> 
> Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?
> 
> https://dnsviz.net/d/state.ma.us/dnssec/
> 
> John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread John W. Blue via bind-users

So out of curiosity why does the us tld have a SHA1 DS in root?  Should be an 
easy thing to tidy up, eh?

John

-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy] 
Sent: Wednesday, February 10, 2021 7:20 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)

Ah, SHA1 DS record or an RSASHA256 DNSKEY, yes.

Stuart 

On 11/2/21, 11:42 am, "bind-users on behalf of John W. Blue via bind-users" 
 wrote:

Notice: This email is from an external sender.

Well .. as best as I can tell .. the us tld does has a SHA1 DS record:

;; QUESTION SECTION:
;us.IN  DS

;; ANSWER SECTION:
us. 50882   IN  DS  21364 8 1 
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882   IN  DS  21364 8 2 
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26

Right?

In checking other tld's looks like it is a mixed bag .. some do .. some 
don’t.

;; QUESTION SECTION:
;com.   IN  DS

;; ANSWER SECTION:
com.78577   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy]
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)

If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’ 
however, is delegated to the state officials of the Commonwealth of 
Massachusetts and is indeed RSASHA1NSEC3.

Stuart
... one of the guy’s that does the DNSSEC for US TLD.

From: bind-users  on behalf of "John W. 
Blue via bind-users"  Reply to: "John W. Blue" 

Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users 
Subject: RE: Bind 9.11 serving up false answers for a single domain.

Notice: This email is from an external sender.

Three words:  tcpdump and wireshark

It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and 
flow .. pen and paper .. I could go on but …

Know them.  Love them.  They are your newest best friends.

Using tcpdump IMHO should be the first tool anyone uses when 
troubleshooting seemly unexplainable DNS weirdness.

Knowing what is being put on the wire (or lack thereof) is critical since 
it provides key factual data points that decisions can be made on.  When 
running tcpdump on the DNS server I personally prefer this command:

tcpdump -n -i  -s 65535 -w 

dash n is telling tcpdump that you do not want it to resolve hostnames.  
This is an important option when doing DNS troubleshooting because you do not 
want extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.

After starting the command, run several queries from a host and ctrl+c to 
exit.

Once you get your file into wireshark now you can start slicing n dicing on 
the data!

Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us

By using a filter of dns.flags.rcode == (number here) you can drive off 
into the weeds and get super granular with sorting the data.  For example 
“dns.flags.rcode == 2” will show you all of the server failures for queries.

It is hard to provide further guidance on what to do since what you find in 
the pcap is only a starting point.

Good hunting!

As an aside I would like to mention that you do not need to travel home to 
get situational awareness when the diggui.com website can be used instead.

Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?

https://dnsviz.net/d/state.ma.us/dnssec/

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
sami's strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.

Thank you all for responding.  One final query about this. I'm seeing this 
issue on my production servers at work.  Yet, when I run the same queries at 
home, I don't see those failed queries.  I actually flushed DNS cache, cleared 
Linux O/S cache, and even bounced my personal DNS server trying to reproduce 
the issue.  But I could not.

TIA

On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org> wrote:
Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you 
the glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us 
@’ for all the addresses in the glue records.

e.g.
dig +dnssec +norec http://internet-dns1.state.ma.us 
@http://146.243.122.17

Mark

> On 10 Feb 2021, at 14:50, sami's str

RE: Bind 9.11 serving up false answers for a single domain. (OT)

2021-02-10 Thread John W. Blue via bind-users

Well .. as best as I can tell .. the us tld does has a SHA1 DS record:

;; QUESTION SECTION:
;us.IN  DS

;; ANSWER SECTION:
us. 50882   IN  DS  21364 8 1 
260D0461242BCF8F05473A08B05ED01E6FA59B9C
us. 50882   IN  DS  21364 8 2 
B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26

Right?

In checking other tld's looks like it is a mixed bag .. some do .. some don’t.

;; QUESTION SECTION:
;com.   IN  DS

;; ANSWER SECTION:
com.78577   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

-Original Message-
From: Stuart@registry.godaddy [mailto:Stuart@registry.godaddy] 
Sent: Wednesday, February 10, 2021 5:24 PM
To: John W. Blue; bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain. (OT)

If you look closer, you’ll see that ‘us.’ is RSASHA256. ‘state.ma.us.’ however, 
is delegated to the state officials of the Commonwealth of Massachusetts and is 
indeed RSASHA1NSEC3.

Stuart
... one of the guy’s that does the DNSSEC for US TLD.

From: bind-users  on behalf of "John W. Blue 
via bind-users"  Reply to: "John W. Blue" 

Date: Thursday, 11 February 2021 at 9:21 am
To: bind-users 
Subject: RE: Bind 9.11 serving up false answers for a single domain.

Notice: This email is from an external sender. 

Three words:  tcpdump and wireshark

It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and 
flow .. pen and paper .. I could go on but … 

Know them.  Love them.  They are your newest best friends.

Using tcpdump IMHO should be the first tool anyone uses when troubleshooting 
seemly unexplainable DNS weirdness.

Knowing what is being put on the wire (or lack thereof) is critical since it 
provides key factual data points that decisions can be made on.  When running 
tcpdump on the DNS server I personally prefer this command:

tcpdump -n -i  -s 65535 -w 

dash n is telling tcpdump that you do not want it to resolve hostnames.  This 
is an important option when doing DNS troubleshooting because you do not want 
extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.

After starting the command, run several queries from a host and ctrl+c to exit.

Once you get your file into wireshark now you can start slicing n dicing on the 
data!

Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us

By using a filter of dns.flags.rcode == (number here) you can drive off into 
the weeds and get super granular with sorting the data.  For example 
“dns.flags.rcode == 2” will show you all of the server failures for queries.

It is hard to provide further guidance on what to do since what you find in the 
pcap is only a starting point.

Good hunting!

As an aside I would like to mention that you do not need to travel home to get 
situational awareness when the diggui.com website can be used instead.

Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?

https://dnsviz.net/d/state.ma.us/dnssec/

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of sami's 
strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.

Thank you all for responding.  One final query about this. I'm seeing this 
issue on my production servers at work.  Yet, when I run the same queries at 
home, I don't see those failed queries.  I actually flushed DNS cache, cleared 
Linux O/S cache, and even bounced my personal DNS server trying to reproduce 
the issue.  But I could not.

TIA

On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews <mailto:ma...@isc.org> wrote:
Run ‘dig +trace +all http://internet-dns1.state.ma.us’ which will show you the 
glue records then try ‘dig +dnssec +norec http://internet-dns1.state.ma.us 
@’ for all the addresses in the glue records.

e.g.
        dig +dnssec +norec http://internet-dns1.state.ma.us 
@http://146.243.122.17

Mark

> On 10 Feb 2021, at 14:50, sami's strat <mailto:sami.st...@gmail.com> wrote:
> 
> Thanks Mark.
> 
> However, the traceroute to the hostnamed failed for the same reason.  Please 
> note:
> 
> [root@myhost data]# dig http://internet-dns1.state.ma.us
>  
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> 
> http://internet-dns1.state.ma.us ;; global options: +cmd ;; Got 
> answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641 ;; flags: 
> qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>  
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;http://internet-dns1.state.ma.us.     IN      A
>  
> ;; Query time: 1263 msec
> ;; SER

RE: Bind 9.11 serving up false answers for a single domain.

2021-02-10 Thread John W. Blue via bind-users

Three words:  tcpdump and wireshark

It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and 
flow .. pen and paper .. I could go on but …

Know them.  Love them.  They are your newest best friends.

Using tcpdump IMHO should be the first tool anyone uses when troubleshooting 
seemly unexplainable DNS weirdness.

Knowing what is being put on the wire (or lack thereof) is critical since it 
provides key factual data points that decisions can be made on.  When running 
tcpdump on the DNS server I personally prefer this command:

tcpdump -n -i  -s 65535 -w 

dash n is telling tcpdump that you do not want it to resolve hostnames.  This 
is an important option when doing DNS troubleshooting because you do not want 
extra resolutions taking place.
dash s is saying gimme the full packet.
dash w is the name of the file you want the output saved in.

After starting the command, run several queries from a host and ctrl+c to exit.

Once you get your file into wireshark now you can start slicing n dicing on the 
data!

Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us

By using a filter of dns.flags.rcode == (number here) you can drive off into 
the weeds and get super granular with sorting the data.  For example 
“dns.flags.rcode == 2” will show you all of the server failures for queries.

It is hard to provide further guidance on what to do since what you find in the 
pcap is only a starting point.

Good hunting!

As an aside I would like to mention that you do not need to travel home to get 
situational awareness when the diggui.com website can be used instead.

Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?

https://dnsviz.net/d/state.ma.us/dnssec/

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of sami's 
strat
Sent: Wednesday, February 10, 2021 11:54 AM
To: Mark Andrews
Cc: bind-users
Subject: Re: Bind 9.11 serving up false answers for a single domain.

Thank you all for responding.  One final query about this. I'm seeing this 
issue on my production servers at work.  Yet, when I run the same queries at 
home, I don't see those failed queries.  I actually flushed DNS cache, cleared 
Linux O/S cache, and even bounced my personal DNS server trying to reproduce 
the issue.  But I could not.

TIA

On Wed, Feb 10, 2021 at 12:09 AM Mark Andrews 
mailto:ma...@isc.org>> wrote:
Run ‘dig +trace +all 
internet-dns1.state.ma.us’ which will show 
you the glue
records then try ‘dig +dnssec +norec 
internet-dns1.state.ma.us @’ for
all the addresses in the glue records.

e.g.
dig +dnssec +norec 
internet-dns1.state.ma.us 
@146.243.122.17

Mark

> On 10 Feb 2021, at 14:50, sami's strat 
> mailto:sami.st...@gmail.com>> wrote:
>
> Thanks Mark.
>
> However, the traceroute to the hostnamed failed for the same reason.  Please 
> note:
>
> [root@myhost data]# dig 
> internet-dns1.state.ma.us
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> 
> internet-dns1.state.ma.us
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;internet-dns1.state.ma.us. IN  A
>
> ;; Query time: 1263 msec
> ;; SERVER: 192.168.33.12#53(192.168.33.12)
> ;; WHEN: Tue Feb 09 22:34:15 EST 2021
> ;; MSG SIZE  rcvd: 54
>
> [root@myhost data]# dig 
> internet-dns1.state.ma.us +trace
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> 
> internet-dns1.state.ma.us +trace
> ;; global options: +cmd
> .   516485  IN  NS  
> c.root-servers.net.
> .   516485  IN  NS  
> e.root-servers.net.
> .   516485  IN  NS  
> f.root-servers.net.
> .   516485  IN  NS  
> l.root-servers.net.
> .   516485  IN  NS  
> m.root-servers.net.
> .   516485  IN  NS  
> d.root-servers.net.
> .   516485  IN  NS  
> g.root-servers.net.
> .   516485  IN  NS  
> k.root-servers.net.
> .   516485  IN  NS  
> b.root-servers.net.
> .   516485  IN  NS  
> h.root-servers.net.
> .   516485  IN  NS  
>

RE: Testing a new master server...

2020-11-18 Thread John W. Blue via bind-users

Hello Bruce!

For opening comments .. I have nothing but empathy for you and the firefight 
you are in.  "Intuitional inertia" is never enjoyable especially when you are 
the one tasked with change.

So you indicated "upstream network management" is sending DNS/DHCP traffic but 
then you say that it is from your vLAN's.  That does not make sense.

It feels like what you meant to say is that you have a bunch of zones and there 
is a ton of traffic (DNS/DHCP) being sent from your vLAN's *and* you need to 
coordinate and changes with "upstream network management".  The reason why I 
bring this up is because (without extra data points) it feels like you are 
attempting to replace an old bandaid with a new one hoping that will resolve 
user angst.

Some things to think about as a sanity check:
If the current configuration is so easy to break, do you really want to keep 
administrating a design that is doing that?
What change management processes are in place when OS patches need to be 
applied or there DNS/DHCP maintenance to be done?
Does this server face the open Internet or is it exclusively an RFC1918 box?
If one server is responsible for both DNS/DHCP for everything would it make 
more sense to split the roles out?

Assuming there is currently one RFC1918 server for everything, my thoughts (at 
a very high level) would be to redesign the environment to start using a hidden 
primary.  Next, stand up two DNS servers as secondaries (configured with ' 
allow-update-forwarding ') each running DHCP to take advantage of "auto partner 
down".  With a hidden primary there is now a single source of truth on the 
network that is being dynamically update by the secondaries.

When it comes time for maintenance, rebooting or taking one of the secondary 
servers offline will not kill off the services for the users.  When it is time 
to apply patches to the hidden primary, do that after hours.  " 
allow-update-forwarding" is real-time forwarding not store and forward.

To address your question about "allow-transfer" and "allow-update" I don’t 
think those are as important as disabling "also-notify".

Regardless, I do hope your migration goes smooth!

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce 
Johnson
Sent: Wednesday, November 18, 2020 11:35 AM
To: bind-users@lists.isc.org
Subject: Testing a new master server...

I’m in the process of migrating our master DNS server from an ancient system 
(it’s running RHEL4.0) to a modern system. This kind of fell in my lap; I’m 
familiar with adding host assignments and such but managing the server itself 
in the past is pretty much relegated  to ’service named reload’ and finding the 
newly introduced typo in the hosts or zone file if it fails...

It's a mildly complicated setup with a bunch of zones (including a big one that 
is dynamically updated) and more pressingly I will need to coordinate with 
upstream network management that sends DNS and dhcp requests from our VLAN's to 
the specific switch port it is on when we do the cutover, then change the IP 
address on the new server so that it repsonds as the old master, so if I can be 
sure it’ll work I’ll have fewer main campus network mnanagers annoyed with me 
and many fewer end users with torches and pitchforks at my door for breaking 
everything...  

I've made some changes to the configuration (mostly removing zones and address 
assignments that are no longer valid) and I'd like to bring it up for testing 
so I know it’s working before we do the cutover to production.

If I comment out the the allow-transfer directive so it does not divert 
requests to our ‘real' secondary servers and the allow-update for the 
dynamically updated zone, I think I should be able to bring it up in a master 
server role (on a different IP address) without it interfering with our real 
one, as the only clients that would actually talk to it would be ones that 
specify that IP address for resolution.

Am I missing something or overcomplicating things?

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC migration sanity check

2020-09-04 Thread John W. Blue via bind-users

Howdy bind-users list.

TLDR: we were able to move zones between DNS servers with different KSK/ZSK 
while keeping the zones secure.


First I want to say a BIG thank you for the replies received since it helped in 
documenting our workflow for these migrations.

Off list, Paul E. mentioned that a test domain might be handy and that obvious 
suggestion made a big difference.  No pressure if we mess it up.  Thanks Paul.

Additionally, Paul also included a link to a draft of multi-signer DNSSEC:

https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec

Of note is the section titled:  2.1.2.  Model 2: Unique KSK set and ZSK set per 
provider

Therein it mentions how "Each provider has their own KSK and ZSK sets" and that 
is exactly the situation we found ourselves.  Our testing showed that we could 
"double-sign" our test zone (is that the correct phrase in this context?) and 
it remained secured as indicated by the "ad" flag:

# dig fqdnhere.com +dnssec +multi

; <<>> DiG 9.14.2 <<>> fqdnhere.com +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44429
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

Although dnsviz.net indicated that the zone was secure it produced many, many 
complaints about errors it was finding.  Which, honestly, is to be expected.  
For example:

"The DS RRset for the zone included algorithm 10 (RSASHA512), but no DS RR 
matched a DNSKEY with algorithm 10 that signs the zone's DNSKEY RRset"

At first glance the task looked overwhelming but it could not have been easier.

John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNSSEC migration sanity check

2020-08-19 Thread John W. Blue via bind-users

We are in the process of moving from one IPAM vendor to another.

All of our zones are DNSSEC signed and the TTL's have been lowered to 300 
seconds.

At a high level, the playbook is to update the registrar with names/IP 
addresses of the new servers and update the DSKEY.  Depending on the time of 
the day that the cutover actually happens at we know the process to request of 
the registrar an out of band data push so the new servers will be seen by the 
open Internet.

A suggestion have been put forth that we should unsign our zones prior to 
migration but I am skeptical of the benefits of doing so.

Are we missing something obvious?

John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: broken trust chain

2020-07-28 Thread John W. Blue via bind-users

What version of BIND are you using?

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
youssef.fassifi...@inwi.ma
Sent: Tuesday, July 28, 2020 6:10 PM
To: bind-users@lists.isc.org
Subject: broken trust chain

Hi All,

I am using Bind as resolver for end users  .

At various time, bind logs show "broken trust chain" continuously  , for about 
20mn  ~ 30 mn causing an increase of "recursive clients" shown in "rndc status" 
and a decrease of  "DNS sucess rate KPI" supervised from end users side.  then 
the error disappear and everything is OK.

the problem appears on different server at different time.

What could be the problem?

Regards,

« Ce message et toutes les pièces y jointes sont susceptibles de contenir des 
informations confidentielles ou privilégiées, lesquelles ne doivent être 
reproduites, diffusées ou exploitées sans autorisation. L'intégrité des 
messages électroniques n'étant pas garantie, WANA CORPORATE décline toute 
responsabilité dans le cas où ce message aurait été altéré, déformé ou falsifié.

Ce message est établi à l'attention exclusive de ses destinataires. Si vous 
avez reçu ce message par erreur, veuillez le signaler à l'expéditeur et le 
détruire y compris les pièces jointes.

Merci. »

« This message and its attachments may contain confidential or privileged 
information that should not be copied, distributed or used without 
authorization. As the integrity of emails may not be guaranteed, WANA CORPORATE 
is not liable for messages that have been modified, changed or falsified.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

Thank you. »
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: BIND DNS problem (?)

2018-09-26 Thread John W. Blue via bind-users

I could not zoom in to see anything.  Please post a better screenshot or better 
yet post the .pcap itself for download and review.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Wednesday, September 26, 2018 2:46 AM
To: bind-users@lists.isc.org
Subject: BIND DNS problem (?)

We are running a couple of Symantec SMG servers, and their DNS clients are 
configured to use your BIND 9.12.2 DNS servers.

In both SMG servers we get the same DNS "server failure" error from all our DNS 
servers when they do some TXT queries to SMG:

http://www.qnet.fi/jp/dns.png

(sorry for the bad quality/format, hope you can zoom in. That's all I got from 
Symantec when contacting their support, and they claim the problem is in our 
DNS servers because of the "server failure" error).

Anyway, I suppose the problem is related to these, in the response:

Answer authenticated: Answer/authority portion was not authenticated by the 
server
Non-authenticated data: Unacceptable

Sooo, any ideas what does this mean, is the problem in out BIND servers, or in 
the other end?

Jukka
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Frequent timeout

2018-08-31 Thread John W. Blue via bind-users

tcpdump is your newest best friend to troubleshoot network issues.  You need to 
see what (if anything) is being placed on the wire and the responses (if any).  
My goto syntax is:

tcpdump -n -i eth0 port domain

I like -n because it prevents a PTR lookup from happing.  Why add extra noise?  
As with anything troubleshooting related it is a process of elimination.

Good hunting!

John

Sent from Nine

From: Alex 
Sent: Friday, August 31, 2018 4:20 PM
To: bind-users@lists.isc.org
Subject: Frequent timeout

Hi,

Would someone please help me understand why I'm receiving so many
timeouts? This is on a fedora28 system with bind-9.11.4 acting as a
mail server and running on a cable modem.

It appears to happen during all times, including when the link is
otherwise idle.

31-Aug-2018 16:52:57.297 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for support.coxbusiness.com/A in
10.000171: timed out/success
[domain:support.coxbusiness.com,referral:2,restart:4,qrysent:5,timeout:4,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

31-Aug-2018 17:06:42.655 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for dell.ns.cloudflare.com/A in
10.000108: timed out/success
[domain:cloudflare.com,referral:0,restart:2,qrysent:13,timeout:12,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

What more information can I provide to troubleshoot this?

Is it possible that even though the link otherwise seems to be
operating okay that there could still be some problem that would
affect DNS traffic?

I've also clear all firewall rules, and it's not even all queries which fail.

Thanks,
Alex
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

40 matches

Mail list logo