Re: Bind: Standard Ports And Non Standard Ports

[Warren Kumari]

On Fri, Feb 11, 2022 at 10:21 AM Tim Daneliuk via bind-users <
bind-users@lists.isc.org> wrote:

>
> After some months of poking around, we are now certain that our so-called
> "Business"
> service from Comcast is compromising our DNS servers because of their
> execrable "Security Edge" garbage.  (They are willing to remove this
> 'service'
> only if we are willing to incur a higher monthly recurring fee.)
>
>
According to "the Internet" (aka, some random reddit thread), there is a
way to disable this:
https://www.reddit.com/r/networking/comments/fl0ujm/xfinity_secureedge_for_business_transparently/

It did not *look* like this required changing service / a higher fee, but
...

W


> Our master is in the wild and works fine, but the slave is behind the
> compromised
> Comcast pipe.  The effect of having Security Edge in place is that the
> slave cannot get updates from the master and is also unable to resolve
> anything outside our own zone.   Comcast is apparently hijacking all port
> 53 requests and doing unspeakable things with them.
>
> Is there a way to have these servers work as usual, listening to resolution
> request on port 53, but have the slave update AND forward requests to the
> master over a non-standard port, so as to work around the Comcast madness?
>
> TIA,
> Tim
>
> P.S. My guess is that this so-call "security" service is no such thing, or
> at
>   least its not the only thing.  They are probably harvesting DNS
> lookups
>   to sell as marketing data, or at least that would be my first guess.
> --
> 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
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
-- 
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: Change records in DNS slave if master is offline

[Warren Kumari]

On Thu, Dec 16, 2021 at 10:37 AM Roberto Carna 
wrote:

> Dear all, I have one BIND9 server as master and 3 as slaves.
>
> The master and one slave are in a given site #1, and the other two
> slaves are in a geographical different site #2.
>
> In case site #1 goes offline, I need to edit records in both slaves
> from site #2, in order to point some services to other public IP's for
> contingency.
>
> My question is:
>
> What is the recommended way to edit the records from a BIND9 slave?
> Because the zone files are binary files


Yup, if you are running (IIRC) > v9.9.x, the default is binary files.
You can convert these beck to text with:
named-compilezone -f raw -F text -o example.com.text example.com
example.com.binary

You can also change the default in named.conf:
options {
// many many options
masterfile-format text;
//
// many other options
//
}

The raw (binary) zone files are good for large zones, but for small zones,
where speed isn't super important, text format works just fine...
W



> and using the Webmin interface
> is blocked.
>
> The only manner is changing the configuration from slave to master?
>
> Thanks in advance, greetings!!!
> ___
> 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
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
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: forwarders used in order or based on RTT ?

[Warren Kumari]

On Mon, Oct 19, 2020 at 11:26 AM Victoria Risk  wrote:
>
> The ARM was updated in 9.16.6.  Sorry it took us so long!
>
> from https://gitlab.isc.org/isc-projects/bind9/-/issues/2030
> Forwarders are typically used when an administrator does not wish for
> all the servers at a given site to interact directly with the rest of
> the Internet. For example, a common scenario is when multiple internal
> DNS servers are behind an Internet firewall. Servers behind the firewall
> forward their requests to the server with external access, which queries
> Internet DNS servers on the internal servers' behalf.
>
> Another scenario (largely now superseded by Response Policy Zones) is to
> send queries first to a custom server for RBL processing before
> forwarding them to the wider Internet.
>
> There may be one or more forwarders in a given setup. The order in which
> the forwarders are listed in ``named.conf`` does not determine the
> sequence in which they are queried; rather, ``named`` uses the response
> times from previous queries to select the server that is likely to
> respond the most quickly. A server that has not yet been queried is
> given an initial small random response time to ensure that it is tried
> at least once. Dynamic adjustment of the recorded response times ensures
> that all forwarders are queried, even those with slower response times.
> This permits changes in behavior based on server responsiveness.


Awesome, thank you -- that's clean and easy to understand.
W

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



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

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: forwarders used in order or based on RTT ?

[Warren Kumari]

On Sun, Oct 18, 2020 at 2:32 PM @lbutlr  wrote:
>
> On 16 Oct 2020, at 08:36, Bob Harold  wrote:
> > That is certainly not obvious.  How do I request improving the manual?
> >
> > "in turn" would seem to imply "in order", and the order would logically be 
> > the order I listed them.]
>
> I disagree. In turn means one is tried, then if that fails the next is tried. 
> There is no implication at all that the order they are tried in is the order 
> specified.
>
> It would not hurt anything to say they were tried in turn accords to RTT, but 
> as it stands the documentation doesn’t say what you think it says.
>
> Again, "in turn" doesn’t mean "in the order I expect" it simply means one 
> after another until all are checked (or one succeeds).


"In turn" might not strictly mean in the order listed (the definitions
converge around 1: "in succession", or 2: a causal step from a
previous outcome), but there is *implication* that it is in the order
listed.
If I said "The carolers visited the houses in turn", the *implication*
is that they visited the first house, then the second, then the third,
etc and not the first, then the seventeenth, etc.

Yes, there is ambiguity - it appears that this usage is that the
succession is "in RTT order", and not "in listed order", but the fact
that it is ambiguous, and people are unsure what is meant,
demonstrates a bug in the documentation.

W
>
>
> --
> "Are you pondering what I'm pondering?"
> "Wuh, I think so, Brain, but I prefer Space Jelly."
>
> ___
> 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



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

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: No response from localhost with "allow-query { any; };"

[Warren Kumari]

What is 'localhost'?

The output you included doesn't really show very much, other than that nc
connect to port 53.

I'd suggest:
dig ns5.lrau.net @localhost
dig ns5.lrau.net @127.0.0.1
dig ns5.lrau.net @::1

Also, have a look in /etc/hosts and make sure that you have something like:
127.0.0.1 localhost


(nc may be connecting over v4 and  may be
doing v6, etc...)

W

On Tue, Sep 1, 2020 at 10:12 AM Axel Rau  wrote:

> Hi!
>
> this is a new server, which answers external queries, sends notifies and
> pushes axfrs.
> It does not answer any query from localhost nor shows any notifies from
> master in the logs.
>
> From local:
> root@ns5:/ # nc -v localhost 53
> Connection to localhost 53 port [tcp/domain] succeeded!
> ^C
> root@ns5:/ # nc -vu localhost 53
> Connection to localhost 53 port [udp/domain] succeeded!
>
> From master server:
> [hermes:local/etc/namedb] root# nc -v ns5.lrau.net 53
> Connection to ns5.lrau.net 53 port [tcp/domain] succeeded!
> ^C
> [hermes:local/etc/namedb] root# nc -vu ns5.lrau.net 53
> Connection to ns5.lrau.net 53 port [udp/domain] succeeded!
>
>
> Any help greatly appreciated,
> Axel
>
> PS:
>
> part of named.conf:
> allow-notify {
> hermes-ns5;
> };
> allow-transfer {
> full-trusted;
> ns5-ping;
> ns4-he;
> management-hosts;
> };
> allow-query { any; };
> allow-query-cache { recursive-users; };
> allow-recursion { recursive-users; };
>
>
> root@ns5:/usr/local/etc/namedb/working/slave # named -V
> BIND 9.16.5 (Stable Release) 
> running on FreeBSD amd64 12.1-RELEASE-p8 FreeBSD 12.1-RELEASE-p8 GENERIC
> built by make with '--disable-linux-caps' '--localstatedir=/var'
> '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2'
> '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit'
> '--with-dlz-filesystem=yes' '--disable-dnstap' '--disable-fixed-rrset'
> '--disable-geoip' '--without-maxminddb' '--without-gssapi'
> '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile'
> '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python'
> '--disable-querytrace' 'STD_CDEFINES=-DDIG_SIGCHASE=1'
> '--enable-tcp-fastopen' '--with-tuning=default' '--disable-symtable'
> '--prefix=/usr/local' '--mandir=/usr/local/man'
> '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.1'
> 'build_alias=amd64-portbld-freebsd12.1' 'CC=cc' 'CFLAGS=-O2 -pipe
> -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include
> -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c
> -fstack-protector-strong ' 'LIBS=-L/usr/local/lib'
> 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
> 'PKG_CONFIG=pkgconf'
> compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.1
> (tags/RELEASE_801/final 366581)
> compiled with OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
> linked to OpenSSL version: OpenSSL 1.1.1d-freebsd  10 Sep 2019
> compiled with libxml2 version: 2.9.10
> linked to libxml2 version: 20910
> compiled with json-c version: 0.14
> linked to json-c version: 0.15
> compiled with zlib version: 1.2.11
> linked to zlib version: 1.2.11
> threads support is enabled
>
> default paths:
>  named configuration:  /usr/local/etc/namedb/named.conf
>  rndc configuration:   /usr/local/etc/namedb/rndc.conf
>  DNSSEC root key:  /usr/local/etc/namedb/bind.keys
>  nsupdate session key: /var/run/named/session.key
>  named PID file:   /var/run/named/pid
>  named lock file:  /var/run/named/named.lock
>
> ---
> PGP-Key: CDE74120  ☀  computing @ chaos claudius
>
> ___
> 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
>


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

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: Reverse lookup response format

[Warren Kumari]

On Tue, Aug 25, 2020 at 10:30 AM Brad Stevenson
 wrote:
>
> Hello, I apologize if this has been discussed before. I tried to search the 
> archives but couldn’t find anything.
>
>
>
> I would like to have the behavior of the reverse lookup responses to only 
> include the hostname, not the hostname with the reverse zone appended. So for 
> example:
>
> # nslookup 192.168.2.206
>
> 206.2.168.192.in-addr.arpa  name = server1.ctois.local
>
>
>
> Instead of the way it is now:
>
> # nslookup 192.168.2.206
>
> 206.2.168.192.in-addr.arpa  name = 
> server1.ctois.local.2.168.192.in-addr.arpa.
>
>
>
> Is this possible? Thanks in advance.

Yup -- you just need a period ('.') at the end of the name --
presumably in the zone file you have server1.ctois.local - that needs
to be server1.ctois.local.  (without the period the server doesn't
know that the name is fully qualified and adds the zone name...

W

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



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

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: A And Cname-record

[Warren Kumari]

Yup - that’s because you cannot (legally) have a CNAME and any other RR
type at the same name — see
https://en.m.wikipedia.org/wiki/CNAME_record for an explanation as to why...

W

On Wed, Jun 17, 2020 at 5:44 PM Ejaz Ahmed  wrote:

> when i am trying to add A and CNAME record together  for the same
> subdomain, getting an error as below, you all kind  assistance would be
> highly appreciated thanks in  advance
>
> my records are as follows in zone
>
> auotdiscover IN A 1.1.1.1
> autodiscover IN CNAME autodiscover.acig.com.sa
>
> ==
>
> dns_master_load: acig.com.sa.hosts:102: autodiscover.a
> cig.com.sa: CNAME and other data
>
> zone acig.com.sa/IN: loading from master file acig.com.sa.hosts failed:
> CNAME and other data
> zone acig.com.sa/IN: not loaded due to errors
> 
>
> ___
> 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
>
-- 
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

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: Batch updating all DNS records on my Bind server

[Warren Kumari]

On Sat, Apr 18, 2020 at 12:52 PM Tony Finch  wrote:
>
> @lbutlr  wrote:
> >
> > Is it possible to batch update all the domains? Looking at nsupdate it
> > looks like I have to step through and do every domain individually.
>
> An UPDATE request can change many records, so long as they are all in the
> same zone, and so long as they fit in the 64KB limit of DNS message size.
> I find one request is usually enough for routine changes, but if you are
> doing a bulk update to a large zone, you will need to split the changes
> across mulitiple update requests.
>
> You might find nsdiff helpful, both to verify that your bulk changes are
> what you expect, and because it will split large updates into multiple
> requests automatically. It's still one-zone-at-a-time, though. A
> quick-and-dirty starting point might be roughly
>
> dig axfr $zone |
> sed 's/oldprefix/newprefix/' |
> nsdiff $zone /dev/stdin |
> nsupdate -l
>
> https://dotat.at/prog/nsdiff/

Another option may be:
rndc sync
rndc freeze
rndc sync
[sed and awk[0] ]
rndc thaw

?

W
[0]: Now at this point I should have remembered that profound truism:
“Some people, when confronted with a Unix problem, think ‘I know,
I’ll use sed.’ Now they have two problems.” jwz - 12 Dec 1992

>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> North Utsire, South Utsire: Variable 3 or less. Smooth or slight, occasionally
> moderate at first. Fair. 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



-- 
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: Try to figure a basic conf for BIND on Mac Catalina

[Warren Kumari]

On Tue, Apr 14, 2020 at 9:53 AM David Chandler
 wrote:
>
> I have been working on this for days. Anything other than Caching-only 
> configuration will not register anything. Port 53 will not open.

It is unclear what you are meaning by "Port 53 will not open" - is
BIND binding to the port? Does it show up in sudo netstat -nP -f inet
-f inet6 | grep '\.53'  ? If you telnet (nc) to localhost 53 do you
get anything?
If yes to the above, it sounds like you have the firewall enabled:
https://support.apple.com/guide/mac-help/change-firewall-preferences-on-mac-mh11783/mac

W


>
> Looking for help with a configuration that will allow this server to be 
> authority for  2 domains focushm.com and focushs.com and forward for all 
> others. Don’t know if I am missing something on the Macintosh but I have 
> followed every configuration I have found on Google and read every document I 
> could find on BIND. Even the sample configuration for the Authoritative 
> Server in the BIND9 documentation yields no joy. The Caching-only will but 
> not the Authoritative.
>
>
>
> Any advice would be helpful!
>
> David Chandler
>
>
> CONFIDENTIALITY NOTICE: This communication contains information intended for 
> the use of the individuals to whom it is addressed and may contain 
> information that is privileged, confidential or exempt from other disclosure 
> under applicable law. If you are not the intended recipient, you are notified 
> that any disclosure, printing, copying, distribution or use of the contents 
> is prohibited. If you have received this in error, please notify the sender 
> immediately by telephone or by returning it by return mail and then 
> permanently delete the communication from your system. 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



-- 
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: DNSSEC - many doubts

[Warren Kumari]

On Thu, Apr 2, 2020 at 11:14 AM David Alexandre M. de Carvalho
 wrote:
>
> Hello, good afternoon.
> My first post in this list :)
>
> I'm running BIND Chroot for many years (currently version 9.8.2) on some old 
> hardware running Oracle Linux 6.
> I believe it was last year when I was reading about implementing DNSSEC, and 
> I think I've even tried to generate a
> keypair in the slowest server, which after more than a day, wasn't ready yet. 
> Maybe I was doing something wrong, I
> honestly don't know.

You almost definitely were -- even a really really slow machine should
be able to generate keys in a small number of seconds -- you didn't
list what commands you used, but I'm going to assume you were trying
to generate an rsa key - you should be able to get a feel for how long
this takes by running:
time openssl genrsa -out private.key 2048
or
time openssl genrsa -out private.key 4096
 (note that this is very different to running 'openssl speed rsa2048
rsa4096', which benchmarks RSA operations, not key generations).

I'm fairly sure that your issue was a lack of entropy -- in order to
generate crypograohically good keys, you need good a good source of
randomness. If you are running an older machine and older kernel, the
/dev/random source is blocking, and if you try and read too much from
it it will just hang until it has enough entropy to give "safe"
output. Newer kernels do a better job of mixing in external event
noise, but there are a number of modules which help with this -
haveged being the best known (http://www.issihosts.com/haveged/ ).
You could also test if this is the issue by using /dev/urandom, which
doesn't block, or 'while true; do cat
/proc/sys/kernel/random/entropy_avail; sleep 2; done' and see if the
available entropy drops to zero during key generation...

W

> So now I had some time and reading about this again.
>
> If I query either of my servers about my domain:
> dig @dns di.ubi.pt DNSKEY
> I do get the DNSKEY, but I have no records when querying about +dnssec. My 
> topdomain (ubi.pt) doesn't have DNSSEC yet
> either.
>
> my named.conf already has the following:
>
> dnssec-enable yes;
> dnssec-validation auto;
> dnssec-lookaside auto;
> bindkeys-file "/etc/named.iscdlv.key";
> managed-keys-directory "/var/named/dynamic";
>
> Outside the configuration file I also have a /etc/named.root.key
>
> My questions:
> 1) Will my old servers (1GB RAM) become much slower with  DNSSEC? Is it worth 
> it?
> 2) I have one global "hosts" file and 3 reverse zone files, each for the 
> respective IP network. Can I use the same
> Keypair in all of them?
> 3) Are the files /etc/named.root.key file and /etc/named.iscdlv.key already 
> being used? I compared them to the result
> of the DNSKEY dig query but they are different.
>
> Thank you so much for your time!
> Best regards
>
> Os melhores cumprimentos
> David Alexandre M. de Carvalho
> ---
> Especialista de Informática
> Departamento de Informática
> Universidade da Beira Interior
>
>
>
> ___
> 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: How to get random subset of large rrset (30+ IPs for round robin)?

[Warren Kumari]

On Fri, Mar 20, 2020 at 1:04 PM Matus UHLAR - fantomas
 wrote:
>
> >On Fri, Mar 20, 2020 at 3:14 AM David Klatt  wrote:
> >> I can't find a way to do the following although I invested plenty of time
> >> in research - maybe you guys have an idea:
> >>
> >> With bind, I'd need to serve a single A record with  30+  IP addresses  and
> >> these addresses have to be returned in random order round robin,
> >> which is done with:
>
> >> Now I'd like bind to just return a  random subset  of e.g. 5 IP addresses
> >> if someone requests this A record.
>
> On 20.03.20 10:37, Warren Kumari wrote:
> >I realize that this is the BIND list, but this sounds like an almost
> >perfect example of PowerDNS's LUA record type (or something with
> >CoreDNS)
> >Other than that, the only thing I can think of is BIND with DLZ and a
> >database that returns a random subset from a DB query, but that sounds
> >awful...
>
> I don't think BIND can do this at all. And I don't think it should...
>
> >> Reason for this are in my case some (thousands) older clients (that I 
> >> can't control)
> >> that seem not being able to handle that many IPs - the OS resolver just 
> >> returns an error.
>
> why no use IPVS-like load balancer and hide all hosts behind one or two IPs?
> that would help you much more, amongst others when any of those machines
> fails.

That's almost definitely the right answer, but there *are* cases where
something like what the OP was asking for -  0.pool.ntp.org springs to
mind as one example.
But, yes, a load balancer / anycast is almost definitely going to be a
better choice...

Warren.


>
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> WinError #98652: Operation completed successfully.
> ___
> 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: How to get random subset of large rrset (30+ IPs for round robin)?

[Warren Kumari]

On Fri, Mar 20, 2020 at 3:14 AM David Klatt  wrote:
>
> Hi,
>
> I can't find a way to do the following although I invested plenty of time
> in research - maybe you guys have an idea:
>
> With bind, I'd need to serve a single A record with  30+  IP addresses  and
> these addresses have to be returned in random order round robin,
> which is done with:
>
> rrset-order {  order random;  };
>
> and records like:
>
> foo  IN A  10.0.0.1
> foo  IN A  10.0.0.2
> foo  IN A  10...N
>
> Now I'd like bind to just return a  random subset  of e.g. 5 IP addresses
> if someone requests this A record.

I realize that this is the BIND list, but this sounds like an almost
perfect example of PowerDNS's LUA record type (or something with
CoreDNS)
Other than that, the only thing I can think of is BIND with DLZ and a
database that returns a random subset from a DB query, but that sounds
awful...

W

>
> Reason for this are in my case some (thousands) older clients (that I can't 
> control)
> that seem not being able to handle that many IPs - the OS resolver just 
> returns an error.
>
> For my use case I absolutely need to make sure that each IP of that large
> A record set is given out equally (statistically) and that at any time when
> bind answers that one A record it only returns a random subset of all these 
> IPs.
>
> Has someone an idea on how to achieve the latter?
>
> Thanks a lot in advance!
>
> David
> Geschäftsführer: Christoph Ostermann (CEO), Oliver Koch, Steffen Schneider, 
> Hermann Schweizer, Tim Ulbricht.
> Amtsgericht Kempten/Allgäu, Registernummer: 10655, Steuernummer 
> 127/137/50792, USt.-IdNr. DE272208908
> ___
> 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: Unable to browse from external network in SplitDNS

[Warren Kumari]

On Wed, Mar 18, 2020 at 11:42 PM Purva Rawan  wrote:
>
> There are three(3) cases as mentioned below.
>
> Case I
> Request from DMZ host(SNat to 172.28.0.2) to Internal of split 
> DNS(172.28.0.11).
> We are able to NSLOOKUP for "registry.npmjs.org".
> We are able to wget/browse "https://registry.npmjs.org;
>
> So, No issues in this.
>
>
> Case II
> Request from DMZ host(SNat to 196.1.113.242) to Public of split 
> DNS(196.1.113.248).
> We are able to NSLOOKUP for "registry.npmjs.org".
> We are NOT able to wget/browse "https://registry.npmjs.org;
>
> So, this we want to fix.


So, you can resolve "registry.npmjs.org" to an IP address, but you
cannot connect to that IP? This is clearly not a DNS issue...


>
> Observation: In the TCP dump on the interface with IP address 
> "196.1.113.248", we see that the DMZ host is trying to re-transmitting SYN 
> packets to DNS server multiple times.
> We cannot do telnet(TCP) from DMZ host to 196.1.113.248 and thats the 
> expected behaviour.


"You are unable to telnet from DMZ host to 196.1.113.248" (expected)
or "You are unable to telnet from DMZ host to 196.1.113.248 port 53" -
this is not expected.
See https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-05
- TCP is required to make DNS work.


>
> The question is why it is switching from UDP to TCP while we try to 
> wget/browse and not the same is happening in Case I.
>
>
> Case III
> Executed for Troubleshooting.
>
> Request from DMZ host(SNat to 196.1.113.242) to Google DNS(8.8.8.8).
> We are able to do NSLOOKUP for "registry.npmjs.org".
> We are able to wget/browse "https://registry.npmjs.org;
>
> So, No issues in this.
>
>
> Hope the above gives more insight into the issue.
>
>
>
> Regards,
>
> Purva Rawan
>
>
> On March 18, 2020 at 7:05 PM Warren Kumari  wrote:
>
>
>
> On Wed, Mar 18, 2020 at 9:03 AM Purva Rawan < pur...@cdac.in> wrote:
>
> Hello ,
>
> We have configured splitDNS .Bind version is 9.9.2.We are able to lookup and 
> browse to particular URL( e.g.https://registry.npmjs.org) from internal 
> network but the same URL when we tried from external network ,it failed to 
> browse ,but able to do nslookup.We checked tcpdump logs and observed that DNS 
> protocol switched from udp to tcp.
>
> Tcpdump logs for reference
>
> 17:39:28.380918 ARP, Request who-has 196.1.113.242 tell 196.1.113.248, length 
> 28
>
> 17:39:28.381205 ARP, Reply 196.1.113.242 is-at 00:09:0f:09:00:1a, length 46
>
> 17:39:30.395995 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 
> 2177054283, win 14600, options [mss 1460,sackOK,TS val 2512104 ecr 
> 0,nop,wscale 7], length 0
>
> 17:39:38.420575 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 
> 2177054283, win 14600, options [mss 1460,sackOK,TS val 2520128 ecr 
> 0,nop,wscale 7], length 0
>
> 17:39:54.451991 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 
> 2177054283, win 14600, options [mss 1460,sackOK,TS val 2536160 ecr 
> 0,nop,wscale 7], length 0
>
> 17:40:26.483591 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S], seq 
> 2177054283, win 14600, options [mss 1460,sackOK,TS val 2568192 ecr 
> 0,nop,wscale 7], length 0
>
> Kindly help to resolve the same.
>
> You appear to have network / firewall, not DNS issues -- 196.1.113.242 is 
> sending SYN (open a connection) packets to  ns1.cdac.in, but is not getting 
> any reply packets from it (assuming you included all of the tcpdump output) - 
> this either means that  ns1.cdac.in was down, or, more likely, that 
> 196.1.113.242 cannot send packets to it on port 53.
> As a quick and dirty test, can you telnet from 196.1.113.242 to port 53 on 
> 196.1.113.248?
>
> W
>
>
>
> Regards,
>
> Purva Rawan
>
>
>
>
> 
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> 
> 

