RE: Logging with Unencrypted DNS, DoT and DoH

[John W. Blue via bind-users]

Ralph,

You already may be aware of the BIND webinar's put on by ISC and presented by 
Carsten:

https://www.isc.org/docs/BIND_9webinar2.pdf
https://www.youtube.com/watch?v=7Uu6XvY68SM

If not, spend some time watching the video and would like to point out that 
slide 12 lists several COTS vendors that are able to consume the named.stats 
output.

John


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Bischof, Ralph F. (MSFC-IS64)[AEGIS] via bind-users
Sent: Tuesday, September 17, 2024 3:40 PM
To: bind-users@lists.isc.org
Subject: Logging with Unencrypted DNS, DoT and DoH

Hello,

BIND 9.18.7
RHEL 8.10 (Oopta)

I am being asked if it is possible to differentiate the percentage of queries 
coming into a server that are unencrypted, DoT and DoH.
Example: For a given 24 hours, 50% were 53, 25% were 853 and 25% were 443.
I cannot find a difference in the query logs to show how the query came into 
the server. My only thought at the moment is to run 'tcpdump' on all of the 
servers and script something.
Is there some way that I just have not found within BIND?
My apologies if this has been asked previously.

Thank you,
Ralph F. Bischof, Jr. | Leidos
DDI Service Architect
Digital Modernization Sector

ralph.bisc...@nasa.gov | 
www.leidos.com
+1 (256) 682-9145 M



-- 
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: Problem with a certain domain

[John W. Blue via bind-users]

Sorry did not spend too much time thinking about this but if you are checking 
DKIM should that be a TXT query instead of an A record?

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Thomas 
Barth via bind-users
Sent: Friday, May 31, 2024 12:14 PM
To: bind-users@lists.isc.org
Subject: Problem with a certain domain

Hello,

I use bind9 on my mail server so that Spamassassin can perform the necessary 
DNS blocklist queries. Since it has already happened several times that I have 
to restart bind9 so that a certain domain can still be resolved, I wanted to 
ask if anyone knows where I have to set something.

A mail user regularly receives a newsletter from Spain. But the query to check 
the DKIM signature sometimes leads to a communication error, timeout and a 
write error. I am then informed of these errors by e-mail so that I can restart 
bind9 promptly. Because then it works smoothly again until this problem occurs 
again at some point.

Domain of DKIM-request (duration when the problem occurs 4992 msec!) 
 dig s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; communications error to 127.0.0.1#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>>
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35945 ;; flags: qr rd ra; 
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 69cb0f9615955ad701006659b7dd9477fff265ac63f6 (good) ;; QUESTION 
SECTION:
;s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es. IN A

;; Query time: 4992 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri May 31 13:43:25 CEST 2024 
;; MSG SIZE  rcvd: 107 

Then after restarting bind9 (1800 msec)


; <<>> DiG 9.18.24-1-Debian <<>>
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33426 ;; flags: qr rd ra; 
QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 1ce3693ff4b0e24a01006659b802511c16009f2773b0 (good) ;; QUESTION 
SECTION:
;s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es. IN A

;; AUTHORITY SECTION:
mallorcazeitung.es. 2560IN  SOA ns1.epi.es. 
hostmaster.mallorcazeitung.es. 1717151222 16384 2048 1048576 2560

;; Query time: 1800 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri May 31 13:44:02 CEST 2024 
;; MSG SIZE  rcvd: 182 

1.8 seconds seems usual for this domain, no idea why, a query from the Bank of 
China is faster \o/

In the Postfix journal I can read:


May 30 13:40:50 mx1 postfix/smtpd[257112]: warning: timeout talking to proxy 
localhost:10024 May 30 13:40:50 mx1 postfix/smtpd[257112]: proxy-reject: 
END-OF-MESSAGE: 
451 4.3.0 Error: queue file write error; ...


My settings in /etc/bind/named.conf.options (Debian 12.5) are:


acl goodclients {
127.0.0.0/8;
localhost;
};

options {
directory "/var/cache/bind";

recursion yes;
allow-query { goodclients; };

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

//forwarders {
//  9.9.9.9;
//  149.112.112.112;
//};


//
// If BIND logs error messages about the root key being expired,
// you will need to update your keys.  See https://www.isc.org/bind-keys

//
dnssec-validation auto;

listen-on { any; };
listen-on-v6 { none; };
};


Any idea for improving the config?

And this "after disabling qname minimization due to" thing seems to slow down 
the requests?

named[287800]: success resolving
's1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/A' after disabling qname 
minimization due to 'ncache nxdomain'



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

RE: Facing issues while resolving only one record

[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]
; ns02.in

RE: host restriction

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

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