Re: Unable to browse from external network in SplitDNS

[Warren Kumari]

On Wed, Mar 18, 2020 at 9:03 AM Purva Rawan  wrote:

> Hello ,
>
> We have configured splitDNS .Bind version is 9.9.2.We are able to lookup
> and browse to particular URL( e.g.https://registry.npmjs.org) from
> internal network but the same URL when we tried from external network ,it
> failed to browse ,but able to do nslookup.We checked tcpdump logs and
> observed that DNS protocol switched from udp to tcp.
>
> Tcpdump logs for reference
>
> 17:39:28.380918 ARP, Request who-has 196.1.113.242 tell 196.1.113.248,
> length 28
>
> 17:39:28.381205 ARP, Reply 196.1.113.242 is-at 00:09:0f:09:00:1a, length 46
>
> 17:39:30.395995 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S],
> seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2512104 ecr
> 0,nop,wscale 7], length 0
>
> 17:39:38.420575 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S],
> seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2520128 ecr
> 0,nop,wscale 7], length 0
>
> 17:39:54.451991 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S],
> seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2536160 ecr
> 0,nop,wscale 7], length 0
>
> 17:40:26.483591 IP 196.1.113.242.54930 > 196.1.113.248.domain: Flags [S],
> seq 2177054283, win 14600, options [mss 1460,sackOK,TS val 2568192 ecr
> 0,nop,wscale 7], length 0
>
> Kindly help to resolve the same.
>
You appear to have network / firewall, not DNS issues -- 196.1.113.242 is
sending SYN (open a connection) packets to ns1.cdac.in, but is not getting
any reply packets from it (assuming you included all of the tcpdump output)
- this either means that ns1.cdac.in was down, or, more likely,
that 196.1.113.242 cannot send packets to it on port 53.
As a quick and dirty test, can you telnet from 196.1.113.242 to port 53
on 196.1.113.248?

W




> Regards,
>
> Purva Rawan
>
>
>
> [image: 150th Anniversary Mahatma Gandhi]
>
> 
>
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and destroy
> all copies and the original message. Any unauthorized review, use,
> disclosure, dissemination, forwarding, printing or copying of this email
> is strictly prohibited and appropriate legal action will be taken.
> 
>
> ___
> 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: Unable to completely transfer root zone

[Warren Kumari]

On Sun, Feb 16, 2020 at 6:48 AM Ed Daniel  wrote:
>
> Thank you for replying and sharing, Warren. I apologise for my
> misunderstanding of the intent of your words.

Nah, no worries - tone gets lost in email, and my response definitely
could have been read as really sarcastic.

I'd also like to thank you for calling me on it - if that had been my
intended tone it would have been inappropriate, and not alright for
this list.

w

>
> On 16/02/2020 03:08, Warren Kumari wrote:
> >
> >
> > On Fri, Feb 14, 2020 at 10:49 PM Ed Daniel  > <mailto:esdan...@esdaniel.com>> wrote:
> >
> > On 11/02/2020 15:28, Warren Kumari wrote:
> > > On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer
> > mailto:bortzme...@nic.fr>> wrote:
> >     >>
> > >> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
> > >>  Warren Kumari mailto:war...@kumari.net>> wrote
> > >>  a message of 70 lines which said:
> > >>
> > >>> Also, can you try:
> > >>> dig +tcp . axfr @192.0.32.132 <http://192.0.32.132>
> > >>> dig +tcp . axfr @192.0.47.132 <http://192.0.47.132>
> > >>> dig +tcp . axfr @b.root-servers.net <http://b.root-servers.net>
> > >>>
> > >>> (no, I'm not really sure why trying with the first 2 IPs instead of
> > >>> hostname
> > >>
> > >> Because you know that IPv6 and IPv4 may exhibit different issues.
> > >
> > > Hey, yeah, that's it! Thank you for explaining my thought processes to
> > > me -- for an encore, can you explain why I keep losing my keys? :-)
> > >
> >
> > I hope you guys are friends otherwise... -1
> >
> >
> >
> > Oh, yes - Stephane and I are definitely friends. There was no sarcasm
> > behind the comments - he was perfectly correct about my reasoning, and I
> > hadn't thought through why I was suggesting that.
> >
> > I hope no one (esp Stephane) took my comment as anything other than
> > self-deprecating - tone gets lost in mail.
> >
> > W
> >
> >
> >
> > ___
> > 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
> >
> > --
> > 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
>


-- 
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: Unable to completely transfer root zone

[Warren Kumari]

On Fri, Feb 14, 2020 at 10:49 PM Ed Daniel  wrote:

> On 11/02/2020 15:28, Warren Kumari wrote:
> > On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer 
> wrote:
> >>
> >> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
> >>  Warren Kumari  wrote
> >>  a message of 70 lines which said:
> >>
> >>> Also, can you try:
> >>> dig +tcp . axfr @192.0.32.132
> >>> dig +tcp . axfr @192.0.47.132
> >>> dig +tcp . axfr @b.root-servers.net
> >>>
> >>> (no, I'm not really sure why trying with the first 2 IPs instead of
> >>> hostname
> >>
> >> Because you know that IPv6 and IPv4 may exhibit different issues.
> >
> > Hey, yeah, that's it! Thank you for explaining my thought processes to
> > me -- for an encore, can you explain why I keep losing my keys? :-)
> >
>
> I hope you guys are friends otherwise... -1



Oh, yes - Stephane and I are definitely friends. There was no sarcasm
behind the comments - he was perfectly correct about my reasoning, and I
hadn't thought through why I was suggesting that.

I hope no one (esp Stephane) took my comment as anything other than
self-deprecating - tone gets lost in mail.

W

>
>
> ___
> 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: Unable to completely transfer root zone

[Warren Kumari]

On Tue, Feb 11, 2020 at 3:12 AM Stephane Bortzmeyer  wrote:
>
> On Mon, Feb 10, 2020 at 02:32:55PM -0500,
>  Warren Kumari  wrote
>  a message of 70 lines which said:
>
> > Also, can you try:
> > dig +tcp . axfr @192.0.32.132
> > dig +tcp . axfr @192.0.47.132
> > dig +tcp . axfr @b.root-servers.net
> >
> > (no, I'm not really sure why trying with the first 2 IPs instead of
> > hostname
>
> Because you know that IPv6 and IPv4 may exhibit different issues.

Hey, yeah, that's it! Thank you for explaining my thought processes to
me -- for an encore, can you explain why I keep losing my keys? :-)

Thanks Stephane,
W

-- 
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: Unable to completely transfer root zone

[Warren Kumari]

On Mon, Feb 10, 2020 at 12:53 PM von Dein, Thomas
 wrote:
>
> Hi everyone,
>
> we are unable to complete root zone transfer from our nameservers. This is 
> the error we're getting:
>
> Feb 10 18:33:32 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> connected using 192.168.1.1#11281
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> resetting
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> connected using 192.168.1.1#46875
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> failed while receiving responses: connection reset
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> Transfer status: connection reset
> Feb 10 18:33:33 bedns2 named[61444]: transfer of './IN' from 192.0.47.132#53: 
> Transfer completed: 11 messages, 3058 records, 179403 bytes, 0.410 secs 
> (437568 bytes/sec)
>
> I can, however do it manually using "dig +tcp . axfr @lax.xfr.dns.icann.org".
>
> The relevant part of the config is:
>
> zone "." {
> type slave;
> file "zone/slave/root.slave";
> masters {
> 192.0.32.132;   // lax.xfr.dns.icann.org.
> 192.0.47.132;   // iad.xfr.dns.icann.org.
> };
> notify no;
> };
>
> Does anyone have an idea, what's wrong here and how I could possibly fix this?

This sounds very much like a path MTU issue -- it starts the transfer,
gets part of the way and then a big packet doesn't make it through...
Are you doing the test dig from the same machine? And if so, from the same IP?
Also, can you try:
dig +tcp . axfr @192.0.32.132
dig +tcp . axfr @192.0.47.132
dig +tcp . axfr @b.root-servers.net

(no, I'm not really sure why trying with the first 2 IPs instead of
hostname, but, hey, 'tis easy to test :-))

W


>
>
> Thanks in advance,
> Tom
> ___
> 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: Using different OS for Master and Slaves

[Warren Kumari]

On Thu, Nov 14, 2019 at 4:58 AM Barry Margolin  wrote:
>
> In article ,
>  Reindl Harald  wrote:
>
> > Am 12.11.19 um 14:00 schrieb G.W. Haywood via bind-users:
> > > Hi there,
> > >
> > > On Tue, 12 Nov 2019, Mundile wrote:
> > >
> > >> Is it good idea and possible to create Master and Slaves nameservers
> > >> using different OSes.
> > >> For example , Master OS =Centos 7 and Slaves Os=Ubuntu 18 or  Windows
> > >> 2016
> > >
> > > It depends on whether or not you enjoy pain
> >
> > there shouldn't be any pain from a technical point of view and there is
> > one security case which could be solved with mixing:
>
> I suspect the pain he was referring to is not really DNS-specific, but
> just due to having to manage servers with different operating systems.
> This means using a more diverse set of management tools, different
> configuration syntax, etc.

Yes -- and as a meta-comment -- using configuration management tools
(Ansible, Puppet, Chef, Salt, etc etc) makes this sort of thing *much*
easier. It;s slightly more work to setup / configure initially, but
especially if you are dealing with multiple nameservers or operating
systems, the level of abstraction you get and / or clear location for
the changes you've made makes a world of differnce.
Just like adding unittests, it initially seems like a lot of faff for
an unclear advantage (other than hipster cred), but once you've gotten
into the habit you quickly understand why it's worth it...

W

>
> --
> Barry Margolin
> Arlington, MA
> ___
> 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: Zoneformat

[Warren Kumari]

On Mon, Oct 28, 2019 at 6:08 AM MEjaz  wrote:
>
>
>
>
>
> From: MEjaz [mailto:me...@cyberia.net.sa]
> Sent: Monday, October 28, 2019 10:27 AM
> To: 'bind-users-boun...@lists.isc.org' 
> Subject: Zoneformat
>
>
>
> Hi all,
>
>
>
> Is ther any way I can create the zone without the (.) I mean non fully 
> qualified domain name just as “example” instead “example.com”’
>
>

Your messages are so terse that it is often hard to know what you are
trying to accomplish, and so hard to answer.

It sounds like the 'search' directive in /etc/resolv.conf will do what
you want -- see https://en.wikipedia.org/wiki/Search_domain for more
info.
If you add 'search cyberia.net.sa' to /etc/resolv.conf, then lookups
for 'crm365app' will first be tried as crm365app.cyberia.net.sa and
then just crm365app.

Note that this is done by the stub resolver, and so you will need to
do this on each machine -- DHCP may help with this (see
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcp-options )

Please note that this is almost definitely a bad idea -- it leads to
all sorts of security issues; it's much better to just get into the
habit of typing 'crm365app.cyberia.net.sa' instead...

W


>
> Thanks in advance  for your assistance
>
>
>
> Ejaz
>
> ___
> 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: Bind-Efficientip

[Warren Kumari]

On Sun, Oct 20, 2019 at 10:26 PM John W. Blue  wrote:
>
> 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.
>

Indeed.
I've been using NetBox (https://netbox.readthedocs.io/en/stable/) for
a few years, and have been very happy with it -- it's a combination:
* IP address management (IPAM) - IP networks and addresses, VRFs, and VLANs
* Equipment racks - Organized by group and site
* Devices - Types of devices and where they are installed
* Connections - Network, console, and power connections among devices
* Virtualization - Virtual machines and clusters
* Data circuits - Long-haul communications circuits and providers
* Secrets - Encrypted storage of sensitive credentials

I use it as the primary source of truth for my personal networks /
wife's client's networks / other networks I help run.
As well as answering "Where the hell is 192.0.2.23?!" it also answers
"What port is the machine foo.bar.exmaple.com connected to, what color
is the cable, what is it labeled as, what rack is it in, and what is
the access code to open the cabinet?!".

It doesn't natively generate DNS zonefiles, but there are plugins
which can do so...

W

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



-- 
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: A policy for removing named.conf options.

[Warren Kumari]

One of the Tesla easter-eggs is that the radio volumes goes to 11...

:-P
W

On Thu, Jun 13, 2019 at 3:27 PM Lightner, Jeffrey
 wrote:
>
> But if the knob goes to 11 you'll know it is superior to those that only go 
> to 10.  :-)
>
>
> -Original Message-
> From: bind-users  On Behalf Of Warren Kumari
> Sent: Thursday, June 13, 2019 2:53 PM
> To: Evan Hunt 
> Cc: Ondřej Surý ; comp-protocols-dns-b...@isc.org
> Subject: Re: A policy for removing named.conf options.
>
> On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt  wrote:
> >
> > > > Is it really much of a hassle to leave the obsolete options in the
> > > > parser, but just ignore them?
> >
> > IMHO, it depends on the option. For something like "managed-keys" and
> > "trusted-keys", there are clear security implications.  Once those are
> > no longer effective, it would be dangerous to have named ignore them -
> > even with a logged warning. Operators who didn't notice the log
> > message wouldn't realize they were running without the security they'd 
> > configured.
> >
> > For something like "cleaning-interval" or "max-acache-size", IMHO it
> > would be safe to let it slide. With "dnssec-enable" or
> > "queryport-pool-ports", maybe those fall somewhere in between, I could see 
> > arguments either way.
>
> I personally think that while it may or may not be a hassle to have the 
> parser ignore them, it would be a significant operational risk / annoyance.
> Having knobs which you can twiddle which don't do anything leads to all sorts 
> of annoyance -- if I'm running low on space for cache, and spend much time 
> twiddling the "max-acache-size" knob before discovering that someone has 
> simply snipped the wires to it, I'd be super-grumpy.
>
> I'm expecting some issues when knobs get deprecated (and I'm likely to run 
> into a few lurking in old configs which have grown over time), but I'd rather 
> have named not start just after I've upgraded it than be running in some 
> partially undefined state.
>
> W
>
> >
> > In any case, if we're going to make a policy that covers the whole
> > range of possibilities, then it needs to address the case when an
> > option must removed, and how to ensure operators aren't blindsided by that.
> >
> > --
> > Evan Hunt -- e...@isc.org
> > Internet Systems Consortium, Inc.
> > ___
> > 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



-- 
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: A policy for removing named.conf options.

[Warren Kumari]

On Thu, Jun 13, 2019 at 2:43 PM Evan Hunt  wrote:
>
> > > Is it really much of a hassle to leave the obsolete options in the
> > > parser, but just ignore them?
>
> IMHO, it depends on the option. For something like "managed-keys" and
> "trusted-keys", there are clear security implications.  Once those are no
> longer effective, it would be dangerous to have named ignore them - even
> with a logged warning. Operators who didn't notice the log message wouldn't
> realize they were running without the security they'd configured.
>
> For something like "cleaning-interval" or "max-acache-size", IMHO it would
> be safe to let it slide. With "dnssec-enable" or "queryport-pool-ports",
> maybe those fall somewhere in between, I could see arguments either way.

I personally think that while it may or may not be a hassle to have
the parser ignore them, it would be a significant operational risk /
annoyance.
Having knobs which you can twiddle which don't do anything leads to
all sorts of annoyance -- if I'm running low on space for cache, and
spend much time twiddling the "max-acache-size" knob before
discovering that someone has simply snipped the wires to it, I'd be
super-grumpy.

I'm expecting some issues when knobs get deprecated (and I'm likely to
run into a few lurking in old configs which have grown over time), but
I'd rather have named not start just after I've upgraded it than be
running in some partially undefined state.

W

>
> In any case, if we're going to make a policy that covers the whole range of
> possibilities, then it needs to address the case when an option must
> removed, and how to ensure operators aren't blindsided by that.
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> 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: dnssec-validation auto vs yes

[Warren Kumari]

On Wed, Jun 12, 2019 at 8:25 PM Evan Hunt  wrote:
>
> On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote:
> > The default BIND9 installation for CentOS7 has dnssec-validation set to
> > "yes" and it also includes managed-keys as well. Do those managed-keys
> > get updated automatically?
>
> Yes, if the "managed-keys" statement is in named.conf (or included in
> it via an "include" statement) then the keys will be updated automatically.
... assuming that named can write to the directory. This is definitely
worth double-checking.

W

> Based on what you copy-pasted, that appears to be the case.
>
> "dnssec-validation auto" causes named to use its built-in key for the root
> zone, so you don't have to put your own "managed-keys" statement into
> named.conf, but otherwise it's the same as "dnssec-validation yes".
>
> (BTW, a note in passing: we're changing the command from "managed-keys" to
> "dnssec-keys" over the next few years. The new syntax will be available in
> BIND 9.15.1, which should be out next week; the old syntax will be
> phased out later.)
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> 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: A policy for removing named.conf options.

[Warren Kumari]

On Thu, Jun 13, 2019 at 6:46 AM Matthijs Mekking  wrote:
>
> Dear BIND 9 users,
>
> BIND 9 has a lot of configuration options.  Some have lost value over
> the years, but the policy was to keep the options to not break old
> configurations.
>
> However, we also want to clean up the code at some point.  Keeping these
> options increases the number of corner cases and makes maintenance more
> cumbersome.  It can also be confusing to new users.  We are trying to
> establish an orderly, staged process that gives existing users ample
> time to react and adapt to deprecated options.
>
> The policy below describes our proposal for the procedure for removing
> named.conf options. We would like to hear your feedback.
>
> Thanks, best regards,
>
> Matthijs
>
>
> # Policy for removing named.conf options
>
> A named.conf option will first become deprecated before it is removed
> from the code and becomes an unknown option.
>
> ## Deprecating
>
> A configuration option that is candidate for removal will be deprecated
> first.  During this phase the option will still work, but we will be
> communicating to users that the option is going to be removed soon. A
> user that has deprecated options configured will see warnings in their
> logs and needs to take action to get rid of those log messages.

Many many people don't look at their logs -- could named also print
stuff to (stdout, stderr) when starting?

Note that this will require some testing -- various distributions use
various init scripts - in many cases things printed at startup don't
actually make it to the console, and I'm suspecting some init systems
will barf, but...

Another phased approach would be to require users to acknowledge that
the feature is being deprecated -- initially it could warn, and then
named could require command line flags to enable the (being)
deprecated features, and then in the next release they would stop (e.g
named --enable_deprecated_cleaning-interval). I think that this is way
overkill, but just a thought.

W


> Configuration options that are deprecated will be identified in the
> Release Note for the release they are deprecated in.
>
> Deprecating an option can be done at any time, but preferably before the
> next ESV release.  For example, an option that that needs to be
> deprecated before the ESV 9.16 will need to flagged so in the 9.15
> development or the 9.14 stable release.
>
> ## Removing
>
> A user that has a removed option configured will be unable to start
> `named` because the configuration option is no longer known.  We plan to
> remove options first in an annual stable release, so that we will learn
> what the impact is of removing a certain option before the change hits
> the more popular ESV release.  Configuration options that are removed
> from BIND 9 will be noted in the Release Note for the first version they
> are removed from.
>
> For example, an option that has been marked as deprecated before 9.16
> could be removed in the 9.17 development release (that will become the
> stable ESV release, 9.18).
>
> If it is not removed in the stable release it should also not be removed
> in the following ESV release.  Following the example, it thus should
> also stay in 9.19/9.20.
>
> ## Removing related code
>
> The code that relates to a configuration option that is to be removed
> will in general be deleted at the same time as the configuration option
> is removed.  The BIND 9 team may decide to remove the related code at an
> earlier stage if it is considered harmful to keep. In that case the
> option will become obsolete rather than deprecated.
>
> ## Candidate options to be deprecated/removed
>
> We certainly don't want to remove any options that are still in
> widespread use. Before making the decision to go ahead with removing an
> option, we plan to post a notice on the bind-users mailing list to
> solicit feedback. Depending on the level of concern from the list, we
> may move ahead or decide to defer deprecating the option.
>
> Below is a table of candidate options we may deprecate and remove.  This
> list is by no means set in stone. Feel free to add suggestions, or add
> comments.
>
> | option | will be deprecated in | comments  |
> | -- | - | - |
> | cleaning-interval  | 9.15/9.16 | obsolete  |
> | dnssec-update-mode |   | use auto-dnssec instead   |
> | dialup |   |   |
> | managed-keys   | 9.15/9.16 | replaced with dnssec-keys |
> | trusted-keys   | 9.15/9.16 | replaced with dnssec-keys |
>
> In addition, there are already quite some options that are ancient,
> obsoleted, or never implemented before 9.15. They are listed in this issue:
>
>   https://gitlab.isc.org/isc-projects/bind9/issues/1086
>
> and may be removed in the next stable release after 9.16.
>
> ___
> Please visit 

Re: Useful tip on nsupdate -- readline support.

[Warren Kumari]

On Tue, Jun 11, 2019 at 10:59 AM Mukund Sivaraman  wrote:
>
> On Tue, Jun 11, 2019 at 10:03:30AM -0400, Warren Kumari wrote:
> > Hi there all,
> >
> > I manually use nsupdate to make some changes to some of my zones -
> > most recently I had to add a bunch of reverse DNS records. These are
> > all very similar - the first octet changes, and then the target name
> > changes. Unfortuniatly nsupdate doesn't support readline, and so the
> > obvious "press up arrow, edit previous line, press enter" doesn't
> > work, and so I end up entering one line, copying that into an editor,
> > making changes, pasting, making changes, etc.
> >
> > I just stumbled across this --
> > https://dnsworkshop.de/nsupdate-history.html by Carsten Strotmann
> >
> > Basically, uses rlwrap to wrap readline support into nsupdate - you
> > just call `rlwrap nsupdate` and magically nsupdate now supports
> > editing.
> >
> > 'tis a simple trick, but removes much annoyance.
>
> nsupdate has built-in readline support (when it finds it during build).
> (Though, for for some reason, the nsupdate that ships with Fedora
> doesn't seem to be linking to readline.)
>

Yup - Jim Reid also just sent me mail mentioning this, and looking in
the nsupdate code I find:

#if defined(HAVE_READLINE)
#include 
#include 
#endif

I build from source, and apparently I need to add '--with-readline' to
my configure invocation.


> On that note, buyer beware. A warning to all redistributors who
> commercially repackage BIND with modifications (whether with blessing
> from ISC or not):
>
> * readline is GPL, and so you'll link your code to GPL if you link to it
>   (which can be esp. bad for you if you modify libisc, libdns,
>   etc. also). It's best to either remove readline from such build
>   environments (libedit may be a suitable drop-in replacement), or
>   configure without it, or patch out the code.
>
>   There is some interesting GPL license enforcement history with readline:
>
>   
> https://en.wikipedia.org/wiki/GNU_Readline#Choice_of_the_GPL_as_GNU_Readline's_license
>   https://gitlab.com/gnu-clisp/clisp/blob/master/doc/Why-CLISP-is-under-GPL
>
> * libcap (POSIX capablities) is GPL similarly. An alternative is
>   libcap-ng which is LGPLv2+, but it has a different API.
>
> I think these are the only two libraries that are copyleft vs. BIND's
> ISC (before) and MPL2 (now) licenses, and because they're GPL, your work
> will be covered by GPL if you link against them.
>
> This is usually not bad for the general public (and good for free
> software), but if you're a commercial re-distributor of BIND and are
> linking to GPL, good luck. I'm sure you'll even miss seeing this
> thread. :)

Indeed :-)
W

>
> Mukund



-- 
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: BIND ignores queries from specific privileged source ports

[Warren Kumari]

On Mon, Jun 10, 2019 at 12:37 PM Grant Taylor via bind-users
 wrote:
>
> On 6/7/19 8:44 PM, Mark Andrews wrote:
> > Named drops those ports as they can be used in reflection attacks.
> > Sane NAT developers avoid those ports for just that reason.  The full
> > list is below.
>
> I understand the logic behind avoiding potentially problematic ports.
>
> But I don't understand the actual attack scenario.  Is the attack
> against the BIND server?

The root problem is cache poisoning -- see "The Hitchhiker’s Guide to
DNS Cache Poisoning" Section 3.2 Blind response forgery using birthday
attack ( https://www.cs.cornell.edu/~shmat/shmat_securecomm10.pdf )
for a reasonable writeup.
It's unclear how much protection using the additional port space
actually helps in practice, but...

There are many other mitigations, and the "right" answer is "just use DNSSEC".

W

>  I.e. in an attempt to cause BIND to establish
> a never ending loop of packets between itself and the purported address?
>   Or is this an attempt to cause BIND to attack a spoofed source with
> said loop?
>
> Nor do I understand why BIND couldn't differentiate between an actual
> query vs a reflected reply, daytime response, chargen, or time packet.
>
> Will someone please explain what I'm failing to understand?
>
>
>
> --
> Grant. . . .
> unix || die
>
> ___
> 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: Bind9 stops responding for some clients

[Warren Kumari]

On Thu, May 30, 2019 at 8:10 PM Gregory Sloop  wrote:
>
> 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.

This is probably a really long shot, but is it possible that the
machines which don't work are trying to use TCP to query the server
(e.g because of weird MTU issues, or similar)?
I recently ran into sporadic issues where BIND would simply stop
listening on TCP -- there would be nothing in the logs, but netstat
would confirm the there was suddenly nothing listening on TCP 53.

I created a prometheus rule to monitor for this:
  - name: DNS TCP
rules:
  - alert: DNS Port 53 down on ron.
expr: probe_success{instance="{{server}}",job="dns_tcp_port"}
== 0 or up{job="dns_tcp_port"} ==0
for: 5m
labels:
  severity: page
annotations:
  identifier: '{{ $labels.instance }}'
  summary: "DNS Port 53 down on Ron {{ $labels.instance }}"
  description: "{{ $labels.instance }} probe_success returned
{{ $value }}"

and it fired twice -- and then I upgraded to BIND 9.12.4-P1 and the
problem hasn't happened since...
The obvious questions:
1: what was I running on this machine before? I think 9.12.
-- will have to check git for more detail
2: why didn't I file a bug report / take a dump / something? I kept
meaning to, but it always broke at inopportune times, so I'd just
restart and plan to do a better job next time...

W

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



-- 
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: Should we remove the DLV code?

[Warren Kumari]

At this point I think DLV is actively dangerous -- I'm not sure if it
"easy" to remove the code without too much risk, but an initial start
would be to make it impossible^whard to enable it (and initially log
an error message for people who already have it configured...).

W

On Tue, May 21, 2019 at 2:34 PM Matthijs Mekking  wrote:
>
> Hi Grant,
>
> On 5/20/19 11:44 PM, Grant Taylor via bind-users wrote:
> > On 5/20/19 4:34 AM, Matthijs Mekking wrote:
> >> * It will make the code much easier to maintain, which is beneficial
> >> for users too since that will mean in general less bugs, easier to
> >> find bugs, and easier to extend it with new features.
> >
> > Drive by 2¢ comment:
> >
> > Is the existing DLV code causing a problem or otherwise breaking something?
>
> Not actively, but in general it adds more corner cases, which make it
> harder to investigate potential bugs in validation behavior.
>
> > How much easier will removing the DLV code make maintaining the rest of
> > the code base?
>
> Hard to say, but quoting my colleague "about 50%".
>
>
> > Is the existing DLV code preventing doing something else that is desired?
>
> Not preventing, but it is something that we need to take into account
> every time we touch the validation code, and so there is a maintenance cost.
>
>
> > IMHO if the code is sitting there and not actively causing problems,
> > despite being unsightly, then I'd be inclined to leave it.  If it's
> > anything more than unsightly, I'd pontificate removing it.
>
> Thanks for your input.
>
> Best regards,
>
> Matthijs
>
>
> >
> >
> >
> >
> > ___
> > 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



-- 
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: DNS flag day

[Warren Kumari]

On Fri, Jan 18, 2019 at 3:28 PM Ben Croswell  wrote:

> I would imagine "its a hoax" is code for we dont want to bother
> remediating.
>
>
yah, I get their "Don't want to do it" position, but "It's a hoax" seems
like a poor selection from the possible excuses -- when flag day occurs it
will be clear that this wasn't a hoax, being tricked simply makes you look
stupid / uninformed.

Much better excuses would be along the lines of "We are planning on
remediating" (and hoping the issue goes away), "We are philosophically
opposed to this", "We believe that we are compliant and the testing is
busticated", "This doesn't apply to us", "Nope, you misunderstood, this
only need to be mitigated by servers which process EDNS replies, and our
servers don't do that." or "That's a question for the architecture team,
I'll get them to call you back the week after next. Pardon? I didn't take
your phone number? Oh well", or even "sorry, I'm going through a tunnel and
my reception is poor... EDNS, yes .. comp..
mitiga.." :-P

W


> On Fri, Jan 18, 2019, 3:20 PM Warren Kumari 
>>
>>
>> On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell 
>> wrote:
>>
>>> I would say we had one provider go as far as saying this whole flag day
>>> thing is a hoax.
>>>
>>
>> That's a weird stance / position. "The whole flag day thing is
>> [stupid|overblown|annoying|confusing|on a Friday]" are all positions I can
>> understand - not agree with (modulo the Friday one), but at least
>> understand. 'tis a hoax is just confusing...
>> Flag Day been discussed at length, and presented at multiple DNS events -
>> it seems that a DNS provider who hasn't seen any of the presentations and
>> recognized at least one person pushing this isn't well connected to the
>> community, and should probably be avoided...
>>
>> W
>> P.S: Unless they think it is simply a *very* subtle, long running,
>> widespread hoax... and now I'm wondering if I'm the patsy here :-P
>>
>>
>>
>>
>>> Not sure what option there is other than voting with your wallet and
>>> moving to a different provider.
>>>
>>
>>> May even be worth looking at 2 providers. I see DNS provider redundancy
>>> as being a huge priority after the Dyn DDoS event.
>>>
>>> On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey <
>>> jlight...@dsservices.com wrote:
>>>
>>>> On checking I find that any of our domains that use Network Solutions’
>>>> Worldnic.com nameservers are reporting failures when checked.
>>>>
>>>> For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea
>>>>
>>>> Other people online have posted about Network Solutions as they also
>>>> saw failures.
>>>>
>>>> On calling Network Solutions today they told me they are compliant
>>>> despite what was reported by https://dnsflagday.net/
>>>>
>>>>
>>>>
>>>> This issue is with domains registered at Network Solutions and using
>>>> their Advanced DNS (i.e. their Worldnic name servers).   Other domains we
>>>> have registered with them but pointing to other name servers (i.e. our own
>>>> BIND servers) displayed as compliant.
>>>>
>>>> When I sent them the links they saw what I saw but still claimed they
>>>> are compliant.   They refused to send me something in writing stating that
>>>> so I suggested they reach out to ISC regarding the checker’s results if
>>>> they believe they are compliant, but they said they don’t see the need.
>>>> I’ve asked them to escalate and they say they have but I suspect I’ll not
>>>> hear back from them.
>>>>
>>>> Is there a list of known edns compliant Registrar name severs for the
>>>> larger Registrars?
>>>>
>>>> Is it possible the failures seen are false?   If so, are there
>>>> alternate edns compliance checkers that might show different responses than
>>>> dnsflagday.net?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* bind-users  * On Behalf Of *Ben
>>>> Croswell
>>>> *Sent:* Friday, January 18, 2019 12:19 PM
>>>> *To:* bind-users@lists.isc.org
>>>> *Subject:* Re: DNS flag day
>>>>
>>>>
>>>>
>>>> I shouldn't have posted so closely to responding to th

Re: DNS flag day

[Warren Kumari]

On Fri, Jan 18, 2019 at 2:58 PM Ben Croswell  wrote:

> I would say we had one provider go as far as saying this whole flag day
> thing is a hoax.
>

That's a weird stance / position. "The whole flag day thing is
[stupid|overblown|annoying|confusing|on a Friday]" are all positions I can
understand - not agree with (modulo the Friday one), but at least
understand. 'tis a hoax is just confusing...
Flag Day been discussed at length, and presented at multiple DNS events -
it seems that a DNS provider who hasn't seen any of the presentations and
recognized at least one person pushing this isn't well connected to the
community, and should probably be avoided...

W
P.S: Unless they think it is simply a *very* subtle, long running,
widespread hoax... and now I'm wondering if I'm the patsy here :-P




> Not sure what option there is other than voting with your wallet and
> moving to a different provider.
>

> May even be worth looking at 2 providers. I see DNS provider redundancy as
> being a huge priority after the Dyn DDoS event.
>
> On Fri, Jan 18, 2019, 2:50 PM Lightner, Jeffrey  wrote:
>
>> On checking I find that any of our domains that use Network Solutions’
>> Worldnic.com nameservers are reporting failures when checked.
>>
>> For example this result:  https://ednscomp.isc.org/ednscomp/e30c6cf0ea
>>
>> Other people online have posted about Network Solutions as they also saw
>> failures.
>>
>> On calling Network Solutions today they told me they are compliant
>> despite what was reported by https://dnsflagday.net/
>>
>>
>>
>> This issue is with domains registered at Network Solutions and using
>> their Advanced DNS (i.e. their Worldnic name servers).   Other domains we
>> have registered with them but pointing to other name servers (i.e. our own
>> BIND servers) displayed as compliant.
>>
>> When I sent them the links they saw what I saw but still claimed they are
>> compliant.   They refused to send me something in writing stating that so I
>> suggested they reach out to ISC regarding the checker’s results if they
>> believe they are compliant, but they said they don’t see the need.   I’ve
>> asked them to escalate and they say they have but I suspect I’ll not hear
>> back from them.
>>
>> Is there a list of known edns compliant Registrar name severs for the
>> larger Registrars?
>>
>> Is it possible the failures seen are false?   If so, are there alternate
>> edns compliance checkers that might show different responses than
>> dnsflagday.net?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* bind-users  * On Behalf Of *Ben
>> Croswell
>> *Sent:* Friday, January 18, 2019 12:19 PM
>> *To:* bind-users@lists.isc.org
>> *Subject:* Re: DNS flag day
>>
>>
>>
>> I shouldn't have posted so closely to responding to the other user.
>>
>>
>>
>> I am not running 9.8. I was replying to them about firewalls in regards
>> to their 9.8 issues.
>>
>>
>>
>> Was just hoping for a statement of 9.x or greater supports the needed
>> badvers signaling etc.
>>
>>
>>
>> On Fri, Jan 18, 2019, 12:15 PM Victoria Risk >
>>
>>
>> On Jan 18, 2019, at 9:09 AM, Ben Croswell  wrote:
>>
>>
>>
>> Has ISC released minimum viable BIND version for flag day?
>>
>>
>>
>> Most versions of BIND authoritative servers, going back years, are EDNS
>> compatible. Certainly ALL currently supported versions are compatible. I
>> see you are running 9.8, which has been EOL since September, 2014.  I think
>> that is probably fine, as far as EDNS, however.
>>
>>
>>
>> The change in BIND related to DNS Flag Day is removing workarounds from
>> resolvers, that will retry without EDNS or otherwise try to proceed even
>> when EDNS fails. This change came in the BIND 9.13 development version, and
>> will be in BIND 9.14, which is not yet released.
>>
>>
>>
>> The problem you are seeing is most likely firewall-related.
>>
>>
>>
>> Vicky
>>
>>
>>
>>
>>
>> I looked around and couldn't find anything.
>>
>> ___
>> 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
>>
> ___
> 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

Re: EDNS Compliance

[Warren Kumari]

On Fri, Jan 18, 2019 at 12:07 PM Ben Croswell 
wrote:

> As long as all 4 DNS servers are running the same version, my first
> suggestion would be to check firewalls for dropped packets.
>
> Some FW/IPS drop packets with edns versions other 0 because they see it as
> an attack.
>

This can be generalized to "Some FW/IPS drop packets".
A huge number of nameservers are running with their nameserver software
directly exposed on the Internet (and the rest of their services protected
by iptables / stateless ACLs) - this leads to better stability,
performance, and predictability - the simplification usually also leads to
better security - being able to understand the system and what the (lack
of) firewall is doing make it simpler and easier to protect.

Either your "firewall" is doing really deep inspection and understanding of
the DNS protocol (in which case you are relying on the ALG to be fully
compliant with all behaviors), or you have disabled all ALG work, in which
case the firewall is simply adding another point of failure (and likely
building state, making troubleshooting harder,etc).

Roland Dobbins had some good articles about the fragility and security
decrease caused by stateful devices in front of Internet service type
protocols (such as DNS,etc).

Warren "Fully expecting FW vendor flames" Kumari.



> On Fri, Jan 18, 2019, 12:02 PM N. Max Pierson  wrote:
>
>> Hi List,
>>
>> I am trying to ensure our Bind servers comply with EDNS for the upcoming
>> Flag Day (https://dnsflagday.net/). I am somewhat ignorant to EDNS but
>> from what I have read, the information is somewhat conflicting as some
>> documentation states EDNS is not a record that you configure in your zone
>> file then other sites refer to some sort of OPT record you can configure.
>> So my first question is which of the documentation is correct from what I
>> have read? Is it DNS server functionality that supports EDNS or do you also
>> have to configure something in the zone files?
>>
>> Also, I have 4 (well 5 counting the master that isn't queryable)
>> nameservers with multiple domains served on them. When I run one of my
>> primary domains through the ISC EDNS tool, it comes back as 2 out of the 4
>> are failing EDNS queries.They are all on the same version of Bind
>> (9.8.2rc1) and they are all slaves of the master so they should all have
>> the same records. Can anyone please explain what I need to do to resolve
>> the timeouts listed on the ISC testing tool?
>>
>> Here is what the tool says ...
>>
>>
>> venyu.com. @208.79.48.30 (ns4.venyu.com.): dns=ok edns=ok *edns1=timeout*
>>  edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok ednsflags=ok
>> docookie=ok edns512tcp=ok *optlist=timeout*
>>
>> venyu.com. @69.2.33.250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>> venyu.com. @2604:d800:12::250 (ns1.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>>
>> venyu.com. @69.2.63.250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>> venyu.com. @2604:d800:13::250 (ns3.venyu.com.): dns=ok edns=ok edns1=ok
>> edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok
>> edns512tcp=ok optlist=ok
>>
>> venyu.com. @208.79.48.26 (ns2.venyu.com.): dns=ok edns=ok *edns1=timeout*
>>  edns@512=ok ednsopt=ok *edns1opt=timeout* do=ok ednsflags=ok
>> docookie=ok edns512tcp=ok *optlist=timeout*
>>
>>
>> TIA!!
>>
>> Regards,
>>
>> Max
>> ___
>> 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
>


-- 
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: Can I use multi-purpose servers for authoritative bind dns servers?

[Warren Kumari]

On Sat, Jan 5, 2019 at 7:06 AM Tom Browder  wrote:

> I have two remote servers: (1) one with one IP (used mainly for backups)
> which is planned to be an OpenStreetmap tile server and (2) one with five
> IP addresses used for serving my personal websites with Apache and planned
> to be a mail server.
>
> Note I am currently running mostly static sites but am in the process of
> setting up more dynamic sites running behind a proxy on the apache server.
> Public usage is very light at the moment and probably will remain that way.
>
> Question: Can I use one or both servers as authoritative bind dns servers,
> or should I get one or two dedicated servers for that purpose?
>

Yup, you sure can — in general the resources required to run Bind / DNS for
“normal” usage is fairly small.

YMMV if you are doing this for a large / popular name, or if your existing
boxes are *horriably* overloaded, but generally it’s fine...

>
> If they are usable, is it preferable to have a unique IP instead of
> sharing with other services?
>

Sharing is fine. Having a dedicated IP address *might* be useful under DOS
conditions (easier to ask your isp to null route an up than filter port
53), but not really important...

W


> Thanks, and Happy New Year!
>
> -Tom
> ___
> 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: no port randomization with dig over IPv6 on mac os

[Warren Kumari]

On Fri, Dec 7, 2018 at 5:19 AM Ralph Seichter 
wrote:

> * Jakob Dhondt:
>
> > I have just noticed that when using dig (different versions) on Mac OS
> > (High Sierra) over IPv6 the source port is not randomized.


Hmmm. I’d never noticed that, but I certainly wouldn’t have expected it -
I’m also wondering *how* it is doing this — to increment by 2 it sounds
like there is state being kept - perhaps dig simply relies on the kernel
for the source port and isn’t randomizing at all ( and so the difference is
actually OS difference, and not dig differences?



>
> I may be having a senior moment, but don't IPv6 privacy extensions cover
> address randomization rather than port randomization?
>


Yes, but this has nothing to do with v6 privacy addresses - they are
orthogonal...

W


> -Ralph
> ___
> 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: Book Bind - DNS ?

[Warren Kumari]

On Sat, Oct 13, 2018 at 11:38 AM Maurizio Caloro via bind-users <
bind-users@lists.isc.org> wrote:

> Hello together
>
>
>
> I asking if the documentation from Bind Homepage are enought
>
>- https://www.isc.org/downloads/bind/docs
>
>
>
> or better to buy the version from Oreilly, 5th Edition
>
>- https://www.oreilly.com/library/view/dns-and-bind/0596100574/
>
> That depends on your current knowledge / preferred learning style, etc. I
really like the "DNS and BIND " books, and probably own at least one copy
of each revision. They are very readable, and contain much which will help
make understanding BIND (or NSD or Unbound or Knot or ... ) easier.

W



> Thanks
>
> Mauri
>
>
>
>
>
>
>
>
> ___
> 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: Question about visibility

[Warren Kumari]

On Thu, Oct 11, 2018 at 1:26 PM Admin Hardy  wrote:

>
> I realise this is not specifically a BIND/DNS question and a bit off
> topic so please ignore if need be I realise people are often very busy.
>
> If you you have a website but the host IP you do not list with any
> domain name in DNS, is it definite that this site could never be reached
> via Google.  I do not really know the nuts and bolts of how Google gets
> access to pages.
>
> If for 'some particular reason' instead of developing a site on a local
> dev machine on your LAN and then uploading/installing the site to a
> remote server, you needed 'for what ever reason' to do the development
> and testing on the final live host accessing it via the ip address,
> would this be a way to be 'almost certain' of keeping it hidden from
> unwanted accidental exposure?
>
>
Nope. It is somewhat less likely that it would be discovered / accidentally
exposed, but it is *far* from certain.

If you were wanting to do something like this, I'd suggest having a DNS
name (because that makes it easier), but firewalling it off so that only
"authorized" people can reach it. This could be something like iptables, a
VPN, or, more likely / less annoying, simply having your webserver require
a login to access the content...

W




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


-- 
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: Which timeouts are used by BIND when resolving recursive queries?

[Warren Kumari]

On Fri, Oct 5, 2018 at 11:12 AM Alberto Colosi  wrote:

> RFC say all
>
> read RFC
>
>
> BIND is a DNS system not an alien so follow RFC
>

No, BIND is an **implementation** of DNS software.

There is much in the RFCs that is subject to interpretation, or not
necessarily well defined. Things like preferred timeouts fall into this
category.

This answer is almost as helpful as Alberto's, but as far as I know, these
timeouts are not well defined, other than in the BIND source.

Here is some of what you are looking for:
http://users.isc.org/~each/doxygen/bind9/resolver_8c-source.html#l00143
and
http://users.isc.org/~each/doxygen/bind9/resolver_8c-source.html#l00178
and
http://users.isc.org/~each/doxygen/bind9/resolver_8c-source.html#l02083


and some of the defaults:
https://github.com/isc-projects/bind9/blob/fa03f941027cd060613f773e63701b5baa77/bin/named/config.c




The ARM ("https://www.isc.org/downloads/bind/doc/bind-9-10/; ) has some
useful info too -- https://www.isc.org/downloads/bind/doc/bind-9-10/


>
> Go and read RFC
>

Great. Please point at the RFC which specifies the base timeout and EDNS0
backoff.

W




>
>
>
> --
> *From:* bind-users  on behalf of ip
> admin via bind-users 
> *Sent:* Friday, October 5, 2018 4:13 PM
> *To:* bind-users@lists.isc.org
> *Subject:* Which timeouts are used by BIND when resolving recursive
> queries?
>
> Hi,
>
>  I understand that I can configure a global timeout for resolving
> recursive queries (resolver-query-timeout) but find that I cannot configure
> the timeout for an individual query used during DNS resolution.
>
>  For testing I configured one unreachable forwarder (and enabled forward
> only) and saw (tcpdump) that BIND (9.10.6-P1) is first trying two queries
> with EDNS which each seems to have a timeout of 1.2s. Afterwards queries
> without ENDS are sent which seem to have a timeout of 1.6s, then 3.2s, then
> 6.4s, then 9s, finally the maximum (=total) resolver-query-timeout of 30s
> is reached.
>
>  Is the timeout behaviour documented anywhere (similar to a stub resolver
> or dig, i.e. how long are timeouts, how many tries per server etc).
>
>  If someone did find a logging setting that shows which servers are used
> when recursing (forwarding or delegations) to find a response (and when the
> individual queries time out) that would be helpful as well.
>
> Regards
>  Tom
>
> ___
> 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: NTP through DNS?

[Warren Kumari]

On Fri, Sep 21, 2018 at 7:57 AM Danny Mayer  wrote:

> On 9/19/2018 10:12 AM, Andrew Latham wrote:
> > You can add SRV records for NTP to your domain if that is what you are
> > asking.
> >
>
> NTP doesn't use SRV records and I don't see a use case to do so.
>

Well, apparently at one point you did :-) --
http://lists.ntp.org/pipermail/questions/2004-December/003645.html

It seems that FreeIPA does actually use SRV for NTP (
https://www.redhat.com/archives/freeipa-users/2014-August/msg00254.html)
It shows up in various other FreeIPA discussion and some mentions of is
being used with NetApp.


W


Therefore I have no idea why this would be any benefit. You can add NTP
> specific FQDN's as A or  or CNAME records if that would be helpful.
>
> Danny
>
> > On Wed, Sep 19, 2018 at 9:09 AM Mauricio Tavares  > > wrote:
> >
> > Stupid question: can I publish/query the NTP server through DNS the
> > same way I can ask who is doing LDAP?
> ___
> 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: load balancing

[Warren Kumari]

On Tue, Sep 18, 2018 at 4:01 PM SIMON BABY  wrote:

> Hi,
>
> Are we support load balancing with latest DNSSEC ? I have a DNSSEC
> application with unbound library. Do i have to add any extra configuration
> to support Load Balancing?
>

Your question is sufficiently light on detail that it cannot be
realistically answered.

What sort of load balancing?
1: Traditional SLB - you hand out one IP address, and have a load balancer
widget which shares this to multiple backends?
2: Global SLB - you hand out different IP addresses to different clients?
3: Round Robin - you hand out different IP addresses, but randomly / in a
order, not tied to specific clients?
4: Anycast - you hand out the same IP address, but this lives on multiple
sites, and routing takes care of getting people to the closest site?
5: Multiple nameservers? Something else?

The term "load balance" is very vague / can be applied to multiple things -
for all of the above except  #2, this should just work without any changes.
GSLB *may* require more work, but may not. # 5 is sufficiently undefined
that it cannot really be answered :-)

What *exactly* is the question / scenario you are asking?
W




>
> Rgds
> Simon
> ___
> 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: DNSSEC will eventually generate Identical Key ID's

[Warren Kumari]

On Mon, Sep 10, 2018 at 4:45 AM Ray Bellis  wrote:

> On 09/09/2018 18:51, Mark Elkins wrote:
> > Just for the record, although I do look from a curiosity point of view
> > for Identical Key ID's once every few month - I've never seen them -
> > until now.
> >
> > Now I have them - generated by BIND within a few days of each other...
> >
> > I've been running DNSSEC for 7 years and have around 400 DNSSEC keys for
> > 133 signed Domains.
> > I'm a smallish Registrar for ZA domains.
> >
> > Never assume a KeyID is unique.  :-)
>
> It's inevitable that they won't be.
>
> With only a 16 bit key tag space (and in 2016 Roy Arends discovered that
> the effective space is only 15 bits) then due to the birthday collision
> paradox you only need of the order of sqrt(32k) different keys to get a
> 50% chance of a collision.
>
>
This reminds me of some interesting (well, interesting to me :-)) related
research Ben Laurie and I did around that time -- while looking at the
distribution of generated keys I noticed that OpenSSL / GnuTLS generate a
different distribution than e.g mbedTLS.
OpenSSL / GnuTLS optimize the generation of primes by setting the least
significant bits (fair, they have to be odd to be primes :-)) but also
clear the most significant bits of both P and Q (to ensure that the product
of P & Q do not overflow) -- this results in a key with less bits of
"security" than most would expect...

W





> Ray
>
> ___
> 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: DNSSEC will eventually generate Identical Key ID's

[Warren Kumari]

On Sun, Sep 9, 2018 at 2:30 PM Anand Buddhdev  wrote:

> On 09/09/2018 19:51, Mark Elkins wrote:
>
> > Never assume a KeyID is unique.  :-)
>
> One of the DNSSEC RFCs specifically says that the KeyID is not meant to
> be unique. I can't remember which one, and it's too late on a Sunday
> evening to be reading RFCs :)
>