[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

[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

[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

[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

[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

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

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

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

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

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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

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

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

[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 +
"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)

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

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

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

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

[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  
> a.root-servers.net

RE: Testing a new master server...

[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

[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

[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

[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: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[John W. Blue]

Speaking about things to be annoyed over .. 

I am still ticked that FreeBSD dropped BIND from the distribution for something 
called unwinding or whatever it is.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ted 
Mittelstaedt
Sent: Friday, July 17, 2020 12:57 PM
To: bind-users@lists.isc.org
Subject: Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

>
> Your personal experience is not the gobal truth. It is your opinion but other 
> experienced pepole see it different than you.
>

Hmm I'm a bit late to this discussion but I will chime in with the others.  The 
service always was called "named"  pronounced "name Dee"
it was called that in the Nutshell book which is easily the authoritative book 
on the subject, it was called this before you were born and it was kind of the 
height of hubris for it to ever be named
bind9 in a software distro.

In fact, the ONLY reason that the name "bind9" was ever even coined at all was 
because the changes from bind8 both in the syntax of the config file and how 
the program operated they wanted to boot admins in the behind to get them to 
change their config files.  It should have been put to bed as a name a long 
time ago, or named "bind version 9" like every other software program does with 
their versions.

So as an experienced person who has been doing this you-nuxs thing since
1982 - I DON'T see it different - and in fact, I see it as a RETURN to what it 
originally was!

Ted
___
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: [DoD Source -- ssshhhh Top Secret] Re: Dumb Question is an A or AAAA record required?

[John W. Blue]

>From a BIND point of view "in-addr.arpa" is a unique zone with no dependencies.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of DeCaro, 
James John (Jim) CIV DISA FE (USA) via bind-users
Sent: Thursday, July 09, 2020 8:16 AM
To: Mark Andrews; @lbutlr
Cc: bind-users
Subject: RE: [Non-DoD Source] Re: Dumb Question is an A or  record required?

Would the lack of A records affect pointer records?  Seems like it would.


Jim

"If you always do what you always did you will always get what you always got."


___
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: Bind9 shared cache

[John W. Blue]

In BIND views can be configured to share a cache on the same server but I do 
not think that it can be done between servers.

That said, time for a sanity check.  Does this configuration resolve a specific 
technical problem?  If so, then I would recommend you keep running your unbound 
system.  If it does not and it is a 2nd level of cool for you, the first being 
you have operational DNS servers, then I would recommend you stay with your 
unbound system and be proud of what you have accomplished.

If, on the other hand, this is a configuration that you inherited or it is a 
configuration that is nice to have but you can live without it I would 
encourage you to stand up some BIND servers.  Get them operational and start 
using them in parallel.  I think you'll find they will perform remarkably well 
with individual caches.

John

Sent from Nine

From: Talkabout 
Sent: Sunday, April 19, 2020 5:29 AM
To: bind-users@lists.isc.org
Subject: Bind9 shared cache

Hi all,

I am considering to switch from Unbound to Bind9 to use as DNS Server, but I 
have a requirement that seems to not being possible with Bind9.

Currently I am using 2 Unbound DNS Servers configured to use Redis (KeyDB as a 
drop-in replacement in my case) to make sure that both Servers are sharing the 
same Cache. That way, when server1 resolves an address and puts it into the 
backend database, server2 does not Need to execute Resolution for this address 
any more but gets it fast from the shared Cache.

I have not found any way in the Bind9 documentation to achieve a similar Thing. 
So my Questions are:


  1.  Is there a way to configure a shared Cache that is used by multiple 
Servers?
  2.  Is there a way to configure custom backends for Bind9?
  3.  Are there any plans to support similar Scenarios? Maybe via a 
Synchronisation mechanism?

Thanks!

Bye

Gesendet von Mail f?r Windows 10

___
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: Bind 9 not responding to queries

[John W. Blue]

Sir Izake,

Any network troubleshooting starts with finding out what is being placed on the 
wire.  In your particular example it sounds like you need to validate if this 
Cent box is seeing a SYN flood.  You do this by using tcpdump.

Assuming you only have one ethernet adapter (which by extension rules out its 
use as a proxy or a bridge) you would issue the following command:

sudo tcpdump 'tcp[13] & 2!=0'

You should see something like this start showing up:

10:27:43.627614 IP 197.2.11.116.33465 > 10.41.32.21.domain: Flags [S], seq 
166424657, win 8192, options [mss 1400,nop,wscale 8,nop,nop,sackOK], length 0

Source IP is on the left of the > and destination IP is on the right.  From 
there you can begin to make informed decisions about your next steps.

Finally, if you have never used tcpdump here is a great resource to get started 
with on how to play around with the different commands:

https://danielmiessler.com/study/tcpdump/

Good hunting!

John


From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of sir 
izake
Sent: Saturday, April 11, 2020 8:42 PM
To: bind-users@lists.isc.org
Subject: Bind 9 not responding to queries

Hi Support

I have installed BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el8 on CentOS Linux release 
8.1.1911.

I have configured bind as a recursive server for my network. At specific times 
of day bind fails to respond to queries even though service is shown to run 
(configured to respond to my network IPs, this works fine till this time when 
service fails to answer queries)

I have looked through the logs and found below ;

Apr 10 20:12:43 # automatic empty zone: B.E.F.IP6.ARPA
Apr 10 20:12:43 # named[25445]: automatic empty zone: 
8.B.D.0.1.0.0.2.IP6.AR>
Apr 10 20:12:43 # named[25445]: automatic empty zone: EMPTY.AS112.ARPA
Apr 10 20:12:43  #  named[25445]: automatic empty zone: HOME.ARPA
Apr 10 20:12:43 # named[25445]: none:103: 'max-cache-size 90%' - setting to 
>
Apr 10 20:12:44 # # named[25445]: configuring command channel from 
'/etc/rndc.>
Apr 10 20:12:44 # named[25445]: command channel listening on 127.0.0.1#953
Apr 10 20:12:44 # named[25445]: configuring command channel from 
'/etc/rndc.>
Apr 10 20:12:44 # named[25445]: command channel listening on ::1#953

others

Apr 11 22:38:01 # systemd[1]: Started Session 29 of user ABC.
Apr 11 22:38:04 #  dbus-daemon[13352]: [system] Activating via systemd: 
service name='net.reactivated.Fprint' unit='fprintd.service' requested by 
':1.24116' (uid=0 pid=5364 comm="su - " 
label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
Apr 11 22:38:04 #  systemd[1]: Starting Fingerprint Authentication Daemon...
Apr 11 22:38:04 #  dbus-daemon[13352]: [system] Successfully activated 
service 'net.reactivated.Fprint'
Apr 11 22:38:04 #  systemd[1]: Started Fingerprint Authentication Daemon.
Apr 11 22:38:09 #  kernel: TCP: request_sock_TCP: Possible SYN flooding on 
port 53. Sending cookies.  Check SNMP counters.
Could  log point to DDoS attack ( how do i mitigate)

I have tried to update bind but it looks like its the stable for Centos 8

Please advise what can be done to prevent the intermittent failures

Regards
Isaac


___
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: securing bind in todays hostile environment

[John W. Blue]

Since it sounds like you have not had much experience with, I urge you to check 
it out should you have anything in your environment that could benefit from 
automation. Simply telling someone to chunk it and not have any experience with 
it is a little misguided IMO.



We pay multiple different teams to play in the ansible, docker, kubernetes et 
al sandbox so, yeah, I admittedly do *need* to have much experience.  My 
comments are not an indictment against ansible itself because I observe it 
being used to create basic servers on a regular basis.  It does a fantastic 
job.  Rather I was questioning the use of ansible to specifically deploy DNS 
servers.

Since you updated your comments to mention that you all are selling DNS 
services, the choice of ansible now makes more sense.

I've worked in the MSP space in the past and my general observation is that it 
is a sweat shop with no loyalty in a race to the bottom of how low of a salary 
they can get away with paying.  I genuinely hope your experience will be 
different.

John

Sent from Nine



___
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: securing bind in todays hostile environment

[John W. Blue]

Some things to think about ..

1.  What is your/teams plan B to fix this type of ansible environment should it 
get horked up?  There is a ton of stuff that is being configured for you all 
under the hood and by your own admission your a novice.  The laws of unintended 
consequences apply.

2.  Why is the decision being made to go with a "solution" using ansible?  Is 
it because software devs are being asked to do double duty as DDI admins?  I 
know that "devops" is what all the cool kids are talking about these days but 
are you all honestly willing to trust a core infrastructure to automation?

3.  (slightly different phrasing) What problem does this plan solve?  Assuming 
the existing DNS servers are doing the job for the organization and running the 
current BIND release why change?

4.  When I read that they called DNSSEC an authentication method I checked out. 
 They dont know what they are talking about.  DNSSEC is  a validation method.

In the absence of more detailed design goals I would recommend that you all 
chunk the ansible  plan and go with what works and is proven.

Using a hidden master either for external or internal or both is a good plan to 
defend against cache poisoning (we do) but only enable DNSSEC on your external 
zone(s).

If you use a split horizon consider naming your servers in such a manner so 
that it obvious which is which when you all drive off into the troubleshooting 
weeds.

Depending on the size of your organization, editing zone files to add remove 
resource records by hand is a painful existence if there is daily changes.  Do 
yourself and everyone that comes after you a favor and invest in a legit IPAM 
solution from either Infoblox or Bluecat.  I prefer Infoblox but both can 
administrate BIND and Microsoft DNS servers.  Plus you get the ability to tag 
up metadata which is good to recall why something was done.

Final word:  no way in the world would I ever sign off on a system that leaves 
me/my team holding the email-is-down bag due to a DNS outage caused by a poorly 
designed system.

Been there .. done that.  No bueno.

(final, final word: if you still want to live in ansible  I would suggest that 
you add another NIC to each server and assume the IPs of the old servers so you 
dont bring cruft forward into your new world order.)



John

Sent from Nine

From: "N. Max Pierson" 
Sent: Saturday, January 18, 2020 8:08 AM
To: bind-users@lists.isc.org
Subject: securing bind in todays hostile environment

Hi List,

First off, I should note that I am a novice with administering Bind, so please 
bear with me.

We are looking to be more pro-active and security minded in our network in 
general and while we are getting ready to completely replace/upgrade our 
current instances of Bind, I would like to hear of opinions of the following 
ansible role that would install, setup, configure, etc our instances taking 
security into account. I have read some of the common best practices on this 
very list over time but wanted to ensure what was in this role wasn't missing 
anything in terms of securing the deployment.

So I am aware it's preferred to split recursive and authoritative services 
across different instances. I also understand it's preferred to use one of the 
"out of zone" (apologies for not knowing the proper terminology) master methods 
(such as hidden or shadow master). It's also a very good idea to deploy TSIG 
for transaction signing. And of course, ACL recursive lookups as well as AXFRs. 
Beyond that, what other best practices should be considered when making a 
deployment such as the following scenario 

ns1 - ns4: authoritative name servers - slaves
ns0 - hidden/shadow master

old ns1- ns4: will be used as recursive as these were deployed doing both 
authoritative and recursive many years ago and policy routing for these old IPs 
is very ugly, so we would like to keep them there after an upgrade as opposed 
to try and figure out who's still using them to notify we're changing the IPs


The ansible role can be seen here at https://github.com/juju4/ansible-bind . So 
you don't have to click on the link, what this role does to secure bind in 
summary is as follows:

- Secure template from Team Cymru template 
(http://www.cymru.com/Documents/secure-bind-template.html). Please note than 
separated internal/external views are not implemented currently.
- DNSSEC for authentication,
- RPZ to whitelist/blacklist entries
- Malware domains list blackholed
- Eventual integration with MISP RPZ export
- Authoritative DNS (mostly for internal zones) Mostly as cache/forwarder but 
could be other roles.

Taking into consideration what I have already learned plus the few things above 
mentioned on GitHub (mainly the security template and malware domain blackhole 
as we do not use RPZ or Views), is there anything else that should be 
considered/added/changed/removed to/from the defaults of this role when we go 
to 

Re: Obfuscating SOA information in RPZ

[John W. Blue]

What does the complaint look like?  Is it preventing this industrial machine 
from doing its job?

John

Sent from Nine

From: Ict Security 
Sent: Nov 29, 2019 7:18 AM
To: bind-users@lists.isc.org
Subject: Obfuscating SOA information in RPZ

Dear guys,

we use RPZ zone in Bind 9 to protect some users against possible
malwares and to force Google safe search changing resolution to
Google's safe IP address server.

We have an industrial machine which, for some reason, if "complaining"
about the SOA information, visible in the additional info of the DNS
query.

Is it possible to obfuscate/remove the SOA information for a specific RPZ zone?

Thank you so much,
Frank
___
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

RE: Inquiry re: DNS over HTTPS

[John W. Blue]

Additionally, Tony Finch back on July 11th of this year suggested:

To give DoH access to clients you need a proxy such as dnsdist or doh101.

https://dotat.at/cgi/git/doh101.git
https://dnsprivacy.org/wiki/display/DP/Using+dnsdist+for+DoT+and+DoH

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Victoria Risk
Sent: Monday, November 04, 2019 12:45 PM
To: LeBlanc, Daniel James; ML BIND Users (bind-users@lists.isc.org)
Subject: Re: Inquiry re: DNS over HTTPS


On Nov 4, 2019, at 10:38 AM, LeBlanc, Daniel James 
mailto:daniel.lebl...@bellaliant.ca>> wrote:

Hello All.

I am interested in whether ISC BIND intends to directly support DNS over HTTPS 
in the near future, or whether it is expected that users will create an 
environment to accept the HTTPS request and convert it into a DNS query.

Daniel,

We do plan to develop support for both DoH and DoT (DNS over TLS) natively in 
BIND. Both will appear in development releases in 2020. We have a kb article 
that explains one way to do DoT today with stunnel 
https://kb.isc.org/docs/aa-01386.

Vicky Risk
Product Manager

___
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: Bind-Efficientip

[John W. Blue]

There is a ton of fluff on the EfficientIP website about carrier grade this and 
carrier grade that.  So it feels like to me that you are getting trapped in the 
marketing goo when you really should be asking if an IPAM solution is what your 
organization needs.



That said, IPAM software (Infoblox and Bluecat for example) is typically geared 
towards enterprise customers who are looking for granularity and the ability to 
populate metadata.  That may or may not be the right fit for you.



I would recommend that you request demo appliance and allow yourself enough 
time to fully evaluate the vendor before making a selection, if any.  You might 
find that the status quo is serving you quite well.



John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of MEjaz
Sent: Sunday, October 20, 2019 1:10 AM
To: bind-users@lists.isc.org
Subject: Bind-Efficientip

Hello all,


We are an leading ISP CYBERIA (www.cyberia.net.sa),  
we are using bind since several years, and 1000  of zones are hosted in it. 
quite ok.

As you know these days  there has been several security threats, So deciding to 
go with  Efficient iP DDI and DNS Security Solution https://www.efficientip.com/

Therefore just wanted to know if anyone have any experience with  EfficientDNS, 
and at the same time wanted to know the major difference between the both..

Please advise, Thanks in advance

Thanks,
Ejaz
Asst. Operation Director of Systems.
Cyberia SAUDI ARABIA
P.O.Box: 301079, Riyadh 11372
Phone:  (+966) 11 464 7114 Ext. 140
Mobile:  (+966) 562311787
Fax:  (+966) 11 465 4735
Website: http://www.cyberia.net.sa




___
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: DNSSEC basic information

[John W. Blue]

Tony,

Thanks for the observations!

My comments about intent and zone data size is based upon information that was 
presented at Infoblox training classes I have attended.  I would assume that 
Infoblox being Infoblox would be (mostly) accurate when it comes to developing 
a slide deck.  However, context is everything.

.local et al TLD's have forever been a burr under my saddle and I know that 
many on this list will see no objection to the use of them.  But I kill em off 
every chance I get.

John

-Original Message-
From: Tony Finch [mailto:d...@dotat.at] 
Sent: Tuesday, September 24, 2019 2:01 PM
To: John W. Blue
Cc: bind-us...@isc.org
Subject: RE: DNSSEC basic information

John W. Blue  wrote:
>
> Nothing prevents anyone from using DNSSEC internally but, as I 
> understand it, that was not the intent.

I'm a relative newcomer having only done DNSSEC for about 10 years (so I wasn't 
around until most of the design arguments were settled), but I don't remember 
seeing anyone say it wasn't intended for internal zones.

There can be some awkward things that make it much harder than signing a public 
zone, though:

  * if your internal DNS squats on a fake TLD

  * if someone says you can't use the same keys to sign internal and
external views

  * RFC 1918 reverse DNS

It would be a lot less awkward if there were a good way to distribute trust 
anchors for internal zones, but sadly there isn't.

> Additionally, if there is an obligation to validate zones internal to 
> an organization that in of itself should be a really big red flag 
> something is wrong with trust relationships.

That depends a lot on how tightly controlled your org is :-) In my fantasy 
world the DNS would serve as a convenient PKI for bootstrapping trust; but in 
the real world it's probably easier to boostrap off private x.509 trust anchors 
or even ssh certificate auth, rather than DNSSEC, sadface.

> So the nuts and bolts of enabling DNSSEC increases zone data by 30 to 
> 40%

More like a factor of 3.5x (number of records) or 10x (bytes of presentation 
format zone file) based on the cam.ac.uk zone (43k records before signing).

> not to mention the additional crypto load induced if there are 
> frequent changes.

You need to be up in the thousands of updates per second before this is a 
problem - see 
https://lists.dns-oarc.net/pipermail/dns-operations/2019-September/019205.html

> If a split horizon is in use then internal zones typically have more 
> records than external.

Yeah, private.cam.ac.uk has 350k records unsigned, but we're possibly being 
silly about DHCP placeholder records :-)

Tony.
--
f.anthony.n.finchhttp://dotat.at/ Dover, Wight, Portland, 
Plymouth, Biscay: West or southwest 5 to 7, occasionally gale 8 except in 
Biscay. Moderate or rough in Dover and east Wight, but elsewhere rough or very 
rough. Showers. Moderate or good.
___
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: DNSSEC basic information

[John W. Blue]

Anne,

Nothing prevents anyone from using DNSSEC internally but, as I understand it, 
that was not the intent.  Additionally, if there is an obligation to validate 
zones internal to an organization that in of itself should be a really big red 
flag something is wrong with trust relationships.

So the nuts and bolts of enabling DNSSEC increases zone data by 30 to 40% not 
to mention the additional crypto load induced if there are frequent changes.  
If a split horizon is in use then internal zones typically have more records 
than external.  On a zone that has a handful of records and very low QPS then a 
signed internal zone a non-issue.

As with everything, when you scale up unintended consequences of choices made 
tend to kick in.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Anne 
Bennett
Sent: Tuesday, September 24, 2019 12:46 PM
To: bind-us...@isc.org
Subject: Re: DNSSEC basic information


Evan Hunt answers Jukka Pakkanen:

> In newer releases there's also a configuration option, 
> "validate-except", which permanently disables validation below 
> specified domains. This can be used, for example, if you have an 
> internal network using a fake TLD and you want to prevent it from showing up 
> as bogus.

... and in a separate message, John W. Blue wrote:

> 1. DNSSEC was designed for external zones


I have a case where I recently had to use "validate-except" because of a domain 
(not mine) whose external view is signed but not the internal view; my resolver 
gets the internal view for that zone.

Can someone enlighten me as to why "DNSSEC was designed for external zones", 
and under what circumstances it makes sense to *not* sign an internal view?  It 
seems to me that it would be most consistent to sign both external and internal 
views.



Anne.
--
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
a...@encs.concordia.ca+1 514 848-2424 x2285
___
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

RE: DNSSEC basic information

[John W. Blue]

Jukka,

Some odds n ends in no particular order:

1. DNSSEC was designed for external zones

2. Use delv instead of dig when troubleshooting DNSSEC and play around with 
these options:

+rtrace (resolver)
+vtrace (validation)

You want to see “fully validated”.

3. Commit these values to memory so that when using delve you will know what is 
being returned:

256 = ZSK
257 = KSK

4. Always remember that the way that records are signed is linear and it will 
help with situational awareness:

A DNS record is signed by the ZSK and the ZSK is signed by KSK.  And a DSKEY is 
created by the KSK.

5. DNSSEC takes a small amount of maintenance and housekeeping to manage key 
rollovers.

Rolling a ZSK is purely an internal operation and requires no interaction with 
the outside world.  Roll monthly.
Rolling a KSK requires a new DS record to be published to the parent.  Roll 
yearly.

6. Use NSEC3.

Hope that helps!

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Monday, September 23, 2019 3:32 PM
To: Jukka Pakkanen; bind-us...@isc.org
Subject: VS: DNSSEC basic information

Already found out about 
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html, and that example 
the dnssec-enable option is now on by default…   but any usefull hints still 
gladly received 😊

Jukka

Lähettäjä: bind-users 
mailto:bind-users-boun...@lists.isc.org>> 
Puolesta Jukka Pakkanen
Lähetetty: 23. syyskuuta 2019 22:17
Vastaanottaja: bind-us...@isc.org
Aihe: DNSSEC basic information

I am finally diging in to DNSSEC, updating out BIND 9.14.5 servers to support 
it, both resolving & signing, secure zone transfers etc.

I just have read the DNSSEC Mastery by Michael W. Lucas from year 2013, and my 
question basically is, is this information from 6 years back still valid, or 
hopelessly outdated?  I do suppose in six years things have already changed a 
lot.  And while started testing some things, noticed they are not working as 
expected, as presented in the book.  Like when upgraded our servers to DNSSEC 
resolving, the only zone I can find the ad flag set is paypal.com, example 
isc.org does not show it.

Also, with current status of DNSSEC, is it still recommend/required to have 
separate authoritative & recursive servers, DNSSEC-wise?

DLV functionality seems to be dropped from the current BIND too?

And so on... would like to know how outdated this book is, what has changed 
since 2013, and also, any hints for a good DNSSEC tutorials with todays BIND 
versions.

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: BIND setup for GSLB (Global Service Load Balancing)

[John W. Blue]

Roberto,

I don’t think an F5 type open source solution exists that will give you active 
updates to DNS.

If you not need to update DNS based upon outages and just looking for DNS to 
work in general then anycast comes to mind.

John 

> On Sep 12, 2019, at 11:40 AM, Roberto Carna  wrote:
> 
> Hi people, is it possible to setup BIND in order to implement GSLB (Global 
> Service Load Balancing) between two sites ?
> 
> I need a near Active-Active scenario between two datacenters in different 
> locations, and I want to do this with an open source solution.
> 
> Thanks a lot !
> 
> Roberto
> ___
> 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

Re: rndc - sync before reload?

[John W. Blue]

Please elaborate on the technical reason why instead of being terse.

Thanks!

John

Sent from Nine

From: Anand Buddhdev 
Sent: Saturday, July 13, 2019 4:48 PM
To: John Thurston; bind-users@lists.isc.org
Subject: Re: rndc - sync before reload?

On 10/07/2019 20:08, John Thurston wrote:

Hi John,

> On a server with both static and dynamic zones, is there any reason to
> perform an:
>   rndc sync
> prior to issuing an:
>   rndc reload

No, there is no need for a sync before reload.

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

Re: rndc - sync before reload?

[John W. Blue]

I have zero experience with dynamic zones on BIND because all of ours are 
static.  That said, and since nobody else has commented, it seems like it would 
make sense to sync before reload.

The man says that sync writes out to the journal which shouldn't ever be a bad 
thing.

John

Sent from Nine

From: John Thurston 
Sent: Wednesday, July 10, 2019 1:09 PM
To: bind-users@lists.isc.org
Subject: rndc - sync before reload?

On a server with both static and dynamic zones, is there any reason to
perform an:
   rndc sync
prior to issuing an:
   rndc reload


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

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

Re: Bind9 stops responding for some clients

[John W. Blue]

Good job on the amount of troubleshooting work done so far.

Next steps should be to run tcpdump on the interface for port 53 to see what is 
happening when an outage is in progress.  What you will be looking for 
specifically is the query packet in and the response packet out.

Use the following command:

tcpdump -n -i eth0 port domain and host 172.24.67.32

Swap out eth0 for whatever you have configured and the host IP address for a 
host that is having problems.

John

Sent from Nine

From: Gregory Sloop 
Sent: Thursday, May 30, 2019 7:11 PM
To: bind-users@lists.isc.org
Subject: Bind9 stops responding for some clients

So, this is a very odd situation and I'm kind of grasping at straws here.
So, I've come to see if any of you have any good straws!

The setup.
---
Ubuntu 18.04 LTS is the distro we're running on.
All software is packaged [from the distro] - not compiled from sources.
Bind9 acting as a recursive resolver for a smallish network. 150 seats.
They're also handling DHCP and Chrony/NTP requests.
[I actually have a pair of these handling DNS/DHCP/NTP this is the master.]

They are running on a Xen/XCP VM.

The one I'm having problems is the master for several internal zones - the one 
that's working fine is the slave for those same zones. None of the zones are 
large.

Intermittently, Bind9 simply stops handling queries from *some* hosts.
Meaning, it simply times out for responses for those hosts.
Yet BIND *is* working fine for lots of other machines on the same networks. 
It's working fine doing dig queries locally on the server, and handles dns 
queries fine for lots of other machines. Yet, again, some machines simply get 
time-outs. I can't find any pattern to which machines get timeouts and which 
don't.

I've checked - no firewalls, fail2ban or the like that might be causing this.
No selinux/apparmour.
Hosts that can't do dns queries can ping the dns server fine.
[So, there's at least some network pathway to the DNS machine.]

Review of the logs for bind don't show anything that looks like a problem to me.
[But I'm not sure what keywords I ought to be looking for, in an effort to find 
symptoms/problems.]

Finally, the two bind/dhcp/ntp servers are currently running on the same Xen 
host, so if it's somehow host related, I'd expect both to have problems, but 
they don't.

Top doesn't show any CPU distress.
Processes look fine
Memory in use is far below what allocated to the machine. [1G allocated, like 
<400M used.]
Restart of BIND doesn't do anything, at least in the cases I've seen - which 
aren't all that many yet.
A restart of the whole VM does appear to fix the issue immediately.
These appear to occur every 3-5 days.
Oh, and if you simply wait, it eventually starts handling queries for all hosts 
again - but it might be a couple+ hours.

Any suggestions on things I might hunt for in the logs in an attempt to figure 
out what's happening?
Other suggestions for things to look for/consider?

TIA
-Greg
___
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: rndc and nsupdate failing to work for me

[John W. Blue]

Marc,

Regarding your rndc problem, I think you might be confusing rndc.

If rndc is invoked with no options, specifically “k”, then rndc assumes the key 
it needs is in the rndc.conf file.  If rndc.conf is not present, rndc will use 
the default rndc.key file.  That said, since rndc knows there is an 
/etc/rndc.key file but it choosing to use rndc.conf is the secret the same in 
both places?

As an option, instead of including /etc/rndc.key nothing prevents you from 
including rndc.conf.  That way you are consistent with your useage.

I personally do not use nsupdate, but I thought that key file had to be created 
by dnssec-keyen and if you opt to use “k” then the file suffix on the command 
line had to be “.private”.

Hope that helps and good hunting!

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Marc 
Chamberlin via bind-users
Sent: Wednesday, March 13, 2019 6:02 PM
To: bind-users@lists.isc.org
Subject: rndc and nsupdate failing to work for me


Hello Bind Users,

I have been working on upgrading my Bind 9.11.2 server (running on a Linux 
system, OpenSuSE Leap 15) so that I can accept DNS challenges/verification 
from/for LetsEncrypt certificates, and I am running into a wall trying to get 
nsupdate (and rndc which I wanted to use to test the server with) to work with 
the server. So I hope some kind guru here can lead me into the light cuz I am 
lost

My configuration is really not all that complicated, I am running the server on 
a firewall computer that supports other services such as web and email services 
also. I have a SOHO internal network behind the firewall computer. I have 
configured the Bind (named) server with the 3 standard views - 
localhost.resolver, internal, and external. Since I support a number of virtual 
hosts and real hosts I have quit a few zones defined for each view. For regular 
queries and things like zone transfers the server is performing OK.

That said I will show what I think are the relevant definitions from my 
configuration files, with sensitive info redacted of course, and follow on with 
questions I have -

named.conf -

There is a bunch of stuff at the beginning of this file, but I think it is 
irrelevant to this issue. Correct me if I am wrong and I will be happy to post 
it...
include "/etc/rndc.key";
 controls {
   inet * port 953
   allow { any; } keys { "rndc-key"; };
 };
  view "localhost_resolver"
 {
match-clients { localhost; };
match-destinations  { localhost; };
... more stuff here but I don't think it is relevant

  include "/etc/named.d/local/local_zones.conf";
  }
view "internal" {
match-clients  { 192.168.10.0/24; };
   match-destinations { 192.168.10.0/24; };
   recursion yes;
... more stuff here but I don't think it is relevant
include "/etc/named.d/internal/internal_zones.conf";
};
view "external" {
   match-clients  { any; };
   match-destinations { any; };
   recursion no;
... more stuff here but I don't think it is relevant
   include "/etc/named.d/external/external_zones.conf";
};

This seems pretty straightforward configuration in named.conf.  The 
configuration of a zone in the external view typically looks like this -

zone "mydomain.com" in {
file "/etc/named.d/external/master/mydomain.com";
type master;
allow-transfer { "dnsmadeeasy1"; };
also-notify { xx.xxx.xx.xxx; yyy.yyy.yy.yyy; zzz.zzz.zz.zz; };
allow-query { any; };
allow-update {
   key "letsencrypt";
};
};

And this is what is in rndc.conf -
key "rndc-key" {
algorithm hmac-md5;
secret "secretkeycodehere";
 };
options {
default-key "rndc-key";
default-server localserver;
default-port 953;
};
server localserver {
addresses   { 127.0.0.1 port 953; };
key "rndc-key";
};
server intserver {
addresses   { 192.168.10.100 port 953; };
key "rndc-key";
};
server extserver {
addresses   { xxx.yyy.zzz.aaa port 953; };
key "rndc-key";
};

Again, straightforward, and as I said normal queries do work  However when 
I use rndc to poke at it, this is what happens -
# rndc showzone mydomain.com in external
WARNING: key file (/etc/rndc.key) exists, but using default configuration file 
(/etc/rndc.conf)
rndc: 'showzone' failed: failure

I don't understand why I am getting the warning, seems like a so what since the 
keys are identical in both locations. (I couldn't figure out if it is possible 
to use an include statement instead of the key definition in rndc.conf)  As for 
the failure when I asked it to do a showzone, I don't have a clue as to why 
this is failing. Log files are not helpful (and neither is this error message 
for that matter!)

I am also experiencing problems with nsupdate in that changes I make with it 
are not persistent across a restart of the named service. To demonstrate this I 
have a file called test.txt -

debug yes
zone mydomain.com.
u

RE: BIND DNS Enable audit logs - Authoritative

[John W. Blue]

> We edit our zones manually ..

*cringe*

No wonder you are looking for audit logging!  Yikes.

Outside of DDI specific solutions like Infoblox or Bluecat, you might want to 
check out Webmin.  It logs all changes made via it's interface:

https://doxfer.webmin.com/Webmin/Webmin_Actions_Log

John
___
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: SSL cert for lists.isc.org expired on Saturday, December 29, 2018

[John W. Blue]

“It looks like you are using a System V-style OS.  BSD is waiting for you.  
Would you like some help?”

Kidding aside, Slackware is old school awesome.

;)

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Noel 
Butler
Sent: Tuesday, January 01, 2019 5:32 PM
To: bind-users@lists.isc.org
Subject: Re: SSL cert for lists.isc.org expired on Saturday, December 29, 2018


On 02/01/2019 04:48, Doug Barton wrote:
I've had LE fail after a cerbot upgrade because it grew a dependency that 
didn't automatically get installed with the upgrade.

So yes, automation good, but not perfect.

Yes likewise on the one box I could actually get certbot to run on, just 
wouldnt run on any of the slackware boxes - which are all but 1, so it too was 
quickly replaced with acme.sh which has *never* failed us.


___
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

SSL cert for lists.isc.org expired on Saturday, December 29, 2018

[John W. Blue]

nuff said, eh?

I thought that Let's Encrypt wanted to roll / revalidate SSL certs every 90 
days.  IIRC they have automation for apache and DNS tools when it comes to 
revalidation.

Good hunting!
___
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: Question about visibility

[John W. Blue]

I agree on using non-standard ports as well.

Moving SSH to a non-standard port is a perfect example of how to actually ID 
bad actors.  It follows that any host connecting to 22 is clearly traffic that 
needs to be dropped and blocked.  And if that host is blocked then any other 
connections it would attempt (eg port 80) are also blocked.  I am reluctant to 
say "one and done" but it is pretty close.

Alternatively, using PF on a BSD with this rule:

pass in on $ext_if proto tcp from any to $ext_if port ssh \
flags S/SA keep state \
(max-src-conn-rate 2/120, overload  flush global)

Will only allow 2 connections within two minutes before the host is blacklisted.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Paul 
Kosinski
Sent: Wednesday, October 24, 2018 11:24 AM
To: bind-users@lists.isc.org
Subject: Re: Question about visibility

Maybe port scanners will find open ports pretty quickly, but I've found that 
using non-standard ports is helpful in reducing traffic, at least.
For example, SSH on port 22 gets lots of SYNs but moving it elsewhere, and 
making 22 totally unresponsive discourages most such attempts. This increases 
security slightly a priori, and may also improve security by simplifying the 
firewall log(s).

When using OpenVPN over UDP, the standard port 1194 can be subject to random 
and/or attack packets. These have to be processed and rejected (since their 
HMACs etc. hopefully won't pass decryption). This won't occur in TCP mode, of 
course, but UDP tends to be more efficient, especially since TCP over TCP tends 
to clog up.

P.S. When you come right down to it, *all* computer (software) security is 
"security by obscurity", whether the obscurity of passwords, private keys, etc. 
For example, DES is no longer used because 56-bit keys are no longer obscure 
enough to hide from modern computers.


On Wed, 24 Oct 2018 13:24:41 +
Timothy Metzinger  wrote:

> There's no security in obscurity.  Automated port scanners will sweep 
> your system in a couple of seconds.
> 
> Tim Metzinger
> 
> From: bind-users  on behalf of G.W.
> Haywood via bind-users  Sent: Wednesday, 
> October 24, 2018 12:15:10 PM To: bind-users@lists.isc.org
> Subject: Re: Question about visibility
> 
> Hi there,
> 
> On Wed, 24 Oct 2018, Hardy, Andrew wrote:
> 
> > Further to the original post, as well as not creating a DNS record 
> > and "possibly" adding robot.txt with appropriate content, as 
> > discussed, I presume that if I run the http server on a personally 
> > selected unprivileged port then it is very "unlikely" the site pages 
> > will be indexed/discovered/etc surely?
> >
> > Thoughts?
> 
> A server on a non-standard port is often neglected.  Its security may 
> be less well maintained than one that is intentionally public.
> 
> That's just the sort of thing that criminals are looking for.  They'll 
> probably find it, and then they'll attack it.
> 
> --
> 
> 73,
> Ged.
> ___
> Please visit
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=02%7C01%7C%7C0b80
> 5cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb435%7C1%7C
> 0%7C636759801644561901&sdata=CqjF4k0IMJVEbFnKVPzflLNxc8LyguCF7iSbl
> AfVbLI%3D&reserved=0 m/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&d
> ata=02%7C01%7C%7C0b805cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb4
> 35%7C1%7C0%7C636759801644561901&sdata=CqjF4k0IMJVEbFnKVPzf
> lLNxc8LyguCF7iSblAfVbLI%3D&reserved=0>
> to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.isc.org%2Fmailman%2Flistinfo%2Fbind-users&data=02%7C01%7C%7C0b80
> 5cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb435%7C1%7C
> 0%7C636759801644561901&sdata=CqjF4k0IMJVEbFnKVPzflLNxc8LyguCF7iSbl
> AfVbLI%3D&reserved=0 m/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users&d
> ata=02%7C01%7C%7C0b805cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb4
> 35%7C1%7C0%7C636759801644561901&sdata=CqjF4k0IMJVEbFnKVPzf
> lLNxc8LyguCF7iSblAfVbLI%3D&reserved=0>
> 
> Tim Metzinger
> 703.963.3015
> 
___
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

RE: Zone transfer failure

[John W. Blue]

And make sure that all of your servers are sync’d to the same NTP.  That has 
burned me in the past.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bob 
Harold
Sent: Wednesday, October 17, 2018 9:16 AM
To: ampra...@gmail.com
Cc: bind-users@lists.isc.org
Subject: Re: Zone transfer failure


On Wed, Oct 17, 2018 at 9:56 AM Andreas Brandino 
mailto:ampra...@gmail.com>> wrote:
Both servers receive the NOTIFY message from NS1. What I see on the logs:

NS3:
17-Oct-2018 16:41:00.688 notify: info: client 1.1.1.1#19513/key ns1ns3_key: 
view external: received notify for zone 'myzone.com': TSIG 
'ns1ns3_key'

Notice the "view external" in the line above, compared to ns5, which got the 
notify on the internal view.  That appears to be the issue.
Try adding the IP of NS1 to the "match" list for the internal view on NS3.

--
Bob Harold

NS5:
17-Oct-2018 16:40:56.131 notify: info: client 1.1.1.1#32586/key ns1ns5_key: 
received notify for zone 'myzone.com': TSIG 'ns1ns5_key'
17-Oct-2018 16:40:56.139 notify: info: zone 
myzone.com/IN: sending notifies (serial 2018101910)

The 2nd line is missing on NS3.
At this point NS5 starts the zone copy (NS1 logs):

17-Oct-2018 16:41:01.233 xfer-out: info: client 5.5.5.5#40909/key ns1ns5_key 
(myzone.com): view internal: transfer of 
'myzone.com/IN': AXFR started: TSIG ns1ns5_key
17-Oct-2018 16:41:01.234 xfer-out: info: client 5.5.5.5#40909/key ns1ns5_key 
(myzone.com): view internal: transfer of 
'myzone.com/IN': AXFR ended

At this point NS3 does nothing.

This is not a firewall or networking problem because I can start the transfer 
manually.

Best Regards

Στις Τετ, 17 Οκτ 2018 στις 4:35 μ.μ., ο/η Bob Harold 
mailto:rharo...@umich.edu>> έγραψε:

On Wed, Oct 17, 2018 at 7:23 AM Andreas Brandino 
mailto:ampra...@gmail.com>> wrote:
Hello all,

I wonder if anyone can help me to find the cause of the problem I am currently 
having.
All servers are running on Debian and BIND 9.10.3-P4-Debian.

I have a master server and 4 slaves.
The zone is transfered from the master [ns1] to all slaves [ns3,ns4,ns5 and 
ns6].
I am also using TSIG with a different key for each server.
Moreover, the zone file refers to the internal view.

When I change the myzone.com, I always update the serial and 
I reload the zone.

The problem:
ns3 and ns4 never get the updated zone file automatically.
On the other hand, ns4 and ns5 always get the updated zone file immediately.

If I initialize the transfer manually from ns3 and ns4, I get no errors.

Here is the config:

NS1 config: (IP 1.1.1.1 - master DNS)

zone "myzone.com" {
type master;
file"/etc/bind/master/myzone.com.INSIDE";
allow-transfer { key ns1ns3_key; key ns1ns4_key; key 
ns1ns5_key; key ns1ns6_key; };
also-notify {
3.3.3.3 port 53 key ns1ns3_key;
4.4.4.4 port 53 key ns1ns4_key;
5.5.5.5 port 53 key ns1ns5_key;
6.6.6.6 port 53 key ns1ns6_key;
};
notify explicit;
notify-source 1.1.1.1 ;
};


NS3 config: (IP 3.3.3.3 - transfer fails)

   zone " myzone .com" {
file"/etc/bind/master/myzone.com.INSIDE";
type slave;
allow-update { key ns1ns3_key; };
masters { 1.1.1.1; };
allow-notify { 1.1.1.1; };
notify yes;
request-ixfr no;
};

NS5 config: (IP 5.5.5.5, successful transfer)

zone "myzone.com" {
file"/etc/bind/master/myzone.com.INSIDE";
type slave;
allow-update { key ns1ns5_key; };
masters { 1.1.1.1; };
notify yes;
request-ixfr no;
};

Do you see any errors in the above configuration that could cause this problem?

Best Regards

What you don't show is the 'match' statement for your views.  Perhaps 1 does 
not match the internal view on 3, so the notify packet hits the wrong view.  
Check the notify messages in the logs on 3, compared to 5.  Here is a typical 
notify log message:


30-Sep-2018 23:12:37.135 general: info: zone 
psych.lsa.umich.edu/IN/oncampus: notify 
from 141.211.147.150#38695: zone is up to date



Note the zone/class/view contains ".../IN/oncampus" - check the view in your 
logs.



If you cannot find the notify, you might need to turn on logging for category 
"general".  Or check routing and firewall rules if the packet is not being 
received.



--

Bob Harold


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

RE: Question about forwarder zones

[John W. Blue]

Based upon everything that I am reading it is name specific.  To wit:

".. forwarding rules apply to queries for all domain names that end in the 
domain name of the zone."

So it would follow that "example.com" would not get queries for 
"reallycool.example.com" if zone forwarding is configured correctly.  You can 
walk this out by creating a test zone and pointing at a server that you can run 
tcpdump on.

As you change the name of the zone (lvl1.example.com vs lvl2.lvl1.example.com) 
the previous queries for lvl1 that worked should stop and tcpdump should 
reflect that.

But honestly, seems like a postmortem should be done to find out why BIND had 
to be restarted unless you already know.

Good hunting!

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Cuttler, Brian R (HEALTH)
Sent: Monday, October 15, 2018 10:27 AM
To: bind-users@lists.isc.org
Subject: Question about forwarder zones


We had an issue with forward zones not resolving this morning, resolved by 
restarting DNS but prompted me to ask a question I'd been wondering about.

We have multiple zones that we forward to DNS servers we do NOT manage.

The domain names take the form

Example.org
Bar.example.org
Foo.bar.example.org
Snafu.foo.bar.example.org

Despite the fact that these are all example.org and managed by our sister 
organization the servers they forward to are often different from one another.
That is bar.example.com might forward queries to a.a.a.a and a.b.b.a but 
foo.bar.example.com might forward to c.d.a.a and d.e.b.a.

What I'm trying to say is that the parent server for a forwarded zone is not 
necessarily, and is seldom the authoritative zone for a child zone.

So it got me wondering, when I want to resolve host.snafu.foo.bar.example.org, 
where does the chain of resolution start?

I'm hoping that it is the most _specific_ domain name, rather than the least or 
random, or first find in the physical zone file.

To me most specific makes the most sense, but I haven't run across that written 
anyplace in my searches and I'd like to know if I should reorder my zones or 
should employ some other mechanism to help assure I'm hitting the 
best-forwarders/most productive forwarder zone selection I can.

Thank you,
Brian


Brian Cuttler
Network and System Administrator, ITG - Information Technology Group Wadsworth 
Center, NYS Department of Health Biggs Lab, Empire State Plaza, Albany, NY 12201
(518) 486-1697 | brian.cutt...@health.ny.gov


___
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

RE: BIND DNS problem (?)

[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: How to create an SRV record for the CSTA service

[John W. Blue]

Meh.  Don’t sweat it .. everyone has goofed in some manner at sometime or 
another.

Besides, we are team BIND!  We won't tell a-n-y-o-n-e.

;)

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of King, 
Harold Clyde (Hal)
Sent: Thursday, September 13, 2018 2:58 PM
To: Reindl Harald; Gary O'Brien; bind-users ISC
Subject: Re: How to create an SRV record for the CSTA service

OK I made mistakes. I’m sorry for wasting anyone's time, I really am. 

I was trying to see if anyone had even made an SRV record for the CSTA service. 
My presentation of the dig example was a poor choice.


-- 
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Shared Systems Services

The University of Tennessee
103C5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone : 974-1599
Helpdesk 24/7 : 974-9900

On 9/13/18, 12:30, "Reindl Harald"  wrote:



Am 13.09.18 um 18:03 schrieb King, Harold Clyde (Hal):
> You have me dead to rights on that. I was trying to make an example and 
failed. Here's my record:
> _csta._tcp.csta.example.com.   3600   IN   SRV   20   0   1040 
hostname.example.com

so why don't you just send an unaltered record instead of 3 mails?

the first two ending with a dot but missing fields, the last one seems
to have all fields but the traling dot is missing

csta.example.com. is a subdomain "csta" below example.com
is that desired?

"hostname.example.com" instead "hostname.example.com." means
"hostname.example.com.example.com"

again: don't provide mangeled informations when you need help - frankly
the only obfusction you can make es replace your domain name and ONLY
that with example.com

the first is a working example from a microsoft SIP record and now
compare it to your real setup

_sipfederationtls._tcp   3600 IN SRV 1 100 5061 sipfed.online.lync.com.
_csta._tcp.csta.example.com. 3600 IN SRV 20  0 1040 hostname.example.com





___
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

RE: Frequent timeout

[John W. Blue]

I will walk back my previous comments and just say that bandwidth may be in 
play because anytime you soak a circuit it is not good.

Take a look at this query sequence:

dns.qry.type == 28 && dns.qry.name == concured.co

Packet 42356 shows a  query for concurred.co.
Packets 42357/8 show 68.195.193.45 relaying the query to 62.138.132.21.
Packets 43015/16 show 62.138.132.21 replying with its query response to 
68.195.193.45.

And that's it.  Nothing is seen being sent back to 127.0.0.1.  At least on the 
wire.  By way of comparison, packet 161 shows 127.0.0.1 answering itself so I 
would consider the previous no response a clue.

Moving on:

Packet 48874 shows 127.0.0.1 asking for a  record again.
This time we don’t see any external communication.
Packet 87174 shows 127.0.0.1 replying with server failure.

It took nearly 25 seconds to decide upon a SERVFAIL and that is another clue.

That said, there a heaps of queries where DNS worked as expected.  I really had 
to dig for the above examples because it seems like the vast majority of the 
server failure messages either do not get a reply on the localhost or we don’t 
see the routable adapter on the server attempting to reach out to get the 
answer.  concurred.co is unique in that we see that attempt to reach out and no 
attempt.

If the traffic that 127.0.0.1 is putting on the wire does not go out I am 
thinking firewall but you may be dealing with bandwidth exhaustion exclusively 
and it is presenting itself in this manner.  Or you may have a server 
configuration issues or a server that is under powered.

Sometimes pcap's are black and white and it gives you a "here is your problem" 
answer and other times it is like this where it does not give us anything 
conclusively to work with.  Since this sever is sputtering around I would set 
about first stabilizing traffic from 127.0.0.1 going out.  You need to see 
outbound traffic hit 127.0.0.1 then hit your external adapter without missing.  
Boom, boom, boom on down the line.

Hopefully others may have better more insightful suggestions.

Good hunting!

John

-Original Message-
From: Alex [mailto:mysqlstud...@gmail.com] 
Sent: Tuesday, September 11, 2018 1:57 PM
To: John W. Blue; bind-users@lists.isc.org
Subject: Re: Frequent timeout

Hi,

On Tue, Sep 11, 2018 at 2:47 PM John W. Blue  wrote:
>
> If you use wireshark to slice n dice the pcap .. "dns.flags.rcode == 2" shows 
> all of your SERVFAIL happens on localhost.
>
> If you switch to "dns.qry.name == storage.pardot.com" every single query is 
> localhost.
>
> Unless you have another NIC that you are sending traffic over this does not 
> look like a bandwidth issue at this particular point in time.

Thanks so much. I think I also may have confused things by suggesting it was 
related to bandwidth or utilization. I see it also happen now more regularly 
too.

Can you ascertain why it is reporting these SERVFAILs?

The queries are on localhost because /etc/resolv.conf lists localhost as the 
nameserver. Is that why we can't diagnose this? This most recent packet trace 
was started with "-i any". Why would the ones on localhost be the ones which 
are failing? I'm assuming postfix and/or some other process is querying bind on 
localhost to cause these errors?
___
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

[John W. Blue]

If you use wireshark to slice n dice the pcap .. "dns.flags.rcode == 2" shows 
all of your SERVFAIL happens on localhost.

If you switch to "dns.qry.name == storage.pardot.com" every single query is 
localhost.

Unless you have another NIC that you are sending traffic over this does not 
look like a bandwidth issue at this particular point in time.

John

-Original Message-
From: Alex [mailto:mysqlstud...@gmail.com] 
Sent: Tuesday, September 11, 2018 1:19 PM
To: bind-users@lists.isc.org; John W. Blue
Subject: Re: Frequent timeout

Hi,

Here is a much more reasonable network capture during the period where there 
are numerous SERVFAIL errors from bind over a short period of high utilization.
https://drive.google.com/file/d/1UrzvB-pumVjPvlmd6ZSnHi-XVynI8y3y/view?usp=sharing

This is when our 20mbs cable upstream link was saturated and resulted in DNS 
query timeout errors. resulting in these SERVFAIL messages.

The packet trace shows multiple TCP out-of-order and TCP Dup ACK packets. Would 
these retransmits cause enough of a delay for the queries to fail?

Would someone more knowledgeable look into these packet errors for me?

It might seem obvious that we should increase the bandwidth of our link, since 
it occurs during periods of high utilization, but it doesn't occur on our other 
10mbs DIA links in the datacenter when the link is saturated.

11-Sep-2018 11:53:25.692 query-errors: info: client @0x7fc7ef343740
127.0.0.1#50821
(8cb54bfffc54eee06342d5619246d67166abc6cf.ebl.msbl.org): query failed
(SERVFAIL) for 8cb54bfffc54eee06342d5619246d67166abc6cf.ebl.msbl.org/IN/A
at ../../../bin/named/query.c:8580

11-Sep-2018 11:53:25.687 query-errors: debug 2: fetch completed at
../../../lib/dns/resolver.c:3927 for
ac949d5d947f8f5cad13e98c68bac6f284c367fd.ebl.msbl.org/A in 30.84:
timed out/success
[domain:ebl.msbl.org,referral:0,restart:6,qrysent:11,timeout:10,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

Thanks,
Alex

On Mon, Sep 10, 2018 at 12:11 PM Alex  wrote:
>
> Hi,
>
> > >> tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap
> > >>
> > >> You don't need all of the extra stuff because -s0 captures the full 
> > >> packet.
> >
> > On 06.09.18 18:42, Alex wrote:
> > >This is the command I ran to produce the pcap file I sent:
> > >
> > ># tcpdump -s0 -vv -i eth0 -nn -w domain-capture-eth0-090518.pcap 
> > >udp dst port domain
> >
> > and that is the problem. "dst port domain" captures packets going to 
> > DNS servers, not responses coming back.
> >
> > "-vv" and "-nn" are useless when producing packet capture and "-s0" 
> > is default for some time. I often add "-U" so file is flushed wich each 
> > packet.
> >
> > you can strip incoming queries by using filter
> >
> > "(src host 68.195.XXX.45 and dst port domain) or (src port domain and dst 
> > host 68.195.XXX.45)"
>
> I've generated a new tcpdump file using these criteria and uploaded it here:
> https://drive.google.com/file/d/1F0VML8yPZJbcDZTys2hXDhjzv1UaBHuV/view
> ?usp=sharing
>
> The SERVFAIL errors didn't really occur over the weekend. I believe it 
> has something to do with mail volume, link congestion/bandwidth 
> utilization.
>
> 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

RE: Frequent timeout

[John W. Blue]

So that file is full of nothing but queries and no responses which, sadly, is 
useless.

Run:

tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap

You don't need all of the extra stuff because -s0 captures the full packet.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alex
Sent: Thursday, September 06, 2018 2:54 PM
To: bind-users@lists.isc.org
Subject: Re: Frequent timeout

On Thu, Sep 6, 2018 at 3:05 PM John W. Blue  wrote:
>
> Alex,
>
> Have you uploaded this pcap with the SERVFAIL's?  I didn't have time to look 
> at your first upload but can review this one.

Thanks very much. I've uploaded the pcap file here. It's about ~100MB 
compressed, and represents about 4hrs of data, I believe.
https://drive.google.com/file/d/1KUpDoQ2zuz5ITeKuO0BhlK7JvWSUAG3B/view?usp=sharing

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

RE: Frequent timeout

[John W. Blue]

Alex,

Have you uploaded this pcap with the SERVFAIL's?  I didn't have time to look at 
your first upload but can review this one.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alex
Sent: Thursday, September 06, 2018 1:49 PM
To: c...@byington.org; bind-users@lists.isc.org
Subject: Re: Frequent timeout

Hi,

On Mon, Sep 3, 2018 at 12:45 PM Carl Byington  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Sun, 2018-09-02 at 21:54 -0400, Alex wrote:
> > Do you have any other ideas on how I can isolate this problem?
>
> Run tcpdump on the external ethernet connection.
>
> tcpdump -s0 -vv -i %s -nn -w /tmp/outputfile udp dst port domain

I've captured some packets that I believe include the packets relating to the 
SERVFAIL errors I've been receiving. Now I have to figure out how to go through 
them.

In the meantime, I've configured /etc/resolv.conf to send queries to a remote 
system of ours, and the errors have (mostly) stopped.

I also notice some traces take an abnormal amount of time. Ping times to 
google.com are less than 20ms, but this trace shows reaching the root servers 
takes 104ms:

# dig +trace +nodnssec google.com

; <<>> DiG 9.11.4-P1-RedHat-9.11.4-5.P1.fc28 <<>> +trace +nodnssec google.com 
;; global options: +cmd
.   3451IN  NS  g.root-servers.net.
.   3451IN  NS  k.root-servers.net.
.   3451IN  NS  j.root-servers.net.
.   3451IN  NS  c.root-servers.net.
.   3451IN  NS  i.root-servers.net.
.   3451IN  NS  e.root-servers.net.
.   3451IN  NS  m.root-servers.net.
.   3451IN  NS  l.root-servers.net.
.   3451IN  NS  a.root-servers.net.
.   3451IN  NS  h.root-servers.net.
.   3451IN  NS  b.root-servers.net.
.   3451IN  NS  d.root-servers.net.
.   3451IN  NS  f.root-servers.net.
;; Received 839 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
;; Received 835 bytes from 202.12.27.33#53(m.root-servers.net) in 104 ms

google.com. 172800  IN  NS  ns2.google.com.
google.com. 172800  IN  NS  ns1.google.com.
google.com. 172800  IN  NS  ns3.google.com.
google.com. 172800  IN  NS  ns4.google.com.
;; Received 287 bytes from 192.33.14.30#53(b.gtld-servers.net) in 44 ms

;; expected opt record in response
google.com. 300 IN  A   172.217.10.14
;; Received 44 bytes from 216.239.36.10#53(ns3.google.com) in 29 ms

Running the same trace again showed 129ms.

I also located this warning:
06-Sep-2018 12:03:33.304 client: warning: client @0x7f502c1d3d50
127.0.0.1#60968 (cmail20.com.multi.surbl.org): recursive-clients soft limit 
exceeded (901/900/1000), aborting oldest query

I've increased recursive-clients to 2500 but the SERVFAIL errors continue.

There are also a ton of lame-server entries, many of which are related to one 
RBL or another, as part of my postscreen config:
06-Sep-2018 13:16:50.686 lame-servers: info: connection refused resolving 
'48.167.85.209.zz.countries.nerd.dk/A/IN': 195.182.36.121#53
06-Sep-2018 13:16:50.706 lame-servers: info: connection refused resolving 
'48.167.85.209.bb.barracudacentral.org/A/IN':
64.235.154.72#53
06-Sep-2018 13:16:51.308 lame-servers: info: connection refused resolving 
'48.167.85.209.bl.blocklist.de/A/IN': 185.21.103.31#53
06-Sep-2018 13:16:54.798 lame-servers: info: connection refused resolving 
'e51dd24f684d212a7da1119b23603b0f.generic.ixhash.net/A/IN':
178.254.39.16#53
06-Sep-2018 13:16:54.799 lame-servers: info: connection refused resolving 
'f4d997d8949e6dbd30f6a418ad364589.generic.ixhash.net/A/IN':
178.254.39.16#53
06-Sep-2018 13:16:55.762 lame-servers: info: connection refused resolving 
'2.164.177.209.bb.barracudac

Re: KSK Rollover

[John W. Blue]

As I personally understand it you can ignore this notice if:

a) you are not enforcing DNSSEC validation
b) if you are running a version of BIND that supports automatic KSK updates.

John

Sent from Nine

From: Brent Swingle 
Sent: Thursday, September 6, 2018 12:36 PM
To: bind-users@lists.isc.org
Subject: KSK Rollover

I recently received an email indicating that our DNS servers are not properly 
equipped for the planned KSK Rollover that is coming.  It leads off with this 
line "On 11 October 2018, ICANN will change or "roll over" the DNSSEC key 
signing key (KSK) of the DNS root zone."

Reading through the email there are links on how to check our server setup and 
make adjustments.  My specific question to the group is in regards to one of 
the steps outlined for checking the current configuration.

This is the link that outlines the server test steps:
https://www.icann.org/dns-resolvers-checking-current-trust-anchors

This is the command that does not work and the output received:
[root@ns2 ~]# rndc secroots
rndc: 'secroots' failed: permission denied
[root@ns2 ~]#

This are the versions that I am running:
[root@ns2 ~]# named -v
BIND 9.10.2-P4-RedHat-9.10.2-5.P4.fc22


Might anyone be able to tell me what adjustment I would need to make in order 
for this command to work properly so I can look at the output file and verify 
my config?

Thanks,
___
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

[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

Re: Stopping name server abuse

[John W. Blue]

I disagree.  Put up classy default page that is smart but funny while pointing 
out that owners of the domains are morons.

So many options here!

John

Sent from Nine

From: Warren Kumari 
Sent: Jun 24, 2018 3:36 PM
To: Alex
Cc: bind-users@lists.isc.org
Subject: Re: Stopping name server abuse

Unfortunately I don't think that there is, other than the nuclear option of 
becoming authoritative and pointing them elsewhere.

That would be a jackass move though.

W

On Sun, Jun 24, 2018 at 3:30 PM Alex 
mailto:mysqlstud...@gmail.com>> wrote:
Hi,
We had a former customer who parked about 300 domains with his
registry on our server but is no longer a customer and hasn't moved
his domains. There aren't any hosts behind the domains.

Is there anything more I can do to block/prevent them from continually
querying my system outside of just redirecting them to localhost or
something?

It's not a terrible amount of traffic, but it's pretty substantial.

Unfortunately asking him nicely didn't work.
___
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
--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf
___
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: Issue with AT&T IPs?

[John W. Blue]

DNS, by design, is generally speaking agnostic when it comes to providing 
answers to DNS questions.  It would have to be a very deliberate edit to the 
"allow-query" option in the conf file to enable your construct of a "DNS 
blacklist".  In an enterprise environment this type of defensive action seems 
best played at the edge where the firewalls live based upon actionable data and 
not in a conf file.  But that is just me.

I read where a packet capture was performed but does no response include 
absence of reset packets?

What did a traceroute show?

Can you place a rule to allow unfiltered traffic in and out from one of your 
IP's for testing?

I am big fan of copying n pasting but it appears that you didn't clean it all 
up when composing this email the BIND group.  You indicate to the admins of 
quickfix8.com that quickfix8.com's servers are "refusing" the query.  So which 
is it?  No response or refusing?  Because getting refused answer is better than 
nothing at all.

In the end the issue may just resolve itself.

:D

Good hunting.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Lightner, Jeffrey
Sent: Tuesday, December 05, 2017 10:24 AM
To: bind-us...@isc.org
Subject: Issue with AT&T IPs?

We're having issues send email to a user @SIDDHAFLOWERS.COM

Investigation here shows that the issue we have is querying your name servers 
(both by name and by IP) are refusing to respond to our name servers.

Their name servers:
NS1.QUICKFIX8.COM
NS2.QUICKFIX8.COM

Our name servers:
DSWADNS1.WATER.COM
DSWADNS2.WATER.COM

We find other name servers such as those as Google are able to query their name 
servers.   Based on that I determined their name server IP (for both) is 
74.124.202.236.   However, if I attempt to reach port 53 (DNS) on that IP from 
our name servers it simply fails to connect.   Our Network Security engineer 
did a capture and shows we send packets but never get a response.

Interestingly further testing shows this is an issue from any of our AT&T 
provided IPs:
12.44.84.194
12.44.84.213
12.44.84.214
12.44.84.216
But not from separate QTS Datacenter provided IPs:
209.10.103.136
209.10.103.148

I've reached out to the folks at QuickFix and am waiting to hear back but we've 
seen a similar issue on another domain using separate name servers.Is it 
possible there is some sort of blacklist for DNS (not email) that people might 
be subscribing to that would cause them to block AT&T IPs?  We can do queries 
from our DNS to most domains but have identified these 2 as problems so suspect 
there might be others.

By the way, I can reach their mail server via command line connection to port 
25 on its IP.   The issue here is purely in querying the DNS servers which of 
course means mail programs can't determine the MX records themselves.

Last night I did see some posts suggesting commenting out query-source but 
testing that didn't do anything.   We do have our query-source setup for random 
outbound ports and I verified last night that it still works based on the test 
site for that.

Most of what I find about blacklisting is about spam blacklisting of mail 
servers not blacklisting of DNS server queries and it is the latter we are 
experiencing.


CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you

___
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: command line ID vs Wireshark transaction ID (dns.id)

[John W. Blue]

> What nameserver addresses are listed in /etc/resolv.conf?

So. 

resolv.conf has the non-RFC1918 ip addresses commented out *and* loopback is 
the only one enabled.

Lovely.  

I decided to leave it as is and retested with:

# tcpdump -n -i lo0 -s0 port domain
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes
08:50:55.837412 IP 127.0.0.1.17709 > 127.0.0.1.53: 59248+ A? www.airnav.com. 
(32)
08:50:56.019525 IP 127.0.0.1.53 > 127.0.0.1.17709: 59248 1/3/6 A 
206.125.168.131 (247)

Wireshark hex transaction id converts to decimal for a successful match.

Thanks for the help Mark!

John
___
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: command line ID vs Wireshark transaction ID (dns.id)

[John W. Blue]

Forgot to add a screenshot:

http://www.rfmapping.com/transactionid.png

Thanks!

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue
Sent: Thursday, August 10, 2017 6:07 PM
To: bind-users@lists.isc.org
Subject: command line ID vs Wireshark transaction ID (dns.id)

I have been trying to correlate the ID value returned via a command line query 
here:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60796

to a "transaction ID" found in wireshark when it dissects the packet found here:

Transaction ID: 0x1aa6

without any success because 0x1aa6 does not hex > dec convert to 60796.


I am clearly missing something here because wireshark can tie the query and 
response together into a stream.

Thoughts?

John



___
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

command line ID vs Wireshark transaction ID (dns.id)

[John W. Blue]

I have been trying to correlate the ID value returned via a command line query 
here:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60796

to a "transaction ID" found in wireshark when it dissects the packet found here:

Transaction ID: 0x1aa6

without any success because 0x1aa6 does not hex > dec convert to 60796.


I am clearly missing something here because wireshark can tie the query and 
response together into a stream.

Thoughts?

John



___
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: designing the DNS from the scratch

[John W. Blue]

Abdulhadi,

Honestly, I think that a design spec of getting DNS responses in 3ms across the 
board is unrealistic.  My initial MX query for litc.ly took 367ms:

;; ADDITIONAL SECTION:
exmail.litc.ly. 14400   IN  A   197.215.159.227
dns2.lttnet.net.21600   IN  A   62.240.36.40
dns3.lttnet.net.21600   IN  A   62.240.36.40

;; Query time: 367 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jul  9 12:50:58 2017
;; MSG SIZE  rcvd: 144

Additionally, given the operational environment in which you exist I would 
recommend that you strive for just providing good DNS services in general.

Good luck.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Abdulhadi Ettwejiri
Sent: Sunday, July 09, 2017 2:32 AM
To: bind-users@lists.isc.org
Subject: designing the DNS from the scratch

HI,

we are ISP company , we are providing Internet to our customer, Recently one of 
our VIP customer ask for DNS service, and need the response time 3msec, we 
don't have enough knowledge of DNS,

1-To achieve the goal of my customer about the response time I need to know 
what's the optimal design solution for DNS ( Authoritative or Recursive(,or 
there is other design.

2-  If the answer in the previous question an "authoritative", is there any 
registration & technical requirements for so (i.e. ccTLD, ...   )


Best regards

Abdulhadi Ettwejiri
Technical Support Department
[Description: LITC-Logo03]
Zawia Street inside GPTC building  | Tripoli | Libya |
*  + 218 91 9994265* 
abdulhadi.ettwej...@litc.ly
* + 218 21 3600234 *  
http://www.litc.ly
7 + 218 21 361

___
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: Delegation not found at parent

[John W. Blue]

Patrik,

The issue here is that you are using pingdom.com to check to see if there is a 
subzone called “ns1” to which there is not.  So the answer that you got is 
correct.

Take “ns1” off and rerun the test.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Patrik 
Laszlo
Sent: Sunday, June 11, 2017 8:01 PM
To: bind-users@lists.isc.org
Subject: Delegation not found at parent


Ciao!

How are you?

I have my ns1.namesystem.tk

It works, but when I test it 
(http://dnscheck.pingdom.com/?domain=ns1.namesystem.tk)

I get this error:

What is this and how can I resolve. it?

Delegation not found at parent.

No delegation could be found at the parent, making your zone unreachable from 
the Internet.
[Image removed by sender.]

Not enough nameserver information was found to test the zone ns1.namesystem.tk, 
but an IP address lookup succeeded in spite of that.
___
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: Weird issue with bind & router

[John W. Blue]

Chris,

First, what a strange problem to have.

You really need to spend some time capturing the traffic placed on the wire via 
tcpdump and then slicing it up for clues with wireshark.

If you set a continuous ping to the router that would be a good timestamp that 
you can use to correlate as a marker.  When it stops responding look at all of 
the other traffic around that time.

I doubt that it will be BIND but stranger things have happened before!

Good luck.

John

Sent from Nine

From: Chris Serella 
Sent: May 25, 2017 9:24 AM
To: bind-users@lists.isc.org
Subject: Weird issue with bind & router


I run a small dev system on my home network, housing dns etc all under the one 
server.

System: ubuntu16.04 server, ispconfig etc etc etc, you get the idea.

Anyway, the problem i am having comes down to the router rebooting (is it 
crashing? I cant tell) every time bind starts/restarts. This ordinarily wouldnt 
be an issue, DNS rarely changes so the service does not need restarting but the 
problem occurs on system boot too.

The router in question is a Plusnet Hub One which I believe is actually a 
repackaged BT Hub 5. The "server" is an ACER AX3300 desktop with ubuntu server 
installed.

Troubleshooting was difficult as i couldnt isolate what it was until i went 
over to ISPConfig for assistance, they informed me that a DNS reload on their 
software simply saves data to files and initiates a service restart.

With this information to hand I made no changes to the DNS in ISPConfig, 
instead i opened a terminal and tunnels into the server and issued a bind9 
restart from there.

Sure enough the problem reared its ugly little head, The ssh session dropped 
out and looking over to the router i could see it was going through its power 
cycle. To be sure this wasn't some freakishly well timed coincidence, I 
completed the steps several times more (3) all with the same result.
___
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: Providing GeoIP information for servers

[John W. Blue]

>From the it-could-be-worse department:

https://arstechnica.com/tech-policy/2016/08/kansas-couple-sues-ip-mapping-firm-for-turning-their-life-into-a-digital-hell/

I am more a fan of continental geolocation accuracy when it comes to IP 
addresses.

John

From: bind-users  on behalf of Mark Andrews 



AFAIK Maxmind et al don't lookup LOC records.  That being said if
enough people published LOC records they might start.

For Google you can update the location using a app which uses the
phone's GPS.

> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

Re: RDRAND, etc [ wasRe: Slow zone signing with ECDSA

[John W. Blue]

TL;DR

Sent from Nine

From: Timothe Litt 
Sent: Apr 20, 2017 7:34 AM
To: bind-users@lists.isc.org
Subject: Re: RDRAND, etc [ wasRe: Slow zone signing with ECDSA


On 20-Apr-17 01:26, Paul Kosinski wrote:

"The tinfoil hat brigade in some distributions has resisted using them,
fearing some conspiracy to provide not-so-random numbers."

I think the NSA *did*, in fact, compromise the "Dual Elliptic Curve
Deterministic Random Bit Generator" and paid RSA to make it the default
in one of their products -- https://en.wikipedia.org/wiki/Dual_EC_DRBG.




My comment was specifically directed to the RDRAND source for /dev/*random.  
The point is that even if the source were somehow compromised, it is mixed with 
other sources using one-way algorithms.   You can search for the full 
discussions; it's by no means simple to envision a scheme where compromising 
RDRAND as a source to /dev/*random is effective after the mixing with other 
sources/whitening.  Merge entropy from multiple machines (e.g. entropybroker), 
and it's more challenging.

On the other hand, if you have legitimate worries about being an attractive 
target - or just are in to conspiracy theories:

There are far more straightforward ways to attack hardware.   Get to a 
microcode patch mechanism & target password prompts.   Or introduce floating 
point math errors in specific computations.  Use "unpredictable" bits as covert 
channels.  For higher bandwidth, see the papers on how forcing cache conflicts 
can produce a high bandwidth covert channel.  Harvest data *before* it's 
encrypted.  Why not attack the AES acceleration instructions?  Detect use of 
the compare instructions in code that tests for randomness and fudge the test 
results.  There are papers on introducing hardware monitors that can be 
concealed at the foundries.  Use power consumption to send data back through 
the power lines - or RF.  (Is your machine room in a double Faraday cage with 
interlocking doors?  Or do bits leak out when you open the door?  What?  No 
cage?)  Do your DRAMs have data transmitters?  Could your power supply 
capacitors hide a microcomputer?  There's a lot you *can* worry about.

Software is an easier vector - why not duplicate ISC's signing keys and send 
you a different version of BIND?  Open source says you CAN read and inspect all 
the code that you get for subtle security flaws.  Do you?  Really?  Or do you 
just trust the people at ISC?  Breaking ONE key is a whole lot easier than 
attacking everyone's encrypted data.

The easiest vector is the oldest - compromise the people.  Snowden, Manning, 
etc... And phish - maybe even you.

Then ask, "what's the alternative"?  You can build your own hardware - if you 
have the expertise.  After all, those DIY plans for RNGs on the internet could 
have been tweaked by your favorite government agency.  But don't stop with the 
hardware RNG - build your own CPU from components that you fabricate yourself.  
And memory.  And IO.  And routers.  And... In your own foundry - using tooling 
that you developed (it can be booby-trapped too.)  When you package your chips 
- you are making your own packages, right?...  And testing the encapsulant for 
nanoprobes?  Better make that too.

You can decide to trust someone else - the USB key or SSL accelerator, or HSM, 
or auditors and software vendors or your in-house staff, or ... (

You can hope that the penetration attacks are diverse, and run all your 
computations on 15 wildly different platforms and compare the results.  Not on 
one system, of course - the comparator/voter could be compromised.  Pay several 
people to develop different versions of your code - remember, it's not just 
hardware.  Or just build a truly secure system - the one with no I/O, no power, 
and no physical access.

If you're a *very* high value target, you may want to exploit all the 
countermeasures that you can afford.

You still need to trust someone.  Or someone trusts you.

Most people (and institutions) selectively apply the reasonable countermeasures 
that they can reasonably afford, balancing cost against the threat to them.  Do 
the basic things like taking care of your people, audits, modest key lifetimes, 
secure storage for important keys, physical access controls - and did I mention 
- backups?

Given all that - are the CPUs' random sources sufficiently likely to be 
compromised that excluding them as one of the inputs to the OSs' entropy pools 
is rational?  Even if true, are the weaknesses at the system level cheap enough 
to exploit that YOU are a worthwhile target?  (Contrary to fiction, attackers 
do not have unlimited budgets/resources.)  How does that compare to the 
business lost when your webserver/DNS/email goes unresponsive due to a lack of 
entropy?

Considering what I know (and what I know I don't know), I don't put using 
RDRAND for an input to /dev/*random very high on my worry list - and I think 
that the distributions that do qualify for the ov

Re: bind-dyndb-ldap integration

[John W. Blue]

The "alternative facts" are that it never happened.

Even if did we wouldn't tell anyone.

;)

John

Sent from Nine

From: Hika van den Hoven 
Sent: Mar 24, 2017 11:10 PM
To: bind userlist
Subject: Re: bind-dyndb-ldap integration


Hoi Hika,

Sorry for my initial double post.
___
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: Graphing BIND 9.11/9.10 Queries

[John W. Blue]

Daniel,

Thanks for sharing.  I like the HTTP statistics channel but trying slice up the 
XML has been challenging.  Going to be checking this combo out.

John

Sent from Nine

From: Daniel Stirnimann 
Sent: Jan 19, 2017 8:19 AM
To: bind-users@lists.isc.org
Subject: Re: Graphing BIND 9.11/9.10 Queries

Apart from DSC which has been mentioned here, we are also using munin
(www.munin-monitoring.org)

Shumon Huque has written a python plug-in for munin which retrieves the
data from BIND statistics server (via localhost HTTP requests).

https://github.com/shuque/bind9stats

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

Re: Test, please ignore

[John W. Blue]

Ignoring level currently at 100% of its original rated performance, beginning 
to throttle up to 104% but doing so under computer control.

Sent from Nine

From: John Anderson 
Sent: Nov 20, 2016 11:43 PM
To: Dan Mahoney ;bind-us...@isc.org
Subject: RE: Test, please ignore

Ignore successful.

John A.



Sent from my T-Mobile 4G LTE Device


 Original message 
From: Dan Mahoney 
Date: 2016/11/20 21:38 (GMT-07:00)
To: bind-us...@isc.org
Subject: Test, please ignore

Sorry for the noise
___
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

RE: BIND/Control Panel/FreeBSD

[John W. Blue]

JCSL,

Personally, my default choice for an OS is always FreeBSD first but let's be 
pragmatic.  BSD 10.x changed drastically in many ways under the hood and 
control panel authors found the cost to benefit ratio too high to keep 
supporting FreeBSD.  Assuming there is a really good reason why the choice for 
cPanel was made (support staff's knowledge/skill/ability of the software) is 
the choice of an OS that much of a project blocker?

When the hosting software breaks, is your team able to handle *anything* that 
come up?  Especially if the software was hacked and slogged into place?

The laws of unintended consequences have a very bad habit of asserting 
themselves at the least opportune time.  Good project and change management 
considerations in the beginning will go a long ways in preventing pain and 
suffering should the worst happen.

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Juan 
Carlos Sanchez-Leanos
Sent: Monday, November 14, 2016 7:03 PM
To: bind-users@lists.isc.org
Subject: BIND/Control Panel/FreeBSD


Hello,

We are planning to run BIND on a FreeBSD server. We planned to use CPANEL but 
is no longer available for FreeBSD. Do you have any other recommendation?

Thanks in advance.

JCSL

--
Open WebMail Project (http://openwebmail.org)

___
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

RE: ThreatSTOP BIND DNS Firewall Available

[John W. Blue]

So an item of note that I noticed is that the "quick start" guide:

http://www.threatstop.com/sites/default/files/threatstop_quickstart_guide.pdf

is more about getting the ThreatSTOP interface configured than an actual BIND 
DNS server.  It might be the day that I am having but it sure was a slog to 
read through it.  It also may be due to tunnel vision as the biggest question 
that I had was how does this service actually get enabled on BIND.  For anyone 
that is curious, the config of a BIND server can be found here:

http://dochub.threatstop.com/pages/viewpage.action?pageId=5079062

Personally, I prefer to zone transfer a blacklist but that is just me due to 
extra chatter/leakage/yadda-yadda-yadda.  I also found it interesting that 
while the trial signup page is HTTPS, if you want to upload a logfile for 
analyzing, that URL is just HTTP:

http://www.threatstop.com/checkip
http://www.threatstop.com/checklogs
http://www.threatstop.com/sinkhole

I know that HTTPS is not the end all, be all but common guys you are a security 
company.  As the phrase goes, "perception is reality" and something about 
having good form .. 

John

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Matt 
Foster
Sent: Thursday, October 06, 2016 11:40 AM
To: bind-users@lists.isc.org
Subject: ThreatSTOP BIND DNS Firewall Available

Hi All, just wanted to let you know that ThreatSTOP's DNS Firewall for BIND has 
just been released and evaluations are available at the below link, we would 
like to invite you to test it out. 

https://www.threatstop.com/index.php?page=index&action=trial

DNS Firewall policies can be custom created, all driven from a live threat 
intel database pulled from over 50 sources as well as our own security 
research. 

Multiple responses can be configured within the policies and a high level of 
customization is available within reports and alerting. 

Fair warning I work at ThreatSTOP 

There is no cost or commitment to evaluate the solution, we welcome market 
feedback. 

m...@threatstop.com
www.threatstop.com 





--
View this message in context: 
http://bind-users-forum.2342410.n4.nabble.com/ThreatSTOP-BIND-DNS-Firewall-Available-tp3027.html
Sent from the Bind-Users forum mailing list archive at Nabble.com.
___
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

Re: forwarder (YES/NO)

[John W. Blue]

Pol,

You can "audit" your traffic by getting a pcap via tcpdump and then analyzing 
it in wireshark.  Packets don't lie.

John

Sent from Nine

From: Pol Hallen 
Sent: Sep 21, 2016 2:35 PM
To: bind-users@lists.isc.org
Subject: Re: forwarder (YES/NO)

hello again!

> try running dig +trace  and see how fast it runs. It should return
> in about same time as BIND does (when it doesn't have anything in cache).

; <<>> DiG 9.10.3-P4-Debian <<>> +trace @192.168.1.212 yahoo.it
; (1 server found)
;; global options: +cmd
.   518367  IN  NS  d.root-servers.net.
.   518367  IN  NS  g.root-servers.net.
.   518367  IN  NS  e.root-servers.net.
.   518367  IN  NS  h.root-servers.net.
.   518367  IN  NS  b.root-servers.net.
.   518367  IN  NS  c.root-servers.net.
.   518367  IN  NS  a.root-servers.net.
.   518367  IN  NS  l.root-servers.net.
.   518367  IN  NS  i.root-servers.net.
.   518367  IN  NS  m.root-servers.net.
.   518367  IN  NS  k.root-servers.net.
.   518367  IN  NS  j.root-servers.net.
.   518367  IN  NS  f.root-servers.net.
.   518396  IN  RRSIG   NS 8 0 518400
2016100417 2016092116 46551 .
tZptpyBClVtkAbyo4NOR2MgHDoq67TlImcBVzZORhn7C2c557prmG42J
sSPD8aZmisk3bbUJbmqFVFB/M2y/O4zjw3jBf42ujHce99VD3xCeJuk7
boGW356J6c7JaApB02GRf3SGQIv7x6MVyBmGeKxAosEePlbfjg/8NPEY +y0=
;; Received 397 bytes from 192.168.1.212#53(192.168.1.212) in 2 ms

it. 172800  IN  NS  a.dns.it.
it. 172800  IN  NS  m.dns.it.
it. 172800  IN  NS  r.dns.it.
it. 172800  IN  NS  dns.nic.it.
it. 172800  IN  NS  nameserver.cnr.it.
it. 86400   IN  NSECitau. NS RRSIG NSEC
it. 86400   IN  RRSIG   NSEC 8 1 86400
2016100417 2016092116 46551 .
LL0eXWf22Lhhi5C0P+PX446JQH+GwCFhxU7tkUUF9wyG+pQ0eDCnpTu0
vm0ww/3YycmNJwlF3IHJmLIh2l7htSW6G/o2/ozNbZU6RF9pMhKxQNrJ
aE6hf4L+Ka1N5uNstgJzrE6pV9ouXOJmL0Epoa3gUnbSZcFHH5QrKbu6 AfQ=
;; Received 545 bytes from 192.58.128.30#53(j.root-servers.net) in 577 ms

yahoo.it.   10800   IN  NS  ns2.yahoo.com.
yahoo.it.   10800   IN  NS  ns1.yahoo.com.
yahoo.it.   10800   IN  NS  ns5.yahoo.com.
yahoo.it.   10800   IN  NS  ns7.yahoo.com.
yahoo.it.   10800   IN  NS  ns3.yahoo.com.
;; Received 136 bytes from 194.0.16.215#53(a.dns.it) in 136 ms

yahoo.it.   300 IN  A   106.10.212.24
yahoo.it.   300 IN  A   98.137.236.24
yahoo.it.   300 IN  A   77.238.184.24
yahoo.it.   300 IN  A   212.82.102.24
yahoo.it.   300 IN  A   74.6.50.24
yahoo.it.   86400   IN  NS  ns3.yahoo.com.
yahoo.it.   86400   IN  NS  ns2.yahoo.com.
yahoo.it.   86400   IN  NS  ns1.yahoo.com.
yahoo.it.   86400   IN  NS  ns4.yahoo.com.
yahoo.it.   86400   IN  NS  ns5.yahoo.com.
;; Received 380 bytes from 68.180.131.16#53(ns1.yahoo.com) in 173 ms

same problem... bind is too slow...

the situation change (very fast) if I use bind like resolver

forwarders {
8.8.8.8;
}

I don't understand why without resolver my bind is so slow... how I can
audit the problem?

thanks! :-)

>> but testing 127.0.0.1, bind keep also 4000/5000ms to resolve a query
>
>
>> forwarders {
>> 127.0.0.1;
>> }
>
> do you forward to yourself???

unfortunately looking for bind on internet there're many wrong howto :-/

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

Re: Error running Configure with OpenSSL 1.1.0 and BIND 9.11.0rc1

[John W. Blue]

Heh.  I did say "personally" and for me being locked out of doing what I want 
to do when I want to do it really helps me decide between something that is 
useful or junk.  And besides, I am cheap.



As an aside .. I remember I went into coworkers office for the first time.  It 
was like a small shrine to Steve Jobs and all things Apple.  There was even 
these small bonzi trees all over the place.  lol.  I had such a mental 
over-the-top-roll of the eyes that I just kind of stood there looking around.

That poor soul.

At least he seemed happy.

Sent from Nine<http://www.9folders.com/>

From: Vinícius Ferrão 
Sent: Aug 30, 2016 11:36 PM
To: John W. Blue
Cc: bind-users@lists.isc.org
Subject: Re: Error running Configure with OpenSSL 1.1.0 and BIND 9.11.0rc1

Unnecessary hate.

OS X is a pretty standard Unix and it's POSIX certified instead of Linux for 
example.

BIND9 simply does not compile with OpenSSL 1.1 yet.

On Aug 31, 2016, at 01:20, John W. Blue 
mailto:john.b...@rrcic.com>> wrote:

I personally avoid all Apple products like the plauge.  Sadly, a iPhone 6s was 
foisted upon me by my place of employment.  Piece of junk.  Hate it.

achem.

Surely you can find some normal hardware to install unix on and then BIND, 
right?  Or.  How about throwing up a VM on the Mac and using that to do testing 
inside of as opposed to the base OS?

Failing all of that have you tried installing something that is not an RC?

John

Sent from Nine<http://www.9folders.com/>

From: James Brown via bind-users 
mailto:bind-users@lists.isc.org>>
Sent: Aug 30, 2016 11:04 PM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: Error running Configure with OpenSSL 1.1.0 and BIND 9.11.0rc1

System is a Mac mini (late-2009) running a new install of Mac OS X 10.11.6.

Installed OpenSSL 1.1.0 using:
./Configure --prefix=/usr/local shared darwin64-x86_64-cc 
enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3
make depend
make test
sudo make install

No problems encountered. Then I tried to install BIND 9.11.0rc1 with:

./configure --with-atf

It failed with:

checking for sched_yield... yes
checking for pthread_yield... no
checking for pthread_yield_np... yes
checking for sysconf... yes
checking for libtool... no
checking for OpenSSL library... using OpenSSL from /usr/local/lib and 
/usr/local/include
checking whether linking with OpenSSL works... yes
checking whether linking with OpenSSL requires -ldl... unknown


Can anyone help me with this?

Thanks,

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

bind-users mailing list
bind-users@lists.isc.org<mailto: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

Re: Error running Configure with OpenSSL 1.1.0 and BIND 9.11.0rc1

[John W. Blue]

I personally avoid all Apple products like the plauge.  Sadly, a iPhone 6s was 
foisted upon me by my place of employment.  Piece of junk.  Hate it.

achem.

Surely you can find some normal hardware to install unix on and then BIND, 
right?  Or.  How about throwing up a VM on the Mac and using that to do testing 
inside of as opposed to the base OS?

Failing all of that have you tried installing something that is not an RC?

John

Sent from Nine

From: James Brown via bind-users 
Sent: Aug 30, 2016 11:04 PM
To: bind-users@lists.isc.org
Subject: Error running Configure with OpenSSL 1.1.0 and BIND 9.11.0rc1

System is a Mac mini (late-2009) running a new install of Mac OS X 10.11.6.

Installed OpenSSL 1.1.0 using:
./Configure --prefix=/usr/local shared darwin64-x86_64-cc 
enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3
make depend
make test
sudo make install

No problems encountered. Then I tried to install BIND 9.11.0rc1 with:

./configure --with-atf

It failed with:

checking for sched_yield... yes
checking for pthread_yield... no
checking for pthread_yield_np... yes
checking for sysconf... yes
checking for libtool... no
checking for OpenSSL library... using OpenSSL from /usr/local/lib and 
/usr/local/include
checking whether linking with OpenSSL works... yes
checking whether linking with OpenSSL requires -ldl... unknown


Can anyone help me with this?

Thanks,

James.
___
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: OPenssl 1.1 and Bind

[John W. Blue]

Doctor,

I enjoyed how http://www.gizoogle.net/textilizer.php adjusted your sig:

Member - Liberal International
God, Queen n' ghetto dag! Never Satan Prezzy Republic! Beware AntiChrist 
rising!
Look at Psalms 14 n' 53 on Atheism
Time fo' tha USA ta hold a referendum on its rehood n' vote ta dissolve!!

I will leave it open to interpretation as to if it was improved.

:D

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of The 
Doctor
Sent: Wednesday, August 17, 2016 9:14 AM
To: comp-protocols-dns-b...@isc.org
Subject: OPenssl 1.1 and Bind

Question, Is Bind openssl 1.1 ready?

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware 
AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism Time 
for the USA to hold a referendum on its republic and vote to dissolve!! 
___
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

Re: Questions on how to setup Reverse DNS in bind 9

[John W. Blue]

Ken,

You typically will not be delegated reverse DNS.  Honestly, I would contact 
godaddy support directly and see if they can adjust it for you.  As in, not on 
your server directly but either tell you how to do it in a control panel on 
your side of the fence or they just do it from their side.

Best regards,

John

Sent from Nine

From: Spork Schivago 
Sent: Jul 17, 2016 9:24 PM
To: bind-users@lists.isc.org
Subject: Questions on how to setup Reverse DNS in bind 9

Hello,

I'm new to operating a website and I'm leasing a virtual private server (VPS) 
from GoDaddy.   I'm paying for cPanel / WHM as well.   It's running CentOS 6.8 
Final.  I'd like to setup reverse DNS but I'm having trouble.   I'm not 100% 
sure how to do it.   I have my hostname, 
franklin.jetbbs.com   and there's two IP addresses 
assigned to that hostname, 104.238.117.105 and 132.148.11.44.   I was trying to 
setup a round robin kinda thing but I don't think I set it up correctly.

Anyway, I have ns1.jetbbs.com which has the IP of 
104.238.117.105   and then I have ns2.jetbbs.com that 
has the IP address of 132.148.11.44.   I wanted to know if someone could look 
over what I have so far and let me know if it's correct and how I should 
proceed.

So, in the /var/named directory, I create a file called: 
0.117.238.104.in-addr.arpa

The contents of 0.117.238.104.in-addr.arpa are as follows:
$TTL 1D
@   IN SOA  ns1.jetbbs.com. 
spork.jetbbs.com. (
2016071705  ; serial
1D  ; refresh
1H  ; retry
1W  ; expire
3H ); minimum

0.117.238.104.in-addr.arpa.IN  NS  
ns1.jetbbs.com.
0.11.148.132.in-addr.arpa. IN  NS  
ns2.jetbbs.com.

104 IN  PTR franklin.jetbbs.com.
44  IN  PTR franklin.jetbbs.com.


Does that look correct?   If not, how should I change it?   If so, what's the 
next step?   Thank you for your help!

Sincerely,
Ken
___
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: Testing

[John W. Blue]

Marco

Sent from Nine

From: Dan Mahoney 
Sent: Jun 24, 2016 6:28 PM
To: bind-us...@isc.org
Subject: Testing

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

RE: UDP Packet Hack

[John W. Blue]

(1)   Does "dig" get its UDP packets from "named" server?



Yes.



tcpdump -n -i lo0 port domain



$ dig www.allpowerlabs.com



20:36:28.073280 IP 127.0.0.1.10588 > 127.0.0.1.53: 18890+ A? 
www.allpowerlabs.com. (38)

20:36:28.210557 IP 127.0.0.1.53 > 127.0.0.1.10588: 18890 1/3/3 A 75.119.212.174 
(166)
___
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: Issues resolving outlook.office365.com

[John W. Blue]

>These were being blamed on "the network".

Nothing can be blamed on the network without a client pcap.  Otherwise it is 
just a bunch of hand waving and hot air.  Show me the money.

;)

John
___
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: ISC considering a change to the BIND open source license

[John W. Blue]

>This change will not automatically ensure that commercial vendors modifying 
>BIND will support ISC, but it will at least communicate that this would be 
>appropriate.

This.
___
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: New type of DDoS? Anyone saw it?

[John W. Blue]

Apologies.  The intent is to drop inbound  queries from the internet.

Sent from Nine<http://www.9folders.com/>

From: Mark Andrews 
Sent: May 16, 2016 3:41 PM
To: John W. Blue
Cc: bind-users@lists.isc.org
Subject: Re: New type of DDoS? Anyone saw it?


In message , "John W. Blue" 
writes:
>
> Hello Marek,
>
> Do you have an IPv6 assignment?  If not, there is really no need to even
> be resolving  records.  An overly simplistic description of a
> potential solution could be to just drop the incoming  request via
> its hex value in much the same way rate limiting is done for the "any"
> query:
>
> -hex-string '|FF0001|'
>
> I don't know off hand what the hex value for  is but it should not be
> too hard to find.
>
> John

Just dropping  queries is a bad idea as most machines actually
have a  addresses (loopback and linklocal) so just about every
application makes  queries.  If you drop  queries you slow
up every address lookup in your network.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: New type of DDoS? Anyone saw it?

[John W. Blue]

Hello Marek,

Do you have an IPv6 assignment?  If not, there is really no need to even be 
resolving  records.  An overly simplistic description of a potential 
solution could be to just drop the incoming  request via its hex value in 
much the same way rate limiting is done for the "any" query:

–hex-string '|FF0001|'

I don't know off hand what the hex value for  is but it should not be too 
hard to find.

John

Sent from Nine

From: Marek Królikowski 
Sent: May 16, 2016 10:04 AM
To: bind-users@lists.isc.org
Subject: New type of DDoS? Anyone saw it?

Hello,
Today i saw my bind eat almost 90% of RAM when i check logs I find
interesting DDoS on my DNS Cluster today:
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: query: 323.016.231.212
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: slip response to
8X.1X0.33.0/24 for . IN   ()
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: query: 235.326.031.064
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: drop response to
8X.1X0.33.0/24 for . IN   ()
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: query: 331.206.372.214
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: slip response to
8X.1X0.33.0/24 for . IN   ()

Looks like IN  query about wrong IPv4 address... i got almost 5000/sec
Anyone saw this too?

Best Regards
Marek


___
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

RE: Intermittent Issues Resolving Microsoft Hostnames

[John W. Blue]

I ran several digs using:


dig @ns1-prodeodns.glbdns.o365filtering.com. A 
zulily-com.mail.protection.outlook.com. +short​


without error.  As mentioned previously by Mark Andrews:


> SERVFAIL usually means that the server is configured for the zone
> but doesn't have a current copy.


You gave a snip of the error that is logged, but you might also consider 
pulling a tcpdump to see both sides of the actual conversation.  It might 
provide additional insight.


John



From: bind-users-boun...@lists.isc.org  on 
behalf of Rob Heilman 
Sent: Wednesday, May 4, 2016 1:02 PM
To: bind-users@lists.isc.org
Subject: Intermittent Issues Resolving Microsoft Hostnames

We run BIND 9.9.5-9 on Debian x86_64 to support a moderately sized email 
hosting system.  System info listed at the end of this message.  We are seeing 
intermittent but frequent issues resolving Microsoft records.  The hostnames 
are usually in the form of 
*.mail.protection.outlook.com or 
*.mail.eo.outlook.com.  They range from 
k-12/university organizations, small businesses, to large commercial companies. 
 Some examples follow:

03-May-2016 09:16:48.001 query-errors: debug 1: client 10.10.10.95#44080 
(zulily-com.mail.protection.outlook.com):
 query failed (SERVFAIL) for 
zulily-com.mail.protection.outlook.com/IN/A
 at query.c:7004
03-May-2016 09:16:48.002 query-errors: debug 2: fetch completed at 
resolver.c:3074 for 
zulily-com.mail.protection.outlook.com/A
 in 0.67: failure/success 
[domain:mail.protection.outlook.com,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]

04-May-2016 09:32:38.498 query-errors: debug 1: client 10.10.10.95#44080 
(hanes-com.mail.protection.outlook.com):
 query failed (SERVFAIL) for 
hanes-com.mail.protection.outlook.com/IN/A
 at query.c:7004
04-May-2016 09:32:38.498 query-errors: debug 2: fetch completed at 
resolver.c:3074 for 
hanes-com.mail.protection.outlook.com/A
 in 0.004677: failure/success 
[domain:mail.protection.outlook.com,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]

04-May-2016 12:47:12.935 query-errors: debug 1: client 10.10.10.95#44080 
(pitt-edu.mail.protection.outlook.com):
 query failed (SERVFAIL) for 
pitt-edu.mail.protection.outlook.com/IN/A
 at query.c:7004
04-May-2016 12:47:12.935 query-errors: debug 2: fetch completed at 
resolver.c:3074 for 
pitt-edu.mail.protection.outlook.com/A
 in 0.85: failure/success 
[domain:mail.protection.outlook.com,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]

04-May-2016 12:47:30.918 query-errors: debug 1: client 10.10.10.96#48950 
(mdfoodbank-org.mail.eo.outlook.com):
 query failed (SERVFAIL) for 
mdfoodbank-org.mail.eo.outlook.com/IN/A
 at query.c:7004
04-May-2016 12:47:30.918 query-errors: debug 2: fetch completed at 
resolver.c:3074 for 
mdfoodbank-org.mail.eo.outlook.com/A
 in 0.78: failure/success 
[domain:mail.eo.outlook.com,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]

I have added config statements to send query-errors to dedicated files and 
increased debugging to 10 on that channel.  The referenced sections of 
resolver.c and query.c are as follows:

resolver.c

fctx_try(fetchctx_t *fctx, isc_boolean_t retrying, isc_boolean_t badcache) {
isc_result_t result;
dns_adbaddrinfo_t *addrinfo;

FCTXTRACE("try");

REQUIRE(!ADDRWAIT(fctx));

addrinfo = fctx_nextaddress(fctx);
if (addrinfo == NULL) {
/*
 * We have no more addresses.  Start over.
 */
fctx_cancelqueries(fctx, ISC_TRUE);
fctx_cleanupfinds(fctx);
fctx_cleanupaltfinds(fctx);
fctx_cleanupforwaddrs(fctx);
fctx_cleanupaltaddrs(fctx);
result = fctx_getaddresses(fctx, badcache);
if (result == DNS_R_WAIT) {
/*
 * Sleep waiting for addresses.
 */
FCTXTRACE("addrwait");
fctx->attributes |= FCTX_ATTR_ADDRWAIT;
return;
} else if (result != ISC_R_SUCCESS) {

Re: Split horizon and authoritative servers

[John W. Blue]

Hello Matthew,

I am mobile right now and a bit distracted sitting here in a parking lot so 
what exactly your question is eludes me.



Speaking from experience, running a split horizon environment has several 
advantages and is quit liberating.  For example, internally your BIND servers 
can be authortative for the root of your zone and then you delegate a subzone 
to Active Directory.  It keeps external/internal root neat and tidy and 
internally allows Active Directory the freedom to run dynamic updates without 
risk of leakage.

Every host get DNS from the Domain Controllers and the DC's get recursion 
exclusively from BIND.

That said, you will want authorative name severs for both external and 
internal.  If you choose to go with hidden external/internal masters that is 
fine.  No need to separate the roles of the slaves out unless there is an 
unknown operational requirement.

Finally,  if you have a lot of RR churn, look to an IPAM solution the help 
shoulder the load.  Editing db files by hand is asking for mistakes to be made.

Hope that helps!

John

Sent from Nine

From: Mathew Ian Eis 
Sent: Apr 4, 2016 7:38 PM
To: bind-users@lists.isc.org
Subject: Split horizon and authoritative servers

Hi BIND,

I have a question about authoritative servers in a split horizon environment 
(suppose two views "internal" and "external").

Is is necessary to have separate internal authoritative (listed in internal 
zone NS records, but not in whois or external NS records) servers, if the 
internal recursive servers are also authoritative (in the same way) slaves to 
an internal hidden master for the relevant zones?

It seems like cache poisoning should not be a concern, since the only servers 
listed in the (internal) NS records would as slaves always have full copies of 
relevant zones, and would not actually be recursing for those records. I can't 
think of any other reason to separate the internal authoritative slaves and the 
internal recursive resolvers... am I missing anything obvious?

Thanks in advance,

Mathew Eis
Northern Arizona University
___
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: what does "max-ncache-ttl 0;" mean?

[John W. Blue]

Now quote your source.

;)

From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of A. Renald Niswady
Sent: Wednesday, March 02, 2016 1:23 AM
To: blrmaani
Cc: comp-protocols-dns-b...@isc.org
Subject: Re: what does "max-ncache-ttl 0;" mean?

max-ncache-ttl sets the maximum time (in seconds) for which the server will 
cache negative (NXDOMAIN) answers (positives are defined by 
max-cache-ttl). 
The default max-ncache-ttl is 10800 seconds (3 hours). max-ncache-ttl cannot 
exceed 7 days and will be silently truncated to 7 days if set to a greater 
value. This statement may be used in 
view or a global 
options clause.

Regards,
A. Renald Niswady
[NOC-System] Orion Cyber Internet

PT Orion Cyber Internet
Gedung Cyber Lt. 1 Jl. Kuningan Barat No. 8, Jakarta Selatan 12710
Telp: 021 5265566 - Fax: 021 6280883
Homepage: http://www.orion.net.id
Internet Access, Webhosting, Colocation, Games and More.


From: "blrmaani" mailto:blrma...@gmail.com>>
To: comp-protocols-dns-b...@isc.org
Sent: Wednesday, March 2, 2016 2:13:29 PM
Subject: what does "max-ncache-ttl 0;" mean?

man pages for named.conf says "max-ncache-ttl " and only talks about 
default values and max values - no mention of minimum-value.

Does "max-ncache-ttl 0;" mean never cache negative queries (queries resulting 
in NXDOMAIN) or does it mean cache negative queries forever?

Too lazy to test this option or look bind code :), hence posting here - 
apologies in advance..!!

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