You are thinking of RFC4034, Section 8. Security Considerations:

The key tag is used to help select DNSKEY resource records
efficiently, but it does not uniquely identify a single DNSKEY
   resource record.  It is possible for two distinct DNSKEY RRs to have
   the same owner name, the same algorithm type, and the same key tag.
   An implementation that uses only the key tag to select a DNSKEY RR
   might select the wrong public key in some circumstances.  Please see
   Appendix B for further details.





>
> Even then, I've had the misfortune of dealing with a vendor whose
> developers didn't read the RFCs properly, and designed their key store
> using the key IDs as indexes. So one fine day, we had a zone signed with
> one key, but the DS record came from another key. Boom. Yuck. What a
> mess it was to sort out!
>
>

Oooh, that sounds like fun to debug
W



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


-- 
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: Domain name based multihome routing?

[Warren Kumari]

On Tue, Jun 26, 2018 at 12:45 PM Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> On 06/25/2018 11:08 PM, Dale Mahalko wrote:
> > * The secondary program looks up the domain in a database, which also
> > includes the multihome destination for each domain. If a match is found,
> > a route is created to that multihome destination. Aliased acceleration
> > domains such as Akamai will be matched using the primary domain name.
>
> Are you saying that you want to dynamically update routes to IPs
> resolved in real time to specific host / domain names?  Such that
> traffic to specific hosts / domain names is routed over DSL?  With
> things that don't match conditions routed over cell?



It feels like one should be able to cobble together something hilarious
using:
A: RPZ to return a  only answer,
B: NAT64

Have RPZ suppress the A record, and return a synthesized  with the
NAT64 prefix tacked on the front. This will route it to a NAT64 box which
converts it to a v4 address, and Bobs yer uncle.

This seems like it would work, but be fragile and annoying.

W


>
> > * I want to put all the huge background bandwidth eating maintenance
> > downloads such as Microsoft Windows updates, Microsoft Store updates,
> > Microsoft P2P updates, Steam game downloads and updates, Adobe updates,
> > iTunes updates, iPhone iOS and App updates, and so forth on the slow DSL.
> >
> > * I want to put all the other things that are important to me like
> > multiplayer gaming UDP streams, remote desktop / SSH, video streaming,
> > and general web browsing on the cellular modem.
>
> I think I understand what you want to do and why you want to do it.
>
> It seems like you're using named as the source of information to feed
> into the process that dynamically updates routing.
>
> I find the pausing of named to be questionable.  But I understand that
> you want to make sure that no connections are started until after the
> (re)routing has been done.
>
> I feel like most of this is outside of named's scope and that it would
> run as a different user.
>
> I would suggest exploring BIND's new Response Policy Service.  I think
> it provides a way for BIND to send information to a side program for
> various ""filtering actions.  IMHO there's no reason that such a side
> program has to actually filter requests / responses.  Instead, you could
> use that as an information feed to do what you're wanting to do with IPs
> and routes.  I just don't know about the ability to pause the response.
> Unless it's possible to do the route modification before returning the
> reply to BIND.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
> ___
> 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: Stopping name server abuse

[Warren Kumari]

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  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: Slow reply under heavy load (on a specific NIC ip)

[Warren Kumari]

On Mon, Jun 4, 2018 at 8:20 AM Ict Security 
wrote:

> Hi guys,
>
> we are running a Bind 9.x Server, everything is going fine.
> Under particular heavy load mometns, with some hundreds of concurrent
> queries coming in, sometime Bing stops answering for some seconds or
> answer with important delays.
>
> But, when i try to query the same server/same Bind on a NIC alias IP
> during congestion on the main IP, everything is fast!
>

​This sounds suspiciously like ​conntrack (or some other state / connection
tracking) becoming full.

Depnding on OS / version, does:
conntrack -L
or
cat /proc/net/ip_conntrack
produce a lot of output?

Are you running iptables / ipfw / ? Behind a firewall? Are there
any interesting messages in [/var/log/message|/var/log/syslog/|] ?

W



>
> I changed some tunings in:
> max-connections in /proc
> txqueue in network
> ipv4_ports
>
> and i mitigate something.
> But it is not completely solved.
>
> Do you think Bind could have some NIC IP limit?
> Some ideas?
>
> Really thank you!
> Francesco
> ___
> 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: extranet.aro.army.mil - not resolving

[Warren Kumari]

Try it with +cd and see if that fixes it.

The DNSSEC stuff for this domain is all borked up -- sufficiently that
I felt like I was playing snakes and ladders while looking at:
http://dnsviz.net/d/extranet.aro.army.mil/dnssec/
On Thu, May 31, 2018 at 5:45 PM John Miller  wrote:
>
> Hi Con,
>
> May I suggest running dig +trace extranet.aro.army.mil from your
> nameserver?  That'll make the delegation process explicit and help you
> troubleshoot a little better.  It could be that one of the three main
> army.mil nameservers is unreachable by your ns for some reason
> (routing being a likely culprit).
>
> John
>
> On Thu, May 31, 2018 at 5:29 PM, Con Wieland  wrote:
> > and here they are but I don’t see anything indicating what the problem 
> > might be
> >
> > 31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 
> > (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A 
> > +E (128.200.1.201)
> > 31-May-2018 13:56:01.151 resolver: debug 1: createfetch: 
> > aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > 31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 
> > (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A 
> > +E (128.200.1.201)
> > 31-May-2018 13:56:06.153 resolver: debug 1: createfetch: 
> > aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > 31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 
> > (extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A 
> > +E (128.200.1.201)
> > 31-May-2018 13:56:11.158 query-errors: debug 1: client 128.200.1.20#37203 
> > (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for 
> > extranet.aro.army.mil/IN/A at query.c:7215
> > 31-May-2018 13:56:11.158 resolver: debug 1: createfetch: 
> > aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > 31-May-2018 13:56:21.168 query-errors: debug 1: client 128.200.1.20#37203 
> > (extranet.aro.army.mil): view internal: query failed (SERVFAIL) for 
> > extranet.aro.army.mil/IN/A at query.c:7215
> >
> >> On May 31, 2018, at 12:51 PM, Reindl Harald  wrote:
> >>
> >>
> >>
> >> Am 31.05.2018 um 21:42 schrieb Con Wieland:
> >>> agreed but why would my server not resolve it while others do?
> >>
> >> ask the logs of 128.200.1.201
> >>
> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
> >> ;; global options: +cmd
> >> ;; Got answer:
> >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
> >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >> ;; SERVER: 128.200.1.201#53(128.200.1.201)
> >>
>  On May 31, 2018, at 12:16 PM, Reindl Harald  
>  wrote:
> 
> 
> 
>  Am 31.05.2018 um 21:09 schrieb Con Wieland:
> > I have a nameserver that can not resolve extranet.aro.army.mil.
> 
>  terrible slow and insane config - fix it
> 
>  https://intodns.com/aro.army.mil
> 
>  ;; Query time: 1175 msec
>  ;; SERVER: 127.0.0.1#53(127.0.0.1)
>  ;; WHEN: Do Mai 31 21:12:26 CEST 2018
>  ;; MSG SIZE  rcvd: 247
> 
>  ;; Query time: 1109 msec
>  ;; SERVER: 8.8.8.8#53(8.8.8.8)
>  ;; WHEN: Do Mai 31 21:12:52 CEST 2018
>  ;; MSG SIZE  rcvd: 191
> 
>  ;; ANSWER SECTION:
>  aro.army.mil.   2022IN  NS  ns03.army.mil.
>  aro.army.mil.   2022IN  NS  ns02.army.mil.
>  aro.army.mil.   2022IN  NS  ns01.army.mil.
> 
>  ;; Query time: 163 msec
>  ;; SERVER: 192.82.113.7#53(192.82.113.7)
>  ;; WHEN: Do Mai 31 21:15:37 CEST 2018
>  ;; MSG SIZE  rcvd: 98
>  WarnSOA REFRESH WARNING: Your SOA REFRESH interval is: 900. 
>  That is
>  not so ok
>  WarnSOA RETRY   Your SOA RETRY value is: 90. That is NOT OK
> >>
> >
> > ___
> > 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
>
>
>
> --
> John Miller
> Senior Systems Engineer
> Brandeis University ITS
> johnm...@brandeis.edu
> (781) 736-4619
> ___
> 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: Test mail to bind-users

[Warren Kumari]

On Thu, May 31, 2018 at 3:48 AM Matus UHLAR - fantomas
 wrote:
>
> >On Wed, 30 May 2018, Michael McNally wrote:
> >>We have had reports that posts to bind-users are (in at least some
> >>cases) triggering unwelcome direct-to-the-submitter messages from
> >>spammers.
>
> it was about time ;-)
>
> On 31.05.18 08:28, G.W. Haywood via bind-users wrote:
> >I'm not sure that there's much that a list manager can do about it.
>
> they can find the abusers relay posts to spam senders and remove them.
>
> I have met similar case on IRC some 15-20 years ago. Spammer joined a
> channel, and relayed nicknames of those who joined (or left) so they got
> spam srom another nickname
>

... these has also been a (recent) issue where someone subscribed
their ticketing system to the list, and so every posting got a:
[ RT - #4217 ] AutoReply: Re: 

Thank you for opening a ticket. We will get to it soon.
Thanks,
   NOC.

W

> >This has been an issue for most of the lists to which I've subscribed
> >for decades.  My list addresses only accept mail from the lists to
> >which they're subscribed, and I'd imagine most other subscribers (at
> >least to the BIND list) would take similar precautions if necessary.
>
> not everyone can set up such configuration and not everyone of those who can
> is willing to play with it.
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Remember half the people you know are below average.
> ___
> 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: also-notify and allow-notify

[Warren Kumari]

On Fri, May 18, 2018 at 9:41 AM Blason R  wrote:

> Hi there,

> Thanks for the update and here is my config and error I am getting. Can
you please suggest correct method that should be implemented?


I believe (but don't have a machine to confirm on) that the syntax should
be:

also-notify { 192.168.5.49 port ;};

(note the lack of semicolon between the IP and "port ")

W


> **
> zone "malware.trap" {
>  type master;
>  file "/var/lib/bind/zones/malware.trap.db";
>  notify explicit;
>  also-notify { 192.168.5.49; port ;};
>  allow-transfer {192.168.5.49; };
>  allow-query { localhost;};
>  };

> zone "whitelist.allow" {
>  type master;
>  file "/var/lib/bind/zones/whitelist.allow";
>  notify explicit;
>  also-notify { 192.168.5.49; port ;};
>  allow-transfer {192.168.5.49; };
>  allow-query { localhost;};
>  };

> zone "block.tld" {
>  type master;
>  file "/var/lib/bind/zones/block.tld.db";
>  notify explicit;
>  also-notify { 192.168.5.49; port ;};
>  allow-transfer {192.168.5.49; };
>  allow-query { localhost;};
>  };

> **



> May 18 13:04:42 dnsfw named[1134]: using up to 4096 sockets
> May 18 13:04:45 dnsfw named[1134]: loading configuration from
'/etc/bind/named.conf'
> May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:34:
missing ';' before ''
> May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:43:
missing ';' before ''
> May 18 13:04:46 dnsfw named[1134]: /etc/bind/named.conf.default-zones:52:
missing ';' before ''
> May 18 13:04:46 dnsfw systemd[1]: bind9.service: Main process exited,
code=exited, status=1/FAILURE
> May 18 13:04:46 dnsfw rndc[1313]: rndc: connect failed: 127.0.0.1#953:
connection refused
> May 18 13:04:46 dnsfw systemd[1]: bind9.service: Control process exited,
code=exited status=1


> On Fri, May 18, 2018 at 12:08 AM, Matthew Pounsett 
wrote:



>> On 17 May 2018 at 13:30, Blason R  wrote:

>>> Hi,

>>> I have RPZ installed on server and its acting as a master server but
somehow port setting is not working on master

>> [...]


>>> So here I am sending notification  to 192.168.5.49 on port 4545; my
queries are

>>> How do I configure port on slave 4545 so that slave server can start
listening on that port.


>> Your slave needs to be listening on the correct IP/port to receive the
NOTIFY.  In the current BIND Administrator's Reference Manual[0], the
discussion on Interfaces starts at page 98.


>>> And my master is failing  after restarting the services due to
notify-them statement.


>> You don't indicate what the error is, but I'm willing to bet it's the
fact that you're trying to specify a masters list by name as well as a
port.  If you look at the 'also-notify' statement definition, you can see
that you're able to use a 'masters' list OR an IP address and port
combination, but not both (ARM pp. 71).  You should specify the port number
as part of the definition of the masters list, not where you use the
masters list.

>> [0]: 



> ___
> 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: DNS primary and secondary receiveing queries at the same time

[Warren Kumari]

On Thu, May 17, 2018 at 4:26 PM Roberto Carna 
wrote:

> Dear Tony, so you say that it's impossible what I want...

> In this scenario that my two DNS servers respond queries at the same
> time, suppose the primary server goes downhow do clients know that
> they have to query the secondary DNS server at this moment?


If they don't get an answer from the first one they try, they will try the
next one, and then the next one, etc...

W


> Thanks again.

> 2018-05-17 11:19 GMT-03:00 Tony Finch :
> > Roberto Carna  wrote:
> >>
> >> I always believed that all the client queries coming from Internet go
> >> to the DNS primary server, and if it is down, just in this case go to
> >> the DNS secondary server.
> >
> > It can't happen that way because there's no way for a resolver to tell
> > which is which.
> >
> > Tony.
> > --
> > f.anthony.n.finch    http://dotat.at/
> > Hebrides: Southeast 4, veering south 5 or 6, then veering west later.
Moderate
> > or rough. Rain later. Good, occasionally moderate.
> ___
> 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: DNS primary and secondary receiveing queries at the same time

[Warren Kumari]

On Thu, May 17, 2018 at 4:07 PM Roberto Carna 
wrote:

> Hi people, I've implemented two BIND9 servers for my company, one as
> primary public DNS server and the other as secondary public DNS
> server.

> I always believed that all the client queries coming from Internet go
> to the DNS primary server, and if it is down, just in this case go to
> the DNS secondary server.

Nope, you are incorrect -- there isn't really a "primary" and "secondary" -
that is poorly used terminology.
There are "masters" and "slaves" (also poor terminology) - new information
gets published on masters, and the slaves copy and serve that, but both
will get queries.


> But it seems it is different than I believedwhen I see the query
> log file in primary and secondary DNS servers, I can see queries
> coming from Internet in both serversin other words, the two DNS
> servers are being contacted all the time.

> Is there any way to make DNS clients from Internet always contact my
> primary DNS server and just if it is down the clients must contact the
> secondary DNS server ???

Nope. Resolvers will choose between your servers at random (it's not
actually random, but close enough for this discussion).

W


> Special thanks !!!

> Robert
> ___
> 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: root hints

[Warren Kumari]

On Wed, May 2, 2018 at 5:02 PM Greg Rivers 
wrote:

> On Wednesday, May 02, 2018 16:48:00 Rick Dicaire wrote:
> > ... what is the official/best practise/recommended way to update
> root.hints?
> >
> https://www.iana.org/domains/root/files
>
> But you don't really need it unless you're running an internal root; as
> stated at that link, "For many pieces of software, this list comes built
> into the software.". As I recall, this is true for BIND.



Yup, this is built into BIND and automagically managed.

Unless you have a *really* good reason to monkey with it, ‘tis best left
alone these days...

W


>
> --
> Greg Rivers
> ___
> 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: Somehow my DNS is not starting up

[Warren Kumari]

PA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 119.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 120.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 121.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 122.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 123.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 124.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 125.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 126.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 127.100.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 127.IN-ADDR.ARPA
>> Apr 18 23:08:45 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 254.169.IN-ADDR.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 2.0.192.IN-ADDR.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 100.51.198.IN-ADDR.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 113.0.203.IN-ADDR.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone:
>> 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: D.F.IP6.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 8.E.F.IP6.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 9.E.F.IP6.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: A.E.F.IP6.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: B.E.F.IP6.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]:
>> automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]: command
>> channel listening on 127.0.0.1#953
>> Apr 18 23:08:46 dnsfw.isn.in <http://dnsfw.isn.in> named[1869]: command
>> channel listening on ::1#953
>> Apr 18 23:09:42 dnsfw.isn.in <http://dnsfw.isn.in> dockerd-current[880]:
>> time="2018-04-18T23:09:41.305371273+05:30" level=error
>> msg="libcontainerd: failed to receive event from containerd: r
>> Apr 18 23:09:43 dnsfw.isn.in <http://dnsfw.isn.in> dockerd-current[880]:
>> time="2018-04-18T23:09:41.859430667+05:30" level=info
>> msg="libcontainerd: new containerd process, pid: 1877"
>> Apr 18 23:09:43 dnsfw.isn.in <http://dnsfw.isn.in> dockerd-current[880]:
>> time="2018-04-18T23:09:42.860103049+05:30" level=info
>> msg="libcontainerd: new containerd process, pid: 1887"
>> Apr 18 23:09:44 dnsfw.isn.in <http://dnsfw.isn.in> systemd[1]:
>> named.service start operation timed out. Terminating.
>> Apr 18 23:09:44 dnsfw.isn.in <http://dnsfw.isn.in> systemd[1]: Failed to
>> start Berkeley Internet Name Domain (DNS).
>> -- Subject: Unit named.service has failed
>> -- Defined-By: systemd
>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> --
>> -- Unit named.service has failed.
>> --
>> -- The result is failed.
>> Apr 18 23:09:45 dnsfw.isn.in <http://dnsfw.isn.in> polkitd[532]:
>> Unregistered Authentication Agent for unix-process:1857:160748 (system
>> bus name :1.29, object path /org/freedesktop/PolicyKit
>> Apr 18 23:09:44 dnsfw.isn.in <http://dnsfw.isn.in> systemd[1]: Unit
>> named.service entered failed state.
>> Apr 18 23:09:44 dnsfw.isn.in <http://dnsfw.isn.in> systemd[1]:
>> named.service failed.
>>
>>
>> On Wed, Apr 18, 2018 at 7:38 PM, Warren Kumari <war...@

Re: Somehow my DNS is not starting up

[Warren Kumari]

On Wed, Apr 18, 2018 at 5:13 AM, Daniel Stirnimann
 wrote:
> On 18.04.18 10:57, Blason R wrote:
>> Well it just loads fine when I run from command line i.e. named -u named
>> -n 4 -c /etc/named.conf
>

... and how long does it take to start up when doing so (in case it is
simply taking too long and systemd get bored waiting).

Also, what does:

systemctl status -l -n 50 named
and
journalctl -u named

show?

Gah, I hate systemd - it makes debugging startup really hard.
W



> Just a guess. If you use and have SELinux in enforcing mode (see
> getenforce), this could be a reason. Your user process runs unconfined
> that's why it works from the command line if you have a policy violation.
>
> You may want to check the audit logs and fix the broken configuration.
>
> sealert -a /var/log/audit/audit.log
>
>
> 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



-- 
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: BIND Server running but not responding

[Warren Kumari]

I'm *really* not a Windows person, but all of the "could not listen on
UDP socket: permission denied" log messages strongly imply that BIND
is not able to bind() to the socket -- can you try start this with
something like Administrator privileges?

W

On Wed, Apr 18, 2018 at 9:51 AM, Admin Hardy  wrote:
>
> I would be so grateful of your help in this issue.
>
> I am running BIND 9 on Windows 7
> Service "ISC BIND" shows as started up
>
> As a temporary measure I have disabled firewall on host and client to rule
> out any issue there.
>
> I have set the DNS IP Address on the client ipv4 to just the address of the
> BIND host 192.168.1.67
>
> I did DNS flush on the client and also cleared any possible DNS caching in
> the client requesting software.
>
> I am requesting resolution for "rota.rotatesting.com" (see below)
>
> the full http request happens to be
> "http://rota.rotatesting.com:8081/mywebapp/;
>
> The client software (browser) cannot resolve the name
> I downloaded dedicated DNS Lookup software and the request times out
> looks like the server is not responding with anything.
>
> Just two of the log files have logging.
>
> I would be really grateful if you could suggest possible causes:
>
> Here is content of file C:\named\zones\db.rotatesting.com.txt
> ===
> ===
>
> $TTL 6h
> @   IN SOA  AndrewHardy.rotatesting.com.hostmaster.rotatesting.com.
> (
> 2018041801
> 10800
> 3600
> 604800
> 86400 )
>
> @   NS  AndrewHardy.rotatesting.com.
>
>
> AndrewHardy IN A192.168.1.67
> *.rotatesting.com.INA192.168.1.67
>
>
> Here is content of file C:\named\etc\named.conf
> ===
> ===
>
> options {
> directory "c:\named\zones";
> allow-transfer { none; };
> recursion no;
> };
>
>
> zone "rotatesting.com" IN {
> type master;
> file "db.rotatesting.com.txt";
> allow-transfer { none; };
> };
>
> key "rndc-key" {
> algorithm hmac-md5;
> secret "bBuMhqgS+8IL1SqZAKC+YQ==";
> };
>
> controls {
> inet 127.0.0.1 port 953
> allow { 127.0.0.1; } keys { "rndc-key"; };
> };
>
> logging {
> channel default_file {
> file "C:\named\default.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel general_file {
> file "C:\named\general.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel database_file {
> file "C:\named\database.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel security_file {
> file "C:\named\security.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel config_file {
> file "C:\named\config.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel resolver_file {
> file "C:\named\resolver.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel xfer-in_file {
> file "C:\named\xfer-in.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel xfer-out_file {
> file "C:\named\xfer-out.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel notify_file {
> file "C:\named\notify.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel client_file {
> file "C:\named\client.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel unmatched_file {
> file "C:\named\unmatched.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel queries_file {
> file "C:\named\queries.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel network_file {
> file "C:\named\network.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel update_file {
> file "C:\named\update.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel dispatch_file {
> file "C:\named\dispatch.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel dnssec_file {
> file "C:\named\dnssec.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel lame-servers_file {
> file 

Re: "Hiding" version.bind in /etc/bind/named.conf.options doesn't work

[Warren Kumari]

On Wed, Feb 28, 2018 at 12:57 PM, G.W. Haywood via bind-users
 wrote:
> Hi there,
>
> On Wed, 28 Feb 2018, (Ing. Pedro Pablo Delgado Martell) wrote:
>
>> Good morning, I'm trying to make it more difficult for an attacker to
>> get my DNS server version.
>
>
> Waste of time.  The attacks are automated, and will be mounted anyway.

Thank you - this has long been a position that I've held/espoused.

It is easier / cheaper / faster for an attacker to simply assume that
a machine is running vulnerable software and try all exploits on it,
instead of carefully checking to see what services / versions a server
advertises and restricting to those.
Also, if you are *not* running a vulnerable version of , it
doesn't matter if the attacker knocks on the door, and if you *are*
running a vulnerable version, having the attacker not know that
doesn't provide you any protection.

I realize that this sounds somewhat ranty, but I've recently had to
deal with some checklist-style security audits / certifications which
require things like hiding version information (and pointing at the
"firewall") while completely ignoring actual security issues (like
"are the versions known vulnerable", "are the firewalls / ACLS /
whatever sane", "do your users know not to click on
unpaid_invoice.doc", "do you use 2FA", "are all your credential
'Hunter2'" ?)


W


>
> --
>
> 73,
> Ged.
> ___
> 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: bind-users Digest, Vol 2842, Issue 2

[Warren Kumari]

On Wed, Feb 21, 2018 at 3:06 PM, SIMON BABY  wrote:
> Hi,
>
>
> 1. Can I use  BIND9, for implementing only the client resolve/validation
> part?  My system has limited memory and CPU power.

Yup, sure can. BIND isn't the smallest / lowest CPU software out
there, but you can definitely set it up to be just a DNSSEC validating
resolver (and not an authorative server).

> 2. In the client resolution part, can i send the queries directly to any of
> the root servers? Instead of any public name server.

Your question is a bit vague, I'm assuming you mean "Have BIND do the
normal resolution (e.g for www.example.com ask the root, and then
follow the referral to example.com's name servers, and then asks them
for www.example.com (and not e.g forward to Google Public DNS)?" If
so, then, yes, definitely -- this is the default behavior. Having BIND
forward queries to another recursive (like 8.8.8.8, OpenDNS, Quad9)
requires special configuration (with the "forward" command).

I'd suggest reading Cricket's "DNS and BIND"
(http://shop.oreilly.com/product/9780596100575.do) as a good intro to
this.

W

>
>
> Rgds
> Simon
>
>
> On Wed, Feb 21, 2018 at 11:09 AM,  wrote:
>>
>> Send bind-users mailing list submissions to
>> bind-users@lists.isc.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.isc.org/mailman/listinfo/bind-users
>> or, via email, send a message with subject or body 'help' to
>> bind-users-requ...@lists.isc.org
>>
>> You can reach the person managing the list at
>> bind-users-ow...@lists.isc.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bind-users digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: questions on allow-query (Tony Finch)
>>2. Re: questions on allow-query (Bob Harold)
>>3. Re: questions on allow-query (Barry Margolin)
>>4. Help  (PENG, JUNAN)
>>5. Re: Help  (Tony Finch)
>>
>>
>> --
>>
>> Message: 1
>> Date: Wed, 21 Feb 2018 13:18:09 +
>> From: Tony Finch 
>> To: Evan Hunt 
>> Cc: "Darcy Kevin (FCA)" ,
>> "bind-users@lists.isc.org" 
>> Subject: Re: questions on allow-query
>> Message-ID: 
>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>>
>> Evan Hunt  wrote:
>> >
>> > One thing to keep in mind, though, is that the two services will share
>> > each
>> > other's fates.  If I were deploying a really big high-traffic server, I
>> > might consider whether I wanted my recursive service to have to wait for
>> > all the zones to load before it could function, or whether I wanted to
>> > have
>> > to update my authoritative server because it was vulnerable to a crash
>> > bug
>> > in the recursive code.
>>
>> On our recursive servers we have authoritative copies of all our local
>> zones so that they can give answers for on-site stuff even when bits of
>> the network are broken. (Downstream validating resolvers will probably be
>> out of luck tho.) This is about 70 zones, average size about 2MB, biggest
>> about 30MB. But, we also have RPZ and the biggest blocklist is about half
>> a gig and this dominates the startup time (it takes nearly 20 seconds).
>> This isn't an availability problem, tho, because the recursive servers are
>> in an HA cluster using keepalived and the health checker won't bring a
>> node into service until it has finished starting.
>>
>> Our authoritative servers are separate. Probably the main reason for not
>> turning them into views on the recursive servers is that the auth servers
>> have to be more exposed to attack from the Internet. Our recursive servers
>> can do things like firewall off external TCP connection attempts, to avoid
>> connection pool exhaustion attacks. I've done less HA engineering on our
>> auth servers, and I'm relatively relaxed about patching them, because I
>> (foolishly?) trust other resolvers out on the Internet to make effective
>> use of my secondaries.
>>
>> Tony.
>> --
>> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h
>> punycode
>> Rockall: Southerly, 5 at first in far southeast, otherwise 6 to gale 8,
>> increasing severe gale 9 at times, veering westerly 5 or 6 later in
>> northwest.
>> Rough or very rough, occasionally high in northwest. Rain or showers.
>> Moderate
>> or good.
>>
>>
>> --
>>
>> Message: 2
>> Date: Wed, 21 Feb 2018 09:16:23 -0500
>> From: Bob Harold 
>> To: Tony Finch 
>> Cc: Evan Hunt , "bind-users@lists.isc.org"
>> 
>> Subject: Re: questions on allow-query
>> Message-ID:
>>
>> 
>> Content-Type: text/plain; 

Re: DNSSEC validation

[Warren Kumari]

On Tue, Feb 13, 2018 at 3:42 PM, SIMON BABY  wrote:
> Hello Evan,
>
> Thank you so much for the quick response.
>
> My requirement is to implement only the recursive resolve and validation
> part of the DNSSEC in my client application. Our CPU and memory are very
> limited. So I am not sure I can go and use BIND 9.
>

I get that this is bind-users, but have you looked at https://getdnsapi.net/ ?

W

> With BIND 9, can I integrate the library in my application to send queries
> and validate the answer in my client code itself. Can you please point if
> any sample code.
>
>
> Rgds
> Simon
>
>
>
> On Tue, Feb 13, 2018 at 12:26 PM, Evan Hunt  wrote:
>>
>> On Tue, Feb 13, 2018 at 12:08:18PM -0800, SIMON BABY wrote:
>> > I am trying to implement the full recursive resolver with libbind
>> > library
>> > in my client code. I am not using resolv.conf in my implementation. Can
>> > anyone please help to point any sample code for this.
>>
>> Not even BIND uses libbind anymore.
>>
>> What's the purpose of this? Why not just use BIND 9, or some other
>> existing resolver?
>>
>> --
>> Evan Hunt -- e...@isc.org
>> Internet Systems Consortium, Inc.
>
>
>
> ___
> 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: Minimum TTL?

[Warren Kumari]

Ok, so I've never used forwarders (actually, that's not strictly true;
I've used them twice, but it was to work around weird issues, and I
felt dirty), but couldn't increasing the TTL cause stupid
configuration issues to become immortal RRs?

I've seen a number of instances where people who *do* forward manage
to make a loop - this works just fine under normal conditions (at
least with BIND's default of "forward first" - resolver A gets a
question for an answer not in it's cache, it asks B, B asks A, after a
few rounds this hits the forward timeout, and one of them recurses to
find the answer. Now the pair (or pathologically, group) has the
answer, and this will decay, just like any other TTL. Eventually it
expires, you get a brief spike as they both ask each other, and the
process repeats.

If TTLs were capped to a minimum, A would time it out, and ask B. B
will respond with e.g 4 seconds, and A will bump that back up to 5. 4
seconds later, B will time out, and will ask A. A still has 1 second
left, to it answers with 1. B helpfully bumps that back to 5, 1 second
later, A expires, and forwards to B, ...

Now, I'm guessing that I'm missing something obvious here (more than
"Well, don't forward and minimum cap TTLs!" and / or "Don't make loops
of forwarders, it's silly"), but I'm not sure what...

W

On Sat, Feb 10, 2018 at 2:42 PM, Matus UHLAR - fantomas
 wrote:
>>> But to answer your question, off-hand, I'd say that any TTL under 60s is
>>> =
>>> suspicious and any TTL under 10s is almost certainly intentionally =
>>> abusive.
>
>
> On 09.02.18 23:11, John Levine wrote:
>>
>> I hope you're not planning to do much spam filtering.
>
>
> do you have any evidence where enforcing a 5s minumum leads to serious
> problems?
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>One OS to rule them all, One OS to find them, One OS to bring them all
> and into darkness bind them ___
>
> 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: Minimum TTL?

[Warren Kumari]

Leave off the "protocol fixup feature", its cleaner

:-P

On Fri, Feb 9, 2018 at 7:15 AM, Tony Finch  wrote:
> Reindl Harald  wrote:
>>
>> CISCO router with "DNS-ALG"
>
> Oh god, never turn on PIX/ASA protocol fuxup features.
>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Malin: West 5 or 6, backing south 7 to severe gale 9 for a time. Very rough or
> high. Rain or wintry showers. Good, occasionally poor.
> ___
> 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: disable dnssec for particular domain

[Warren Kumari]

On Wed, Feb 7, 2018 at 7:41 AM, Tony Finch  wrote:
> Michelle Konzack  wrote:
>
>> If someone is interested making a slave for me, I can do
>> the same with him/her/whatelse.
>
> I'm cheap, so for my personal domains I use free secondaries from
> https://puck.nether.net/dns/ and https://admin.gratisdns.com/

Not adding anything relevant to the thread (shocking, I know!), but a
number of us use puck --- and I wanted to give a quick shout-out to
Jared Mauch for providing this to the community.

W


>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Viking, North Utsire, South Utsire, Forties: Northwesterly 4 or 5, backing
> southerly or southwesterly 5 to 7, occasionally gale 8 in Viking and North
> Utsire. Moderate or rough. Wintry showers, then occasional rain. Good,
> occasionally poor.
> ___
> 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: SOA settings

[Warren Kumari]

On Fri, Feb 2, 2018 at 3:31 PM, Dave Warren <d...@thedave.ca> wrote:
> On Fri, Feb 2, 2018, at 11:57, Warren Kumari wrote:
>> Hopefully Lewis knows / understand that we are just squabbling amongst
>> ourselves because we've know each other for a long time and this is in
>> good humor.
>
> Yes indeed :)
>
>> The actual values used are open to tuning, but in the original
>> posting, you, that was 15 seconds, and was *probably* a typo for 15
>> minutes. I personally always use seconds in my zonefiles, and avoid
>> the new fangled hours / weeks / syntax.
>
> I'm the exact other way around, I prefer content to be as human readable as 
> possible, and in my experience most humans work better with smaller numbers 
> including units (especially under stress/pressure).

What?! You mean you still think in archaic units like hours and laghu
and days and fortnights and similar?! Weird Do you measure length
in alen? Or kyndemil?

I use seconds for *everything* -- when pointy-haired boss types ask if
I'm actually working on a project (instead of, you know, snarking on
mailing lists) I tell them that I've put in "more than 2834 seconds in
the past 2 weeks alone". The arbitrary precision and large number
makes it sound like I've done way more than, you know, less than an
hour.

It only takes a few 2678400 seconds to get into this habit - if you
are having a hard time adjusting, I'd recommend Kris Allen's seminal
work - https://www.youtube.com/watch?v=PwYnG2DGbPo   [0] - this is
only the first in a planned series; IIRC, the next one will cover the
number of seconds needed to cook an egg to the desired yolk
consistency, and the following one, for some unknown reason, helps you
remember the gestation period of a muskrat.

>
> Each to their own, obviously.
>

Apparently.
W
P.S: You are welcome for the earworm.



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

[Warren Kumari]

On Fri, Feb 2, 2018 at 1:17 PM, Dave Warren via bind-users
 wrote:
> On 2018-02-01 17:21, Lyle wrote:
>>
>> Bind does default to seconds.
>>
>>
>> However this is not the SOA record.
>
>
> Who said it was a SOA record?

Ooghf.

You are right. The OP simply said "a config file", and we've all assumed.

Hopefully Lewis knows / understand that we are just squabbling amongst
ourselves because we've know each other for a long time and this is in
good humor.

Assuming that it *is* an SOA (which is a reasonable assumption at this
point :0) ) yes, that is 15 seconds, and is almost definitely not what
you want.

RIPE has a suggestion (
https://www.ripe.net/publications/docs/ripe-203 ), SWITCH.CH has some
others (https://securityblog.switch.ch/2014/02/06/zone-file-recommendations/)
, Peter Koch (related to the RIPE page :-)) had others:
https://tools.ietf.org/html/draft-koch-dns-soa-values-01

The actual values used are open to tuning, but in the original
posting, you, that was 15 seconds, and was *probably* a typo for 15
minutes. I personally always use seconds in my zonefiles, and avoid
the new fangled hours / weeks / syntax.

W



>
>
> ___
> 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: SOA settings

[Warren Kumari]

On Fri, Feb 2, 2018 at 1:48 AM, Reindl Harald  wrote:
>
>
> Am 02.02.2018 um 01:21 schrieb Lyle:
>>
>> Bind does default to seconds.
>> However this is not the SOA record.
>
>
> surely, at least a part of it
>
> @ IN SOA srv-rhsoft.rhsoft.net. admin.rhsoft.net. (
> 2017110901  ; Serial
> 1800; Refresh
> 600 ; Retry
> 1814400 ; Expire
> 900 ; Negative-TTL
> );
>
>

Nope.

https://memegenerator.net/instance/81230988

It is, at best, part of a simplified textural representation of an SOA
record. And I'm not even willing to commit to that...
:-P

W

>> On 02/01/18 18:08, lbutlr wrote:
>>>
>>> I am looking at a config file and seeing:
>>>
>>> 2017112100 ; serial
>>> 1H ; refresh
>>> 15 ; retry
>>> 1w ; expire
>>> 1H ; minimum
>>>
>>> Is that 15 15 seconds?
>>> I'm guess ion it should be 15m?
>
> ___
> 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: Possible To Log NXDOMAIN At The Server?

[Warren Kumari]

On Tue, Jan 30, 2018 at 3:12 PM, Reineman, Rick  wrote:
> Hello, I recently migrated our internal DNS service to a newer OS and Bind.  
> Bind 9.9.4 on CentOS7.
>
> The previous service had a dataset that was in really bad shape and I did a 
> lot of cleanup for the migration.  Unfortunately there were a few records I 
> dropped that I should not have, but it's hard to figure out which until 
> someone complains.
>
> I am interested in capturing queries that fail, return a NXDOMAIN to the 
> client in other words.
>
> I have two logging categories setup "queries" and "query-errors", both going 
> to separate logs.
>
> The problem is that the logs do not log what I am interested in.  The queries 
> log, logs every query, the query-errors log supposedly only logs a SERVFAIL.
>
> Does anyone know if it is possible to get what I want from the DNS server?

Er, you *might* be able to, but I'd suggest just using DNSCAP
(https://github.com/DNS-OARC/dnscap)

# ./dnscap -sr -ex -g
[140] 2018-01-30 20:27:34.966108 [#0 br0 4095] \
[204.194.23.4].53 [76.104.90.25].56101  \
dns QUERY,NXDOMAIN,51223,qr|aa|rd \
1 nonexistant.snozzages.com,IN,A 0 \
1 
snozzages.com,IN,SOA,600,ns01.kumari.net,warren.kumari.net,2011053169,86407,7200,360,17280
\
1 .,4096,4096,0,edns0[len=0,UDP=4096,ver=0,rcode=0,DO=0,z=0] \


-sr will Select Responses
-ex will log Errors of type nXdomain

-g will write to stderror, -w foo will create files of the form foo..

W


>
> Thanks,
> Rick
> ___
> 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: 9.11 can't validate sss.gov

[Warren Kumari]

Unrelated to the DNS bit, but still silly / annoying:

http://www.sss.gov works OK, but http://sss.gov always seems to return
"The requested service is temporarily unavailable. It is either
overloaded or under maintenance. Please try later.".

There is a fair bit os disagreement over if a bare domain should
resolve / have a web-server listening, but ISTM that if you *do*, you
should have it work -- I wonder how many people have tried the bare
domain and never realized that adding in the 'www' "fixes" it.

W

On Mon, Jan 22, 2018 at 11:08 AM, Timothy A. Holtzen
 wrote:
> I've informed the selective service (sss.gov) of the issue.  They have
> supposedly passed it on to their "web support group".  We will see if
> anything happens but I'm not holding my breath.  At least a government
> agency should have more influence to get qwest to fix their servers than
> I do.
>
> Timothy A. Holtzen
> Campus Network Administrator
> Nebraska Wesleyan University
> Public PGP key CFB4 3AE8 B726 DEBF 00D9  CCFC 426E 76AF DABC B3D7
>
>
> On 01/19/2018 05:04 PM, Mark Andrews wrote:
>> Yes, qwest were informed years ago that there severs are broken. Report this 
>> to the .gov site operators.  The servers return BADVERS to the queries which 
>> was never part of the EDNS spec and is a invention of the servers 
>> developers. FORMERR was permissible by STD13  but this was tightened when 
>> the EDNS spec was revised to say ignore unknown EDNS options.
>>
>
>
>
> ___
> 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: head scratcher: nsupdate, Bind views, and TLSA record updates

[Warren Kumari]

So, can you confirm that you are not getting SERVFAIL?

You really haven't provided enough information (like the actual
domains!) for people to be able to help you.
W

On Tue, Oct 31, 2017 at 3:39 PM, Kevin via bind-users
<bind-users@lists.isc.org> wrote:
>
>
> - Original Message -
>> From: "Kevin" <bind-users...@thesandiegos.com>
>> To: "Kevin" <bind-users...@thesandiegos.com>
>> Cc: "Warren Kumari" <war...@kumari.net>, "bind-users" 
>> <bind-users@lists.isc.org>
>> Sent: Tuesday, October 31, 2017 12:33:56 PM
>> Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>
>> - Original Message -
>> > From: "Kevin" <bind-users...@thesandiegos.com>
>> > To: "Warren Kumari" <war...@kumari.net>
>>> Cc: "Kevin" <bind-users...@thesandiegos.com>, "bind-users"
>> > <bind-users@lists.isc.org>
>> > Sent: Tuesday, October 31, 2017 12:18:41 PM
>> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>
>> > From: "Warren Kumari" <war...@kumari.net>
>> > To: "Kevin" <bind-users...@thesandiegos.com>
>> > Cc: "bind-users" <bind-users@lists.isc.org>
>> > Sent: Tuesday, October 31, 2017 11:28:58 AM
>> > Subject: Re: head scratcher: nsupdate, Bind views, and TLSA record updates
>
>> > On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users
>> > <bind-users@lists.isc.org> wrote:
>> >> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a
>> >> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash
>> >> script that executes the following nsupdate batch commands which are
>> >> directed to a Bind "view" that is accessible from the wider internet:
>
>> >> server 1.2.3.4
>> >> zone example.com
>> >> key updatekey xyz123...
>> >> update delete _25._tcp.mail.example.com. TLSA
>> >> local 127.0.0.1
>> >> show
>> >> send
>
>> >> And then:
>> >> server 1.2.3.4
>> >> zone example.com
>> >> key updatekey xyz123...
>> >> update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123...
>> >> local 127.0.0.1
>> >> show
>> >> send
>
>> >> I get the following output, all looks good:
>
>> >> + Updating DNS 1.2.3.4: for ... ok.
>> >> + Updating DNS 1.2.3.4: for ... ok.
>
>> >> I see the following in /var/log/messages, all looks good (updating the 
>> >> view
>> >> named "remote", responsible for answering queries from off-network 
>> >> sources):
>> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: 
>> >> view
>> >> remote: signer "updatekey" approved
>> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: 
>> >> view
>> >> remote: updating zone 'example.com/IN': deleting rrset at
>> >> '_25._tcp.mail.example.com' TLSA
>> >> Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending
>> >> notifies (serial 165)
>> >> Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal:
>> >> received notify for zone 'example.com'
>> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: 
>> >> view
>> >> remote: signer "updatekey" approved
>> >> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: 
>> >> view
>> >> remote: updating zone 'example.com/IN': adding an RR at
>> >> '_25._tcp.mail.example.com' TLSA
>
>> >> But then when I try to do a query from remote, no TLSA record exists.
>
>> >> $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec
>
>> >> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA
>> >> _25._tcp.mail.example.com +dnssec
>> >> ; (1 server found)
>> >> ;; global options: +cmd
>> >> ;; Got answer:
>> >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421
>> >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>> >> ;; OPT PSEUDOSECTION:
>> >> ; EDNS: version: 0, flags: do; udp: 512
>> >> ;; QUESTION SECTION:
>> >> ;_25._tcp.mail.example.com. IN TLSA
>
>> >> ;; Q

Re: head scratcher: nsupdate, Bind views, and TLSA record updates

[Warren Kumari]

On Tue, Oct 31, 2017 at 1:50 PM, Kevin via bind-users
 wrote:
> I'm running into an odd issue with Bind 9.9.4 whereby I'm trying to run a
> scripted nsupdate to rotate TLSA records. I'm running nsupdate via a Bash
> script that executes the following nsupdate batch commands which are
> directed to a Bind "view" that is accessible from the wider internet:
>
> server 1.2.3.4
> zone example.com
> key updatekey xyz123...
> update delete _25._tcp.mail.example.com. TLSA
> local 127.0.0.1
> show
> send
>
> And then:
> server 1.2.3.4
> zone example.com
> key updatekey xyz123...
> update add _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 abc123...
> local 127.0.0.1
> show
> send
>
> I get the following output, all looks good:
>
>  + Updating DNS 1.2.3.4:  for ... ok.
>  + Updating DNS 1.2.3.4:  for ... ok.
>
> I see the following in /var/log/messages, all looks good (updating the view
> named "remote", responsible for answering queries from off-network sources):
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view
> remote: signer "updatekey" approved
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#33710/key updatekey: view
> remote: updating zone 'example.com/IN': deleting rrset at
> '_25._tcp.mail.example.com' TLSA
> Oct 31 10:28:19 test named[106]: zone example.com/IN/remote: sending
> notifies (serial 165)
> Oct 31 10:28:19 test named[106]: client 1.2.3.4#38629: view internal:
> received notify for zone 'example.com'
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view
> remote: signer "updatekey" approved
> Oct 31 10:28:19 test named[106]: client 127.0.0.1#56323/key updatekey: view
> remote: updating zone 'example.com/IN': adding an RR at
> '_25._tcp.mail.example.com' TLSA
>
> But then when I try to do a query from remote, no TLSA record exists.
>
> $ dig @8.8.8.8 TLSA _25._tcp.mail.example.com +dnssec
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7 <<>> @8.8.8.8 TLSA
> _25._tcp.mail.example.com +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29421
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;_25._tcp.mail.example.com.INTLSA
>
> ;; Query time: 74 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Tue Oct 31 10:37:02 PDT 2017
> ;; MSG SIZE  rcvd: 59
>
> Oct 31 10:33:12 test named[106]: query logging is now on
> Oct 31 10:33:33 test named[106]: client 74.125.80.69#45732
> (_25._tcp.mail.example.com): view remote: query: _25._tcp.mail.example.com
> IN TLSA -ED (1.2.3.4)
> Oct 31 10:33:36 test named[106]: client 1.2.3.4#39184
> (74.165.37.177.in-addr.arpa): view internal: query:
> 74.165.37.177.in-addr.arpa IN PTR + (1.2.3.4)
> Oct 31 10:33:39 test named[106]: received control channel command 'querylog'
>
> I'm at a loss as to what's going on, any ideas?

You've elided enough stuff that debugging/helping you is really hard,
but at least one of the issues is that you are getting back SERVFAIL.
This is almost defeintely a DNSSEC issue -- I'd suggest looking at
DNSVIZ to fogure out why...

W
>
> -Kevin
>
>
> ___
> 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: Forcing external domains TTL value

[Warren Kumari]

On Sat, Oct 7, 2017 at 12:59 AM, Job  wrote:
> Dear guys,
>
> Due to heavy traffic caching performance, i would like to force external 
> domains TTL - for external domains - to at least 600 seconds.
>
> Is there a way to do it, maybe by recompiling the package?

There is  max-cache-ttl  , but this does exactly the opposite
of what you want -- it overrrides the TTL, specifying the maximum time
a record can be cached.

I'd advise against what you are trying to do -- apart from violating
standards, it may cause issues -- domain admins set the TTL low for a
reason, but because they like the added traffic and fragility. How big
is your cache? What is your cache miss rate? What issues are you
seeing?

W


>
> Thank you, very best!
> /F
> ___
> 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: NOAA.GOV domain not working

[Warren Kumari]

On Mon, Sep 18, 2017 at 10:40 AM, Levesque, Ricky (SNB)
 wrote:
> Thank you for your reply,
> When I notice too many failed queries from this domain name 
> (www.nhc.noaa.gov) restarting the service or clearing the cache (rndc 
> reload), seems to allow queries to work. But still latent (in the 3500ms 
> range)
>
> This is what I get from a DIG +trace...  the connection times out every time.
> #dig +trace www.nhc.noaa.gov
>
> But if I try another domain, example: "cisco.com" it completes properly
> #dig +trace cisco.com
>
> As another test, I ran a trace for www.nhc.noaa.gov on Googles DNS servers 
> (8.8.8.8) and the query seems to time out as well.
> # dig +trace www.nhc.noaa.gov @8.8.8.8
>
>
> ; <<>> DiG 9.11.0-P1 <<>> www.nhc.noaa.gov @*removed DNS-SRV-IP*  +trace
> ;; global options: +cmd
> .   434277  IN  NS  e.root-servers.net.
> .   434277  IN  NS  d.root-servers.net.
> .   434277  IN  NS  f.root-servers.net.
> .   434277  IN  NS  a.root-servers.net.
> .   434277  IN  NS  i.root-servers.net.
> .   434277  IN  NS  h.root-servers.net.
> .   434277  IN  NS  g.root-servers.net.
> .   434277  IN  NS  l.root-servers.net.
> .   434277  IN  NS  b.root-servers.net.
> .   434277  IN  NS  k.root-servers.net.
> .   434277  IN  NS  j.root-servers.net.
> .   434277  IN  NS  c.root-servers.net.
> .   434277  IN  NS  m.root-servers.net.
> ;; Received 811 bytes from *removed DNS-SRV-IP* #53(*removed DNS-SRV-IP*) in 
> 4 ms
>
> gov.172800  IN  NS  a.gov-servers.net.
> gov.172800  IN  NS  b.gov-servers.net.
> gov.172800  IN  NS  c.gov-servers.net.
> gov.172800  IN  NS  d.gov-servers.net.
> gov.86400   IN  DS  7698 8 1 
> 6F109B46A80CEA9613DC86D5A3E065520505AAFE
> gov.86400   IN  DS  7698 8 2 
> 6BC949E638442EAD0BDAF0935763C8D003760384FF15EBBD5CE86BB5 559561F0
> gov.86400   IN  RRSIG   DS 8 1 86400 2017100105 
> 2017091804 15768 . 
> TwWja3x0St/rN8/hvlzI88QouBcsarUYFdo1w73NROAmztwC+I24SyIg 
> /7zygGfvtZtaD4m/ebnS93V0l7Kb7+cP3V/u4Icd0r2U/ub/p0aCqqw+ 
> 4Yc449qZCI04LPSq5q6wnCEI4dK+sSH9RBoLhJ08Obol6+YfHR9zvBSG 
> 0x1+t99i/xSICyHnh/Mcr4Q+7p7Cl+EdgwG8TQIqTOq/qi0n4oTuGixJ 
> BTpcZB5/dhk8oJbPfBiqJDJ6uFQJ5r/kMGYRp9440HaY3BvQ7bqjOHNo 
> QfRybJEv45KZL4mCBGt9HZLkrHqT6Wz4wKflyLlr7JIS7eDzNlraMcqF D9wTaA==
> ;; Received 671 bytes from 193.0.14.129#53(k.root-servers.net) in 64 ms
>
> noaa.gov.   86400   IN  NS  ns-e.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-mw.noaa.gov.
> noaa.gov.   86400   IN  NS  ns-nw.noaa.gov.
> noaa.gov.   3600IN  DS  13774 5 1 
> 4823D2F9C36F98D586ECCD779731F813218BD875
> noaa.gov.   3600IN  DS  13774 5 2 
> C0500C34A55DC61290B397E995A618337594694117A4A667FD3CEF27 EA23AC63
> noaa.gov.   3600IN  RRSIG   DS 8 2 3600 20170925101007 
> 20170918101007 21428 gov. 
> UUOtQnMJgAZQAPS0J259CtXri0WyuDnJsdA5Glqt7FUAnvOFXNCEO8K6 
> 0Kpyp/JHSM6hfeWKoAW3P0IaEeY+nYm91jdZ1Z214sWpiGmjvtE46KV4 
> oVwvwnhyMjqI6gIZ9tTmm67iKz5E4UF524d/liZL9RMqSoy5uL94VUSm tSs=
> ;; Received 483 bytes from 69.36.157.30#53(a.gov-servers.net) in 49 ms
>
> ;; connection timed out; no servers could be reached
>

Huh. Weird.

Try:
dig  www.nhc.noaa.gov @ns-e.noaa.gov.
dig  www.nhc.noaa.gov @ns-mw.noaa.gov.
dig  www.nhc.noaa.gov @ns-nw.noaa.gov.

and:
dig  -4 www.nhc.noaa.gov @ns-e.noaa.gov.
dig  -4 www.nhc.noaa.gov @ns-mw.noaa.gov.
dig  -4 www.nhc.noaa.gov @ns-nw.noaa.gov.

and
dig  +tcp www.nhc.noaa.gov @ns-e.noaa.gov.
dig  +tcp www.nhc.noaa.gov @ns-mw.noaa.gov.
dig  +tcp www.nhc.noaa.gov @ns-nw.noaa.gov.


and also:
traceroute ns-e.noaa.gov.
traceroute ns-mw.noaa.gov.
traceroute ns-nw.noaa.gov.


What address range are you coming from? It sounds like you cannot
reach the noaa.gov nameservers (or they cannot reach you!)

W

>
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John 
> Miller
> Sent: September 18, 2017 11:03 AM
> Cc: bind-users@lists.isc.org
> Subject: Re: NOAA.GOV domain not working
>
> Hi Ricky,
>
> Try running a "dig +trace www.nhc.noaa.gov," then query each record in the 
> chain and see which one's slow to respond.  I don't see anything crazy in 
> your named.conf.  Something you didn't mention: does clearing cache make a 
> difference?
>
> John
> --
> John Miller
> Systems Engineer
> Brandeis University
> johnm...@brandeis.edu
>
>
> On Mon, Sep 18, 2017 at 8:03 AM, Levesque, 

Re: Is there a need for clients to advertize the capabilities for DNS Responses over TCP

[Warren Kumari]

On Fri, Sep 15, 2017 at 3:37 AM, Harshith Mulky
 wrote:
> Hello Experts,
>
>
> I had a query on advertising the payload size on client in DNS Responses
> over UDP/TCP
>
>
> This is as much I have understood from RFC 6891, that a requester(client)
> can address his capabilities to restrict the UDP Payload size to a limit
> between 512 to 4096 bytes based on his limitation when supporting EDNS
> Procedures.
>
>
> Is it the same case with TCP?
>
>
> Can we(client) advertize our capabilities over TCP to limit the payload size
> in Responses?

What is it that you are actually trying to accomplish / why?
I'm going to assume that this is to deal with some sort of brokenness
and not just idle curiosity[0].

If you are actually experiencing issues with DNS over TCP it is most
likely that you have some sort of broken path MTU discovery issue, and
have a lower than expected MTU (this is likely also affecting other
applications), but it could also be some broken middle box -- for
example Cisco PIX has some, er, interesting DNS TCP artifacts:
"Customers with NAT configured on a Cisco IOS device may experience
issues receiving large DNS query response messages when TCP is used as
the transport. Cisco IOS NAT does not have support for reassembling
TCP segments. The lack of support for TCP segment reaasembly is a
well-known issue that is documented under the question "Q. What is the
difference between IP fragmentation and TCP segmentation?" at the
following link:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_q_and_a_item09186a00800e523b.shtml.
"

Anyway, without knowing more it is tricky to know what your actual
issue is, but a: fixing pMTUd by making sure ICMP is allowed would
likely be helpful, or b: decreasing the MTU / MSS to your actual MTU
may help.

W
[0]: Which is also fine, but I needed to start somewhere.


>
>
> Thanks
>
> Harshith
>
>
>
> ___
> 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: Re: Re: checkhints: view “internal”: b.root-servers.net/AAAA (2001:500:200::b) extra record in hints

[Warren Kumari]

On Sun, Sep 10, 2017 at 8:15 PM, Mark Andrews  wrote:
>
> In message , Timothe Litt 
> writes:
>> The most sensible thing to do is ignore the message, and keep named
>> reasonably up-to-date.
>
> Well something in the resolution path is changing the answer to
> return the old  address which is why I suggested that there may
> be a forwarder involved.  One should get a answer like this from
> all of the root server addresses.  The exact ordering of the records
> may differ.  If one doesn't then something on the path is modifying
> the response.

... and here's a (really ugly) bit of bash to allow you to check all of them:
for letter in `echo "abcdefghijklm" | grep -o .` ; do echo "Letter:
${letter}"; dig ns . @${letter}.root-servers.net | grep
b.root-servers.net | grep ; done

W

>
> ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> ns . +norec 
> @a.root-servers.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29723
> ;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;.  IN  NS
>
> ;; ANSWER SECTION:
> .   518400  IN  NS  a.root-servers.net.
> .   518400  IN  NS  b.root-servers.net.
> .   518400  IN  NS  c.root-servers.net.
> .   518400  IN  NS  d.root-servers.net.
> .   518400  IN  NS  e.root-servers.net.
> .   518400  IN  NS  f.root-servers.net.
> .   518400  IN  NS  g.root-servers.net.
> .   518400  IN  NS  h.root-servers.net.
> .   518400  IN  NS  i.root-servers.net.
> .   518400  IN  NS  j.root-servers.net.
> .   518400  IN  NS  k.root-servers.net.
> .   518400  IN  NS  l.root-servers.net.
> .   518400  IN  NS  m.root-servers.net.
>
> ;; ADDITIONAL SECTION:
> a.root-servers.net. 518400  IN  A   198.41.0.4
> b.root-servers.net. 518400  IN  A   192.228.79.201
> c.root-servers.net. 518400  IN  A   192.33.4.12
> d.root-servers.net. 518400  IN  A   199.7.91.13
> e.root-servers.net. 518400  IN  A   192.203.230.10
> f.root-servers.net. 518400  IN  A   192.5.5.241
> g.root-servers.net. 518400  IN  A   192.112.36.4
> h.root-servers.net. 518400  IN  A   198.97.190.53
> i.root-servers.net. 518400  IN  A   192.36.148.17
> j.root-servers.net. 518400  IN  A   192.58.128.30
> k.root-servers.net. 518400  IN  A   193.0.14.129
> l.root-servers.net. 518400  IN  A   199.7.83.42
> m.root-servers.net. 518400  IN  A   202.12.27.33
> a.root-servers.net. 518400  IN  2001:503:ba3e::2:30
> b.root-servers.net. 518400  IN  2001:500:200::b
> c.root-servers.net. 518400  IN  2001:500:2::c
> d.root-servers.net. 518400  IN  2001:500:2d::d
> e.root-servers.net. 518400  IN  2001:500:a8::e
> f.root-servers.net. 518400  IN  2001:500:2f::f
> g.root-servers.net. 518400  IN  2001:500:12::d0d
> h.root-servers.net. 518400  IN  2001:500:1::53
> i.root-servers.net. 518400  IN  2001:7fe::53
> j.root-servers.net. 518400  IN  2001:503:c27::2:30
> k.root-servers.net. 518400  IN  2001:7fd::1
> l.root-servers.net. 518400  IN  2001:500:9f::42
> m.root-servers.net. 518400  IN  2001:dc3::35
>
> ;; Query time: 179 msec
> ;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
> ;; WHEN: Mon Sep 11 10:09:10 AEST 2017
> ;; MSG SIZE  rcvd: 811
>
> --
> 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



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

[Warren Kumari]

... yes, yes you are.

I'm explicitly responding in case you have the mailman "Don't send me
my own posts" (not metoo) option.

W

On Wed, Aug 30, 2017 at 11:20 AM, Alan Clegg  wrote:
> I don't think I can post to this list for some reason.
>
> I'd like to be able to respond to questions, but my responses never seem
> to show up...
>
> this is just a test to see if I am visible on the list.
>
> Thanks!
> AlanC
>
>
> ___
> 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: Subdomain DNSSEC

[Warren Kumari]

On Mon, Aug 28, 2017 at 12:25 PM, Niall O'Reilly  wrote:
> On 28 Aug 2017, at 17:06, Michael Dahlberg wrote:
>
>> My apologies if this question has an easily discoverable answer but my
>> google-fu seems to be failing me today.
>
>
>   Try "insecure delegation" against your favourite search engine.
>   Here's an example of what searching for this gave me (from DuckDuckGo
> rather than Google):
>
> https://stackoverflow.com/questions/25674236/how-to-create-delegation-signer-ds-record-for-a-subdomain-with-powerdns
>
>>  If a domain is signed, is it possible to delegate a subdomain to a 3rd
>> party who is unable to sign that subdomain?
>
>
>   Yes.  You need NS records as has always been the case.  By simply not
> adding a DS
>   record, you signal an insecure delegation.

Yup, exactly -- take .com as an example -- it is a signed zone, but
there are a large number of unsigned subdomains in it.

W

>
>   You may have problems if the two sets of name servers (for parent and
> child zones)
>   overlap.
>
>   Best regards,
>   Niall O'Reilly
> ___
> 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: [DNS] BIND 9.9.9-P8 issue

[Warren Kumari]

On Mon, Aug 21, 2017 at 4:33 AM, Daniel Rodrigues  wrote:
> Hello guys,
>
>
>
> We are facing to an important issue which is strongly annoying us on our DNS
> resolvers. We saw our cache decrease and we got lot of SERVFAIL/recursion
> during this period. The only way to solve it is to flush cache or reboot
> BIND. Our version is 9.9.9-P8 running on RHEL 6.6. We already got it 6 times
> in 1 week on different servers.
>
> Here some logs when the problem appears :


Some questions:
1: What do you have in your hints file? What do you get if you run
"dig ns . @" where
 are the addresses in the hints file.

2: Have you manually configured / changed the max-cache-size ? If so,
er, why and to what?


3: Do you usually get the "maximum number of FD events (64) received" message?
Have you followed the advice in
https://kb.isc.org/article/AA-00716/0/Since-upgrading-to-BIND-9.9-Im-seeing-maximum-number-of-FD-events-64-received.html
 ?

and, the obvious 4: What changed recently? What sort of boxes are
these? What is their network connectivity like?

W

>
>
>
> named[10616]: database: warning: delete_node: dns_rbt_findnode(nsec):
> partial match
>
> named[10616]: general: warning: checkhints: unable to get root NS rrset from
> cache: not found
>
> general: info: sockmgr 0x7f4419f240f0: maximum number of FD events (64)
> received
>
>
>
> Below one link to see one cacti’s screen showing the performance:
>
> https://drive.google.com/file/d/0B3pglqx0sbOiN3ZWQmM3MDdYOTQ/view?usp=sharing
>
>
>
>
> Do you have any idea to solve it definitively ? Is it an exploit bug ?
>
> Thanks for you help.
>
>
>
>
> ___
> 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: Can bind works without defining root servers

[Warren Kumari]

On Tue, Aug 15, 2017 at 11:36 AM, Matthew Pounsett  wrote:
>
>
> On 15 August 2017 at 11:29, King, Harold Clyde (Hal)  wrote:
>>
>> How does Bind update the root servers? Does it go out and check, or is a
>> release made for each change?
>
>
> Yes. :)
>
> BIND has a compiled-in root hints list that is kept up to date at each
> release, which can be overridden with a zone of type 'hint'.   It also does
> what's calling "priming queries", which is to contact one of the known root
> servers from the hints list, and retrieve and up-to-date authoritative NS
> set for the root zone from the root zone itself.

... and for gory details on priming queries, see RFC8109 (
https://datatracker.ietf.org/doc/rfc8109/ )


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

[Warren Kumari]

On Sun, Jul 9, 2017 at 1:59 PM John W. Blue  wrote:

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

Like many poorly written / articulated SLAs, the devil is in the details.

I could happily read this as the server / service must respond within 3ms.
The OP mentioned VIP, so this could be for auth DNS, in which case
responding to a query within 3ms is trivial...

W


;; 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*
>
> *[image: 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

-- 
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: difference in responses between UDP and TCP

[Warren Kumari]

On Thu, Jun 15, 2017 at 11:13 AM, Alan Clegg  wrote:
>
>
> On 6/15/17 6:20 AM, Arun Natarajan wrote:
>> Hello,
>>
>> Wondering why we are seeing different serial numbers from a bind
>> authoritative server for requests over UDP and TCP.
>>
>> dig +tcp soa @ns.example.com  example.com
>>  +short
>> ns1.example.com . hostmaster.example.com
>> . 2017061505 10800 3600 360 3600
>>
>> dig +notcp soa @ns.example.com  example.com
>>  +short
>> ns1.example.com . hostmaster.example.com
>> . 2017061506 10800 3600 360 3600
>>
>> any idea?
>
> Twelve.
>
>
Actually, 1.

$echo "2017061506 - 2017061505" | bc -l
1
$



> ___
> 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: [Ext] Re: Redirect only second and third level domains

[Warren Kumari]

On Fri, Feb 24, 2017 at 1:12 PM, Edward Lewis  wrote:
> On 2/24/17, 03:42, "bind-users on behalf of Andrea Gabellini" wrote:
>
>>the server is a resolver for about 20K clients. My goal is to supply a
>>courtesy page if a domain is not found. For every domain.
>
> No approach relying on wildcards will work because of the way wildcards 
> "work."  (*.example.com won't catch non-existing abc.def.example.com if 
> cba.def.example.com exists.)
>
> There are commercial applications that do this, the one I know of from a 
> previous employer is http://www.barefruit.co.uk/.
>
> I don't know of any open solutions to this goal.
>
> (As you can tell from other replies, folks think this is a bad idea.  But if 
> you are told to accomplish this by a manager, saying it's a bad idea isn't 
> what the manager wants to hear.)

True, that may not be what the manager wants to hear -- but:
A: that's not a good manager and
B: not clearly explaining all of the risks, dangers, downsides to the
manager (in writing if necessary) makes you a bad employee.

Being a "Yes man" only gets you brownie points for a short while, but
is bad for the organization and your management too -- it soon blows
up and you have to explain why you didn't prevent bad things from
happening...

This email thread would be a useful thing to show management -- a
bunch of people who run name-servers are all saying 'tis a bad idea.

>
> I can't think of an in-protocol or in-server solution.  Given that you should 
> be mindful of the special use domain names too (.local or .onion as 
> examples), this begs an out of band solution and probably manual management.
>
> See 
> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain
>  for the special use domain names.
>
>

Yup. good point. There are many many ways that this ends poorly, and
basically none where it ends well

W


>
>
> ___
> 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: Redirect only second and third level domains

[Warren Kumari]

Yeah, what you are describing is NXDomain rewriting -- it turns out to
be a really bad idea.

Here are some initial documents decribing why:
https://www.icann.org/en/system/files/files/sac-032-en.pdf -- ICANN
Security and Stability Advisory Committee SAC 032 Preliminary Report
on DNS Response Modification

http://www.icsi.berkeley.edu/pubs/networking/redirectingdnsforads11.pdf
-- Redirecting DNS for Ads and Profit


It breaks all sorts of things, creates security risks, and ends up
confusing customers. Just don't do it...

W

On Fri, Feb 24, 2017 at 9:50 AM, /dev/rob0 <r...@gmx.co.uk> wrote:
>> Il 23/02/2017 20:38, Warren Kumari ha scritto:
>> > What are you actually trying t odo?
>
> On Fri, Feb 24, 2017 at 09:42:17AM +0100, Andrea Gabellini wrote:
>> the server is a resolver for about 20K clients. My goal is to
>> supply a courtesy page if a domain is not found. For every domain.
>
> Ugh.  You call it a courtesy, I call it ignorant and abusive.
>
>> A query for abc.example.com or example.com (and these do not
>> exist) has to receive the address of the courtesy web server.
>>
>> A query for xyz.abc.example.com (and this do not exists), have
>> to receive NXDOMAIN.
>>
>> This is a workaround for queries made to the dnsbl services like
>> spamhaus.org or mailspike.org, where the queries are of type
>> "4.3.2.1.zen.spamhaus.org". If the redirect is for all levels of
>> the domain, there is a response and the antispam system thinks
>> that this IP is in blacklist.
>
> No.
>
> A mail server needs clean DNS, no NXDOMAIN hijacking at all.  Such
> as, if a user submits mail to somewhere@invalid.example, the MTA
> needs to know that "invalid.example" is NXDOMAIN.
>
> It's one thing, if you're trying to be "courteous" to ordinary
> web-only users; it is quite different when you are serving DNS to
> servers of various kinds.  Your customers WILL be calling to
> complain.
>
> Perhaps you should offer a clean nameserver for business and static
> IP address customers?  Inform them and advise them to change before
> you implement your "courteous" NXDOMAIN abuse?
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
> ___
> 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: switching entire DNS system to new servers and IP addresses

[Warren Kumari]

On Thu, Feb 23, 2017 at 3:03 PM, Reindl Harald  wrote:
>
>
> Am 23.02.2017 um 20:52 schrieb Eldridge, Rod A [ITNET]:
>>
>>
>> Iowa State University is replacing 7 ISC NAMED/BIND servers and 4 ISC DHCP
>> servers with Infoblox servers on March 14th. We want to keep the domain
>> names of our external servers the same (with one exception), but we will be
>> changing all of the IPv4 and IPv6 addresses of those external servers.
>>
>> Current external name servers:
>>
>>DNS-1.IASTATE.EDU   129.186.6.249,
>> 2610:130:101:100::249
>>DNS-2.IASTATE.EDU   129.186.88.249,
>> 2610:130:102:e01::249
>>ISU.DNS.NORTHERNLIGHTS.GIGAPOP.NET  146.57.253.249,
>> 2607:ea00:1:9::aa
>>
>> The exception is that we will be removing
>> ISU.DNS.NORTHERNLIGHTS.GIGAPOP.NET (a server located at the UMN) and will be
>> installing a server at UIowa (that will be named DNS-3.IASTATE.EDU).
>>
>> The new IPv4 addresses for the new external name servers will be:
>>
>>DNS-1.IASTATE.EDU   129.186.67.129
>>DNS-2.IASTATE.EDU   129.186.67.145
>>DNS-3.IASTATE.EDU   128.255.x.x <== not yet
>> assigned
>>
>> We haven't assigned IPv6 addresses yet.
>>
>> We'd like advice about any issues or problems we might run into and to
>> watch out for, what preparations should we do or must we do before the
>> switch, and any other advice to help us make this switch go smoothly and
>> unnoticed.
>

I think that I'd modify Reindl's list:

A: startup the new servers
B: keep them in sync
C: decrease the TTL on your NS (and other sensitive records) --
currently they are a day. Nothing is more embarrassing than e.g making
a type and having to wait a long TTL to be able to recover
D:  update 1 NS records to the new servers
E:  update GLUE records for same
F: go back to D, updating the next one.
G: wait TTL + safety time
H:  shutdown the old servers



>
> * startup the new servers
> * keep them in sync
> * update NS records to the new servers
> * update GLUE records
> * wait TTL + safety time
> * shutdown the old servers
>
> when we speak of TTL - GLUE recors have a *really large* TTL independent of
> your zones - but that is no problem at all since for some time you have
> running old and new servers
>
> so it don't matter for anybody as long they all have the same zone data
>
> ___
> 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: Redirect only second and third level domains

[Warren Kumari]

On Thu, Feb 23, 2017 at 7:21 AM, Andrea Gabellini
 wrote:
> Hi,
>
> I would like to redirect the NXDOMAIN responses to a courtesy page but
> only for second and third level domains. I mean something like:
>
> *.*. IN A 1.2.3.4
> *.*.*. IN A 1.2.3.4
>
> that obviously doesn't work. Is there a solution to do it?

I don't think that there is, but your question is somewhat vague -- is
this for second / third levels *within a domain you are authoritative
for*?

If so, *.example.com is the closest you can do without some serious futzing.
If you want to do this during recursion, nope, you cannot really
accomplish this with BIND -- not, even if you could, it sounds like a
really really bad idea.

What are you actually trying t odo?

W

>
>
> Actually my configuration is:
>
> zone "." in {
>   type redirect;
>   file "redirect";
> };
>
> and the zone file is:
>
> $TTL 300
> @ IN SOA dns.example.com. hostmaster.example.com. 2017020202 0 0 0 0
> @ IN NS dns.example.com.
> ;
> *. IN A 1.2.3.4
>
> Thanks,
> Andrea
>
> --
> 
> If today was a fish, I'd throw it back in !
>
> 
>
> Ing. Andrea Gabellini
> Email: andrea.gabell...@telecomitalia.sm
> Skype: andreagabellini
> Tel: (+378) 0549 886111
> Fax: (+378) 0549 886188
>
> Telecom Italia San Marino S.p.A.
> Via XXVIII Luglio, 212 - Piano -2
> 47893 Borgo Maggiore
> Republic of San Marino
>
> http://www.telecomitalia.sm
>
> ___
> 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: bind 9 goes rogue and revert zone information

[Warren Kumari]

This really sounds like the zone file is *in* the container itself, and
that the container is restarting.
You said that this is running under LXC -- is this actually a Docker
container? How are you starting the container?

W


On Tue, Feb 7, 2017 at 11:35 AM, Raul Dias  wrote:

> I know.
>
> So far, the only files changed are the ones I changed myself, like bind
> config files and vimrc.
>
> No hidden toolkit found too.
>
> I still think that it is easier to be a misconfiguration done by myself.
>
> Still looking for better indications that this could be the case.
>
> On 07/02/2017 12:42, Alberto Colosi wrote:
>
> IP ports not open does not mean is not hacked.
>
> a vulnerability can be used to make a change or an access
>
>
> try to change and audit file access and permission firewall log analisys
> can give a plus to find a solution (check all IP traffic out from TCP/UDP
> 53)
>
>
> If you have RNDC , change KEY or disable it
>
>
>
>
> --
> *From:* Raul Dias  
> *Sent:* Tuesday, February 7, 2017 3:34 PM
> *To:* Alberto Colosi; bind-users@lists.isc.org
> *Subject:* Re: bind 9 goes rogue and revert zone information
>
>
> Sorry,
> Static files.
> It is the master server.
> No dynamic updates.
> Host under lxc with only bind ports open.
>
> On Tue, Feb 7, 2017, 12:27 Alberto Colosi  wrote:
>
>> hi is unclear named structure if is a slave a master if dynamic updates
>> are enabled and if the unix box has been hacked
>>
>> as last , zones are static files on fs ?
>>
>>
>> --
>> *From:* bind-users  on behalf of Raul
>> Dias < r...@dias.com.br>
>> *Sent:* Tuesday, February 7, 2017 3:03 PM
>> *To:* bind-users@lists.isc.org
>> *Subject:* bind 9 goes rogue and revert zone information
>>
>> Hello,
>>
>> I have a very strange behavior that I am failing to understand.
>>
>> 2 to 5 times a week, a named server revert back to a previous version os
>> a master zone.
>> This happens during the night, usually around 20h EST.
>>
>> This zone has a serial of 3017020401 <(301)%20702-0401> (yes, I typo the
>> 3 somewhere in the
>> past).
>> When it reverts its zone information, it goes back to 3016060101
>> <(301)%20606-0101>.
>>
>> I have updated, restarted the host, clean all cache and journal files,
>> grep all files in the host for 3016060101 <(301)%20606-0101> (just shows
>> up in the logs).
>>
>> So, I have no clue why, or how it is happening. Where does it get the
>> old information.
>>
>> I thought first about the serial, but it would have happened in the past
>> too, right?  As it should be a 32bit unsigned integer, it shouldn't be a
>> problem, IMHO.
>>
>> Yet, when "dig domain -t SOA @server", it is there again.
>>
>> The host is a debian Jessie and bind is 9.9.5, 1:9.9.5.dfsg-9+deb8u8
>> more specifically.
>>
>>
>> Thanks for any direction.
>> -rsd
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>> bind-users Info Page - Internet Systems Consortium
>> 
>> lists.isc.org
>> To see the collection of prior postings to the list, visit the bind-users
>> Archives. Using bind-users: To post a message to all the list members, send
>> ...
>>
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>> bind-users Info Page - Internet Systems Consortium
>> 
>> lists.isc.org
>> To see the collection of prior postings to the list, visit the bind-users
>> Archives. Using bind-users: To post a message to all the list members, send
>> ...
>>
>>
> --
> Att. Raul Dias
>
>
> ___
> 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: bind 9 goes rogue and revert zone information

[Warren Kumari]

On Tue, Feb 7, 2017 at 9:34 AM, Raul Dias  wrote:

> Sorry,
> Static files.
> It is the master server.
> No dynamic updates.
> Host under lxc with only bind ports open.
>

​If it is the master, and there are no automatic updates, I strongly
suspect:
1: ​there is a cron job (or similar) which rewrites the old zone file --
some busticated automation or, more likely
2: you said that this is a "host under lxc" -- this sounds VERY much like
it is in a container, and the container is restarting every N (sometime
around 20h Eastern!) -- the zonefile in the container, and not in an
external volume / persistent disk...

W




>
> On Tue, Feb 7, 2017, 12:27 Alberto Colosi  wrote:
>
>> hi is unclear named structure if is a slave a master if dynamic updates
>> are enabled and if the unix box has been hacked
>>
>> as last , zones are static files on fs ?
>>
>>
>> --
>> *From:* bind-users  on behalf of Raul
>> Dias 
>> *Sent:* Tuesday, February 7, 2017 3:03 PM
>> *To:* bind-users@lists.isc.org
>> *Subject:* bind 9 goes rogue and revert zone information
>>
>> Hello,
>>
>> I have a very strange behavior that I am failing to understand.
>>
>> 2 to 5 times a week, a named server revert back to a previous version os
>> a master zone.
>> This happens during the night, usually around 20h EST.
>>
>> This zone has a serial of 3017020401 <(301)%20702-0401> (yes, I typo the
>> 3 somewhere in the
>> past).
>> When it reverts its zone information, it goes back to 3016060101
>> <(301)%20606-0101>.
>>
>> I have updated, restarted the host, clean all cache and journal files,
>> grep all files in the host for 3016060101 <(301)%20606-0101> (just shows
>> up in the logs).
>>
>> So, I have no clue why, or how it is happening. Where does it get the
>> old information.
>>
>> I thought first about the serial, but it would have happened in the past
>> too, right?  As it should be a 32bit unsigned integer, it shouldn't be a
>> problem, IMHO.
>>
>> Yet, when "dig domain -t SOA @server", it is there again.
>>
>> The host is a debian Jessie and bind is 9.9.5, 1:9.9.5.dfsg-9+deb8u8
>> more specifically.
>>
>>
>> Thanks for any direction.
>> -rsd
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>> bind-users Info Page - Internet Systems Consortium
>> 
>> lists.isc.org
>> To see the collection of prior postings to the list, visit the bind-users
>> Archives. Using bind-users: To post a message to all the list members, send
>> ...
>>
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>> bind-users Info Page - Internet Systems Consortium
>> 
>> lists.isc.org
>> To see the collection of prior postings to the list, visit the bind-users
>> Archives. Using bind-users: To post a message to all the list members, send
>> ...
>>
>>
> ___
> 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: Bind Queries log file format

[Warren Kumari]

On Mon, Feb 6, 2017 at 7:44 AM, MURTARI, JOHN  wrote:
>> We may move it to the end of the log message (bugs ticket #44606 has
>> been created for looking at it). Maybe its location was poor.. please
>> can everyone who participated in this thread say whether having it at
>> the end will be ok?
>
> It's really only for code debug.  I'd say give the admin a means via 
> rndc/config
> to turn it on 'debug' if needed.  That also allows you to add anything else 
> you might
> like in the future.


I suspect perhaps some of the thread got missed (or was unclear).

The reason for adding it to the main log file *by default* is because
of things like:
Customer: "My BIND went Boom! It's been running fine for many years,
and then for no reason at all it went Boom. Here are my log files..."
ISC: "Doh. Sorry. Unfortunately the log file doesn't have sufficient
debug info. Can you please turn on debug using , so
that we have enough logging info next time this happens?"
Customer: "Bah. Ok. Will do"


The additional logging info is specifically for the unusual bugs,
which happen very rarely - asking customers to enable the additional
logs after a rare event (which might not happen again for months /
years) means that ISC cannot hunt down and squash the corner case
bugs...

W



> John
>
>
> -Original Message-
>
> From: Mukund Sivaraman 
> To: Alan Clegg 
> Cc: bind-users@lists.isc.org
> Subject: Re: Bind Queries log file format
> Message-ID: <20170203164526.GA6221@jurassic>
> Content-Type: text/plain; charset="us-ascii"
>
> On Fri, Feb 03, 2017 at 08:51:01AM -0600, Alan Clegg wrote:
>> On 2/3/17 8:01 AM, Mukund Sivaraman wrote:
>>
>> > We have the debug log level, but consider the case when an operator has
>> > a non-deterministic or rare crash that isn't reproducible because the
>> > operator has no information about what caused it. All we have is the
>> > config, log that was already generated before the crash and perhaps a
>> > backtrace and core to deduce the steps leading to the crash. It's not
>> > possible to re-run that scenario with debug logging.
>> >
>> > I'll create a ticket to put the client pointer at the end if that'll
>> > help, but note that the syntax in 9.10 was not consistent either. 9.10
>> > would log the client pointer when the client object didn't have a valid
>> > peer.
>>
>> Adding code to allow enabling or disabling this output on the fly would
>> work MUCH better (as an example, see "rndc querylog"/ options "querylog
>> [on | off ]").
>>
>> Adding a "well, we needed this one time" value to the middle of a
>> long-standardized log file does no customer any good and inconveniences
>> everyone.
>>
>> You own the code and can do whatever you want to, but I'd recommend
>> making the default log message what it was prior to 9.10 and adding
>> additional fields via pre-configuration and "rndc".
>
> We may move it to the end of the log message (bugs ticket #44606 has
> been created for looking at it). Maybe its location was poor.. please
> can everyone who participated in this thread say whether having it at
> the end will be ok?
>
> The query log is getting more fields at the end of it such as
> CLIENT-SUBNET logging.
>
> Making it a configurable option misses the reason it is the way it is -
> please see the first paragraph quoted above.
>
> This seems to be a case where having it is inconvenient, and not having
> it is inconvenient.
>
> Mukund
>
> ___
> 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: broken trust chain on forwarder

[Warren Kumari]

On Friday, September 30, 2016, /dev/rob0  wrote:

> On Fri, Sep 30, 2016 at 12:04:33PM -0400, John Ratliff wrote:
> > I am building a new recursive DNS server. I have it set to forward
> > records for a single zone to our HQ DNS servers. When I try to
> > resolve a record, I get errors like this:
> >
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> > @0x7fb51810b8f0: stc.corp SOA: got insecure response; parent
> > indicates it should be secure
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG)
> > resolving 'inelhqnagios.stc.corp/DS/IN': 10.21.0.101#53
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> > @0x7fb520545fe0: stc.corp SOA: got insecure response; parent
> > indicates it should be secure
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG)
> > resolving 'inelhqnagios.stc.corp/DS/IN': 10.21.0.100#53
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid DS)
> > resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.100#53
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> > @0x7fb51810ac60: inelhqnagios.stc.corp A: bad cache hit
> > (inelhqnagios.stc.corp/DS)
> > Sep 30 11:25:39 bltn-dns-04 named[2012]: error (broken trust chain)
> > resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.101#53
> >
> > This seems to indicate that the servers at 10.21.0.100 and 101 are
> > telling me that stc.corp domain is DNSSEC enabled. However, the new
> > server fails to find any DS or RRSIG records, so validating this
> > claim is not possible. Is this interpretation accurate? Are the
> > errors I'm seeing here the result of a misconfigured DNS server at
> > our HQ?
>
> Not quite, no.  The 10.21.0.10[01] servers are giving you insecure
> answers which conflict with those you have already gotten from the
> root, which say there is no "corp." TLD.
>
>
What about creating and installing a local trust anchor for .Corp?

Also, im assuming that you already know that using a local / non-delegated
TLD is a really bad idea. You should strongly consider moving your
namespace under E.g companyname.com.
See the whole set of discussions on name collisions, home/Corp/mail, the
inability to get TLS certificates, etc.

W
(Apologies for terseness, about to go into dr appt).





> > I've seen on the internet people suggest disabling DNSSEC
> > validation. That seems to be an extreme solution to this problem.
> > It works, but my understanding is that this would disable DNSSEC
> > validation globally, not just for a single zone.
>
> That's correct, and it's the only workaround I know of, other than
> going to BIND 9.11 and having a cron job to set a negative trust
> anchor ("rndc nta") for stc.corp.
>
> Note that this usage of NTA is undocumented and not recommended; NTAs
> are intended to be temporary.
>
> > The HQ DNS servers at 10.21.0.100 and 101 are Microsoft DNS servers
> > over which I have no control, if that information is relevant.
>
> It is.  If you could have at least one of those allow you to transfer
> the stc.corp zone, you could have a slave zone, which would have been
> another possible workaround.
>
> As a slave zone, your server would have authoritative answers, and
> thus no need to go to the root.
>
> > I am running bind9 9.9.5 on Debian 8 with this single zone defined
> > in an otherwise stock debian bind9 configuration. I can post the
> > remainder of my config if it would be of use.
> >
> > zone "stc.corp" IN {
> > type forward;
> > forwarders { 10.21.0.100; 10.21.0.101; };
> > forward only;
> > };
>
> Oh, another thing you can try; offhand I don't know if it will work,
> but try a zone of type "stub" or "static-stub".
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
> ___
> 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: Load balancer for Bind

[Warren Kumari]

I may be completely misunderstanding your question, but why not simply
do Anycast / ECMP?

Each DNS server has the same IP address (usually bound to the loopback
interface), and runs a (very simple) health-check script. If the
health-check passes the host injects a /32 route into the IGP (or a
private-AS BGP instance).
Your router already does ECMP, Anycast is already a really well known
/ understood technology - you are simply building an anycast network
with all nodes behind the same device.

Any "load balancer" will simply be an additional widget (and so point
of failure / state location / dos opportunity) between the router and
servers.
W

On Wed, Sep 14, 2016 at 2:30 PM, Frank Pikelner
 wrote:
> Hello Bert,
>
> This is the first I've heard of DNSDIST. I'll need to read more about it, but 
> wanted to ask whether upon receiving the query, does DNSDIST act as a bridge 
> for the complete request/response, or simply redirects the traffic with the 
> response bypassing DNSDIST?
>
> THanks,
>
> Frank
>
> - Original Message -
> From: "bert hubert" 
> To: "Job" 
> Cc: bind-users@lists.isc.org
> Sent: Wednesday, 14 September, 2016 13:43:59
> Subject: Re: Load balancer for Bind
>
> On Wed, Sep 14, 2016 at 06:17:13PM +0200, Job wrote:
>> which is the best load balancer for two or more Bind DNS Server, located in 
>> the same farm?
>> I read something about HAProxy but it does not manage udp connection and the 
>> interesting security proxy/balancer DnsDist does not pass original client ip 
>> for Bind-DLZ...
>
> Hi Francesco,
>
> dnsdist can transfer the original IP over EDNS Client Subnet (ECS).
> http://dnsdist.org/README/ has how this works.
>
> I don't know if BIND can make use of the original IP address though.
> PowerDNS geoipbackend can in any case. BIND is also an excellent choice.
>
> Good luck!
>
> Bert (one of the dnsdist authors)
> ___
> 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



-- 
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: rndc on local host: need named running?

[Warren Kumari]

On Saturday, August 27, 2016, Tom Browder  wrote:

> My plan is to have two remote, authoritative name servers (master and
> slave) for my owned domains.  I would like to use rndc to control them from
> my local host.
>
> A couple of questions:
>
> 1. Does named need to be running on the local host?
>


 Nope.



> 2. Can I use rndc from my local host which doesn't have a fixed ip address?
>
>
Yup.

W


> Thanks.
>
> Best regards,
>
> -Tom
>


-- 
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: Breaking trusted chain in dnssec

[Warren Kumari]

Or nsec3 with opt-out?

The question is unclear...

W

On Wednesday, July 13, 2016, Tony Finch  wrote:

> rams > wrote:
>
> > Is any one explain how to break trusted chain in dnssec with example how
> to
> > create zone or data with trusted chain break.
>
> Create a delegation without a DS record.
>
> Tony.
> --
> f.anthony.n.finch  >  http://dotat.at/  -  I
> xn--zr8h punycode
> Lundy, Fastnet, Irish Sea: West or northwest 4 or 5, increasing 6 at times.
> Slight or moderate. Showers. 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
>


-- 
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: Additional Section - TXT Format?

[Warren Kumari]

On Sat, Jul 9, 2016 at 12:56 AM, Ian Manners  wrote:
> Hi Jun Xiang X Tee,
>
>> I have a simple question here. Is it possible to have
>> a TXT format tuple appearing at the additional section?
>
> Are you meaning to ask what switches dig requires to
> return txt records that include a term such as spf?
>
> This seems to ring a bell with me, have you asked this
> before?

https://lists.isc.org/pipermail/bind-users/2016-July/097096.html

https://lists.isc.org/pipermail/bind-users/2016-June/097012.html

https://lists.isc.org/pipermail/bind-users/2016-June/097045.html

https://lists.isc.org/pipermail/bind-users/2016-June/097047.html

These are all variations on a theme, with multiple requests along the
lines of "Please explain *why* you want to do this, and what *exactly*
you want to accomplish. That way we can actually help you, instead of
wasting our time repeating that this is probably a bad idea (or a
variation on a homework question)..."

W




>
>
> Cheers
> Ian Manners
> http://www.os2site.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



-- 
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: Can anyone tell me a good DNS server testing program

[Warren Kumari]

Kinda depends on what you are testing, but there is also Nominum's
dnsperf: http://nominum.com/measurement-tools/

This is easy to install, simple to use, and comes with a sample query file.
W

On Wed, Jun 22, 2016 at 8:48 AM, Emil Natan  wrote:
> queryperf, supplied with BIND, found under contrib.
> What we usually do is "record" some real traffic, then run queryperf on
> multiple machines against a server. If I'm not mistaken similar topic was
> discussed here recently so you can search the archives.
>
> Emil
>
> On Wed, Jun 22, 2016 at 3:34 PM, King, Harold Clyde (Hal) 
> wrote:
>>
>> I have a new DNS BIND setup that I need to stress test. There are many
>> test for hitting a web server to simulate traffic, but I can’t find a one
>> for doing the same thing to a DNS server. Does anyone have any
>> recommendations?
>>
>>
>> --
>> 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
>>
>> ___
>> 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



-- 
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: disable ipv6 source query

[Warren Kumari]

On Tuesday, June 21, 2016, Mark Andrews  wrote:

>
> server ::/0 { bogus yes; };


Eeeeww! That's gross, but in a bizarrely satisfying way.

W



>
> In message <
> cajs9+yby3vl3kehtjmt58ekqrf6qazfvt3khvy05q26lmpt...@mail.gmail.com
> >, Hillary Nelson writes:
> > We are moving our v6 DNS from F5 to anycast, since F5 can translate
> address
> > from v6 to v4, our backend servers are still only v4 and we never have
> > problem to resolve hostname with v4 only.
> >
> > Now for anycast, I want to enable v6 with private address only, but seems
> > like named favors v6 and using it to source query other nameserver, it
> will
> > try v4 if v6 fails, like this(I've configured source-query-v6 address
> ::1
> > so v6 always fails):
> >
> > 21:04:33.303536 IP6 ::1.34892 > 2001:dcd:1::7.53: 33940% [1au] A?
> > example.com. (48)
> > 21:04:34.146521 IP 1.1.1.1.58822 > 2.2.2.2: 55501% [1au] A? example.com.
> > (48)
> >
> >
> > My question is how to config named to only using v4 address to query
> other
> > nameserver, but still keep an listening v6 address?
> >
> > Thanks in advance!!
> > Hillary
> >
> --
> 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
>


-- 
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: UDP Packet Hack

[Warren Kumari]

Sorry, but isn't this almost exactly the same question which you asked
in: https://lists.isc.org/pipermail/bind-users/2016-June/097012.html
("Append a Hard-coded Text Tuple into Additional Section of "dig"
Feature") ? And "Query "resolver" and "lwresd" via "dig"" ?

Perhaps if you explained what you are actually trying to *accomplish*,
and *why*, people here might be able to provide you with a more useful
answer.

dig simply performs DNS queries and displays the results. It provides
some knobs, like the ability to specify the server to query, to set
specific flags, etc, but fundamentally it is just a client with
performs DNS lookups and prints the results.

"DESCRIPTION
   dig (domain information groper) is a flexible tool for
interrogating DNS name servers. It performs DNS lookups and displays
the answers that are
   returned from the name server(s) that were queried. Most DNS
administrators use dig to troubleshoot DNS problems because of its
flexibility, ease of
   use and clarity of output. Other lookup tools tend to have less
functionality than dig."

If you want to stuff some other information into the additional
section (almost definitely a bad idea!) you will first need a good,
fundamental understanding of how the DNS works -- I'd suggest you
start of by reading "DNS and BIND" by Cricket -
http://shop.oreilly.com/product/9780596100575.do

There are many things you will need to know first, like, who do you
want to include this? The authoritative server or the recursive? Who
is going to consume this additional information?

As I said, a much clearer explanation of what you want to actually
accomplish, and why, will allow people to provide useful answers...

W

On Tue, Jun 21, 2016 at 9:06 PM, Jun Xiang X Tee  wrote:
> Dear all,
>
>
>   I am working on hacking UDP packets returned to "dig" client. I wish to
> include some extra information about the "digged" domain (e.g.,
> facebook.com) at Additional Section of "dig" reply in TXT format. The ideal
> result is to be able to see the hacked UDP packets having the extra
> information using tools such as Wireshark.
>
>
>   For the past two weeks, I have searched through many articles online and
> asked many people on how to do this, but I am still confused on where "dig"
> gets the UDP packets from. Below are my questions:
>
>   (1) Does "dig" get its UDP packets from "named" server? Or "lwresd"
> server? Or others?
>
>
>   (2) For hacking purpose, I should work on BIND9 source codes. I don't need
> to install BIND9 using "apt-get install", right?
>
>
>   (3) Lastly, the most important question: How should I configure DNS server
> for "dig"?
>
> What I am doing now is going into "bin/dig" folder and run something
> like "./dig google.com".
>
> I think what I should do is "./dig @chosen_DNS_server google.com",
> but I do not know how to configure the server.
>
>
>
>   It will be great if someone can shed some lights on my questions. I have
> stuck for two weeks with zero progress, and have already thought about
> switching to another software. Haha. Thanks!
>
>
> Regards,
>
> Jun Xiang Tee
>
>
> ___
> 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: Monitor DNS queries toward Root severs

[Warren Kumari]

On Wed, May 4, 2016 at 4:37 AM, Daniel Dawalibi
 wrote:
> Hello
>
>
>
> Is there any tool or configuration that allows us to monitor/graph the
> number of outbound DNS queries toward the Root servers?
>

Others have provided information on how to capture the traffic.


> As you can see in the below examples the first query answered by M root then
> F root in the second query.


I just wanted to make sure that you know that it is perfectly normal /
expected that your queries will go to different root servers. BIND
should learn which is fastest, but will periodically check other
letters as well..
Didn't want you to waste time troubleshooting an issue which doesn't exist

W


>
>
>
> ; <<>> DiG 9.7.0-P1 <<>> www.cnn.com +trace
>
> ;; global options: +cmd
>
> .   450124  IN  NS  f.root-servers.net.
>
> .   450124  IN  NS  b.root-servers.net.
>
> .   450124  IN  NS  j.root-servers.net.
>
> .   450124  IN  NS  d.root-servers.net.
>
> .   450124  IN  NS  h.root-servers.net.
>
> .   450124  IN  NS  g.root-servers.net.
>
> .   450124  IN  NS  a.root-servers.net.
>
> .   450124  IN  NS  c.root-servers.net.
>
> .   450124  IN  NS  k.root-servers.net.
>
> .   450124  IN  NS  m.root-servers.net.
>
> .   450124  IN  NS  e.root-servers.net.
>
> .   450124  IN  NS  l.root-servers.net.
>
> .   450124  IN  NS  i.root-servers.net.
>
> ;; Received 496 bytes from 193.227.177.130#53(193.227.177.130) in 12 ms
>
>
>
> com.172800  IN  NS  c.gtld-servers.net.
>
> com.172800  IN  NS  d.gtld-servers.net.
>
> com.172800  IN  NS  a.gtld-servers.net.
>
> com.172800  IN  NS  h.gtld-servers.net.
>
> com.172800  IN  NS  b.gtld-servers.net.
>
> com.172800  IN  NS  f.gtld-servers.net.
>
> com.172800  IN  NS  l.gtld-servers.net.
>
> com.172800  IN  NS  k.gtld-servers.net.
>
> com.172800  IN  NS  j.gtld-servers.net.
>
> com.172800  IN  NS  m.gtld-servers.net.
>
> com.172800  IN  NS  i.gtld-servers.net.
>
> com.172800  IN  NS  g.gtld-servers.net.
>
> com.172800  IN  NS  e.gtld-servers.net.
>
> ;; Received 489 bytes from 202.12.27.33#53(m.root-servers.net) in 68 ms
>
>
>
> cnn.com.172800  IN  NS  ns1.timewarner.net.
>
> cnn.com.172800  IN  NS  ns3.timewarner.net.
>
> cnn.com.172800  IN  NS  ns1.p42.dynect.net.
>
> cnn.com.172800  IN  NS  ns2.p42.dynect.net.
>
> ;; Received 190 bytes from 192.43.172.30#53(i.gtld-servers.net) in 64 ms
>
>
>
> www.cnn.com.300 IN  CNAME   turner.map.fastly.net.
>
> ;; Received 64 bytes from 204.74.108.238#53(ns1.timewarner.net) in 61 ms
>
>
>
>
>
>
>
> ; <<>> DiG 9.7.0-P1 <<>> www.cnn.com +trace
>
> ;; global options: +cmd
>
> .   450105  IN  NS  a.root-servers.net.
>
> .   450105  IN  NS  f.root-servers.net.
>
> .   450105  IN  NS  l.root-servers.net.
>
> .   450105  IN  NS  h.root-servers.net.
>
> .   450105  IN  NS  b.root-servers.net.
>
> .   450105  IN  NS  g.root-servers.net.
>
> .   450105  IN  NS  k.root-servers.net.
>
> .   450105  IN  NS  i.root-servers.net.
>
> .   450105  IN  NS  j.root-servers.net.
>
> .   450105  IN  NS  c.root-servers.net.
>
> .   450105  IN  NS  m.root-servers.net.
>
> .   450105  IN  NS  d.root-servers.net.
>
> .   450105  IN  NS  e.root-servers.net.
>
> ;; Received 496 bytes from 193.227.177.130#53(193.227.177.130) in 0 ms
>
>
>
> com.172800  IN  NS  j.gtld-servers.net.
>
> com.172800  IN  NS  d.gtld-servers.net.
>
> com.172800  IN  NS  h.gtld-servers.net.
>
> com.172800  IN  NS  k.gtld-servers.net.
>
> com.172800  IN  NS  g.gtld-servers.net.
>
> com.172800  IN  NS  f.gtld-servers.net.
>
> com.172800  IN  NS  c.gtld-servers.net.
>
> com.172800  IN  

Re: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

[Warren Kumari]

On Fri, Mar 25, 2016 at 12:49 PM John Wobus  wrote:

> On Mar 18, 2016, at 6:28 AM, Barry Margolin  wrote:
> > In article ,
> > Mark Andrews  wrote:
> >
> >> How do you actually expect this to ever work in real life?
> >
> > I'm pretty sure Google DNS does this. Other resolver operators often get
> > complaints about "Why can't I look up  through your DNS
> > servers when I can do it through Google DNS?"
>
> I’d guessed Google just re-queries before it needs to, which has benefits
> but
> requires a more complex “clean out very-seldom-used records” strategy.

I’d imagine they'd use a somewhat-random amount of time to pre-query
> as one of their measures against cache poisoning.
>

A few years back a number of us wrote draft-wkumari-dnsop-hammer ("Highly
Automated Method for Maintaining Expiring Records").

My motivations for working on this were:

1: to keep often used information in the cache, avoiding the periodic
spikes in latency as things age out and need to be refetched (not for cache
poisoning protection or TTL stretching).

2: (equally, or more  important) to be able to get "Stop! Hammer time" into
a document: "If the original TTL of the RR is less than STOP *
HAMMER_TIME then the cache entry should be marked with a "Can't touch
this" flag, and the described method should not be used."

Many implementations (including Unbound, OpenDNS, and ISC BIND) now do
something like this, but sadly call it something like "prefetch" or
something equally boring. I keep meaning to go back push the document again.

W

>
> This would be a good nameserver feature, e.g. when a response is given
> from the cache, a secret (shorter) ttl is adjusted to help assure
> continuity.
> Or other variants.  Such a feature might address Ron’s concern.
> (I believe I recall discussions on this or another list, perhaps even
> a feature in the wings.)
>
> In any case, I cringe at the thought of overriding TTLs.  They’re there
> for a reason.  In some instances, overriding could “help”, but in others,
> it
> would be really, really bad.


> John Wobus
> Cornell University IT
> ___
> 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: DNS Service Discovery

[Warren Kumari]

On Sun, Mar 13, 2016 at 2:34 AM David Li  wrote:

> Hi Everyone,
>
> Is this the right place ask  general DNS-SD questions?  If not, can
> someone point me to the right list? I can't seem to find one.
>


It almost definitely is not the right place, but what is the question?
Perhaps someone can point you at the best place to ask it (or, just answer
it :-)).
I'm guessing dns-operations may be the place, but...

W



>
> 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
>
___
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: Ns records rfc

[Warren Kumari]

... also, you mention TLD zone - if this is for a gTLD, ICANN has some
additional requirements, including more than one AS number.

W

On Sun, Mar 6, 2016 at 5:11 AM S Carr  wrote:

> On 6 March 2016 at 04:08, rams  wrote:
> > Is there any rfc that a tld zone should have atleast two ns records when
> we
> > create the tld zone
>
> RFC 1034 Section 4.1
>
> A given zone will be available from several name servers to insure its
> availability in spite of host or communication link failure.  By
> administrative fiat, we require every zone to be available on at least
> two servers, and many zones have more redundancy than 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
>
___
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: Interesting behavior with wildcard domains

[Warren Kumari]

On Wed, Feb 24, 2016 at 12:30 PM Mark Andrews  wrote:

>
> In message , Mathew Ian Eis
> write
> s:
> Illegal character '-' in input file.
> > Hi BIND,
> >
> > Ive encountered (quite by accident) an interesting behavior in BIND with
> > wildcard domains:
> >
> > The relevant configuration is a zone; e.g. bar.com, with what Ill call a
> > second level wildcard host, e.g. *.foo.bar.com A 10.10.10.5 in that
> zone.
> > (as opposed to what might be considered the more usual wildcard host
> > record of *.bar.com).
> >
> > buz.foo.bar.com returns A 10.10.10.5 as expected.
> >
> > However, a query for foo.bar.com returns NOERR with zero results, when I
> > would expect a NXDOMAIN.
>
> Why?  If *.foo.bar.com exists then foo.bar.com, bar.com and com all exist.
>
> > Anyone know if the NOERR with zero results is the expected / correct
> > behavior?
>
> It is the expected behaviour
>

Nah, it is the *correct* behavior, fairly clearly it is not the *expected*
behavior :-P

W
(sorry, I'm feeling ornery today...)




> > Thanks in advance,
> >
> > Mathew Eis
> > Northern Arizona University
> > Information Technology Services
> >
> ___
> 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: How to check slave zone freshness

[Warren Kumari]

The standard, compatible way to do this is simply to do a lookup for the
SOA record and make sure that the serial number matches what you expect it
to be / what is on the master. I'm not sure what monitoring tool you are
using (or if you are writing your own), but most standard monitoring tools
have such a script already written - e.g:
https://exchange.nagios.org/directory/Plugins/Network-Protocols/DNS/checkexpire/details

I believe that BIND also updates the mtime on the zone file when it does
the check (not only when something changes):
root@eric:/etc/namedb/slave# date
Mon Feb  8 08:36:58 EST 2016
root@eric:/etc/namedb/slave# ls -al superficialinjurymonkey.com*
-rw-r--r-- 1 named named  714 Feb  8 03:51 superficialinjurymonkey.com
-rw-r--r-- 1 named named 1236 Feb  8 03:51 superficialinjurymonkey.com.jnl
root@eric:/etc/namedb/slave#

So, you should be able to just run 'ls' and see if the 'mtime' is larger
than you expect...

W


On Mon, Feb 8, 2016 at 5:40 AM Klaus Darilion 
wrote:

> Hi!
>
> I want to monitor the freshness of my slaves zones. Is it somehow
> possible to extract the status of slave-zones from bind?
>
> Thanks
> Klaus
> ___
> 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: How to check slave zone freshness

[Warren Kumari]

There is also transfer logs -- you could watch those and see if you are
getting any failures, but this seem, um, more brittle..

W

On Mon, Feb 8, 2016 at 6:22 AM Klaus Darilion <klaus.mailingli...@pernau.at>
wrote:

>
>
> Am 08.02.2016 um 14:59 schrieb Warren Kumari:
> > The standard, compatible way to do this is simply to do a lookup for the
> > SOA record and make sure that the serial number matches what you expect
> > it to be / what is on the master. I'm not sure what monitoring tool you
> > are using (or if you are writing your own), but most standard monitoring
> > tools have such a script already written -
> > e.g:
> https://exchange.nagios.org/directory/Plugins/Network-Protocols/DNS/checkexpire/details
>
> This does not detect problems between the master and slave as long as
> the master is not updated.
>
> Further I can not fetch the serial easily from the slave as our slave is
> a "bump in the wire" signer, so the SOA is the internal increased
> "DNSSEC serial". So I would need to extract it from the local zone
> files/journal.
>
> > I believe that BIND also updates the mtime on the zone file when it does
> > the check (not only when something changes):
> > root@eric:/etc/namedb/slave# date
> > Mon Feb  8 08:36:58 EST 2016
> > root@eric:/etc/namedb/slave# ls -al superficialinjurymonkey.com
> > <http://superficialinjurymonkey.com>*
> > -rw-r--r-- 1 named named  714 Feb  8 03:51 superficialinjurymonkey.com
> > <http://superficialinjurymonkey.com>
> > -rw-r--r-- 1 named named 1236 Feb  8 03:51 superficialinjurymonkey.com
> .jnl
> > root@eric:/etc/namedb/slave#
> >
> > So, you should be able to just run 'ls' and see if the 'mtime' is larger
> > than you expect...
>
> This is an interesting hint and good starting point. Thanks.
>
> Nevertheless, additionally I would to need to extract the SOA refresh
> value for every zone to find out if a zone is not fresh any more.
>
> Thanks
> Klaus
>
___
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: DNS BIND traffic capture ICMP/UDP

[Warren Kumari]

On Fri, Jan 15, 2016 at 8:49 AM Daniel Dawalibi 
wrote:

> Hello
>
>
>
> We observed an unusual traffic combining ICMP and UDP packets while
> running the tcpdump command on the DNS caching server
>
> Kindly note that only UDP DNS traffic is allowed on this server (ICMP is
> not allowed from outside to DNS server)
>
> Any help regarding this issue? Why we are getting ICMP and UDP requests?
> Could it be an attack?
>
>
>
>
>
> *Logs:*
>
>
>
> # tcpdump –n icmp
>
>
>
> 15:41:05.054237 IP 10.151.130.74 > DNSIP: ICMP 10.151.130.74 udp port
> 52003 unreachable, length 52
>
> 15:41:05.064449 IP 10.75.6.36 > DNSIP: ICMP 10.75.6.36 udp port 50162
> unreachable, length 52
>
> 15:41:05.067953 IP 10.33.10.155 > DNSIP: ICMP 10.33.10.155 udp port 50233
> unreachable, length 52
>
> 15:41:05.067958 IP 10.75.15.162 > DNSIP: ICMP 10.75.15.162 udp port 53847
> unreachable, length 52
>
> 15:41:05.072727 IP 10.33.12.219 > DNSIP: ICMP 10.33.12.219 udp port 51024
> unreachable, length 52
>
> ….
>
> Example: 10.151.130.74 (client source IP)
>
> DNSIP: DNSServer IP
>
>
>

Your description is either incomplete, or incorrect (or at least sine set
of things is misconfigured) -- without additional information it will be
difficult / impossible to assist.

1: You state that you observe traffic while running tcpdump **on the
caching server**.
2: You state that "ICMP is not allowed from outside **to** DNS server"
(emphasis mine) - this implies that ICMP is supposed to be filtered before
reaching the server, not e.g iptables *on the server*.
3: The tcpdump output shows traffic from client IPs (presumably "outside")
to the DNS server.

I do not see how all of the above can simultaneously be true
A: What are the actual IPs involved?
B: What are you counting as "outside" (are the client IPs "inside" or
"outside"?)?.
C: Where are you filtering the ICMP, and, more importantly, why are you
filtering ICMP (it is needed to make IP work properly...)
D: How busy is the server / what percentage of ICMP responses to DNS
queries?
E: What is the connectivity of the server? It is likely that resolutions
are taking significant time, and the clients have a: given up or b: already
gotten the replies from another recursive?


This could be an attack (e.g spoofed packets as part of a cache poisoning
attempt) or it could be perfectly normal operation -- eliding the IP
addresses and not providing more information makes it imposs^W hard to
tell

W


> Regards
>
> 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: Allow-Query=any

[Warren Kumari]

Yah, I guess it does kinda :-)
I seem to remember Olafur or Marek admitted that including the text was an
ugly, temporary kludge, and provided some "cover" so that is was more clear
that this was the intended behavior, and not that e.g they had just not
fully implemented ANY (as many DNS load-balancers / middleboxes seem to
do). Once this becomes common practice the HINFO can go to null.

Personally I think that they should have instead:
A: inserted naughty limericks or
B: sold this space off as advertising space.

W
DISCLAIMER: B is a joke... although huh



On Thu, Jan 7, 2016 at 5:05 PM Darcy Kevin (FCA) <kevin.da...@fcagroup.com>
wrote:

> I do find it a little ironic that the HINFO RDATA shown earlier in the
> thread, references the "refuse-any" draft, yet, in the selfsame RDATA,
> violates one of the "SHOULD"s of the draft:
>
> "The OS field of the HINFO RDATA SHOULD be set to the null string to
> minimise the size of the response."
>
> Kind of sends a mixed message, don't you think?
>
> -
> Kevin
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org [mailto:
> bind-users-boun...@lists.isc.org] On Behalf Of Reindl Harald
> Sent: Thursday, January 07, 2016 4:41 PM
> To: bind-users@lists.isc.org
> Subject: Re: Allow-Query=any
>
>
> Am 07.01.2016 um 22:31 schrieb Warren Kumari:
> > Reindl, did you read the draft referred to in the HINFO? (
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ ). It
> > clearly outlines the reasons that cloudfare is doing this. This
> > document was discussed in the DNSOP WG, and was presented at a few
> meetings.
> > The consensus within the DNSOP WG was to adopt and work on the draft,
> > so I object to your characterization of this as "another clueless
> > idiot degrading services" at a large company.
> > Olafur and Joe (the authors of this) are far from clueless idiots.
> > In addition, please try to moderate your tone - people come to the
> > BIND Users list for assistance - your argumentative (and often
> > insulting) posts are not helpful to building a community
>
> i did read and understand the reasoning long before this thread as i also
> had the RRL patches in production long before they went to stable releases
> http://www.tummy.com/blogs/2013/02/20/bindrrl-patched-rpms-available/
>
> with RRL and "minimal-responses yes;" the response size/impact of a ANY
> query is very limited while that is a completly different reasoning than "I
> don't want display all info"
>
> ___
> 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