RFC7344 (was: Funky Key Tag in AWS Route53 (2))

2022-12-29 Thread Peter
On Thu, Dec 29, 2022 at 09:17:26AM -0500, Timothe Litt wrote:

! (Manual processes
! are error-prone.  That getting registrars to adopt CDS/CDNSKEY - RFC7344 -
! has been so slow is unfortunate.)

Seconded. Do You have information about this moving at all? Because to
me it looks very much like dead-in-the-water, and my registrar didn't
even know what that is.

Otherwise I would have perfect automation for continuous rollover -
but still I have to either hack the data into their webinterface, or
figure out what kind of crappy api they might have - and in my view the
first option is boring and the second is superfluous work.

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: RFC7344 (was: Funky Key Tag in AWS Route53 (2))

2022-12-30 Thread Peter
On Thu, Dec 29, 2022 at 03:43:35PM -0500, Timothe Litt wrote:

! So much like DNSSEC itself, the technology is there, but the will to use it
! everywhere it's needed is not.

Timothy, thank You for the update. I agree to Your viewpoints, and we
have seen mostly the same with IPv6. Apparently it needs serious pain to
move something in technology that is mostly invisible to the common
user. (OTOH we can see new collaboration tools or javascript
frameworks every day.)

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

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


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


Re: DNSSEC With Primary Hidden - Clarifying Question from Documentation

2023-01-17 Thread Peter
On Tue, Jan 17, 2023 at 05:28:57PM -0600, E R wrote:
! I am planning on implementing the current version of BIND to replace the
! aging, undocumented authoritative servers I inherited.  I want to hide the
! primary server on our internal network and have two secondary servers be
! publicly available.  While reading the DNSSEC Guide
!  recipes
! it seems to imply that I cannot have a hidden primary that handles all the
! DNSSEC stuff.
! 
! Does the primary server that handles the DNSSEC duties not be hidden?  Or
! were they just illustrating that you do not need to touch your hidden
! primary server and just add one that does the DNSSEC duties?

In fact, none of them needs to.
I for my part have two publicly visible servers, plus a hidden
primary, and the DNSSEC stuff is entirely separated from all of them;
that happens in a vault, no network connection, signed e-mail in and
out only (I don't want to bother with a hw crypto device).

Obviousely, YMMV, it depends on the tools You use to maintain your
zones.

cheers,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: dnstab-read with detailed information

2023-03-15 Thread Peter
On Wed, Mar 15, 2023 at 09:34:40PM +, MAYER Hans wrote:
! 
! 
! Dear All,
! 
! dnstab is a great feature to analyse the details what’s going on. But I think 
there is room for improvement.
! 
! I write the data to a file and once a day I do a log rotate.
! With "dnstab-read FILE | grep IP“ I get basic information about an IP which I 
am looking for.
! Now getting full information required options -p and -y
! In this case „grep“ing isn’t so easy. Options -A can help.
! What I do is, I redirect output to a file and open it with „vi“.
! You can imagine, that this file can become large.
! 
! Are there any other (better) possibilities ?

Yes. Parse the YAML, feed it into a database. Or, use the dnstap
libaries and parse that stuff directly, should be faster, but needs
C coding.

Database finds query and answer and pairs them back together.

From there on everything is possible. You could do data mining
for intrusion detection, i.e. search for anomalies, or whatever.
-- 
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: How to make SRV records work with caching resolvers?

2023-06-07 Thread Peter
Hi,

  In July last year I asked about a problem with an IP telephone
mis-handling the DNS responses (and got the clear answer that the
telephone is to blame).

I quote my original message here:

On Wed, Jul 13, 2022 at 01:06:13PM +0200, Peter wrote:
! My Telco has removed the A record for their VoIP server, and now has
! only SRV data there - which seems not to work properly.
! 
! The SRV data contains various services (SIP via UDP, TCP, secure
! TCP, whatever), and these get individual expiry counters in the
! caching resolver.
! So when a telephone sends a query, the caching resolver will provide
! that data in the "Additional section" - but only those records that
! have not yet expired. 
! 
! If the configured service (the one the telephone should use) is no
! longer contained in the answer (but others are still present), the
! telephone goes offline until all the records have expired and a new
! authoritative query is made.
! 
! The Telco is of no help - they just want to sell their own equipment.
! 
! The telphones (Alcatel) are the usual linux plastic box, and I cannot
! easily hack these. It probably does not behave fully correct, but
! also not fully wrong.
! 
! In BIND/named I didn't find an easy approach to fix the issue - it
! doesn't look like it is supposed to be fixed there. And before I go
! for the more difficult approaches, I would like to ask how this
! is actually supposed to work, at all.

Accidentially reading the docs for 9.18 instead of my 9.16 (which
is differently structured), I found the solution: "minimal-responses".

This does away with the Additional section entirely, so there is no
longer a problem with incomplete data considered as complete by the
client.

The actual issue is slightly different than described above:

The client telephone is expected to query a NAPTR for the SIP server.
That NAPTR provides three records, which should be queried as SRV and
again provide three records each. So in total there are 13 records
(including the finally used A record), and that doesn't fit into
576 bytes.

So, apparently, named/BIND sends only some selection of Additional
records, based on it's own discretion. And that doesn't work with the
broken client. Either /all/ or /nothing/ would work, and
"minimal-responses" enforces the /nothing/ option. 

It seems the problem is now solved.
-- 
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: Stub zones, but secndary?

2023-11-19 Thread Peter
lhost; };" into every friggin'
! zone entryto every friggin' zone entry. I REALLY don't like this.
! 
! I'm wondering whether there's a more elegant way. Like "secondary-hint" zones.
! Have I overlooked something?

Maybe. As You can see, it can be done, but it's a bit weird -
I got the fancy that I want to have all six-way in one running image. ;)
(Originally I just got bored of the SSH known-host files, and to get
rid of these you need DANE/SSHFP and proper DNSSEC.)

cheerio,
Peter
-- 
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: Stub zones, but secndary?

2023-11-20 Thread Peter
On Mon, Nov 20, 2023 at 03:30:13PM +1300, Nick Tait via bind-users wrote:
! On 20/11/2023 1:00 pm, Peter wrote:
! > It's tricky. One problem is these are slave zones, they are
! > authoritative and do not work well with DNSSEC.
! 
! I'm curious... What issues did you have with these zones and DNSSEC? I would
! have expected that the signed zones should just work?

Probably they do just work. But then, when I query a
nonexistent domain from a simple root-slave, the answer
carries an AA flag. When I query the same nonexistent
domain from 8.8.8.8, it carries an AD flag.

Also, somewhere in the depths of the ISC docs and tutorials
I found a paper that shows how to setup the root-slave for
DNSSEC so that it does recurse and validate (and that is
from where I started to adapt my config). So likely there is
an issue somewhere.

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


XFR killed by security

2024-03-04 Thread Peter
Hi folks,

  a few days ago I apparently lost the beneficence of my zone feeds,
and XFR started to get into timeout.

Looking at the usual culprits I then found this:
   DNS Response containing multiple DNSSEC RRSIG Entries (Algorithm
   14) - Possible CVE-2023-50387 Activity
   [Classification: Detection of a Denial of Service Attack]
   {TCP} 192.0.47.132:53 -> 

I don't find it really surprizing that XFR would contain "multiple
RRSIG entries". But, according to the strategy ("shoot first, ask when
the corpses stack to the ceiling"), this thing just kills the transfers.

So, what is it about? Is it something serious?

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: XFR killed by security

2024-03-04 Thread Peter
On Mon, Mar 04, 2024 at 03:43:48PM +0100, Ondřej Surý wrote:
! > On 4. 3. 2024, at 14:55, Peter  wrote:
! > 
! > I don't find it really surprizing that XFR would contain "multiple
! > RRSIG entries".
! 
! Unfortunately, this is obviously surprising to the vendor of the security 
device. This needs to be fixed there, not here. As for the CVE, you have the 
number that can be used, but here’s the blogpost for reference: 
https://www.isc.org/blogs/2024-bind-security-release/

Thank You, Ondrej, this link shortens my path. This is what I wanted
to know.
So the current version of BIND mitigates the issue, and the somehow
ill-devised security rule can then simply be excluded. Wonderful.

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: Switching from rhel base 9.16 to 9.18 copr

2024-05-05 Thread Peter
On Sun, May 05, 2024 at 06:15:13PM +0200, Luca vom Bruch via bind-users wrote:
! Hello,
! 
! I use bind (stock from alma 9.3) as a nameserver for a webhosting server
! with webmin/virtualmin.
! 
! If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of
! 9.18 - I want to experiment with DoT for opportunistic TLS between
! nameservers, upcoming standard  
! RFC 9539 - Unilateral Opportunistic Deployment of Encrypted
! Recursive-to-Authoritative DNS (ietf.org) )
! 
! what are the necessary steps to make isc-bind read the existing config
! files? named.conf in /etc and zones in /var/named?

Don`t know Your OS details, but when I upgraded 9.16 to 9.18 on
FreeBSD, my entire site fell apart and nothing did work anymore.

I found the problem - after I managed to access the respective
system (my ssh utilizes DANE/SSHFP) - that I had to newly write my
config files because all the filesystem pathnames have changed
between 9.16 and 9.18.

So beware.
-- 
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


CNAME and IPv6

2024-05-28 Thread Peter
Hello,

  if I understand corrently, the use of CNAME is just a convenience
and no technical feature, right?

In lots of examples on the net, a zonefile for a domain might contain
things similar to this:

  @ORIGIN example.com.
  ..
  myhost   A1.2.3.4
  www  CNAMEmyhost.example.com.
  www1 CNAMEmyhost.example.com.
  someapp  CNAMEmyhost.example.com.
  xyz  CNAMEmyhost.example.com.
  ...

Often, the webserver and other applications are not actually
running on node 1.2.3.4, but are internally portforwarded to
some other node, for various reasons.

Now we add an IPv6 address for 'myhost'. But portforwarding
doesn't work for IPv6. Instead we are required to use different
addresses all over, like so:

NOT CORRECT:
  myhost   A1.2.3.4
  myhost    4321::1
  www  CNAMEmyhost.example.com.
  www   4321::10
  ...

Or, NOT CORRECT:
  myhost   A1.2.3.4
  myhost    4321::1
  internal  4321::10
  www  CNAME4   myhost.example.com.
  www  CNAME6   internal.example.com.
  ...

So, how would you do it? Is there a nice and elegant way?
-- 
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: CNAME and IPv6

2024-05-28 Thread Peter
On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote:
! Am 28.05.2024 um 12:00:09 Uhr schrieb Peter:
! 
! >   if I understand corrently, the use of CNAME is just a convenience
! > and no technical feature, right?
! 
! It is technical because the query is redirected to the domain listed in
! the CNAME.

Seen that way, yes. Not using CNAME would then even be a load reducing
improvement.

! > Often, the webserver and other applications are not actually
! > running on node 1.2.3.4, but are internally portforwarded to
! > some other node, for various reasons.
! 
! This is bad IPv4 stuff, you should get rid off that ASAP.

Yes, that's the official stance...

! > Now we add an IPv6 address for 'myhost'. But portforwarding
! > doesn't work for IPv6. Instead we are required to use different
! > addresses all over, like so:
! 
! port forwarding would work, but is nasty here. Redirectors like rinetd
! can handle that, but I recommend against in this case.

I tried it, and didn't get around the Path MTU discovery: Forward SNMP
to one host, HTTP to another - which one then gets the ICMPv6 2.0
"message too big"? 

! > So, how would you do it? Is there a nice and elegant way?
! 
! www   CNAME   webserver1
! ftp   CNAME   ftp2
! 
! webserver1A   192.168.0.1
! webserver12001:db8::1
! ftp2  A   172.16.0.1
! ftp2  2001:db8:::1
! 
! That makes it possible to redirect it to the actual machines that runs
! the service.

Okay, looks good. Lets go that way.

Thanks for Your reply!
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: CNAME and IPv6

2024-05-28 Thread Peter
On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote:
> Am 28.05.2024 um 18:48:38 Uhr schrieb Peter:
> 
> > On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote:
> 
> > > > Now we add an IPv6 address for 'myhost'. But portforwarding
> > > > doesn't work for IPv6. Instead we are required to use different
> > > > addresses all over, like so:
> > > 
> > > port forwarding would work, but is nasty here. Redirectors like rinetd
> > > can handle that, but I recommend against in this case.
> > 
> > I tried it, and didn't get around the Path MTU discovery: Forward SNMP
> > to one host, HTTP to another - which one then gets the ICMPv6 2.0
> > "message too big"? 
> 
> rinetd manages 2 separate connections and should work with PMTUD.

I'm wondering how it would. The connections are TCP, the PMTU works
via ICMP6. So I would assume, the ICMP "packet too big" message
reaches the host where rinetd runs, is swallowed by the kernel, and
the kernel sets the MTU in it's hostcache. Or something along that
line.
The TCP traffic however gets forwarded by rinetd to the internal
appserver(s) - which never get the message that they should reduce
their MTU.

> Did you use that or another way?

I didn't find that one. I tried two other tools for connection
forwarding, they were unsatisfactory. And then I did things with NPTv6
(which is fun). With NPTv6 I can forward the ICMP alongside with the
connection traffic, and that works - but obviousely to only *one*
internal host.

> PS: I still recommend pointing to the machines that host the stuff
> instead of having a middlebox that might create additional headache
> like improper logging, performance issues. :-)

Absolutely, in any regular business scenario where proper connectivity
is mandatory. But this here is my fancy evaluation site where I can
do all kinds of things that are too ambitioned (or too crazy) for
regular sites. ;) Like routing stuff half around the world for no
reason, Or running clockwork-orange...
yeah, this is clockwork orange: https://dnsviz.net/d/icall.icu/dnssec/
High availability, continuous rollover, changes keys every 4 days -
but then, too obese for normal operations. Anyway, mine is the
longest. :)

Okay, enough of the nonsense. Occasionally I just feel the need to
modestly ask how people would normally solve a task, before I start
hacking something crazy...

Cheerio & greetings,
PMc

P.S. I edited the quote-symbol for You. Hope I'll remember.
-- 
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: CNAME and IPv6

2024-05-29 Thread Peter
On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas wrote:
! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote:
! > > rinetd manages 2 separate connections and should work with PMTUD.
! 
! On 28.05.24 22:17, Peter wrote:
! > I'm wondering how it would. The connections are TCP, the PMTU works
! > via ICMP6.
! 
! No, Path MTU discovery works with TCPv4 using ICMPv4 as well.
! (although it was/is quite common to block ICMP packets which can make it not
! work properly)

That is a different matter, lots of people switch them off
and things do still work, because we're in most cases allowed to
defragment (firewalls do that) and refragment at any point on the
way as needed.
Blocking ICMPv4 a practise that is certainly annoying, but what
can we do? With v6 things simply won't work.

! > So I would assume, the ICMP "packet too big" message
! > reaches the host where rinetd runs, is swallowed by the kernel, and
! > the kernel sets the MTU in it's hostcache. Or something along that
! > line.
! 
! > The TCP traffic however gets forwarded by rinetd to the internal
! > appserver(s) - which never get the message that they should reduce
! > their MTU.
! 
! The data from one TCP connection are sent through another TCP connection,
! where both connections are separate with separate MTU and PMTUD.

A new quintuple, then. Hm. Not sure why I was unhappy with that... one
reason was probably that a webserver would not be able to know the
client address.

But I think this goes into off-topic here.
-- 
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


qname minimization: me too :(

2024-06-19 Thread Peter


Hi all,
  today I happened to look into a named.log, and found it full of
qname minimization messages.
Now as far as I understand, the saying goes that this is a problem
of misconfigured upstream nameservers and we cannot do much about
it.

But, what if these "misconfigured upstream servers" happen do be
some of my own? What do I do then?

Because I've seen through the proceedings, and I do not yet see
the error.

cheerio,
Peter
-- 
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: qname minimization: me too :(

2024-06-19 Thread Peter
On Wed, Jun 19, 2024 at 10:33:41PM +0200, Stephane Bortzmeyer wrote:
! On Wed, Jun 19, 2024 at 10:15:48PM +0200,
!  Peter  wrote 
!  a message of 32 lines which said:
! 
! >   today I happened to look into a named.log, and found it full of
! > qname minimization messages.
! 
! Which message? Could you copy-and-paste it?

Yes, sure. I grabbed three typical cases to analyze further, and
currently trying to understand the proceedings - unsuccessfully, up
to now. :(

Case 1:
---
Jun 19 17:42:12  conr named[24481]: lame-servers:
   info: success resolving '26.191.165.185.in-addr.arpa/PTR'
   after disabling qname minimization due to 'ncache nxdomain'

This one does not point back to me, but nevertheless I do not
see the lame server.

Case 2:
---
Jun 19 18:02:44  conr named[24481]: lame-servers:
   info: success resolving 'reactivite.fr.intra.daemon.contact/'
   after disabling qname minimization due to 'ncache nxdomain'

Here, for whatever reason, the client was not happy with the official
answer on "reactivite.fr", and tried to append the search domain for
internal hosts on my LAN.
So this does absolutely point to me, only. The recursing LAN server
asks the authoritative LAN server (same image, different view), and
that one basically says, this is bogus.

Case 3:
---
Jun 19 18:28:48  conr named[24481]: lame-servers:
   info: success resolving
   
'1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.0.0.3.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa/PTR'
   after disabling qname minimization due to 'ncache nxdomain'

This one does also point back to me (kind of), because HE does
delegate the rDNS zones (I love them), only they do not do DNSSEC
in the rDNS. It correctly ends up at my autoritative public servers
and gets resolved.


I'm currently extracting the exact proceedings from dnstap - but I
don't get much enlighenment from them.
-- 
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: qname minimization: me too :(

2024-06-21 Thread Peter
On Fri, Jun 21, 2024 at 07:03:14AM +, Michael Batchelder wrote:
! > Yes, sure. I grabbed three typical cases to analyze further, and
! > currently trying to understand the proceedings - unsuccessfully, up
! > to now. :(
! >
! > Case 1:
! > ---
! > Jun 19 17:42:12  conr named[24481]: lame-servers:
! >info: success resolving '26.191.165.185.in-addr.arpa/PTR'
! >after disabling qname minimization due to 'ncache nxdomain'
! > 
! > This one does not point back to me, but nevertheless I do not
! > see the lame server.
! > 
! > Case 2:
! > ---
! > Jun 19 18:02:44  conr named[24481]: lame-servers:
! >info: success resolving 'reactivite.fr.intra.daemon.contact/'
! >after disabling qname minimization due to 'ncache nxdomain'
! > 
! > Here, for whatever reason, the client was not happy with the official
! > answer on "reactivite.fr", and tried to append the search domain for
! > internal hosts on my LAN.
! > So this does absolutely point to me, only. The recursing LAN server
! > asks the authoritative LAN server (same image, different view), and>
! > that one basically says, this is bogus.
! > 
! > Case 3:
! > ---
! > Jun 19 18:28:48  conr named[24481]: lame-servers:
! >info: success resolving
! >
'1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.0.0.3.2.f.1.0.7.4.0.1.0.0.2.ip6.arpa/PTR'
! >after disabling qname minimization due to 'ncache nxdomain'
! 
! Peter,
! 
! Case 1:
! 
! The 191.165.185.in-addr.arpa zone (@200.3.13.14) responds with NXDOMAIN to 
queries for any QTYPE for QNAME 191.165.185.in-addr.arpa.
! 
! Case 2:
! 
! The intra.daemon.contact zone (@195.154.230.217) responds with NXDOMAIN to 
queries for any QTYPE of QNAME intra.daemon.contact.
! 
! Case 3:
! 
! The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with NXDOMAIN 
to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
! 
! You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.
! 
! b.

Hi Michael,

   thank You very much for looking at this. Now I can see the problem.

Case 3 is indeed an interesting matter:

  7.4.0.1.0.0.2.ip6.arpa -> NOERROR  (ARIN)
0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR  (HE)
  1.0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR
f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
  1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR
  0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
0.0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
  c.0.0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NXDOMAIN
2.c.0.0.3.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa -> NOERROR  (myself)

AFAIK, HE does serve more than only a few IPv6. It's strange that
nobody has worried about this, yet. 


And Case 2 is my own venture into splitting the horizon:
I indeed want /You/ to see NXDOMAIN for intra.daemon.contact when
asking the SOA of daemon.contact

But my internal servers have this:

zone "daemon.contact" {
type static-stub;
server-addresses { fdff::2; } ;
};
zone "intra.daemon.contact" {
type static-stub;
server-addresses { fdff::2; } ;
};

and should get:
$ host -t SOA daemon.contact fdff::2
daemon.contact has SOA record myhost.intra.daemon.contact ...
$ host -t SOA intra.daemon.contact fdff::2
intra.daemon.contact has SOA record myhost.intra.daemon.contact ...

According to the manual:
   "static-stub: ... when recursion is necessary for a query that
   matches a static-stub zone, the locally configured data (name
   server names and glue addresses) is always used, even if
   different authoritative information is cached"

It seems I have to analyze why that doesn't work as inteded in
this case.

Thank You for figuring it out!

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: qname minimization: me too :(

2024-06-24 Thread Peter
On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote:
! On Fri, Jun 21, 2024 at 07:03:14AM +,
! 65;6800;1c Michael Batchelder  wrote 
!  a message of 59 lines which said:
! 
! > You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.
! 
! Yes and, if you want the whole context, you can read RFC 8020
!  and section 4 of RFC 7816
! .


Sure, I did that already. And I also talked to the maintainer of
ns*.he.net, i.e. this one:

! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with 
NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
! >
! > You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.

And they seem to think, there is nothing wrong with that, because
nobody ever has complained about that.


Now I am really wondering: why do I, an unemployed old guy just
running his own computer, suddenly find myself in between a root
operator and the biggest v6 network on the planet?

In other words: why do You guys no longer talk to each other?


cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: qname minimization: me too :(

2024-06-25 Thread Peter
On Tue, Jun 25, 2024 at 07:00:51AM +1000, Mark Andrews wrote:
! It’s just a false positive when the result is NXDOMAIN. Because
> people forget to put delegating NS records in parent zones when both
> are served by the same server the lookups continue on NXDOMAIN. There
> is an issue to address this.  

You mean this?

Jun 25 16:18:31  conr named[4725]: lame-servers:
   info: success resolving 'bar.foo.isc.org/A' after disabling
   qname minimization due to 'ncache nxdomain'

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

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


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


Re: qname minimization: me too :(

2024-06-25 Thread Peter
On Tue, Jun 25, 2024 at 04:41:54PM +0200, Stephane Bortzmeyer wrote:
! On Tue, Jun 25, 2024 at 04:22:40PM +0200,
!  Peter  wrote 
!  a message of 16 lines which said:
! 
! > Jun 25 16:18:31  conr named[4725]: lame-servers:
! >info: success resolving 'bar.foo.isc.org/A' after disabling
! >qname minimization due to 'ncache nxdomain'
! 
! I do not see how this is possible ("success resolving") since the name
! does not exist and all ISC name servers reply it does not exist.
! 
! And all the resolvers I tried (through RIPE Atlas) say the same. No
! "success resolving".
! 
! Strange...

Good, now we're getting on the same page. :)

I think I understand it now (more or less):

Let's assume the nameserver for isc.org. is configured correctly. Then
this message concerning qname-minimization cannot be substantial, it
likely rather is, as Mark Andrews said, a "false positive".

Second, what do we mean by "success resolving"? Do we mean we got the
desired answer? Do we mean we got a correct proof of nonexistance? Or
do we just mean we did not end up in timeout/SERVFAIL?

I don't know exactly, and I don't bother anymore. I spent my time
searching my own configurations for an error (or just an
imperfectness) due to this same message - and probably there is none.


cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


bind918 malfunction?

2024-09-05 Thread Peter
I have complaints about network malfunction. From the logs I can see
that a device which always regained network access within ~40 seconds,
now takes 1-2 hours to recover, and this happening almost daily.

There is a possible alignment between the start of the malfunction
and an upgrade from 9.16 to 9.18.28 (later 29).
Is there anything about 9.18 that I might need to know?

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: bind918 malfunction?

2024-09-05 Thread Peter
On Thu, Sep 05, 2024 at 07:05:29PM +0200, Ondřej Surý wrote:
! It’s impossible to answer your question as you haven’t provided
! absolutely no information about your problem. Perhaps if you provide
! detailed information about nature of the problem, your DNS
! configuration, and your network configuration, we might be able to
! help you.

Alright, I can give you the logs.
This is the device with 9.16, taking 40 seconds to regain
network access:

Apr 15 01:44:39  alcatel syslog: Register account 1: Failed. 
Apr 15 01:45:20  alcatel syslog: Register account 1: successful. 

And this is the device now:

Aug 31 06:12:43  alcatel syslog: Register account 1: Failed. 
Aug 31 08:10:19  alcatel syslog: Register account 1: successful. 


Now don't tell me that the device is crap, because I know that
already. For now we have to live with it - and it did work before.

Here is the traffic for the first case (only the answers):

   q_timestmp|   a_timestmp|typ
| seq | rrtext  
   
-+-+---+-+
 15.04.2024 01:44:38.729122 CEST | 15.04.2024 01:44:38.785851 CEST | QUESTION  
|   1 | tel.t-online.de. IN NAPTR
 15.04.2024 01:44:38.729122 CEST | 15.04.2024 01:44:38.785851 CEST | ANSWER
|   1 | tel.t-online.de. 7200 IN NAPTR 10 0 "s" "SIPS+D2T" "" 
_sips._tcp.tel.t-online.de.
 15.04.2024 01:44:38.729122 CEST | 15.04.2024 01:44:38.785851 CEST | ANSWER
|   2 | tel.t-online.de. 7200 IN NAPTR 30 0 "s" "SIP+D2T" "" 
_sip._tcp.tel.t-online.de.
 15.04.2024 01:44:38.729122 CEST | 15.04.2024 01:44:38.785851 CEST | ANSWER
|   3 | tel.t-online.de. 7200 IN NAPTR 20 0 "s" "SIP+D2U" "" 
_sip._udp.tel.t-online.de.
 15.04.2024 01:44:39.266325 CEST | 15.04.2024 01:44:39.307556 CEST | QUESTION  
|   1 | _sip._udp.tel.t-online.de. IN SRV
 15.04.2024 01:44:39.266325 CEST | 15.04.2024 01:44:39.307556 CEST | ANSWER
|   1 | _sip._udp.tel.t-online.de. 3600 IN SRV 20 0 5060 
hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.266325 CEST | 15.04.2024 01:44:39.307556 CEST | ANSWER
|   2 | _sip._udp.tel.t-online.de. 3600 IN SRV 30 0 5060 
nes008-f01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.266325 CEST | 15.04.2024 01:44:39.307556 CEST | ANSWER
|   3 | _sip._udp.tel.t-online.de. 3600 IN SRV 10 0 5060 
lei001-l01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.304721 CEST | 15.04.2024 01:44:39.497833 CEST | QUESTION  
|   1 | _sip._tcp.tel.t-online.de. IN SRV
 15.04.2024 01:44:39.304721 CEST | 15.04.2024 01:44:39.497833 CEST | ANSWER
|   1 | _sip._tcp.tel.t-online.de. 3600 IN SRV 20 0 5060 
hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.304721 CEST | 15.04.2024 01:44:39.497833 CEST | ANSWER
|   2 | _sip._tcp.tel.t-online.de. 3600 IN SRV 10 0 5060 
lei001-l01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.304721 CEST | 15.04.2024 01:44:39.497833 CEST | ANSWER
|   3 | _sip._tcp.tel.t-online.de. 3600 IN SRV 30 0 5060 
nes008-f01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.475107 CEST | 15.04.2024 01:44:39.499073 CEST | QUESTION  
|   1 | tel.t-online.de. IN A
 15.04.2024 01:44:39.475107 CEST | 15.04.2024 01:44:39.499073 CEST | AUTHORITY 
|   1 | tel.t-online.de. 10800 IN SOA ns1.edns.t-ipnet.de. dns.telekom.de. 
2018022700 43200 1800 1209600 21600
 15.04.2024 01:44:39.502283 CEST | 15.04.2024 01:44:39.502592 CEST | QUESTION  
|   1 | tel.t-online.de. IN A
 15.04.2024 01:44:39.502283 CEST | 15.04.2024 01:44:39.502592 CEST | AUTHORITY 
|   1 | tel.t-online.de. 10800 IN SOA ns1.edns.t-ipnet.de. dns.telekom.de. 
2018022700 43200 1800 1209600 21600
 15.04.2024 01:44:39.474596 CEST | 15.04.2024 01:44:39.52327 CEST  | QUESTION  
|   1 | _sips._tcp.tel.t-online.de. IN SRV
 15.04.2024 01:44:39.474596 CEST | 15.04.2024 01:44:39.52327 CEST  | ANSWER
|   1 | _sips._tcp.tel.t-online.de. 3600 IN SRV 20 0 5061 
hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.474596 CEST | 15.04.2024 01:44:39.52327 CEST  | ANSWER
|   2 | _sips._tcp.tel.t-online.de. 3600 IN SRV 10 0 5061 
lei001-l01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:44:39.474596 CEST | 15.04.2024 01:44:39.52327 CEST  | ANSWER
|   3 | _sips._tcp.tel.t-online.de. 3600 IN SRV 30 0 5061 
nes008-f01-mav-pc-rt-001.edns.t-ipnet.de.
 15.04.2024 01:45:18.755781 CEST | 15.04.2024 01:45:18.756249 CEST | QUESTION  
|   1 | tel.t-online.de. IN NAPTR
 15.04.2024 01:45:18.755781 CEST | 15.04.2024 01:45:18.756249 CEST | ANSWER
|   1 | tel.t-online.de. 7160 IN NAPTR 20 0 "s" "SIP+D2U" "" 
_sip._udp.tel.t-online.de.
 15.04.2024 01:45:18.755781 CEST | 15.04.2024 01:45:18.756249 CEST | ANSWER
|   2 | tel.t-online.de. 7160 IN NAPTR 10 0 "s" "SIPS+D2T" "" 
_sips._tcp.tel.t-online.de.
 15.04.2024 01:

Re: bind918 malfunction?

2024-09-06 Thread Peter
This one was accidentially not sent to the list, sorry!

On Thu, Sep 05, 2024 at 08:04:37PM +0200, Ondřej Surý wrote:
! I’m on my phone, so this is a long shot, but you can try disabling the qname 
minimization.

Thank You for the suggestion, I can try this occasionally. Rather
I'd prefer to figure out what exactly is going wrong. Looking
through the entire dialogue it appears as if the resolver just stopped in
midflight and gave back SERVFAIL, with no obvious reason.

After figuring out why assumedly my database started to quote
querystrings ;) I looked into the data of the day, I found something
interesting: there is again the resolver apparently giving up in
midflight, but this time there are some error messages:

Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns1.edns.t-ipnet.de/A'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns1.edns.t-ipnet.de/'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns2.edns.t-ipnet.de/A'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns2.edns.t-ipnet.de/'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns3.edns.t-ipnet.de/A'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns3.edns.t-ipnet.de/'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns4.edns.t-ipnet.de/A'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns4.edns.t-ipnet.de/'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns5.edns.t-ipnet.de/A'
Sep  5 17:18:33  conr named[4456]: resolver: info: loop detected 
resolving 'ns5.edns.t-ipnet.de/'
Sep  5 17:18:34  conr named[4456]: query-errors: info:
  client @0x885bd4160 192.168.97.23#3102 (_sip._udp.tel.t-online.de):
  view intra: query failed (failure) for _sip._udp.tel.t-on line.de/IN/SRV at 
query.c:7836
Sep  5 17:18:34  conr named[4456]: query-errors: info:
  client @0x87d9fc160 192.168.97.23#3102 (_sip._tcp.tel.t-online.de):
  view intra: query failed (failure) for _sip._tcp.tel.t-on line.de/IN/SRV at 
query.c:7836
Sep  5 17:18:34  conr named[4456]: query-errors: info:
  client @0x840265160 192.168.97.23#3102 (_sips._tcp.tel.t-online.de):
  view intra: query failed (failure) for _sips._tcp.tel.t-online.de/IN/SRV at 
query.c:7836

Looking further, there are more of these "loop detected", apparently for
random nameservers all around world. And also from 9.16, but they
didn't seem to harm back then.
Not sure what to make of this - it doesn't look good.


cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: bind918 malfunction?

2024-09-06 Thread Peter
On Fri, Sep 06, 2024 at 12:55:20PM -0400, Bob Harold wrote:
! Recently (2024/9/21) I ran into an issue that might be similar.  Due to
! DDoS attacks that use complicated lookups to make DNS servers do extra
! work, to slow them down, some recent DNS server software has tightened the
! amount of 'work' that it will do on a single query before giving up and
! returning SERVFAIL.  In my case I had spread out my NS records over several
! domains, and each of those domains depended on yet more domains.  This was
! designed to increase resilience by not depending on a single domain.  But
! we began to get random failures, in our case when trying to get an SSL
! Certificate, LetEncrypt using Unbound was verifying every NS record and
! sometimes gave up, with an error message "exceeded the maximum nameserver
! nxdomains" even though there were no 'nxdomains' in the log.  I simplified
! my NS records and the problem went away.

Thank You,

  I am on this track now, also. I found that in two cases there were
precisely 31 resolver queries before the SERVFAIL, and I wondered why
this would be the same number. Then I found in the release notes
something about limiting query count to 32.

  If this is indeed the issue, then we need an error message that
actually tells us what the problem is.

  I am currently analyzing issues that appeared /after/ upgrade to 9.18
and /before/ 9.18.29 - and these are a lot rarer, and most look like
genuine weirdness/outages/maintenance.

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: bind918 malfunction?

2024-09-06 Thread Peter
On Fri, Sep 06, 2024 at 08:05:18PM +0200, Ondřej Surý wrote:
! Try using running `named -d 9 (plus other existing args)` to see why there 
are 31+ queries. There must be something wonky going on.
! 

Alright. "-d 9" does nothing.

Changing the named.conf does something:
channel named_log {
syslog local0;
// severity info;
severity debug 99;
print-category yes;
print-severity yes;
};
channel activity_log {
syslog local1;
// severity info;
severity debug 99;
print-category yes;
print-severity yes;
};
category client  { activity_log; };
category config  { named_log; };
category database{ named_log; };
category dnssec  { activity_log; };
category general { named_log; };
category network { named_log; };
category notify  { named_log; };
category queries { null; };
category query-errors{ activity_log; };
category resolver{ activity_log; };
category security{ named_log; };
category update  { named_log; };
category update-security { named_log; };
category xfer-in { named_log; };
category xfer-out{ named_log; };
category unmatched   { named_log; };
category default { named_log; };

Not sure if this is all we need. "queries" got me bored, as I
have dnstap anyway. If we need it, I must try to repeat - it
does not always happen. Here it did:

20:31:59# host ns4.edns.t-ipnet.de
Host ns4.edns.t-ipnet.de not found: 2(SERVFAIL)

Apparently the 99 is now a bit more than you wanted.
But - voila!

Sep  6 20:31:59  pole named[71152]: resolver: debug 3: exceeded 
max queries resolving 'ns1.edns.t-ipnet.de/' (querycount=33, maxqueries=32)

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: bind918 malfunction?

2024-09-06 Thread Peter
On Fri, Sep 06, 2024 at 09:12:51PM +0200, Ondřej Surý wrote:
! Now the question remains - why? I don’t really see a reason for this
! behavior from where I tested it, so what is the traffic between your
! recursor and the Internet during the time this happens?

Well, I can see why - but I don't know if this is all as intended:

* Query comes along "tel.t-online.de. IN NAPTR"
* RESOLVER_QUERY goes to 2003:180:4:10a::2:53 (I don't know where that
  comes from. Cache?
* Response gives *six* authoritative: ns1...ns6.edns.t-ipnet.de.
* 12 queries (v4/v6) go to the root servers
* we get 12 identical answers, containing *six* servers for "de."
* 12 queries go to z.nic.de.
* we get 12 identical answers, containing five servers for "t-ipnet.de."
* 6 queries go to dns20.dns.t-ipnet.de.
* we get 6 answers and cannot use them, because 1+12+12+6 = 31
* SERVFAIL

You have the details in the attachment on one of my mails.

It looks logically correct to me. If this is not how it is supposed
to work, then tell me. I didn't build it ;) - I just tried to
understand it and then make it work nicely.
And I did not hack that part! - only the dnstap, to get to the
information that is needed for this kind of analysis (microseconds and
view). 

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


How to create a fake root server?

2014-03-12 Thread Peter

Hi guys,

I'm doing a virtual internet (internal net) for several VPS's. My goal 
is to simulate the Internet root servers and the ISP:s domain servers, 
which are hosting the actual domains. I want to the create several DNS 
nameservers that will contain the specific domain under the "xxx.loc, 
yyy.loc, zzz.loc".


1 server for the .loc root
3 servers for xxx.loc (server1), yyy.loc (server2), zzz.loc (server3)

Running BIND 9 at every server.

Any suggestions or good links are highly appreciated.

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

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


Re: How to create a fake root server?

2014-03-13 Thread Peter

Hi Kevin,

Thanks for your reply. It's just for a closed internal network with no 
access to the rest of the internet. Making labs such as testing ISP 
functions and services, mail servers etc. Everything is running inside 
an VMware host with an internal closed network.


I have created a closed "Internet" on 172.16.x.x where I would like to 
put up a root server for .loc, where several other ISP-DNS servers, with 
domains, are referred to. I've managed to create those "ISP-DNS" servers 
which works fine. But I'm having trouble to create the root DNS server 
with Bind. I haven't found any useful examples at the web yet.


It's for a school project.

Regards, Peter


On 12/03/14 19:56, Kevin Darcy wrote:

First of all, don't use .loc as an internal TLD. There are *many*
proposals in process with ICANN for establishing new TLDs, and for all
you know, .loc might be one of them. If .loc gets established on the
Internet, and you're using it internally, that presents abundant
opportunities for confusion and failure.

Use a publically-registered domain, a descendant of a
publically-registered domain, or potentially, one of the reserved TLDs
in RFC 6761.

I'm not sure what your question is, exactly. Set up the root zone,
slave it, publish 2 or more of the master/slaves in the NS records,
delegate whatever TLD you're going to use, set up *that* zone, lather,
rinse, repeat, for the entire hierarchy. Anyone who reads
_DNS_and_BIND_ should be able to set up an internal-root
infrastructure, IMO (although, sadly, the later editions don't seem as
aligned to internal-root as they used to be).

    - Kevin


On 3/12/2014 11:07 AM, Peter wrote:

Hi guys,

I'm doing a virtual internet (internal net) for several VPS's. My
goal is to simulate the Internet root servers and the ISP:s domain
servers, which are hosting the actual domains. I want to the create
several DNS nameservers that will contain the specific domain under
the "xxx.loc, yyy.loc, zzz.loc".

1 server for the .loc root
3 servers for xxx.loc (server1), yyy.loc (server2), zzz.loc (server3)

Running BIND 9 at every server.

Any suggestions or good links are highly appreciated.

Best regards,
Peter
___
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


Re: How to create a fake root server?

2014-03-13 Thread Peter
I finally managed to configure a TLD DNS server which will answer, in 
its own CLI, with proper IP:s for added domains. The problem is that it 
doesn't reply to the other querying Domain DNS servers when they are 
asking for domain lookups to it. I can only do lookups inside the TLD 
DNS server.


The TLD server settings:

named.conf
---
options {
directory "/var/cache/bind";

// forwarders {
//  0.0.0.0;
// };

dnssec-validation auto;

auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
allow-query { any; };
recursion yes;
};
zone "loc" {
type master;
file "/etc/bind/pri.loc";
};
---

pri.loc
---
$ORIGIN .
$TTL 7200   ; 2 hours
loc IN  SOA ns1.intranet admin.intranet.loc (
2   ; serial
7200   ; refresh (2 hours)
1800   ; retry (30 minutes)
7200   ; expire (2 hours)
7200   ; minimum (2 hours)
)
NS  ns1.intranet
$ORIGIN loc.
domain1  A   172.16.0.121
domain2A   172.16.0.122
---

TLD Server# ping domain1.loc
PING domain1.loc (172.16.0.121) 56(84) bytes of data.
64 bytes from 172.16.0.121: icmp_req=1 ttl=64 time=0.196 ms
64 bytes from 172.16.0.121: icmp_req=2 ttl=64 time=0.160 ms
64 bytes from 172.16.0.121: icmp_req=3 ttl=64 time=0.177 ms

TLD Server# ping domain2.loc
PING domain2.loc (172.16.0.121) 56(84) bytes of data.
64 bytes from 172.16.0.121: icmp_req=1 ttl=64 time=0.193 ms
64 bytes from 172.16.0.121: icmp_req=2 ttl=64 time=0.168 ms
64 bytes from 172.16.0.121: icmp_req=3 ttl=64 time=0.172 ms

Domain Server1# ping domain2.loc
ping: unknown host domain2.loc

Domain Server2# ping domain1.loc
ping: unknown host domain2.loc


On both Domain DNS servers, I have made forwards with the IP of the TLD 
server. But they simply will not receive any lookup answers. They have 
also been configured with 127.0.0.1 in the resolv.conf file, which means 
they will use their own internal DNS server for lookups. All servers are 
on the same 172.16.0.x network.


What am I doing wrong here?

Sincerely, Peter


On 13/03/14 11:10, Mark Andrews wrote:

In message <53216b43.8040...@gmail.com>, Peter writes:

Hi Kevin,

Thanks for your reply. It's just for a closed internal network with no
access to the rest of the internet. Making labs such as testing ISP
functions and services, mail servers etc. Everything is running inside
an VMware host with an internal closed network.

I have created a closed "Internet" on 172.16.x.x where I would like to
put up a root server for .loc, where several other ISP-DNS servers, with
domains, are referred to. I've managed to create those "ISP-DNS" servers
which works fine. But I'm having trouble to create the root DNS server
with Bind. I haven't found any useful examples at the web yet.

Perhaps because a root zone is like any other zone.  It has a SOA
record and NS records at the apex and other records.

. 3600 SOA server.example.net. hostmaster.example.net. 1 3600 1200 2419200 3600
. 3600 NS server.example.net.
. 3600 NS another.example.net.
server.example.net. 3600 A 1.2.3.4
another.example.net. 3600 A 1.2.3.5


It's for a school project.

Regards, Peter


On 12/03/14 19:56, Kevin Darcy wrote:

First of all, don't use .loc as an internal TLD. There are *many*
proposals in process with ICANN for establishing new TLDs, and for all
you know, .loc might be one of them. If .loc gets established on the
Internet, and you're using it internally, that presents abundant
opportunities for confusion and failure.

Use a publically-registered domain, a descendant of a
publically-registered domain, or potentially, one of the reserved TLDs
in RFC 6761.

I'm not sure what your question is, exactly. Set up the root zone,
slave it, publish 2 or more of the master/slaves in the NS records,
delegate whatever TLD you're going to use, set up *that* zone, lather,
rinse, repeat, for the entire hierarchy. Anyone who reads
_DNS_and_BIND_ should be able to set up an internal-root
infrastructure, IMO (although, sadly, the later editions don't seem as
aligned to internal-root as they used to be).

 - Kevin


On 3/12/2014 11:07 AM, Peter wrote:

Hi guys,

I'm doing a virtual internet (internal net) for several VPS's. My
goal is to simulate the Internet root servers and the ISP:s domain
servers, which are hosting the actual domains. I want to the create
several DNS nameservers that 

Without IPv6 half of the queries yield SERVFAIL

2021-08-05 Thread Peter


Hi all,

  first off: I do not have IPv6 physical connectivity yet, but I would
like to run a nameserver nevertheless.

Sadly, it seems that without IPv6 connectivity, half of the queries
fail, in a random fashion.

There is no clue in the logfile about any reason for this behaviour,
only so much as:

client: error: query client=0x80db45160
   thread=0x80125ba00(pole.daemon.contact/A): query_gotanswer:
   unexpected error: SERVFAIL
query-errors: info: client @0x80db45160 192.168.98.10#17919
   (pole.daemon.contact): view intra: query failed (SERVFAIL)
   for pole.daemon.contact/IN/A at query.c:7376

Increasing the debug level does not give me more insight.

The failure happens randomly, half of the time. (Only after 'rndc flush',
obviousely, so it went undetected at first, taken for a network
hiccup.)

I finally resorted to full dnstap logging, and walked myself thru
the whole orgy of recursive resolving. The outcome:

This name in question, pole.daemon.contact, has four nameservers,
each of them has two IPv4 and one IPv6 addresses.

In the cases when the query is successful, the recursion happens just
as we would expect it: at some point an IP address for one of the four
nameservers is obtained, then from that IP address the desired A
record is queried and obtained, and after a bit more of validation
stuff (probably DNSSEC) the client gets the proper answer.

In the cases when the query yields SERVFAIL, the difference is that
the first arriving answer for one of the nameserver's addresses is an
answer to an  query, not an A query (as mentioned, ther are four
possible nameservers, and each has A and  records). At that point
the client is sent NXDOMAIN, disregarding that the other (A and )
records are just at that moment being received. So the query is fail,
and the service is outage, and it is bad.

The problem appears on different machines, all running FreeBSD 12.2
and BIND 9.16.18.

I tried to use this recommendation, https://kb.isc.org/docs/aa-00206,
marking all IPv6 addrs as bogus, but it does not make a difference in
behaviour.

Is there any means to tell named that we just don't have IPv6
connections yet (which actually should be obvious because there is
not IPv6 address on the interfaces, except for lo0)?

I know I can use -4 cmdline option, but that disables everything,
while I would rather like to slowly and tentatively enter IPv6 (but
on my pace, and not forced by a named insisting in all-or-nothing).
I would rather like named to continue and try the other seven address
options, and not just NXDOMAIN rightaway.


rgds,
PMc
___
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: Without IPv6 half of the queries yield SERVFAIL

2021-08-05 Thread Peter
On Thu, Aug 05, 2021 at 11:53:35PM +0200, Peter wrote:

! I tried to use this recommendation, https://kb.isc.org/docs/aa-00206,
! marking all IPv6 addrs as bogus, but it does not make a difference in
! behaviour.

Update: Actually there is a difference if this recommended
configuration is present or not - only the NXDOMAIN outcome is the
same in both cases.

WITH this configuration ("server ::/0 { bogus yes; };") I get the
behaviour as described in the previous msg: Resolving will
occasionally fail, depending on the sequence in which the recursive
queries get answered.

WITHOUT this configuration lots of INET6 queries are generated (and
cannot be sent anywhere as there is no IPv6). And then frequently
this error appears:

Aug  6 00:05:51  conr named[5623]: resolver: debug 3:
exceeded max queries resolving 'curitiba.porkbun.com/'
(querycount=101, maxqueries=100)

Now that is something I can understand. :) So, when I put this
into the configuration: "max-recursion-queries 400;", then things
appear to work!
But this is probably not "The Good Way" to solve this (and it fills
the log with all these "lame-servers" errors from the unreachable
IPv6 addresses).

So then, maybe the recommended configuration with
"server ::/0 { bogus yes; };"
is not so really recommendable and rather dangerous? Or mabye it is
somehow misbehaving in this case?

rgds,
PMc
___
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: Without IPv6 half of the queries yield SERVFAIL

2021-08-06 Thread Peter
On Fri, Aug 06, 2021 at 07:22:32AM +0200, sth...@nethelp.no wrote:
! > ! I tried to use this recommendation, https://kb.isc.org/docs/aa-00206,
! > ! marking all IPv6 addrs as bogus, but it does not make a difference in
! > ! behaviour.
! > 
! > Update: Actually there is a difference if this recommended
! > configuration is present or not - only the NXDOMAIN outcome is the
! > same in both cases.
! 
! Have you tried:
! 
! listen-on-v6{ none; };

No, I have

listen-on-v6{ ::1; };

And as I understand, this is something different: this is where named
will respond to queries from clients, while my issue is with the
servers named asks when doing recursive resolve.
If anything, then "query-source-v6" would be the appropriate one, but
that doesn't seem to allow "none;".

rgds,
PMc
___
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


Failure from rate-limit

2021-08-11 Thread Peter
Hi,

 my servers fail to query the upstream servers with these errors:
 
rate-limit: debug 99: rrl=0x0, HAVECOOKIE=0, result=DNS_R_SERVFAIL,
fname=0x8027a5450(0), is_zone=0, RECURSIONOK=1, query.rpz_st=0x0(0),
RRL_CHECKED=0

The operator of the upstream servers says it is due to a configuration
mistake. How can this be fixed? I do not have any rate-limit option
configured...

rgds,
PMc
___
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


ERROR: Failed to create fetch for DNSKEY update

2021-11-14 Thread Peter
Hi all,

 I continuousely happen to see this message:

> local0.warn named[2291]:
> dnssec: warning: managed-keys-zone: Failed to create fetch for DNSKEY update

I see it on different nameservers, at different sites, with and
without views, with and without IPv6, and I see it every time when
named is restarted.

I couldn't find the message mentioned on google etc.

The docs say DNSSEC for a mere recursive server should work out of the
box with the defaults. Apparently it doesn't, but where could I find a
clue about what my config is missing? (I have nothing at all
configured concerning DNSSEC.)



Other clues failing, I took a look at the source, and I suppose things to
bo like that:

lib/dns/zone.c:zone_refreshkeys()
if (result == ISC_R_SUCCESS) {
fetching = true;
} else {
...skipping...
dnssec_log(zone, ISC_LOG_WARNING,
   "Failed to create fetch for DNSKEY update 
%d", result);

lib/dns/resolver.c:dns_resolver_createfetch()
lib/dns/resolver.c:fctx_create()
lib/dns/view.c:dns_view_findzonecut()

} else if (result != ISC_R_SUCCESS) {
/*
 * Something is broken.
 */

(could have almost imagined that ...)

lib/dns/zone.c:dns_zone_getdb()

if (zone->db == NULL) {
result = DNS_R_NOTLOADED;
-

So this doesn't give a clue either :(


Wondering
 * WHAT is broken?
 * Why does it happen only to me?


Cheerio,
PMc
___
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: ERROR: Failed to create fetch for DNSKEY update

2021-11-15 Thread Peter

On Mon, Nov 15, 2021 at 09:14:19AM +0100, Ondřej Surý wrote:
! > On 15. 11. 2021, at 3:41, Peter  wrote:   
 
! > 
! > Wondering   
! > * WHAT is broken?   
! > * Why does it happen only to me?
!   
! We can’t really help you if you don’t share any details of your installation  
! and configuration (hint: You can use `named-checkconf -px` to scrub the   
! configuration).   
!
! So far, you shared a **single line** from the log and nothing else.   


Yes, certainly, since You do not allow more to be sent.


When I try to send log or config data, I only get this in reply:


   - The following addresses had permanent fatal errors -   

(reason: 550 5.7.1 Blocked by SpamAssassin) 
  
(reason: 550 5.7.1 Blocked by SpamAssassin) 

   - Transcript of session follows -
... while talking to mx.pao1.isc.org.:  
>>> DATA
<<< 550 5.7.1 Blocked by SpamAssassin   
554 5.0.0 Service unavailable   


cheerio,
PMc
___
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


Found the bug (was: ERROR: Failed to create fetch for DNSKEY update)

2021-11-19 Thread Peter


Hija,

  I finally found the cause of the error! As soon as I stop slaving
the root-zones and instead use the (configured or compiled-in)
hint-file, the error stops.

The actual error-condition (zone is not loaded) then becomes
obvious, because this RFC-5011 action happens very early, before
any zones are loaded. And with slaved root-zones instead of a
hint-file, the root zone has to be loaded like the others.

So the flaw is in the initialization sequence.

I don't really see why we would need to do this RFC-5011 so early.
As matters are, it now is failed, postponed, and run an hour later
successfully, and things should work just as well.

So You may now fix the issue, or just continue to spamblock the
bugreports (which is a great scheme to get error-free software, btw).

cheerio,
PMc
___
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: Found the bug (was: ERROR: Failed to create fetch for DNSKEY update)

2021-11-21 Thread Peter
On Sun, Nov 21, 2021 at 06:51:13PM +0100, Sten Carlsen wrote:
! As far as I am aware - and what I have always done - the normal
| thing to do is to use a hints file. Lately the hints are built-in,
| so nothing is really needed.

Ah. Well, I have here a named.conf.sample file that comes with the
distribution, and that shows both ways. And it doesn't seem to say
that one of them would be "normal".

! One question that comes to mind:
! What happens if the slaved root zones are not up to date /not
! correct?

Hm. It depends. When they are not up to date, the question is WHERE
are they not up to date, and why?
When they are not correct - since these are digitally signed
zonefiles, they must be identical everywhere. So if they are not
correct, then I think the Internet has a problem.

Anyway, as long as the roots let me xfer, I do xfer. For me it has a
few advantages: 1. a baseline of proven functionality: xfers do work.
2. I always have a syntactically correct example zonefile on file. 3.
I have them in the backup and can easily see when something was changed.

! might that be the cause?

No. These files are checked/updated about every 15 minutes, and I have
not had any problem with them in more than a decade.
And this error message appears only and exactly once at server start,
no matter if or when these zonefiles have been fetched before.

So, I've just updated OS, so let's have a look at the logs:

Nov 21 17:07:58  pole named[1771]: general: info: shutting down: 
flushing changes
Nov 21 17:07:58  pole named[1771]: general: notice: stopping 
command channel on 127.0.0.1#953
Nov 21 17:07:58  pole named[1771]: general: notice: exiting
Nov 21 18:04:40  pole named[3722]: zoneload: info: 
managed-keys-zone: loaded serial 346
Nov 21 18:04:40  pole named[3722]: dnssec: warning: 
managed-keys-zone: Failed to create fetch for DNSKEY update
Nov 21 18:04:40  pole named[3722]: zoneload: info: zone ./IN: 
loaded serial 2021112100 (DNSSEC signed)
Nov 21 18:04:40  pole named[3722]: zoneload: info: zone 
10.in-addr.arpa/IN: loaded serial 2021080800
Nov 21 18:04:40  pole named[3722]: zoneload: info: zone arpa/IN: 
loaded serial 2021112101 (DNSSEC signed)

So, we can see, at first it opens that "managed-keys-zone"
pseudozone. There it detects that it might query the DNSKEY,
and *fails*. Only *after that* it loads the ./IN & friends.

Now if one looks a bit into the running code, the error number is
65586 ( that's what the error message would show if it would show the
error number. :/ ), and in the source this error is defined as
DNS_R_NOTLOADED.

Now let's look further on. Exactly an hour later this appears:

Nov 21 19:04:40  pole named[3722]: dnssec: info: 
managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer 
complete)

The question would now be: what does it do in the meantime? Does
it distrust the trust-anchor? That's interesting, because without
trust anchor it would likely need to distrust everything.

Lets try that out: shutdown, restart, see the error - and I still
get the AD bit in TLDs. So it seems to have no troublesome effect.


Now lets make something else clear: I am running these machines
since way back into the last century - when it was common to know
*every file* on your machine, and to read the sourcecode within thse
files - and occasionally to even understand it.
And I hold on to that line, because what we have today is worse.


cheerio, PMc
___
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


Bugfix: missing line in message.c

2022-06-01 Thread Peter
Hi,

  this is broken in 916 (and apparently 918 also).
Consequentially, output from dnstap gets unreadable (invalid YAML)
when using dynamic zone updates. 

 PATCH 
--- lib/dns/message.c.orig  2022-05-10 11:02:21.0 +0200
+++ lib/dns/message.c   2022-05-30 04:02:40.568222000 +0200
@@ -4296,6 +4296,7 @@
INDENT(style);
ADD_STRING(target, "QUESTION: ");
} else {
+   INDENT(style);
ADD_STRING(target, "ZONE: ");
}
snprintf(buf, sizeof(buf), "%1u",
 PATCH 

And when You'ra at it:
I would very much appreciate when we could get the *view name* into the
dnstap output.

I am running my nameservers as
 * authoritative to the public,
 * authoritative for the LAN,
 * recursing for the LAN (for DNSSEC to work some useful DANE things),
 * authoritative as root slave,
 * recursing as root slave (for DNSSEC to get 'AD' instead of 'AA'),
 * plus a couple of in-between cases,
all in a single process. :)

Obviousely that needs lots of views. I found dnstap to be the perfect
and long desired solution for debugging and understanding what
actually happens, to become even able to create more fancy setups.

But then the view name is needed in the messages. There is an option 
'dnstap-identity (  | none | hostname );'
and putting that into the views would be the natural solution - but
that doesn't work, it gets rejected as a syntax error (for no reason
obvious to me). I tried 918, it gets rejected there also.

So for now I hacked it with a simple approach (because I know my
version anyway, I need only the identity of an instance and the view)
and that works for now:
-   dm->d.version.data = env->version.base;
-   dm->d.version.len = env->version.length;
+   dm->d.version.data = (uint8_t *)(view->name);
+   dm->d.version.len = strlen(view->name);

But this is ugly as it computes strlen() on every call. I could do it
nicer, but then I think the beforementioned option should be made
working instead.


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

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


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


Re: Bugfix: missing line in message.c

2022-06-05 Thread Peter
On Thu, Jun 02, 2022 at 08:23:27AM +1000, Mark Andrews wrote:
! Thanks.
! 
! INDENT is being addressed.
! 
! Can you add an issue on https://gitlab.isc.org/ for the view name in dnstap?

Bad luck for me, my login does actually work there - so I probably
have to... ;)

Done, it says #3391.


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

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


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


IPv6 scoped address disambiguation

2022-06-16 Thread Peter
Hi @all,

 the reference manual says something about scoped ipv6 addresses,
so I might assume they are understood and useable. But maybe either
I did misunderstand something, or something is wrong here:

My configuration:

listen-on-v6 port 53{ fe80::2%lo0;
  fe80::3%lo0; };

This is what I have:

# ifconfig | grep fe80
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 fe80::2%lo0 prefixlen 128 scopeid 0x3
inet6 fe80::3%lo0 prefixlen 128 scopeid 0x3
inet6 fe80::2%tun0 prefixlen 124 scopeid 0x5
inet6 fe80::2%tun1 prefixlen 124 scopeid 0x6

And this is what I get when starting named:

# netstat -an6 | grep "fe80.*53.*LISTEN"

tcp6   0  0 fe80::2%tun1.53*.*LISTEN 
tcp6   0  0 fe80::2%tun0.53*.*LISTEN 
tcp6   0  0 fe80::3%lo0.53 *.*LISTEN 
tcp6   0  0 fe80::2%lo0.53 *.*LISTEN 

I didn't expect the %tun0 and %tun1 to appear here.
Am I missing some necessary quoting in the address string?

My version:

BIND 9.16.29 (Extended Support Version) 
running on FreeBSD amd64 12.3-RELEASE-p5


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


How to make SRV records work with caching resolvers?

2022-07-13 Thread Peter


My Telco has removed the A record for their VoIP server, and now has
only SRV data there - which seems not to work properly.

The SRV data contains various services (SIP via UDP, TCP, secure
TCP, whatever), and these get individual expiry counters in the
caching resolver.
So when a telephone sends a query, the caching resolver will provide
that data in the "Additional section" - but only those records that
have not yet expired. 

If the configured service (the one the telephone should use) is no
longer contained in the answer (but others are still present), the
telephone goes offline until all the records have expired and a new
authoritative query is made.

The Telco is of no help - they just want to sell their own equipment.

The telphones (Alcatel) are the usual linux plastic box, and I cannot
easily hack these. It probably does not behave fully correct, but
also not fully wrong.

In BIND/named I didn't find an easy approach to fix the issue - it
doesn't look like it is supposed to be fixed there. And before I go
for the more difficult approaches, I would like to ask how this
is actually supposed to work, at all.


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

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


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


Re: How to make SRV records work with caching resolvers?

2022-07-13 Thread Peter
On Wed, Jul 13, 2022 at 09:22:17PM +1000, Mark Andrews wrote:
! The client is supposed to lookup missing address records.

Now that's clear and short. Thank You very much, Mark!

! Complain to the supplier of the phone that they have a defective product.

I still have to see a linux plastic box without such flaws... And yes,
You're right, that would be the way to go when running a 3+ digit
unit-count of these phones. But now as I know who is to blame, I can
think about an interim workaround.


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

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


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


Re: How to make SRV records work with caching resolvers?

2022-07-25 Thread Peter
On Thu, Jul 14, 2022 at 06:22:47PM +0200, Ondřej Surý wrote:
! Could you for the purpose of the debugging share the DNS traffic between the 
phone device and the resolver?
! 
! I think stepping back a little might help debug the issue. Perhaps people on 
the list might notice something that might help.
! 
! Ondrej

Hi Ondrej,

thanks for Your reply. I tried to obtain something reproducible, but
with no luck. These failures are a bit difficult to catch, they happen
mostly deep at night, for whatever reason. (And in any case a reset of
the phone does fix the issue.) Once I tried to analyze the failure and
noticed the partial information in the additional section, as
described - so I thought I had identified the issue (and should
occasionally learn how this should actually work - as I did now).

Now when I log the entire DNS traffic, I don't see the same pattern
appearing again. (Obviousely there can be many other reasons for a
temporary outage.)
The plan is now to put this on hold until it appears at annoying daytimes
again, and ideally obtain a kind of VoIP-proxy or PBX to put in between.

-- PMc


! > On 13. 7. 2022, at 13:18, Peter  wrote:
! > 
! > 
! > My Telco has removed the A record for their VoIP server, and now has
! > only SRV data there - which seems not to work properly.
! > 
! > The SRV data contains various services (SIP via UDP, TCP, secure
! > TCP, whatever), and these get individual expiry counters in the
! > caching resolver.
! > So when a telephone sends a query, the caching resolver will provide
! > that data in the "Additional section" - but only those records that
! > have not yet expired. 
! > 
! > If the configured service (the one the telephone should use) is no
! > longer contained in the answer (but others are still present), the
! > telephone goes offline until all the records have expired and a new
! > authoritative query is made.
! > 
! > The Telco is of no help - they just want to sell their own equipment.
! > 
! > The telphones (Alcatel) are the usual linux plastic box, and I cannot
! > easily hack these. It probably does not behave fully correct, but
! > also not fully wrong.
! > 
! > In BIND/named I didn't find an easy approach to fix the issue - it
! > doesn't look like it is supposed to be fixed there. And before I go
! > for the more difficult approaches, I would like to ask how this
! > is actually supposed to work, at all.
! > 
! > 
! > -- PMc
! > -- 
! > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list
! > 
! > ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.
! > 
! > 
! > bind-users mailing list
! > bind-users@lists.isc.org
! > https://lists.isc.org/mailman/listinfo/bind-users
! 
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


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

2022-08-02 Thread Peter
On Tue, Aug 02, 2022 at 05:51:28AM -0400, Timothe Litt wrote:

! You can get the AD flag set, with a bit of extra work.  I've done this for
! years.

Thanks for Your message, Timothe.
After investigating the matter, I had figured out a similar approach -
but didn't know if this is a recommended or commonly used way. There
is only a paper somewhere in the depths of ISC describing how to do
that for a root-slave. Anyway, it appears to work.
I finally created 6-way servers by using some extra addresses on lo0
(auth+recursing for root+intranet+public) and then found the result
suitable structured and maintainable.

! Before your authoritative view, define a recursive view with the internal
! zones defined as static-stub, match-recursive-only "yes",  and a
! server-address of localhost. 

Uh? Why before?

My approach so far:

view "rootslave" {
match-clients { fdff::1; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;

};
view "intraslave" {
match-clients { fdff::2; key "slave1"; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;

};
view "extraslave" {
match-clients { key "slave1extra"; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;

};
view "guest" {// public WLAN etc.
match-clients { ... };

// not yet deployed, needs clarification
};
view "desktop" {// user devices
match-clients { ... };



};
view "intra" {
match-clients {  };


};
view "public" {   // external sites allowed to use recursing
match-clients { ... } ;
// not yet deployed, needs evaluation
};
view "external" { // fall-through
match-clients { any; } ;
allow-query-cache { none; };
allow-recursion { none; };
recursion no;
zone "." {   // is this necessary? (something didn't work without)
type hint;
file "/usr/local/etc/namedb/named.root";
};

};


Sure this could also be done by running 2 or 3 instances, and probably
more safe - but where would be the fun then?


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

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


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


Re: bind-users Digest, Vol 4031, Issue 3

2022-08-02 Thread Peter
On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:
! 
! On 02-Aug-22 11:09, bind-users-requ...@lists.isc.org wrote:
! 
! > | Before your authoritative view, define a recursive view with the internal
! > ! zones defined as static-stub, match-recursive-only "yes",  and a
! > ! server-address of localhost.
! > 
! > Uh? Why before?
! 
! Because each request attempts to match the views in order.  You want the
! stub view to match recursive requests.  The non-RD requests will fall thru
! to the internal zone and get the authoritative data. 

Ahh, I see. But this does not work so well for me, because I have the
public authoritative server also in the same process. And from the
Internet will come requests with RD flag set, and these must get a
REFUSED ("recursion desired but not available").

So I considered it too dangerous to select views depending on the RD
flag being present or not, and resolve this with a slightly different
ordering of the views.

-- PMc
-- 
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: Stopping ddos

2022-08-02 Thread Peter
On Tue, Aug 02, 2022 at 11:16:15PM +0200, Michael De Roover wrote:
! For my servers I'm using iptables rules to achieve ratelimiting. They
! look as follows:
! -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent --
! update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255
! --rsource -j DROP
! -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent --set
! --name DEFAULT --mask 255.255.255.255 --rsource
! 
! It should be fairly trivial to convert these to use UDP 53, and tweak
! the timings you want. These rules are intended to allow 4 connections
! (which normally should be entire SMTP transactions) every 10 minutes.
! Since I have 2 edge nodes with these rules, that is doubled to 8
! connections total. If you're an authoritative name server only,
! realistically mostly recursors / caching servers would query your
! servers and not too often. You can easily restrict traffic here. If
! you're a recursor too, this becomes a bit more complicated.

Just to give a Heads Up:

I have a very similar config in IPFW protecting port 53 with a rate
limit. I had put that in because the option was there and I thought
it a good idea, and then entirely forgotten about it.

I was then very surprized when I couldn't renew my certificates due
to creepy and non-reproducible failures. A CA cen send quite an amount
of queries when validating a site, and may have tough timeouts.
I recommend testing such a rate-limit against DNSviz.net which also
sends a high amount of queries.

(My actual fault was to forget about the limit, otherwise one could
just remove it temporarily during such actions.)

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

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


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


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

2022-08-03 Thread Peter
On Tue, Aug 02, 2022 at 02:04:22PM -0400, Timothe Litt wrote:   
! On 02-Aug-22 13:18, Peter wrote:  
! > On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:   
! > !   
! > ! On 02-Aug-22 11:09,bind-users-requ...@lists.isc.org  wrote:   
! > !   
! > ! > | Before your authoritative view, define a recursive view with the 
internal   
! > ! > ! zones defined as static-stub, match-recursive-only "yes",  and a  
! > ! > ! server-address of localhost.  
! > ! > 
! > ! > Uh? Why before? 
! > !   
! > ! Because each request attempts to match the views in order.  You want the  
! > ! stub view to match recursive requests.  The non-RD requests will fall thru
! > ! to the internal zone and get the authoritative data.  
! > 
! > Ahh, I see. But this does not work so well for me, because I have the   
! > public authoritative server also in the same process. And from the  
! > Internet will come requests with RD flag set, and these must get a  
! > REFUSED ("recursion desired but not available").
! > 
! > So I considered it too dangerous to select views depending on the RD
! > flag being present or not, and resolve this with a slightly different   
! > ordering of the views.  
! > 
! > -- PMc  
!   
! Order matters, and changing it will change behaviors. 

That is obvious.

! The server doesn't select ONLY on the RD flag.  It also selects on IP address 
!and/or TSIG keys.  The RD flag is only used to select between the recursive and
!authoritative view pairs for MATCHING CLIENTS. 

Fine.   

! So you should order the views as I showed.

That's not going to work with me. I posted the description of   
my approach, so either you provide evidence of why my logic is  
flawed, or You stop telling me that I should obey You.  

I devised my logic, and it is well possible that it is flawed,  
but if so, then I want to understand the exact flaw, and learn  
and improve.

! The public clients will fail the "match-clients" clause of the internal views 
!regardless of the RD because of their IP addresses.  They will fall thru to the
!r-external view.  That will also fail unless they are listed clients.  So  
!again, they fall thru to the external view.  That has recursion no - which 
!means that RD will return REFUSED. 

Fine. Same here.

! The only danger comes from failing to properly setup the client matching ACLs,
!or from making changes to the logic without understanding how it works.

Mistakes can happen, e.g. when in a hurry.  
 

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

2022-08-03 Thread Peter
On Wed, Aug 03, 2022 at 04:49:35PM +1000, Mark Andrews wrote:
! Additionally authoritative servers for a zone are supposed to answer queries 
with RD=1 set with RA=0 if the client is not being offered recursion.  REFUSED 
is the wrong answer of the query name involves zones you serve. Only if you are 
a recursive only server should you be considering REFUSED. 

I am seeing queries for example.com (literally). I didn't talk about
people querying my own domains. Those seem to get their answer, plus
"recursion desired but ..."

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

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


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


Re: DNSSEC adoption

2022-08-03 Thread Peter
I see a two-fold issue with DNSSEC:

1. The wide-spread tutorials seem to explain a key rollover as an
   exceptional activity, a *change* that is infrequently done. And
   changes, specifically the infrequent ones, bring along the
   possibility of failure, mostly due to human error.

   I don't see reason why this is so. DNSSEC can be fully
   automated (mine is), and then it can be done frequently, and the
   human factor is out of the loop. It is then no longer a change,
   but a regular operation that happens every 
   without anybody even need noticing it.
   (Let'sEncrypt did the same for certificates, and that also works
   well.)

2. TCP seems still to be considered a second-class-citizen in the
   DNS world. (If I got the details right, TCP is only "optional",
   and must only be tried as a second choice after receiving TC.)
   So people may be induced to try and squeeze replies into whatever
   512 or 1280 or 1500 bytes. Which means, they probably cannot use
   more than one key, and so take possible redundancy out of the game.

   I do not currently know about how or where this issue could be
   tackled appropriately; I for my part have decided to happily ignore
   it, and am using *four* KSK, thereby supporting RFC 5011 and RFC
   7344, all with one simple script - and anyway now I have the longest;
   here you can see it in action: https://dnsviz.net/d/daemon.contact/dnssec/
   Let's see where this leads into problems; for now it appears not to.

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

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


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


Re: Question about dnstap

2022-09-12 Thread Peter
On Mon, Sep 12, 2022 at 12:27:25PM +0200, Borja Marcos wrote:

! I am not sure this is intended behavior, or maybe I should file a bug.
! 
! I am doing some tests with dnstap and bind (9.18.6 now but I see the same 
behavior with older 9.18 versions). I am using
! dnstap-go.
! 
! I have configured bind to use dnstap with no other options and using a Unix 
domain socket. (On named.conf, dnstap {all;};).
! 
! If I start named but the dnstap collector is not running it will never try to 
connect. I need to start the dnstap program 
! _before_ starting named. 
! 
! From the named.conf documentation I assumed that bind would retry the dnstap 
connection periodically. (fstrm-reopen-interval).

I don't know if intended or not, but when configuring dnstap I
noticed the same behaviour.

I tried at first to write to a file, but not by any means could I get
the file rotation to work. Then I considered writing to a file that is
a named pipe - but that would require the reading program to reopen
whenever named might be restarted. Finally I resorted to the socket,
and noticed that the reader program now must not be restarted while
named is running.
I can live with that.

bind916-9.16.30
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3
(Probably slightly lower versions at the time of testing.)

FreeBSD 13.1-RELEASE-p2, w/ some patches, all ports locally built,
build logs available on request.
(Maybe FreeBSD 12.3 at the time of testing.)
-- 
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: Question about dnstap

2022-09-12 Thread Peter
On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! My testing did not uncover anything problematic.
! 
! Versions:
! fstrm 0.6.1-1
! protobuf 21.5-1
! protobuf-c 1.4.1-1
! 
! 
! A procedure which works:
! - start BIND configured with
! options {
!   dnstap { all; };
!   dnstap-output unix "/tmp/unix";
! };
! 
! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix
! -w /tmp/capture
! 
! - fire couple queries: sleep 6 && dig bla example
! 
! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature

Negative. Does not work here:

/tmp # ls -la capture
-rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
/tmp # dnstap-read -y /tmp/capture
/tmp # named -V
BIND 9.16.30 (Extended Support Version) 
running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
built by make with '--disable-linux-caps' '--localstatedir=/var' 
'--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--without-python' 
'--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib 
-ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' 
'--disable-geoip' '--without-maxminddb' '--with-gssapi=/usr' 
'CFLAGS=-I/usr/include -O2 -pipe -march=haswell -DLIBICONV_PLUG 
-fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 
'LDFLAGS= -fstack-protector-strong ' 'LIBS=-lkrb5 -lgssapi -lgssapi_krb5 
-L/usr/local/lib' 'KRB5CONFIG=/usr/bin/krb5-config' '--with-libidn2=/usr/local' 
'--without-json-c' '--disable-largefile' '--without-lmdb' 
'--disable-native-pkcs11' '--enable-querytrace' '--enable-tcp-fastopen' 
'--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' 
'--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13.1' 
'build_alias=amd64-portbld-freebsd13.1' 'CC=cc' 'CPPFLAGS=-DLIBICONV_PLUG 
-isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 
'PKG_CONFIG_LIBDIR=/var/local/ports/usr/ports/dns/bind916/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig'
 'PYTHON=/usr/local/bin/python3.8'
compiled by CLANG FreeBSD Clang 13.0.0 (g...@github.com:llvm/llvm-project.git 
llvmorg-13.0.0-0-gd7b669b3a303)
compiled with OpenSSL version: OpenSSL 1.1.1o-freebsd  3 May 2022
linked to OpenSSL version: OpenSSL 1.1.1o-freebsd  3 May 2022
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled


-- 
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: Question about dnstap

2022-09-13 Thread Peter
On Tue, Sep 13, 2022 at 12:24:15PM +0200, Petr Špaček wrote:
! On 12. 09. 22 15:49, Peter wrote:
! > On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! > ! My testing did not uncover anything problematic.
! > !
! > ! Versions:
! > ! fstrm 0.6.1-1
! > ! protobuf 21.5-1
! > ! protobuf-c 1.4.1-1
! > !
! > !
! > ! A procedure which works:
! > ! - start BIND configured with
! > ! options {
! > !   dnstap { all; };
! > !   dnstap-output unix "/tmp/unix";
! > ! };
! > !
! > ! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u 
/tmp/unix
! > ! -w /tmp/capture
! > !
! > ! - fire couple queries: sleep 6 && dig bla example
! > !
! > ! - check content of /tmp/capture with dnstap-read: dnstap-read -y 
/tmp/cature
! > 
! > Negative. Does not work here:
! > 
! > /tmp # ls -la capture
! > -rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
! > /tmp # dnstap-read -y /tmp/capture
! > /tmp # named -V
! > BIND 9.16.30 (Extended Support Version) 
! > running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
! 
! Unfortunately neither me on Linux or my colleague who testing on FreeBSD are
! able to reproduce the problem you describe.

Okay, thank You for checking. I didn't look into the matter since I
got my things working nevertheless.
It looks a bit different now as not only me is experiencing the
behaviour.

! There is a caveat, though: Without the --split interval option one has to
! terminate fstrm_capture to get data for dnstap-read to consume. That's
! probably by design and outside of our control (in libfstrm).

This would then happen no matter if fstrm_capture is started before or
after named.


Let's have a short look.
truss tells me that named is trying to open the socket, and receives
ECONNREFUSED.
Then, after every 5 seconds (just as the docs say) it tries again, but
now it receives EPERM !

Apparently, the first connect() happens (after chroot but) before
droppings priviledges.
(The FreeBSD integration script does set -u to UID "bind", by default.)

So, apparently, fstrm_capture should also run as UID "bind" (and would
then need a proper filespace where it is allowed to create that
socket). Or something else along that line.

The OP should check if their problem suddenly resolves when doing a
"chmod 777" on that socket (and then devise a suitable design
according to their security policy).

It's a joy to work with you folks, as always. :)

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

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


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


named 9.14.6 memory leak, cannot start

2019-10-15 Thread Peter


When starting named 9.14.6, before doing any activity it immediately
grows infinitely, hits the system limits and crashes with:

> mem.c:710: fatal error:
> malloc failed: Cannot allocate memory
> exiting (due to fatal error in library)

Version 9.14.3 does not have this memory leak and runs flawlessly
(with 100MB VSZ).


Here are the detailled messages:

starting BIND 9.14.6 (Stable Release) 
running on FreeBSD i386 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0
r351611M#N348:361: Fri Aug 30 04:59:55 UTC 2019
built with '--localstatedir=/var' '--disable-linux-caps'
   '--with-libxml2=/usr/local'
   '--with-readline=-L/usr/local/lib -ledit'
   '--with-dlopen=yes' '--with-openssl=/usr'
   '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes'
   '--disable-dnstap' '--disable-fixed-rrset' '--without-geoip2'
   '--with-gssapi=/usr' 'KRB5CONFIG=/usr/bin/krb5-config'
   '--with-libidn2=/usr/local' '--without-libjson'
   '--disable-largefile' '--without-lmdb' '--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=i386-portbld-freebsd11.3'
   'build_alias=i386-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe
   -march=pentium3 -DLIBICONV_PLUG -fstack-protector-strong -isystem
   /usr/local/include -fno-strict-aliasing ' 'LDFLAGS=
   -fstack-protector-strong ' 'LIBS=-L/usr/local/lib'
   'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
   'PKG_CONFIG=pkgconf' 
running as: named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 (tags/RELEASE_800/final 
356365)
compiled with OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
linked to OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11

BIND 9 is maintained by Internet Systems Consortium,
Inc. (ISC), a non-profit 501(c)(3) public-benefit 
corporation.  Support and training for BIND 9 are 
available at https://www.isc.org/support

mem.c:710: fatal error:
malloc failed: Cannot allocate memory
exiting (due to fatal error in library)


This is 9.14.3:

starting BIND 9.14.3 (Stable Release) 
running on FreeBSD i386 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0
   r351611M#N348:361: Fri Aug 30 04:59:55 UTC 2019
built with '--localstatedir=/var' '--disable-linux-caps'
   '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit'
   '--with-dlopen=yes' '--with-openssl=/usr'
   '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes'
   '--disable-dnstap' '--disable-fixed-rrset' '--with-ssapi=/usr'
   'KRB5CONFIG=/usr/bin/krb5-config' '--with-libidn2=/usr/local'
   '--without-libjson' '--disable-largefile' '--without-lmdb'
   '--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=i386-portbld-freebsd11.3'
   'build_alias=i386-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe
   -march=pentium3 -DLIBICONV_PLUG -fstack-protector-strong -isystem
   /usr/local/include -fno-strict-aliasing ' 'LDFLAGS=
   -fstack-protector-strong ' 'LIBS=-L/usr/local/lib'
   'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
   'PKG_CONFIG=pkgconf'
running as: named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 (tags/RELEASE_800/final 
356365)
compiled with OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
linked to OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11

BIND 9 is maintained by Internet Systems Consortium,
Inc. (ISC), a non-profit 501(c)(3) public-benefit 
corporation.  Support and training for BIND 9 are 
available at https://www.isc.org/support

command channel listening on 127.0.0.1#953
general: notice: all zones loaded
general: notice: running
___
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: named 9.14.6 memory leak, cannot start

2019-10-16 Thread Peter
On Wed, Oct 16, 2019 at 12:27:39PM +0200, Ondřej Surý wrote:
! Hi Peter,
! 
! we had a similar report in the past,

Ah, that's a good message!

! so maybe you can chime in and add
! the information to the issue here 
https://gitlab.isc.org/isc-projects/bind9/issues/1179 ?

Okay, done.

Further investigation shows the basic memory usage increased by about
factor 10, and the per-zone memory usage increased by factor 100.

So it's not a leak, it just doesn't fit into the available ~1.2GB
user heap space anymore.

cheerio,
P.
___
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: FYI: FreeBSD: upgrade to protobuf-c 1.4.1_6 breaks dig

2024-10-14 Thread Peter
On Mon, Oct 14, 2024 at 06:10:20AM -0700, Steve Rikli wrote:
! On Mon, Oct 14, 2024 at 07:19:06AM +0200, Peter wrote:
! > On Sun, Oct 13, 2024 at 10:55:52PM +0100, Niall O'Reilly wrote:
! > ! FYI only.  I've submitted a [bug report][] to the FreeBSD Bugzilla.
! > 
! > ! After upgrading to 1.4.1_6, I see:
! > ! 
! > ! ```
! > ! grab(maint)$ uname -a
! > ! FreeBSD grab.no8.be 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64
! > ! grab(maint)$ pkg info protobuf-c | grep -i ^version
! > ! Version: 1.4.1_6
! > ! grab(maint)$ dig -v
! > ! ld-elf.so.1: /usr/local/lib/libprotobuf-c.so.1: version 
LIBPROTOBUF_C_1.0.0
! > ! required by /usr/local/lib/bind-tools/libdns-9.20.2.so not defined
! > ! grab(maint)$
! > ! ```
! > 
! > I cannot reproduce:
! > 
! > # dig -v
! > DiG 9.20.2
! > # ldd /usr/local/bin/dig | grep protobuf
! > libprotobuf-c.so.1 => /usr/local/lib/libprotobuf-c.so.1 
(0x174f307b6000)
! > # pkg which /usr/local/lib/libprotobuf-c.so.1
! > /usr/local/lib/libprotobuf-c.so.1 was installed by package 
protobuf-c-1.4.1_6
! > 
! > # uname -a
! > FreeBSD vbuild3 13.4-RELEASE-p1 FreeBSD 
13.4-RELEASE-p1[e0f62d90381c=bc3877972ebd+41] ZE6R13V1 amd64
! 
! Peter, in your reproduce attempt, were these newly-installed (presumably
! together), or was protobuf[-c] subsequently upgraded in an existing
! installation?

Let's say, "radically new installed".
I run builds inside temporary bhyve-guests, so things are all freshly
compiled on a pristine OS image.

! In a quick experiment, which had bind 9.18.30 btw, I was unable to
! reproduce the problem in a fresh install of bind or bind-tools, either
! FreeBSD pkg pulls in the protobuf[-c] pre-req pkg during install.
! 
! However, on 4 servers (3 amd64, 1 i386) which had pre-existing bind and
! bind-tools pkgs already installed, upgrading protobuf[-c] yielded the
! lib problem Niall saw, e.g. for both 'dig' and 'named' binaries.
! 
! Re-installing bind[-tools] resolved the library conflict. I don't quite
! understand why.

I agree, this is creepy.

1. dig shouldn't even use this library. It is present in order to build
   dnstap-read. I'm not aware of any other use.
2. dig should be able to run with any variant of the library, as long
   as it is 1.0.
   Quick check:
 - DiG 9.18.29 built with protobuf-c 1.4.1_2 reports version with
   protobuf-c 1.4.1_6 
 - DiG 9.20.2 built with protobuf-c 1.4.1_6 reports version with
   protobuf-c 1.4.1_2

Whatever is going on here is not easy to understand from a remote
position.
As I just see, the "bind-tools" pkg was recently switched from 9.18 to
9.20. Named itself however is whatever version you choose to install
(if any). Maybe there is some conflict in that area.

I'll leave this for now, let's see what happens when my builds are
done and things are rolled out...

cheers,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


Re: FYI: FreeBSD: upgrade to protobuf-c 1.4.1_6 breaks dig

2024-10-13 Thread Peter
On Sun, Oct 13, 2024 at 10:55:52PM +0100, Niall O'Reilly wrote:
! FYI only.  I've submitted a [bug report][] to the FreeBSD Bugzilla.

! After upgrading to 1.4.1_6, I see:
! 
! ```
! grab(maint)$ uname -a
! FreeBSD grab.no8.be 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64
! grab(maint)$ pkg info protobuf-c | grep -i ^version
! Version: 1.4.1_6
! grab(maint)$ dig -v
! ld-elf.so.1: /usr/local/lib/libprotobuf-c.so.1: version LIBPROTOBUF_C_1.0.0
! required by /usr/local/lib/bind-tools/libdns-9.20.2.so not defined
! grab(maint)$
! ```

I cannot reproduce:

# dig -v
DiG 9.20.2
# ldd /usr/local/bin/dig | grep protobuf
libprotobuf-c.so.1 => /usr/local/lib/libprotobuf-c.so.1 (0x174f307b6000)
# pkg which /usr/local/lib/libprotobuf-c.so.1
/usr/local/lib/libprotobuf-c.so.1 was installed by package protobuf-c-1.4.1_6

# uname -a
FreeBSD vbuild3 13.4-RELEASE-p1 FreeBSD 
13.4-RELEASE-p1[e0f62d90381c=bc3877972ebd+41] ZE6R13V1 amd64
-- 
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: FYI: FreeBSD: upgrade to protobuf-c 1.4.1_6 breaks dig

2024-10-14 Thread Peter
On Mon, Oct 14, 2024 at 11:26:58AM +0100, Niall O'Reilly wrote:
! On 14 Oct 2024, at 6:19, Peter wrote:
! 
! > I cannot reproduce:
! 
! Thanks.  I've been made aware, off list, of people who can.

Interesting.
I for my part do normally not link dig against protobuf at all:

$ pkg info bind-tools | grep DNSTAP
DNSTAP : off

Currently, I am still building the 2024Q4, so I was grateful for your
heads-up, there might be a problem with dns/protobuf.
I started a test, switched the DNSTAP to on, and rebuilt. And there
were no problems.

! One of these has let me know that, for them, re-installing
! bind[-tools]

Well then I might assume, something broken was installed before.

That is probably one of the examples for why I recommend to run
your own deploy-chain, build on-site, and know exactly what you build.

cheerio,
PMc
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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


BIND Process failed during logrotate

2023-03-22 Thread White, Peter
I had the named process fail this past weekend on two secondaries running BIND 
9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13. It seems that logrotate.d is calling 
the following script at the time of the failure.

/var/named/data/named.run {
missingok
su named named
create 0644 named named
postrotate
/usr/bin/systemctl reload named.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-chroot.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-sdb.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-sdb-chroot.service > /dev/null 2>&1 || 
true
/usr/bin/systemctl reload named-pkcs11.service > /dev/null 2>&1 || true
endscript
}

First of all, is this script part of the normal BIND distribution, or is it 
part of the RHEL 7 distribution? From what I can tell, it is called weekly.

Poring through the BIND logs for the cause of the failure, I came across this. 
Note the server.c:2948 error message and subsequent failure.
19-Mar-2023 03:46:01.908 received control channel command 'reload'
19-Mar-2023 03:46:01.908 loading configuration from '/etc/named.conf'
19-Mar-2023 03:46:01.909 reading built-in trust anchors from file 
'/etc/named.root.key'
19-Mar-2023 03:46:01.909 GeoIP Country (IPv4) (type 1) DB not available
19-Mar-2023 03:46:01.909 GeoIP Country (IPv6) (type 12) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv4) (type 2) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv4) (type 6) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv6) (type 30) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv6) (type 31) DB not available
19-Mar-2023 03:46:01.909 GeoIP Region (type 3) DB not available
19-Mar-2023 03:46:01.909 GeoIP Region (type 7) DB not available
19-Mar-2023 03:46:01.909 GeoIP ISP (type 4) DB not available
19-Mar-2023 03:46:01.909 GeoIP Org (type 5) DB not available
19-Mar-2023 03:46:01.909 GeoIP AS (type 9) DB not available
19-Mar-2023 03:46:01.909 GeoIP Domain (type 11) DB not available
19-Mar-2023 03:46:01.909 GeoIP NetSpeed (type 10) DB not available
19-Mar-2023 03:46:01.909 using default UDP/IPv4 port range: [1024, 65535]
19-Mar-2023 03:46:01.909 using default UDP/IPv6 port range: [1024, 65535]
19-Mar-2023 03:46:01.910 sizing zone task pool based on 2 zones
19-Mar-2023 03:46:01.911 ../../../bin/named/server.c:2498: fatal error:
19-Mar-2023 03:46:01.911 RUNTIME_CHECK(tresult == 0) failed
19-Mar-2023 03:46:01.911 exiting (due to fatal error in library)
Looking back a week earlier when the script last run, that server.c error was 
not there.

Any thoughts on what could have caused this on two secondaries? The primary 
reloaded around the same time without incident.

Thanks for your assistance.
-- 
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: Unable to upgrade BIND v9.19.11 on Ubuntu without error

2023-07-11 Thread Peter Davies

Hi Richard,
  FYI: The BIND 9.19.12 Release Notes contain the following:


Removed Features
...
Zone type delegation-only, and the delegation-only and root-delegation-only 
statements, 
have been removed. Using them is a configuration error.
...

Kind Regards Peter

-
-- 
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: occasional SERVFAIL error

2024-02-29 Thread Peter Davies

Hi Ludovit,

   It looks like you have two version of the jiscd.sk zone.

host -C jiscd.sk
Nameserver 2001:67c:1bd4:8080::20:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 
604800 86400

Nameserver 195.49.191.160:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 
604800 86400

Nameserver 2001:67c:1bd4:8080::10:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 
604800 86400

Nameserver 195.49.191.162:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 
604800 86400



Kind Regards Peter

On 29/02/2024 15.20, Ludovit Koren wrote:


Hi,

occasionally I get the following SERVFAIL error:

dig www.jiscd.sk

; <<>> DiG 9.18.24 <<>> www.jiscd.sk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 35fe56eb9b5f3f22010065df34b4c313eedf839eac9d (good)
;; QUESTION SECTION:
;www.jiscd.sk.  IN  A

;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 14:27:16 CET 2024
;; MSG SIZE  rcvd: 69



I can get rid of it only after issuing:

rndc flush

Afterwards it works for uncertain time.

Could it be I have a configuration problem of my server (I have prefetch
0 set in options section of my server)? Is it a problem of the
authorized domain server?

Thank you very much.

Regards,

lk


--
Peter Davies

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


named 100% utilization

2024-04-30 Thread Peter Carlson
  listen-on port 53 { 192.168.10.11; 127.0.0.1; ::1; };

      minimal-responses yes;

      tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";

      };

   administrator@nc1:/etc/bind$ cat named.conf.local
   acl internals { 192.168.10.0/24; 192.168.11.0/24; localhost; };
   acl vpn   { 10.9.0.0/24; };

   view trusted {
    match-clients { internals; };
    allow-recursion { internals; };
    allow-query { "internals"; };
    allow-query-cache { "internals"; };
    recursion yes;

    zone "MYDOMAIN.com" IN { type master; file
   "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };
    zone "3cx.us" IN { type master; file "/etc/bind/db.3cx.us";
   allow-update { none; }; };

    zone "localhost" { type master; file "/etc/bind/db.local"; };
    zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; };
    zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; };
    zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; };
   include "/var/lib/samba/bind-dns/named.conf";
   };

   view vpn {
    match-clients { vpn; };
    allow-recursion { vpn; };
    allow-query { "vpn"; };
    allow-query-cache { "vpn"; };
    recursion yes;

    zone "MYDOMAIN.com" IN { type master; file
   "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };
   include "/var/lib/samba/bind-dns/named.conf";
   };


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

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


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


bind_dlz and views and samba

2024-05-15 Thread Peter Carlson
As I understand it bind_dlz does not support multiple views, I have to 
following scenario and am trying to figure out how to configure it:


 * Internal (192.168.10.0/24)
 o resolve internal domain xyz.com
 o resolve internal samba domain xyz.lab
 o resolve single address xyz.3cx.us to 192.168.10.25
 * External is resolved by a different server and xyz.3cx.us resolves
   to a public address
 * VPN (10.9.0.0/24)
 o resolve internal domain xyz.com
 o resolve internal samba domain xyz.lab
 o resolve single address xyz.3cx.us via normal public dns or
   alternatively resolve to external address

I initially set this up with views:


    acl internals { 192.168.10.0/24; 192.168.11.0/24; localhost; };
    acl vpn   { 10.9.0.0/24; };

    view trusted {
    match-clients { internals; };
    zone "MYDOMAIN.com" IN { type master; file 
"/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };
    zone "3cx.us" IN { type master; file "/etc/bind/db.3cx.us"; 
allow-update { none; }; };

    };

    view vpn {
    match-clients { vpn; };
    zone "MYDOMAIN.com" IN { type master; file 
"/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };

    };


But this crashes as soon as I add:


dlz "AD DNS Zone" {
 database "dlopen 
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_18.so";

};


So I split out DNS from ADDC, configured bind on DC to forward to 
another DNS and setup views there, but that doesnt work either as all 
requests now come from IP of the DC and so the ACLs wont match.


Any ideas how I can accomplish this?

Peter

-- 
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: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread Peter Andreev
2012/2/9 John Hascall 

>
>
> Questions:
>
> (1) It looks to me like if the ghost name is in our
>DNS RPZ zone, then that 'fixes' the problem for
>that name.   Is this correct?
>

Ghost domain could be redelegated to a new owner and become absolutely
legal.

>
> (2) It also looks like restarting bind flushes the cache
>and that prevents the repopulation of the local cache
>with names which are ghosts (new different ghost names
>could, of course, be created).Is this correct?
>

AFAIK 'rndc flush' will do the same.

>
> Thanks,
> John
>
>
> ---
> John Hascall, j...@iastate.edu
> Team Lead, NIADS (Network Infrastructure, Authentication & Directory
> Services)
> IT Services, The Iowa State University of Science and Technology
>
> > In , ISC
> > writes:
> >
> > > ISC continues to recommend that organizations with security needs
> > > who are reliant on the Domain Name System proceed with adoption of
> > > DNSSEC; DNSSEC is the best known method of mitigating this issue.
> >
> > But ISC provides no details about *how* exactly DNSSEC will solve the
> > problem. I'm puzzled. In the ghost domain names attack, the child zone
> > is controlled by the bad guy, who wants the domain to stick. So, he
> > will certainly not sign it. Unless you make DNSSEC mandatory, how will
> > you solve the ghost domain problem with DNSSEC? If the resolver is
> > sticky (will not go to the parent to ask the NS RRset), it won't check
> > the NSEC at the parent either...
> >
> > Is it because the resolver, even if sticky, re-queries the parent when
> > the negative TTL of the (missing) DS records ends? And chokes when it
> > receives back a NXDOMAIN?
> > ___
> > 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
>



-- 
--
AP
___
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: Anycast DNS

2012-02-29 Thread Peter Andreev
2012/3/1 Beavis 

> Just want to piggy back on this topic is there any documentation
> available online that shows a deployment guideline for Anycast?
>
> -beavis
>

What about RFC 4786?


> On Wed, Feb 29, 2012 at 10:31 AM, Warren Kumari  wrote:
> >
> > On Feb 29, 2012, at 11:00 AM, Todd Snyder wrote:
> >
> >> The reason I’ve heard a few times is that users are uncomfortable using
> only 1 address.  In the past I’ve done 2 or 3 addresses just so that we can
> give out 3 addresses that all point to the same pool of servers.
> >>
> >> Silly, I know, but sometimes it’s easier to placate than to change
> someone/groups understanding of the
> world/networking/resilience/dns/loadbalancing.
> >
> > It's partly silly, it's also partly not wanting to have all your eggs in
> one basket.
> >
> > Having more than one anycast address provides protection against things
> like routing attacks / leaks, overenthusiastic ACLs, router blackholes and
> similar.
> > It also provides a backup in case the primary node chosen by your
> routing infrastructure is unavailable -- if you only have a single anycast
> address (192.0.2.1) and the instance chosen by your routing system is down
> (for example though a DoS, misconfiguration, etc) you have no service. If
> you have a second address (10.10.10.10) that is announced by a different
> constellation you have redundancy.
> >
> > Also, anycast  provide the closest instance according to the *network
> topology* -- this doesn't always equate to fastest response -- if is not
> uncommon for a longer BGP path to have a shorter latency. providing
> multiple addresses allows the resolver to choose based upon time.
> >
> > W
> >
> >>
> >>
> >> $0.02
> >> t.
> >>
> >> From: bind-users-bounces+tsnyder=rim@lists.isc.org [mailto:
> bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of ju wusuo
> >> Sent: Tuesday, February 28, 2012 10:56 PM
> >> To: bind-users@lists.isc.org
> >> Subject: Anycast DNS
> >>
> >> Have seen some anycast DNS implementations using more than one address,
> some times even on the same subnet, any considerations or reasons for doing
> that?
> >>
> >>
> >>
> >> -
> >> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be
> unlawful. ___
> >> 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
>
>
>
> --
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
>
> Disclaimer:
> http://goldmark.org/jeff/stupid-disclaimers/
> ___
> 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
>



-- 
--
AP
___
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 reconfig" vs. "rndc reload"

2012-03-16 Thread Peter Andreev
2012/3/16 Mark Pettit 

> I've read carefully through the BIND ARM and am still not sure of the
> answer to this, so I figured I'd ask on here.
>
> "rndc reconfig" causes BIND to re-load its config file, but unlike "rndc
> reload", BIND will not scan the zone files it's mastering to see if there
> have been any updates.  This is very useful in our situation because most
> of our name servers have tens of thousands of zones.
>
> We have an antiquated push process that copies files into the zonefile
> directory and then tells BIND "rndc reload".  For various reasons, "rndc
> reload" takes about 120 seconds to complete.  BIND is not answering queries
> for a very large part of that time.
>
> I recently started experimenting with a different process: instead of
> "rndc reload" after updaing some of the zone files, I loop through the list
> of updated zone files and run "rndc reload " for each one.
>
> This is a vast improvement, because BIND doesn't appear to ever stop
> answering queries.
>
> However, I'm curious what I should do when an update contains both a new
> config file and new zone files.
>
> Normally a "rndc reload" would rescan the config and then scan all zone
> files (including the new ones), loading the new ones into memory and
> starting to serve them.  But obviously we want to avoid "rndc reload" at
> all costs.
>
> I was considering doing "rndc reconfig", followed by a "rndc reload
> " for each of the new zones.
>
> Would this work?
>
>
"rndc reconfig" forces BIND to re-read config file and load *only* new
zones. So if you add a new zone and want BIND to load it, you don't need
"rndc reload " at all, "rndc reconfig" is completely sufficient.

"rndc reload " is needed only if you modify existing zone.

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



-- 
AP
___
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: reverse dns for IPV6 ranges

2012-03-19 Thread Peter Andreev
2012/3/19 hugo hugoo 

>  Jay,
>
> - Can you give me an example of such configuration?
>
>
>
> As anyone else some examples of IPV6 reverse configuration used in
> production environment?
>
> Thanks for sharing your experience...
>
> Hugo,
>

We use IPv6 in production environment. It was a real headache to fill
reverse ip6.arpa zones by hand until I have learned about "arpaname"
utility. Since that maintaining reverse IPv6 zones is just a piece of cake.


>  > Date: Mon, 12 Mar 2012 16:28:53 -0500
> > From: jay-f...@uiowa.edu
>
> > To: hugo...@hotmail.com
> > CC: bind-users@lists.isc.org
> > Subject: RE: reverse dns for IPV6 ranges
> >
> > On Mon, 12 Mar 2012, hugo hugoo wrote:
> > > Has anyone else experience with reverse IPV6 configuration with Bind?
> >
> > We do static PTR records in the ip6.arpa zones like we do in the
> in-addr.arpa
> > zones, to create address->name mappings matching the name->address
> mappings
> > created by the  & A records.
> >
> > I fairly recently started fiddling with wildcard PTR records for DHCPv6
> > address pools, to at least return some answer for a query about the
> > addresses. Right now I have it configured so that a query for any
> address in
> > any of the pools returns the same name, but it could be changed to
> return
> > different names for different pools. This obviously doesn't create
> symmetric
> > name->address & address->name mapping, which might or might not be a
> problem.
> > I don't have enough real use of this to know whether this wildcard stuff
> is
> > helpful or not.
> >
> > 
> > Jay Ford, Network Engineering Group, Information Technology Services
> > University of Iowa, Iowa City, IA 52242
> > email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
>
> ___
> 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
>



-- 
AP
___
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: reverse dns for IPV6 ranges

2012-03-20 Thread Peter Andreev
2012/3/20 michoski 

> On 3/19/12 11:58 AM, "Peter Andreev"  wrote:
> > 2012/3/19 hugo hugoo 
> >>  Jay,
> >>
> >> - Can you give me an example of such configuration?
> >>
> >> As anyone else some examples of IPV6 reverse configuration used in
> >> production environment?
> >>
> >> Thanks for sharing your experience...
> >
> > We use IPv6 in production environment. It was a real headache to fill
> > reverse ip6.arpa zones by hand until I have learned about "arpaname"
> > utility. Since that maintaining reverse IPv6 zones is just a piece of
> cake.
>
> Hmm...  Yes, well I can see this as useful (though not much more than a few
> lines of any programming language?) if you intend to maintain generic
> placeholders...but not if you want RFC-compliant matching A/PTR.  Granted,
> you should not drop mail in such cases, but many do.  I guess tools and
> best
> practices take time to catch up to technological leaps.  ;-)
>
> Or do you actually create A's matching your generic PTR and heavily rely on
> CNAMEs?  Of course that simply won't do for some standard RR types.
>
> As much as I dislike djb in general, the way tinydns auto-creates matching
> PTR (and also provides a mechanism to disable as needed) for each A RR
> kinda
> makes sense.  Granted, it doesn't do IPv6 at all without 3rd-party
> hacks...but they do at least exist.
>
> --
> All his life he has looked away... to the horizon, to the sky,
> to the future.  Never his mind on where he was, on what he was doing.
>-- Yoda
>
>
Sorry for my stupidity, but I didn't catch your idea.

We have finite number of hardware. Due to geographic distribution, security
issues, lots of different prefixes in use, etc we don't use DHCP and assign
addresses by hand. So we do with PTRs. Of course I would go crazy if I fill
full v6 reverse zone, so I write only those PTRs which are needed.
If we assign IP blocks to clients, usually we simply delegate them
corresponding reverse zone.

-- 
AP
___
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: slave not updating or creating ofd zone files

2012-03-28 Thread Peter Andreev
2012/3/29 RYAN M. vAN GINNEKEN 

> Hello all i have what is to me a very strange bind 9 master slave transfer
> issue.
>
> When i update a zone file on the master the file updates correctly the
> notifies are sent and every thing seems to work perfectly except it
> transfers 0 bytes to the slave.  Checking the slave confirms that indeed
> thier was no transfer and that the slave is still serving the old zone, i
> have gon as far as to completely delete the zone files from the slave and
> restart bind to my suprise it puts back all the old files.  What is going
> on?  Below is an example of one of the files that is not updating correctly
> there are many and some of file I have updated more recently are not even
> showing up in the logs of the server.
>
> On the server Ubuntu 8.04 LTS running BIND 9.4.2-P2.1 chrooted
> 29-Mar-2012 06:03:39.461 general: info: zone jodygamracy.com/IN/external:
> loaded serial 2012031501
> 29-Mar-2012 06:03:39.614 notify: info: zone jodygamracy.com/IN/external:
> sending notifies (serial 2012031501)
> 29-Mar-2012 06:03:41.761 xfer-out: info: client 96.51.192.233#33074: view
> external: transfer of 'jodygamracy.com/IN': IXFR ended
>
> On the slave Ubuntu 10.04 LTS  BIND 9.7.0-P1
> 29-Mar-2012 00:03:41.666 general: info: zone jodygamracy.com/IN/external:
> Transfer started.
> 29-Mar-2012 00:03:41.706 xfer-in: info: transfer of '
> jodygamracy.com/IN/external' from 204.244.122.132#53: connected using
> 96.51.192.233#33074
> 29-Mar-2012 00:03:41.782 xfer-in: info: transfer of '
> jodygamracy.com/IN/external' from 204.244.122.132#53: Transfer completed:
> 0 messages, 1 records, 0 bytes, 0.076 secs (0 bytes/sec)
>
> As a side not i have both machines firewalled, but have port 53 open on
> both machines, and have ports set using this in these lines in the
> named.conf. file
>   query-source address * port 53;
> transfer-source * port 53;
> notify-source * port 53;
>
> and see this in the dameon logs
> /etc/named.conf:9: using specific query-source port suppresses port
> randomization and can be insecure.
>
> Computer King   CaN-MailSurveillance
> King
> http://computerking.ca http://canmail.org
> http://surveillanceking.net
>
> Surveillance - Sales Service - Hosting Backup
> Internet Based Surveillance Systems
> Custom Service Pac kages
> Secure IMAP Email - Automated Remote Backups - Photo Blogs - Online ERP
> and Accounting Packages
>
>
> ___
> 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
>

Enlarge your serial!

-- 
AP
___
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: slave not updating or creating ofd zone files

2012-03-28 Thread Peter Andreev
2012/3/29 Peter Andreev 

>
>
> 2012/3/29 RYAN M. vAN GINNEKEN 
>
>> Hello all i have what is to me a very strange bind 9 master slave
>> transfer issue.
>>
>> When i update a zone file on the master the file updates correctly the
>> notifies are sent and every thing seems to work perfectly except it
>> transfers 0 bytes to the slave.  Checking the slave confirms that indeed
>> thier was no transfer and that the slave is still serving the old zone, i
>> have gon as far as to completely delete the zone files from the slave and
>> restart bind to my suprise it puts back all the old files.  What is going
>> on?  Below is an example of one of the files that is not updating correctly
>> there are many and some of file I have updated more recently are not even
>> showing up in the logs of the server.
>>
>> On the server Ubuntu 8.04 LTS running BIND 9.4.2-P2.1 chrooted
>> 29-Mar-2012 06:03:39.461 general: info: zone jodygamracy.com/IN/external:
>> loaded serial 2012031501
>> 29-Mar-2012 06:03:39.614 notify: info: zone jodygamracy.com/IN/external:
>> sending notifies (serial 2012031501)
>> 29-Mar-2012 06:03:41.761 xfer-out: info: client 96.51.192.233#33074: view
>> external: transfer of 'jodygamracy.com/IN': IXFR ended
>>
>> On the slave Ubuntu 10.04 LTS  BIND 9.7.0-P1
>> 29-Mar-2012 00:03:41.666 general: info: zone jodygamracy.com/IN/external:
>> Transfer started.
>> 29-Mar-2012 00:03:41.706 xfer-in: info: transfer of '
>> jodygamracy.com/IN/external' from 204.244.122.132#53: connected using
>> 96.51.192.233#33074
>> 29-Mar-2012 00:03:41.782 xfer-in: info: transfer of '
>> jodygamracy.com/IN/external' from 204.244.122.132#53: Transfer
>> completed: 0 messages, 1 records, 0 bytes, 0.076 secs (0 bytes/sec)
>>
>> As a side not i have both machines firewalled, but have port 53 open on
>> both machines, and have ports set using this in these lines in the
>> named.conf. file
>>   query-source address * port 53;
>> transfer-source * port 53;
>> notify-source * port 53;
>>
>> and see this in the dameon logs
>> /etc/named.conf:9: using specific query-source port suppresses port
>> randomization and can be insecure.
>>
>> Computer King   CaN-MailSurveillance
>> King
>> http://computerking.ca http://canmail.org
>> http://surveillanceking.net
>>
>> Surveillance - Sales Service - Hosting Backup
>> Internet Based Surveillance Systems
>> Custom Service Pac kages
>> Secure IMAP Email - Automated Remote Backups - Photo Blogs - Online ERP
>> and Accounting Packages
>>
>>
>> ___
>> 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
>>
>
> Enlarge your serial!
>
> --
> AP
>

Sorry for previous message, I suggest you to update BIND.

-- 
AP
___
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 doesn't make zone delegation.

2012-04-19 Thread Peter Andreev
Hi,

First of all, nslookup isn't a good tool for debug DNS problems. Use dig
instead.

Could you show the output of "dig @freebsdbox sokol.msk.united-networks.ru.
NS +norec" run from freebsd box itself?


2012/4/19 Ellad G. Yatsko 

>
> Hello!
>>
>>I have FreeBSD 7.2 x64 installed. And Bind 9.4:
>>
>>/etc/namedb> named -v
>>BIND 9.4.3-P2
>>
>>I have zone "/united-networks.ru/" and I try to do the following:
>>...
>>$ORIGIN sokol.msk.united-networks.ru.
>>@   IN NS   srvgate
>>srvgate IN A172.31.16.16
>>$ORIGIN united-networks.ru.
>>...
>>
>>As I understand I delegated the SOA (IN NS) to server with name
>>
>> srvgate.sokol.msk.united-**networks.ru("srvgate"
>>  has no tailing "dot"
>>so domain "sokol.msk.united-networks.ru" from $ORIGIN operator will be
>>appended), then I placed "glue"-record with srvgate.sokol.msk's
>> address.
>>It is because as I understood nameserver of delegated zone is in it.
>>
>>From here I thought on the server 172.31.16.16 (it's Ubuntu) I must
>>receive DNS-requests related to zone sokol.msk.united-networks.ru. For
>>example if I try do nslookup sokol.msk.united-networks.ru on FreeBSD
>>7.2 x64. But:
>>
>>/etc/bind# hostname -f
>>
>> srvgate.sokol.msk.united-**networks.ru
>>/etc/bind# tshark -ta -ni tun0 -R dns
>>Running as user "root" and group "root". This could be dangerous.
>>Capturing on tun0
>>
>>...there is nothing! And FreeBSD issues NXDOMAIN. I say more - FreeBSD
>>tries to resolve name "sokol.msk.united-networks.ru" through its
>> forwarder in
>>external world!
>>
>>Where am I wrong? I simulated this situation with the same
>> configurations
>>on Ubuntu (Bind 9.7.0-P1) and fresh-installed FreeBSD 9.0 x64 (Bind
>> 9.8.1-P1).
>>All works fine!
>>
>>--** related portion of
>> named.conf --**
>>options {
>> directory   "/etc/namedb";
>> pid-file"/var/run/named/pid";
>> dump-file   "/var/dump/named_dump.db";
>> statistics-file "/var/stats/named.stats";
>>
>> listen-on   {
>> 
>> 127.0.0.1;
>> 172.16.0.1;
>> 172.16.1.1;
>> 172.16.2.1;
>> 172.31.0.1;
>> };
>>
>> forwarders {
>> 89.222.167.2;
>> 8.8.8.8;
>> };
>> recursion yes;
>> allow-recursion {0/0;};
>>};
>>
>>...
>>
>>view internal {
>> match-clients {
>> 127.0.0.0/8;
>> 172.16.0.0/12;
>> };
>>...
>> zone "united-networks.ru" {
>> type master;
>> file "master/forward/united-**networks.ru.internal";
>> allow-transfer {
>> 172.16.0.2;
>> 172.16.16.2;
>> 172.31.16.16;
>> 172.31.17.0;
>> 172.31.18.0;
>> };
>> };
>>...
>>};
>>...
>>--**--**
>> --**-
>>
>>Kind regards,
>>Ellad
>>
>
> __**_
> Please visit 
> https://lists.isc.org/mailman/**listinfo/bind-usersto
>  unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/**listinfo/bind-users
>



-- 
AP
___
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 doesn't make zone delegation.

2012-04-19 Thread Peter Andreev
2012/4/19 Ellad G. Yatsko 

>  Hello!
> Here is output:
> /etc/namedb> dig @172.16.0.1 sokol.msk.united-networks.ru. NS +norec
>
> ; <<>> DiG 9.4.3-P2 <<>> @172.16.0.1 sokol.msk.united-networks.ru. NS
> +norec
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14255
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;sokol.msk.united-networks.ru.  IN  NS
>
> ;; AUTHORITY SECTION:
> sokol.msk.united-networks.ru. 3600 IN   NS
> srvgate.sokol.msk.united-networks.ru.
>
> ;; ADDITIONAL SECTION:
> srvgate.sokol.msk.united-networks.ru. 3359 IN A 172.31.16.16
> srvgate.sokol.msk.united-networks.ru. 3359 IN A 172.16.16.1
>
> ;; Query time: 0 msec
> ;; SERVER: 172.16.0.1#53(172.16.0.1)
> ;; WHEN: Thu Apr 19 14:08:55 2012
> ;; MSG SIZE  rcvd: 100
>

Looks good for me.


> I noticed that after some time FreeBSD still tried to ask for
> sokol.msk.united-networks.ru from Ubuntu (srvgate.sokol.msk).
> It happened after 2-3 minutes after "named" was restarted on FreeBSD. But
> now FreeBSD doesn't ask for hosts in this zone.
> All what I was doing during this time period - I restarted freevrrp-daemon
> on FreeBSD machine. Could it be related to issue?
>

Is FreeBSD a master for sokol.msk.united-networks.ru? Looks like it is
trying to send notifies.


> Something very strange..  Another FreeBSD (9.0) works fine in the same (or
> much like) conditions...
>
> Kind regards,
> Ellad
>
> Hi,
>
> First of all, nslookup isn't a good tool for debug DNS problems. Use dig
> instead.
>
> Could you show the output of "dig @freebsdbox sokol.msk.united-networks.ru.
> NS +norec" run from freebsd box itself?
>
>
> 2012/4/19 Ellad G. Yatsko 
>
>>
>> Hello!
>>>
>>>I have FreeBSD 7.2 x64 installed. And Bind 9.4:
>>>
>>>/etc/namedb> named -v
>>>BIND 9.4.3-P2
>>>
>>>I have zone "/united-networks.ru/" and I try to do the following:
>>>...
>>>$ORIGIN sokol.msk.united-networks.ru.
>>>@   IN NS   srvgate
>>>srvgate IN A172.31.16.16
>>>$ORIGIN united-networks.ru.
>>>...
>>>
>>>As I understand I delegated the SOA (IN NS) to server with name
>>>srvgate.sokol.msk.united-networks.ru ("srvgate" has no tailing "dot"
>>>so domain "sokol.msk.united-networks.ru" from $ORIGIN operator will
>>> be
>>>appended), then I placed "glue"-record with srvgate.sokol.msk's
>>> address.
>>>It is because as I understood nameserver of delegated zone is in it.
>>>
>>>From here I thought on the server 172.31.16.16 (it's Ubuntu) I must
>>>receive DNS-requests related to zone sokol.msk.united-networks.ru.
>>> For
>>>example if I try do nslookup sokol.msk.united-networks.ru on FreeBSD
>>>7.2 x64. But:
>>>
>>>/etc/bind# hostname -f
>>>srvgate.sokol.msk.united-networks.ru
>>>/etc/bind# tshark -ta -ni tun0 -R dns
>>>Running as user "root" and group "root". This could be dangerous.
>>>Capturing on tun0
>>>
>>>...there is nothing! And FreeBSD issues NXDOMAIN. I say more - FreeBSD
>>>tries to resolve name "sokol.msk.united-networks.ru" through its
>>> forwarder in
>>>external world!
>>>
>>>Where am I wrong? I simulated this situation with the same
>>> configurations
>>>on Ubuntu (Bind 9.7.0-P1) and fresh-installed FreeBSD 9.0 x64 (Bind
>>> 9.8.1-P1).
>>>All works fine!
>>>
>>>-- related portion of named.conf
>>> --
>>>options {
>>> directory   "/etc/namedb";
>>> pid-file"/var/run/named/pid";
>>> dump-file   "/var/dump/named_dump.db";
>>> statistics-file "/var/stats/named.stats";
>>>
>>> listen-on   {
>>> 
>>> 127.0.0.1;
>>> 172.16.0.1;
>>> 172.16.1.1;
>>> 172.16.2.1;
>>> 172.31.0.1;
>>> };
>>>
>>> forwarders {
>>> 89.222.167.2;
>>> 8.8.8.8;
>>> };
>>> recursion yes;
>>> allow-recursion {0/0;};
>>>};
>>>
>>>...
>>>
>>>view internal {
>>> match-clients {
>>> 127.0.0.0/8;
>>> 172.16.0.0/12;
>>> };
>>>...
>>> zone "united-networks.ru" {
>>> type master;
>>> file "master/forward/united-networks.ru.internal";
>>> allow-transfer {
>>> 172.16.0.2;
>>> 172.16.16.2;
>>> 172.31.16.16;
>>> 172.31.17.0;
>>> 172.31.18.0;
>>> };
>>> };
>>>...
>>>};
>>>...
>>>
>>>  
>>> -

Re: Bind doesn't make zone delegation.

2012-04-19 Thread Peter Andreev
2012/4/19 Ellad G. Yatsko 

>  Nope. FreeBSD is not the master for sokol.msk.united-networks.ru. It
> delegates zone sokol.msk only.
> Not more.Master for sokol.msk.united-networks.ru is
> srvgate.sokol.msk.united-networks.ru (Ubuntu
> server).
>
> Indeed, now when I try nslookup sokol.msk.united-networks.ru - it returns
> me its IP. FreeBSD asks for zone
> information Ubuntu. Ubuntu answers. But when I try to resolve what is "
> ap-1131.sokol.msk.united-networks.ru"
> FreeBSD is silent as before. It does not ask Ubuntu. It does not return
> any IP: NXDOMAIN.
>
> Kind regards,
> Ellad
>

Is zone united-networks.ru  listed in
external view? If so has it records for
sokol.msk.united-networks.ru?
Is option "recursion yes" global or view-specific? Could you provide
configuration details for recursing and forwarding?

>
> 2012/4/19 Ellad G. Yatsko 
>
>>  Hello!
>> Here is output:
>> /etc/namedb> dig @172.16.0.1 sokol.msk.united-networks.ru. NS +norec
>>
>> ; <<>> DiG 9.4.3-P2 <<>> @172.16.0.1 
>> sokol..msk.united-networks.ru . NS
>> +norec
>>
>> ; (1 server found)
>> ;; global options:  printcmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14255
>> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
>>
>> ;; QUESTION SECTION:
>> ;sokol.msk.united-networks.ru.  IN  NS
>>
>> ;; AUTHORITY SECTION:
>> sokol..msk.united-networks.ru .
>> 3600 IN   NS  srvgate.sokol.msk.united-networks.ru.
>>
>>
>> ;; ADDITIONAL SECTION:
>> srvgate.sokol.msk.united-networks.ru. 3359 IN A 172.31.16.16
>> srvgate.sokol.msk.united-networks.ru. 3359 IN A 172.16.16.1
>>
>> ;; Query time: 0 msec
>> ;; SERVER: 172.16.0.1#53(172.16.0.1)
>> ;; WHEN: Thu Apr 19 14:08:55 2012
>> ;; MSG SIZE  rcvd: 100
>>
>
> Looks good for me.
>
>
>> I noticed that after some time FreeBSD still tried to ask for
>> sokol..msk.united-networks.ru  from
>> Ubuntu (srvgate.sokol.msk).
>>
>> It happened after 2-3 minutes after "named" was restarted on FreeBSD. But
>> now FreeBSD doesn't ask for hosts in this zone.
>> All what I was doing during this time period - I restarted
>> freevrrp-daemon on FreeBSD machine. Could it be related to issue?
>>
>
> Is FreeBSD a master for sokol.msk.united-networks.ru? Looks like it is
> trying to send notifies.
>
>
>> Something very strange..  Another FreeBSD (9.0) works fine in the same
>> (or much like) conditions...
>>
>> Kind regards,
>> Ellad
>>
>> Hi,
>>
>> First of all, nslookup isn't a good tool for debug DNS problems. Use dig
>> instead.
>>
>> Could you show the output of "dig @freebsdbox
>> sokol.msk.united-networks.ru. NS +norec" run from freebsd box itself?
>>
>>
>> 2012/4/19 Ellad G. Yatsko 
>>
>>>
>>> Hello!

I have FreeBSD 7.2 x64 installed. And Bind 9.4:

/etc/namedb> named -v
BIND 9.4.3-P2

I have zone "/united-networks.ru/" and I try to do the following:
...
$ORIGIN sokol.msk.united-networks.ru.
@   IN NS   srvgate
srvgate IN A172.31.16.16
$ORIGIN united-networks.ru.
...

As I understand I delegated the SOA (IN NS) to server with name
srvgate.sokol.msk.united-networks.ru ("srvgate" has no tailing "dot"
so domain "sokol.msk.united-networks.ru" from $ORIGIN operator will
 be
appended), then I placed "glue"-record with srvgate.sokol.msk's
 address.
It is because as I understood nameserver of delegated zone is in it.

From here I thought on the server 172.31.16.16 (it's Ubuntu) I must
receive DNS-requests related to zone sokol.msk.united-networks.ru.
 For
example if I try do nslookup 
 sokol.msk.united-networks.ruon 
 FreeBSD
7.2 x64. But:

/etc/bind# hostname -f
srvgate.sokol.msk.united-networks.ru
/etc/bind# tshark -ta -ni tun0 -R dns
Running as user "root" and group "root". This could be dangerous.
Capturing on tun0

...there is nothing! And FreeBSD issues NXDOMAIN. I say more -
 FreeBSD
tries to resolve name "sokol.msk.united-networks.ru" through its
 forwarder in
external world!

Where am I wrong? I simulated this situation with the same
 configurations
on Ubuntu (Bind 9.7.0-P1) and fresh-installed FreeBSD 9.0 x64 (Bind
 9.8.1-P1).
All works fine!

-- related portion of named.conf
 --
options {
 directory   "/etc/namedb";
 pid-file"/var/run/named/pid";
 dump-file   "/var/dump/named_dump.db";
 statistics-fil

Re: Can I build a new DNS/BIND system parallel to our existing DNS production system?

2012-05-03 Thread Peter Andreev
Hello, Samad,

Another way to estimate you query rate is using system's udp counters. Not
as precise as query logging, but doesn't cause performance drop in case of
high query rates and accurate enough for estimation.

2012/5/4 Samad Agha 

> Thanks Daniel, I really appreciate your help.
>
> SA
>
> On Thu, May 3, 2012 at 1:34 PM, Daniel Deighton 
> wrote:
>
>>
>>
>> On 05/03/2012 02:44 PM, Samad Agha wrote:
>> > Thanks for your help Eivind.
>> >
>> >>Depends, how long is a piece of string? I don't know what amount of
>> >>traffic you're currently seeing, or what your uptime requirements are.
>> >
>> > - Are there tools to find out about current amount of traffic?
>> > - Our uptime requirements are basically from 6am to 6pm during city's
>> > business hours.
>> >
>> >>Estimate what amount of traffic you're seeing during prime time. How
>> > many >queries per second?
>> >
>> > - Again, how do I find out?
>>
>> It is fairly easy to find out your query load using BIND. You will just
>> need to enable query logging (if it isn't already enabled) and use the
>> data to calculate your queries per second from the data.
>>
>> Getting the information from your Windows DNS servers is not as easy.
>> You will likely need to put your Windows DNS servers into debug mode to
>> get any sort of query logging and the output isn't exactly pretty. You
>> could also get the data by taking packet captures and/or using a tool
>> such as dnssnarf, dnsdump or some other tool that another list member
>> might recommend.
>>
>> >
>> >>I'd normally not recommend running BIND on slower
>> > multi-threaded Sun/Oracle >servers like the T-series, you'll normally be
>> > better off with fewer threads but >higher clock speeds from typical
>> > Intel/AMD systems.(caveat: I haven't bench->marked BIND 9.9.x, which
>> > might have improved this).
>> >
>> > - Currently I have two:
>> >  Dell PowerEdge 2950 servers with two Intel Xeon 3.0GHZ CPUs, and
>> > 4GB RAM each running RHEL 5.8 OS
>> >
>> >
>> > Thanks again,
>> > 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
>> ___
>> 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
>



-- 
AP
___
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: TTL for name servers

2012-06-05 Thread Peter Andreev
Just to clarify, let's assume that you maintain zone example.be. Let's also
say that in .be zone TTL for your NS'es is 86400 and TTL for NS'es in your
zone is 345600.

In such scenario the latter will be cached by resolver because it is the
authoritative data. For some resolver implementations this behaviour can be
overrided.

To replace nameserver with new one I would do the following:
1. set up new server;
2. send updates to parent zone;
3. wait for TTL mentioned in my zone (for example above - 345600);
4. shut down old server(s).

2012/6/5 hugo hugoo 

>  Dear all,
>
>
>
> Can anyone clarify to me the use of the TTL for a NS record?
>
> Let’s take the example of a *.be domain.
>
>
>
> A TTL value is present on both locations.
>
>
>
> 1)In a dns.be server (for example x.dns.be): in my example here
> below, value is 86400
>
> 2)In the name server itself: in my example here below, value is 345600
>
>
>
>
> If we plan to change the name server to be used for a certain domain, do
> we have to change the TTL in the dns.be?
>
> Is this possible?
>
>
>
> Is this value that all the cache servers use?
>
> If yes…what about the TTL value of the name server itself?
>
>
>
>
>
> Thank in advance of any useful feedback,
>
>
>
> Hugo,
>
>
>
>
>
> *Example:*
>
>
>
>
>
> dig @localhost google.be NS +trace
>
>
>
> ; <<>> DiG 9.6-ESV-R4 <<>> @localhost google.be NS +trace
>
> ; (1 server found)
>
> ;; global options: +cmd
>
> .   502894  IN  NS  f.root-servers.net.
>
> .   502894  IN  NS  g.root-servers.net.
>
> .   502894  IN  NS  h.root-servers.net.
>
> .   502894  IN  NS  a.root-servers.net.
>
> .   502894  IN  NS  i.root-servers.net.
>
> .   502894  IN  NS  b.root-servers.net.
>
> .   502894  IN  NS  j.root-servers.net.
>
> .   502894  IN  NS  c.root-servers.net.
>
> .   502894  IN  NS  k.root-servers.net.
>
> .   502894  IN  NS  l.root-servers.net.
>
> .   502894  IN  NS  d.root-servers.net.
>
> .   502894  IN  NS  m.root-servers.net.
>
> .   502894  IN  NS  e.root-servers.net.
>
> ;; Received 436 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>
>
>
> be. 172800  IN  NS  m.ns.dns.be.
>
> be. 172800  IN  NS  x.dns.be.
>
> be. 172800  IN  NS  london.ns.dns.be.
>
> be. 172800  IN  NS  prague.ns.dns.be.
>
> be. 172800  IN  NS  brussels.ns.dns.be.
>
> be. 172800  IN  NS  amsterdam.ns.dns.be.
>
> ;; Received 307 bytes from 198.41.0.4#53(a.root-servers.net) in 27 ms
>
>
>
> google.be.  86400   IN  NS  ns2.google.com.
>
> google.be.  86400   IN  NS  ns1.google.com.
>
> google.be.  86400   IN  NS  ns4.google.com.
>
> google.be.  86400   IN  NS  ns3.google.com.
>
> ;; Received 109 bytes from 193.190.135.4#53(brussels.ns.dns.be) in 1 ms
>
>
>
> google.be.  345600  IN  NS  ns4.google.com.
>
> google.be.  345600  IN  NS  ns1.google.com.
>
> google.be.  345600  IN  NS  ns3.google.com.
>
> google.be.  345600  IN  NS  ns2.google.com.
>
> ;; Received 173 bytes from 216.239.36.10#53(ns3.google.com) in 18 ms
>
>
>
> ___
> 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
>



-- 
AP
___
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: TTL for name servers

2012-06-06 Thread Peter Andreev
2012/6/6 Mark Andrews 

>
> In message  c...@mail.gmail.com>
> , Alexander Gurvitz writes:
> > Hi.
> >
> > TTL returned by YOUR zone authoritative server will (at least should) be
> > preferred by caches.
> >
> > Matt Larson from verisign explained on these:
> >
> > http://www.merit.edu/mail.archives/nanog/2004-07/msg00255.html
> >
> > Regards,
> > Alexander Gurvitz,
> > net-me.net
>
> TTL of NS records are complicated as the existance of the delegation
> is covered by the parents NS records but the contents of the NS
> records comes from the child zone.  Named looks at both TTLs to
> determine when to remove the NS RRset.
>

Mark, could you please describe the algorithm being used by BIND? Does it
choose NS rrset with lowest TTL or something else?


> https://deepthought.isc.org/article/AA-00691/
>
> If you are wanting to workout when to decommission a nameserver take the
> maximum of the two NS rrset after they have both been updated as when it
> is safe to decommission.
>
> Mark
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



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

What does "deleted from unreachable cache" mean?

2012-07-18 Thread Peter Olsson
Hello!

After my latest bind upgrade our slave server started
occasionally writing these messages to the log:

master 2a02:::::2#53 (source ::#0) deleted from unreachable cache

master 62.xxx.xxx.2#53 (source 0.0.0.0#0) deleted from unreachable cache

DNS seems to work fine anyway, and all zonefiles in the slave
seem to update like they should, so everything seems ok. But I
would like to be certain that there is nothing to worry about,
so I wonder what these messages mean. (I didn't find anything
interesting in the list archives or in Google.)

Both master and slave are FreeBSD, running port bind97-9.7.6.1.

Thanks!

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

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


Re: What does "deleted from unreachable cache" mean?

2012-08-02 Thread Peter Olsson
On Thu, Aug 02, 2012 at 03:26:08PM +0100, Cathy Almond wrote:
> On 19/07/12 00:49, Peter Olsson wrote:
> > Hello!
> > 
> > After my latest bind upgrade our slave server started
> > occasionally writing these messages to the log:
> > 
> > master 2a02:::::2#53 (source ::#0) deleted from unreachable 
> > cache
> > 
> > master 62.xxx.xxx.2#53 (source 0.0.0.0#0) deleted from unreachable cache
> > 
> > DNS seems to work fine anyway, and all zonefiles in the slave
> > seem to update like they should, so everything seems ok. But I
> > would like to be certain that there is nothing to worry about,
> > so I wonder what these messages mean. (I didn't find anything
> > interesting in the list archives or in Google.)
> > 
> > Both master and slave are FreeBSD, running port bind97-9.7.6.1.
> > 
> > Thanks!
> > 
> 
> There'll be a new KB FAQ published on this early next week
> (https://kb.isc.org/article/AA-00765).  Preview is that it will say
> something like this:
> 
> What does named log message "deleted from unreachable cache" mean?
> 
> An example of the messages being logged is:
> 
> 02-Aug-2012 07:58:20.601 general: info: master 192.0.2.4#53 (source
> 192.0.2.8#0) deleted from unreachable cache
> 
> BIND maintains a cache of unreachable masters to which it refers when
> handling a zone refresh. If a zone refresh fails with a specific master
> (either during the query for the SOA or after querying and while
> attempting a subsequent zone transfer), then this master is cached as
> 'unreachable' for 10 minutes.
> 
> As of versions 9.6-ESV-R6, 9.7.5, 9.8.2 and 9.9.0 onwards, the change
> below implements an earlier removal of a master server from the
> unreachable cache if a notify is received from it.
> 
> Note that receipt of a notify (which is a UDP packet travelling from
> master to slave) doesn't guarantee that the master will be reachable
> from the slave, but it does ensure quicker recovery in the situation
> where a master was temporarily unavailable, for example for a reboot.
> 
> This is the relevant info from the Release Notes:
> 
> Master servers that had previously been marked as unreachable because of
> failed zone transfer attempts will now be removed from the "unreachable"
> list (i.e. considered reachable again) if the slave receives a NOTIFY
> message from them. [RT #25960]
> 
> In the CHANGES file, it is described thus:
> 3204. [bug]   When a master server that has been marked as
> unreachable sends a NOTIFY, mark it reachable again. [RT #25960]
 
Excellent information, thanks!
However, it is worrying that the master sometimes is unreachable.
Is there some way I can make the slave server log, with timestamp,
what zone it was trying to refresh when it failed?

Thanks!

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

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


Re: What does "deleted from unreachable cache" mean?

2012-08-03 Thread Peter Olsson
On Fri, Aug 03, 2012 at 09:13:50AM +0100, Cathy Almond wrote:
> On 02/08/12 19:00, Michael Hoskins (michoski) wrote:
> > -Original Message-
> > 
> > From: Peter Olsson 
> > Date: Thursday, August 2, 2012 10:25 AM
> > To: Cathy Almond 
> > Cc: "bind-users@lists.isc.org" 
> > Subject: Re: What does "deleted from unreachable cache" mean?
> > 
> >> Excellent information, thanks!
> > 
> > Agreed.  I really appreciate the effort ISC has put into the KB.
> > 
> >> However, it is worrying that the master sometimes is unreachable.
> >> Is there some way I can make the slave server log, with timestamp,
> >> what zone it was trying to refresh when it failed?
> > 
> > Not sure if you've already tried, but do you have xfer logging enabled?
> > 
> > logging {
> > 
> > 
> > 
> > channel audit_log {
> > 
> > file "/var/named/bind/named.log";
> > severity debug;
> > print-time yes;
> > 
> > };
> > 
> > 
> > 
> > 
> > category xfer-in { audit_log; };
> > category xfer-out { audit_log; };
> > category notify { audit_log; };
> > category network { audit_log; };
> > category update { audit_log; };
> > // might want this to debug...
> > //category queries { audit_log; };
> > 
> > };
> 
> The point at which the 'unreachable' entry is cached, is logged under
> category 'xfer-in' - although it doesn't actually tell you that it's
> caching it.  Look for messages containing text "failed to connect" or
> "could not refresh".
> 
> Once the master is already in the unreachable cache, if the refresh code
> checks and finds it there, then there are several messages (different
> circumstances) that explain why a transfer isn't going to happen right
> then - and these ones all incorporate the text "unreachable (cached)".
> 
> But yesterday, I dug further into the code that's reporting "deleted
> from unreachable cache" and I'm sorry that I have to report that there
> is a bug there - the code is matching the source of the notify
> correctly, but may also mistakenly include and report on older cache
> entries that are already "deleted".
> 
> We'll fix this.  It's being tracked as bug ticket #30501.
> 
> But if you have no evidence of ongoing problems (looking at what's
> logged in category xfer-in - per my suggestions above) then you can
> safely ignore these messages. There will have been an issue at some
> point in the past, but which is now cleared.
> 
> Apologies.

I will try logging, but it's good to know that it might not
be a big problem.

Thanks!

-- 
Peter Olssonp...@leissner.se
___
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 BIND-DLZ for a hidden master [was: Re: dns master-slave transfer]

2012-11-01 Thread Peter Andreev
2012/11/1 Chris Thompson :
> On Oct 29 2012, Feng He wrote:
>
>> 于 2012-10-29 9:58, kavin 写道:
>>>
>>> Now,I want transfer the zone data from the master dns serverto slave
>>> dns server ,the master dns use bind-dlz+mysql and the slave dns server
>>> use bind+file.
>>
>>
>> AFAIK, BIND DLZ doesn't send a notify message to slave, so both your
>> master and slave should be able to use the DLZ backend and run a mysql
>> replication for data sync.
>
>
> That exchange prompts me to ask whether anyone has managed to use
> BIND-DLZ in something like the following scenario.
>
> We have a hidden master for vanity zones (we call them something else
> for the punters) that runs in a small footprint virtual machine
> together with the web server providing the updating interface. The
> latter stores the data in a MySQL database.
>
> At the moment there is a crontab that extracts data from that database
> and updates zone files (if they need changing - there are some neat-o
> optimisations) and does an "rndc reload" on the hidden master daemon.
> That NOTIFYs the public nameservers for the zones, which are are in fact
> our regular authoritative-only ones.
>
> It seems that one ought to be able to use BIND-DLZ to cut out a step
> there, but none of the how-to's for it seem to address this sort of
> scenario, and the NOTIFY issue is particularly relevant. Fast responses
> from the hidden master to queries are certainly *not* a requirement here,
> and indeed we expect to be able to operate with it (and its MySQL database)
> down for significant periods.
>
> On the other hand, there is also a possibility that we might want to sign
> the vanity zones (we use JANET, Nominet and Gandi for their registrations,
> who all support signed delegations now), and how that would interact with
> BIND-DLZ might also be an issue. Can one use BIND 9.9 "inline signing"
> with the unsigned version provided by a DLZ interface?

In our case (big zones, distant servers) we have found DLZ very
inefficient because of huge overhead due to AXFRs. Another problem is
absence of NOTIFIes.

As for me the way your system is working now is much more simple,
predictable and reliable than DLZ.

>
> --
> Chris Thompson
> Email: c...@cam.ac.uk
> ___
> 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

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

Lots of "RSA_verify failed" after upgrade to 9.7.7

2012-11-05 Thread Peter Olsson
Yesterday I upgraded our slave DNS (running FreeBSD 7.4)
from bind 9.7.6.4 to 9.7.7. The server uses bind97 from
ports.

After that upgrade I get lots of these in syslog:

RSA_verify failed error:04077068:rsa routines:RSA_verify:bad 
signature:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/rsa/rsa_sign.c:263:

I have never seen these before.
I tried Google but got no recent results.
Anyone know what this means and how to get rid
of these errors?

Thanks!

Peter Olsson
___
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: Strange issue with signed zone

2012-11-08 Thread Peter Andreev
Hi everybody!

We signed another zone and met the same problem again. The only
difference is algorithm - now it is RSASHA256.

> We have ~30 servers running BIND (9.8, 9.7, 9.6). A week ago we
> signed first of our zones with RSA/SHA1 + NSEC3 + OPT-OUT.
> Recently we realised that our servers don't generate NSEC3 for signed zone.
> Problem has gone after we restarted BIND instances.

We are using views, could it be related?


-- 
AP
___
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: Strange issue with signed zone

2012-11-09 Thread Peter Andreev
2012/11/9 Tony Finch :
> Peter Andreev  wrote:
>>
>> We signed another zone and met the same problem again. The only
>> difference is algorithm - now it is RSASHA256.
>>
>> > We have ~30 servers running BIND (9.8, 9.7, 9.6). A week ago we
>> > signed first of our zones with RSA/SHA1 + NSEC3 + OPT-OUT.
>> > Recently we realised that our servers don't generate NSEC3 for signed zone.
>> > Problem has gone after we restarted BIND instances.
>>
>> We are using views, could it be related?
>
> Did you add an NSEC3PARAM record?

Yes, we did.

>
> The signing algorithms that support NSEC3 use NSEC by default unless the
> zone has an NSEC3PARAM record.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
> Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
> occasionally poor at first.



-- 
AP
___
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: Strange issue with signed zone

2012-11-09 Thread Peter Andreev
2012/11/9 Peter Andreev :
> 2012/11/9 Tony Finch :
>> Peter Andreev  wrote:
>>>
>>> We signed another zone and met the same problem again. The only
>>> difference is algorithm - now it is RSASHA256.
>>>
>>> > We have ~30 servers running BIND (9.8, 9.7, 9.6). A week ago we
>>> > signed first of our zones with RSA/SHA1 + NSEC3 + OPT-OUT.
>>> > Recently we realised that our servers don't generate NSEC3 for signed 
>>> > zone.
>>> > Problem has gone after we restarted BIND instances.
>>>
>>> We are using views, could it be related?
>>
>> Did you add an NSEC3PARAM record?
>
> Yes, we did.
>

Actually without restart, servers didn't generate neither NSEC3, nor NSEC.

>>
>> The signing algorithms that support NSEC3 use NSEC by default unless the
>> zone has an NSEC3PARAM record.
>>
>> Tony.
>> --
>> f.anthony.n.finchhttp://dotat.at/
>> Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
>> Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
>> occasionally poor at first.
>
>
>
> --
> AP



-- 
AP
___
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: Change in statistics format

2012-11-15 Thread Peter Yardley
I wrote a script to extract stats from the XML channel. Works for cricket, 
cacti, MRTG ...

You can find it here…

<http://members.iinet.net/~pyard...@ihug.com.au/projects/?project=bind9_5_counters>

Looks like I'll have to update it for 9.10 tho, hope they updated the schema 
number.

On 16/11/2012, at 6:04 AM, John Miller  wrote:

> Thanks, Evan.  That's exactly what I wanted to know.  I'm already 
> running the statistics server, so I'd certainly prefer to leverage that 
> rather than rely on a bunch of regexes to parse the statistics file.
> 
> I'll let the folks at Hyperic know about the upcoming schema changes.
> 
> John
> 
> On 11/15/2012 12:22 PM, Evan Hunt wrote:
>> On Thu, Nov 15, 2012 at 11:44:12AM -0500, John Miller wrote:
>>> Hello everyone,
>>> 
>>> When did BIND 9 switch over from the older
>> 
>> The new stats counters were added in 9.5.0.  They're in all currently-
>> supported releases; the old format is fully deprecated now.
>> 
>> Incidentally, that release also introduced an http statistics channel
>> and XML stats reporting, which might be of interest to your monitoring
>> software.  (Note, though, in 9.9.3 we're going to introduce a newer
>> better XML schema for statistics as a compile-time option, and it'll
>> be standard in 9.10, so if they wanted to write code to parse our XML,
>> they might want to know there'll be a few different schema versions in
>> the field soon.)
>> 
>>> Is this a tunable parameter?
>> 
>> No.
>> 
> ___
> 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

._--_|\   Peter Yardley|
/  \  Senior Network Administrator | peter.yard...@uts.edu.au
\_.--._*  Information Technology Division, | Ph:  +61 2 9514-2358
. v   University of Technology, Sydney.| Fax: +61 2 9514-4327





UTS CRICOS Provider Code: 00099F
DISCLAIMER: This email message and any accompanying attachments may contain 
confidential information.
If you are not the intended recipient, do not read, use, disseminate, 
distribute or copy this message or
attachments. If you have received this message in error, please notify the 
sender immediately and delete
this message. Any views expressed in this message are those of the individual 
sender, except where the
sender expressly, and with authority, states them to be the views of the 
University of Technology Sydney.
Before opening any attachments, please check them for viruses and defects.

Think. Green. Do.

Please consider the environment before printing this email.
___
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: reverse zone of type forward when /28 subnet

2012-12-27 Thread Peter Andreev
Please correct me if I'm wrong: you'd like to edit PTR records for
your part of the /24 zone?
If so, what you ISP says about rfc2317?

2012/12/27 Dmitri Tarkhov :
> Hi,
> I've searched the list archives and Google and don't see anything
> to answer my question subj.
> we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
> We want to have a master DNS without unnecessary extra functionality.
> (Including no caching)
>
> This is the named.conf with obscured addresses:
> # cat /dns992/etc/named.conf
> key "rndc-key" { ... };
> controls { ... };
> acl nameservers { A; B; };
> options { directory "/var/named";
>   allow-query { any; };
>   recursion no;
>   version "Some Server";
>   listen-on { x.y.z.w; };
>   pid-file "/var/run/named.pid";
> };
> zone "company" IN { type master;
> file "company.dat";
> allow-transfer { nameservers; };
> };
> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
> file "company.rev";
> allow-transfer { nameservers; };
> };
> zone "z.y.x.in-addr.arpa" IN { type forward; forward only;
> forwarders { intranet.1; }; };
>
> //zone "z.y.x.in-addr.arpa" IN { type slave;
> //file "z_y_x_in-addr.arpa";
> //masters { A; B; };
> //};
>
> zone "localhost" IN { type master;
> file "master.localhost";
> allow-update { none; };
> };
> zone "0.0.127.in-addr.arpa" IN { type master;
> file "localhst.rev";
> notify no;
> };
>
> Direct resolving works fine. Our subzone is delegated from ISP properly.
> dig +trace shows due CNAMEs and in general reverse resolving works as well.
> But I want to achieve reverse resolving on our DNS itself.
> It is a quite natural desire, to be self sufficient or at least pretend to
> be,
> isn't it ...
> The simplest way to achieve that would be to have a slave zone for the whole
> class C network x.y.z.0/24 but the ISP don't allow zone transfer.
> A can understand why transfers of direct zones are limited by security
> reasons. But reverse zones do not contain any private subdomains or
> whatever.
> There is nothing in the reverse zone that cannot be collected by simple
> queries. And, BTW nothing to hide.
> Well, another way would be to have a reverse zone for z.y.x.in-addr.arpa
> of type forward with forward only clause and due forwarders.
> But it doesn't seem to work. I've tried external forwarders including
> 8.8.8.8 + 8.8.8.4 without success and now stick with our internal dns
> at "intranet/24".1
> This internal dns produces perfect reverse resolving but only for internal
> users, of course the "internals" acl includes the address of external dns.
> It has this set of options:
> options {
> directory "/var/named";
> forward first;
> version "not available";
> forwarders { A; B; };
> allow-query { internals; };
> allow-transfer { "none"; };
> allow-recursion { internals; };
> listen-on { intranet.1; };
> };
>
> What I have when performing reverse resolving at external dns is:
>>
>> x.y.z.k
>
> Server: x.y.z.w
> Address:x.y.z.w#53
>
> ** server can't find k.z.y.x.in-addr.arpa: REFUSED
>
> and setting set d2 in nslookup v9.9.2 doesn't reveal anything
> catching attention although I see that there is an attempt to
> contact the forwarder.
>
> trying origin "company.internal" (obscured as well)
> recursive query
> add_question()
> starting to render the message
> done rendering
> create query 0x402a4010 linked to lookup 0x82168c0
> do_lookup()
> send_udp(0x402a4010)
> bringup_timer()
> have local timeout of 5
> working on lookup 0x82168c0, query 0x402a4010
> sockcount=1
> recving with lookup=0x82168c0, query=0x402a4010, sock=0x402a5008
> recvcount=1
> sending a request
> unlock_lookup dighost.c:3530
> lock_lookup dighost.c:2328
> success
> send_done()
> sendcount=0
> check_if_done()
> list empty
> unlock_lookup dighost.c:2357
> recv_done()
> lock_lookup dighost.c:3053
> success
> recvcount=0
> lookup=0x82168c0, query=0x402a4010
> before parse starts
> after parse
> next_origin()
>
> So for some reason the list is empty and recvcount=0 in the second
> occasion.
> From the same shell, from the very same nslookup instance with
>>
>> server 
>
> the reverse lookup is OK.
>
> And of course I am more interested in some working solution than
> digging in subtleties of traces provided that I don't need to
> allow recursion and forward in general options section for
> my external dns.
>
> I look forward for any suggestions, working examples, corrections,
> sources of indepth information. TIA.
>
> --
> Best regards,
> Dmitri Tarkhov
>
> ___
> 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



-- 
AP
___
Please visit https://lists

Re: reverse zone of type forward when /28 subnet

2012-12-27 Thread Peter Andreev
Forwarding does not work without recursion enabled.

There is a few ways to solve the problem:
1. Using views;
2. Using another dns resolver (for example Unbound);
3. Downloading the zone via script (bad idea from any point);
4. Do not bother where your resolver get authoritative data (I'd
recommend this one).

Actually, I'm afraid you won't be able to achieve your goal without
needless overcomplication.

2012/12/27 Dmitri Tarkhov :
> Well, it's Ok with that. I indeed am the owner of small reverse
>
> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
> named with accordance with rfc2317 CNAME trick and can edit it.
> The changes are transferred one way to the ISP side and make part of
> their zone "z.y.x.in-addr.arpa". So my changes are seen by the world.
> But this small subzone cannot be used for direct reverse resolving right
> at my dns. It can only be done at class C (or B, or A) granularity.
> So to achieve exactly what I want I need to pull somehow this class C
> zone "z.y.x.in-addr.arpa" to my dns. Either as slave zone (which is
> denied by ISP) or as forward zone which I cannot tune to work.
> May be some other unknown by me approach exists.
> Again, there is no problem with reverse resolving in general but
> I cannot achieve this directly at my dns, that is to receive a response
> from it no matter wherever it forwards the request or from where it
> gets the PTR records.
>
>
> Peter Andreev wrote:
>
>> Please correct me if I'm wrong: you'd like to edit PTR records for
>> your part of the /24 zone?
>> If so, what you ISP says about rfc2317?
>>
>> 2012/12/27 Dmitri Tarkhov :
>>
>>> Hi,
>>> I've searched the list archives and Google and don't see anything
>>> to answer my question subj.
>>> we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
>>> We want to have a master DNS without unnecessary extra functionality.
>>> (Including no caching)
>>>
>>> This is the named.conf with obscured addresses:
>>> # cat /dns992/etc/named.conf
>>> key "rndc-key" { ... };
>>> controls { ... };
>>> acl nameservers { A; B; };
>>> options { directory "/var/named";
>>>  allow-query { any; };
>>>  recursion no;
>>>  version "Some Server";
>>>  listen-on { x.y.z.w; };
>>>  pid-file "/var/run/named.pid";
>>> };
>>> zone "company" IN { type master;
>>>file "company.dat";
>>>allow-transfer { nameservers; };
>>> };
>>> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
>>>file "company.rev";
>>>allow-transfer { nameservers; };
>>> };
>>> zone "z.y.x.in-addr.arpa" IN { type forward; forward only;
>>>forwarders { intranet.1; }; };
>>>
>>> //zone "z.y.x.in-addr.arpa" IN { type slave;
>>> //file "z_y_x_in-addr.arpa";
>>> //masters { A; B; };
>>> //};
>>>
>>> zone "localhost" IN { type master;
>>>file "master.localhost";
>>>allow-update { none; };
>>> };
>>> zone "0.0.127.in-addr.arpa" IN { type master;
>>>file "localhst.rev";
>>>notify no;
>>> };
>>>
>>> Direct resolving works fine. Our subzone is delegated from ISP properly.
>>> dig +trace shows due CNAMEs and in general reverse resolving works as
>>> well.
>>> But I want to achieve reverse resolving on our DNS itself.
>>> It is a quite natural desire, to be self sufficient or at least pretend
>>> to
>>> be,
>>> isn't it ...
>>> The simplest way to achieve that would be to have a slave zone for the
>>> whole
>>> class C network x.y.z.0/24 but the ISP don't allow zone transfer.
>>> A can understand why transfers of direct zones are limited by security
>>> reasons. But reverse zones do not contain any private subdomains or
>>> whatever.
>>> There is nothing in the reverse zone that cannot be collected by simple
>>> queries. And, BTW nothing to hide.
>>> Well, another way would be to have a reverse zone for z.y.x.in-addr.arpa
>>> of type forward with forward only clause and due forwarders.
>>> But it doesn't seem to work. I've tried external forwarders including
>>> 8.8.8.8 + 8.8.8.4 without success and now stick with our internal dns
>>

Re: reverse zone of type forward when /28 subnet

2012-12-27 Thread Peter Andreev
2012/12/27 Dmitri Tarkhov :
> Hi,
> thanks a lot for the information.
> Contains key reason and sounds interesting.
>
> 1. Do you mean I can isolate zone "z.y.x.in-addr.arpa"
>into  a separate view where recursion is enabled but all
>other zones are excluded? If so, it's very promising.

Actually, forwarding also doesn't work for queries without RD bit.
Such queries are being sent by resolver in normal circumstances.

> 2. Sorry, "Unbound" - is it just another dns server?

Yep, it is recursive-only dns server. It has an option called
"local-zone", which is absolutelly what you are looking for. Note that
Unbound has very limited capabilities to support authoritative data.

> 3. Thought about a script. Know Korn shell at middle level.
>Nobody prohibits to maintain yet another copy of master zone.

Nobody but zone owner.

>But I don't want to indulge into such remote circumventions.
> 4. That's possible to not bother about the issue but for now
>I am not ready to fold hands.

I just meant that fencing your resolver without really good reasons is
a bad idea. If you do it "just for fun" in production environment, you
should think twice.

>
>
> Peter Andreev wrote:
>
>> Forwarding does not work without recursion enabled.
>>
>> There is a few ways to solve the problem:
>> 1. Using views;
>> 2. Using another dns resolver (for example Unbound);
>> 3. Downloading the zone via script (bad idea from any point);
>> 4. Do not bother where your resolver get authoritative data (I'd
>> recommend this one).
>>
>> Actually, I'm afraid you won't be able to achieve your goal without
>> needless overcomplication.
>>
>> 2012/12/27 Dmitri Tarkhov :
>>
>>> Well, it's Ok with that. I indeed am the owner of small reverse
>>>
>>> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
>>> named with accordance with rfc2317 CNAME trick and can edit it.
>>> The changes are transferred one way to the ISP side and make part of
>>> their zone "z.y.x.in-addr.arpa". So my changes are seen by the world.
>>> But this small subzone cannot be used for direct reverse resolving right
>>> at my dns. It can only be done at class C (or B, or A) granularity.
>>> So to achieve exactly what I want I need to pull somehow this class C
>>> zone "z.y.x.in-addr.arpa" to my dns. Either as slave zone (which is
>>> denied by ISP) or as forward zone which I cannot tune to work.
>>> May be some other unknown by me approach exists.
>>> Again, there is no problem with reverse resolving in general but
>>> I cannot achieve this directly at my dns, that is to receive a response
>>> from it no matter wherever it forwards the request or from where it
>>> gets the PTR records.
>>>
>>>
>>> Peter Andreev wrote:
>>>
>>>
>>>> Please correct me if I'm wrong: you'd like to edit PTR records for
>>>> your part of the /24 zone?
>>>> If so, what you ISP says about rfc2317?
>>>>
>>>> 2012/12/27 Dmitri Tarkhov :
>>>>
>>>>
>>>>> Hi,
>>>>> I've searched the list archives and Google and don't see anything
>>>>> to answer my question subj.
>>>>> we have let's say x.y.z.240/28 subnet and BIND 9.9.2-P1.
>>>>> We want to have a master DNS without unnecessary extra functionality.
>>>>> (Including no caching)
>>>>>
>>>>> This is the named.conf with obscured addresses:
>>>>> # cat /dns992/etc/named.conf
>>>>> key "rndc-key" { ... };
>>>>> controls { ... };
>>>>> acl nameservers { A; B; };
>>>>> options { directory "/var/named";
>>>>> allow-query { any; };
>>>>> recursion no;
>>>>> version "Some Server";
>>>>> listen-on { x.y.z.w; };
>>>>> pid-file "/var/run/named.pid";
>>>>> };
>>>>> zone "company" IN { type master;
>>>>>   file "company.dat";
>>>>>   allow-transfer { nameservers; };
>>>>> };
>>>>> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
>>>>>   file "company.rev";
>>>>>   allow-transfer { nameservers; };
>>>>> };
>>>>> zone "z.y.x.in-addr.arpa" IN { type forward; forward

Re: reverse zone of type forward when /28 subnet

2012-12-27 Thread Peter Andreev
2012/12/27 Dmitri Tarkhov :
> Ok, thank you,
> I'll try views first of all.
>
> And I need some further clarification about this:
>
>> I just meant that fencing your resolver without really good reasons is
>> a bad idea.
>
> By "fencing  your resolver" do you mean converting a dns
> server into only a source of information from its master zones
> cutting severely any unnecessary functionality or anything else?
> What is a bad idea and why?

You are trying to cut some ways of information obtaining for resolver.
That is what I mean.

>
> In fact I want to do so because I want to protect it from
> cache poisoning and any other attack of forge nature.

I can't say these attacks are very common. Actually I can't recall any
cases of such attacks in a wild nature. Also, in-addr.arpa isn't a
good target.

As for now the best defence against cache poisoning is DNSSec and
since we have signed all russian TLDs you could implement it.

>
>
> Peter Andreev wrote:
>
>> 2012/12/27 Dmitri Tarkhov :
>>
>>> Hi,
>>> thanks a lot for the information.
>>> Contains key reason and sounds interesting.
>>>
>>> 1. Do you mean I can isolate zone "z.y.x.in-addr.arpa"
>>>   into  a separate view where recursion is enabled but all
>>>   other zones are excluded? If so, it's very promising.
>>
>>
>>
>> Actually, forwarding also doesn't work for queries without RD bit.
>> Such queries are being sent by resolver in normal circumstances.
>>
>>
>>> 2. Sorry, "Unbound" - is it just another dns server?
>>
>>
>>
>> Yep, it is recursive-only dns server. It has an option called
>> "local-zone", which is absolutelly what you are looking for. Note that
>> Unbound has very limited capabilities to support authoritative data.
>>
>>
>>> 3. Thought about a script. Know Korn shell at middle level.
>>>   Nobody prohibits to maintain yet another copy of master zone.
>>
>>
>>
>> Nobody but zone owner.
>>
>>
>>>   But I don't want to indulge into such remote circumventions.
>>> 4. That's possible to not bother about the issue but for now
>>>   I am not ready to fold hands.
>>
>>
>>
>> I just meant that fencing your resolver without really good reasons is
>> a bad idea. If you do it "just for fun" in production environment, you
>> should think twice.
>>
>>
>>>
>>> Peter Andreev wrote:
>>>
>>>
>>>> Forwarding does not work without recursion enabled.
>>>>
>>>> There is a few ways to solve the problem:
>>>> 1. Using views;
>>>> 2. Using another dns resolver (for example Unbound);
>>>> 3. Downloading the zone via script (bad idea from any point);
>>>> 4. Do not bother where your resolver get authoritative data (I'd
>>>> recommend this one).
>>>>
>>>> Actually, I'm afraid you won't be able to achieve your goal without
>>>> needless overcomplication.
>>>>
>>>> 2012/12/27 Dmitri Tarkhov :
>>>>
>>>>
>>>>> Well, it's Ok with that. I indeed am the owner of small reverse
>>>>>
>>>>> zone "255-241.z.y.x.in-addr.arpa" IN { type master;
>>>>> named with accordance with rfc2317 CNAME trick and can edit it.
>>>>> The changes are transferred one way to the ISP side and make part of
>>>>> their zone "z.y.x.in-addr.arpa". So my changes are seen by the world.
>>>>> But this small subzone cannot be used for direct reverse resolving
>>>>> right
>>>>> at my dns. It can only be done at class C (or B, or A) granularity.
>>>>> So to achieve exactly what I want I need to pull somehow this class C
>>>>> zone "z.y.x.in-addr.arpa" to my dns. Either as slave zone (which is
>>>>> denied by ISP) or as forward zone which I cannot tune to work.
>>>>> May be some other unknown by me approach exists.
>>>>> Again, there is no problem with reverse resolving in general but
>>>>> I cannot achieve this directly at my dns, that is to receive a response
>>>>> from it no matter wherever it forwards the request or from where it
>>>>> gets the PTR records.
>>>>>
>>>>>
>>>>> Peter Andreev wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Please correct me i

Re: reverse zone of type forward when /28 subnet

2012-12-29 Thread Peter Andreev
Actually, Mark's advice is much better.

2012/12/29 Dmitri Tarkhov :
> Hi,
> this finally works:
>
> view "reverse1" IN {
> recursion yes;
>
> zone "z.y.x.in-addr.arpa" IN { type forward; forward only;
> forwarders { A; B; }; };
>
>
> zone "localhost" IN { type master;
> file "master.localhost"; };
>
>
> zone "0.0.127.in-addr.arpa" IN { type master;
> file "localhst.rev"; };
> };
>
> And Happy New Year!
>
>
> Dmitri Tarkhov wrote:
>
>> Hi, all,
>>
>> thank you very much for discussion. It was interesting and very useful.
>> You can pretty well imagine that I am not much dns involved,
>> I am rather unix and unix HW guy.
>> Unfortunately I saw dns cache poisoning attack and although it could be
>> provoked by side effects it's better to get rid of it altogether.
>> For just 14 (241-254) addresses it is not difficult to maintain 2 types
>> of master zones in sync (RFC 2317 and RFC 1035) and it's enough to put a
>> couple of comment lines to not forget it later.
>> Yes, life is short but this is not the reason to not train the brain,
>> can help to hook a life a bit longer ...
>> Bring stir to the chicken coop and request compliance is generally
>> good idea and fingers itch but I don't expect much from our ISPs ...
>> So first I'll try "type forward" within a view,
>> then I'm sure, one address zones can serve me right.
>> I will also contact the ISP but without great expectations.
>>
>> Why I do all this is:
>> - enforce security
>> - assure stable mail exchange (which depends on reverse resolving)
>>
>> Mark Andrews wrote:
>>
>>> In message <50dcd454.2070...@dougbarton.us>, Doug Barton writes:
>>>
 On 12/27/2012 11:18 AM, Mark Andrews wrote:

> zone "241.Z.X.Y.IN-ADDR.ARPA" {
> type master;
> file "241.Z.X.Y.IN-ADDR.ARPA";
> };



 That's great locally, but it doesn't match the 2317 delegation from the
 upstream, and usually it's not possible to change what they send you.

 Or are you suggesting maintaining both the individual versions of the
 zones, and the 2317 zone?
>>>
>>>
>>>
>>>
>>> No.  I'm suggesting that they tell their ISP to do RFC 2317 right
>>> or do RFC 1035 delegations.   If their ISP won't do either change
>>> ISP.
>>>
>>>
 Doug
 ___
 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
>>
>>
>>
>
> --
> Best regards,
> Dmitri Tarkhov
>
> ___
> 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



-- 
AP
___
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: Wildcard CNAME record?

2013-01-16 Thread Oliver Peter
On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote:
> Is it acceptable to have a wildcard CNAME?  Example:
> 
> * IN   CNAMEsomewhere.com.
> 
> Or, would it be advised to only use wildcard 'A' records?

Not valid since there should be SOA and NS records for somewhere.com,
the CNAME would conflict with them.

This should be OK:

* IN   CNAMEsub.somewhere.com.

Cheers
~ollie

-- 
Oliver PETER   oli...@opdns.de   0x456D688F
"You need healthy, natural sleep. Chew some Valerian root and get more 
exercise."


signature.asc
Description: Digital signature
___
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: Wildcard CNAME record?

2013-01-16 Thread Oliver Peter
On Wed, Jan 16, 2013 at 10:33:03AM -0500, Barry Margolin wrote:
> In article ,
>  Oliver Peter  wrote:
> 
> > On Wed, Jan 16, 2013 at 02:57:48PM +, Baird, Josh wrote:
> > > Is it acceptable to have a wildcard CNAME?  Example:
> > > 
> > > * IN   CNAMEsomewhere.com.
> > > 
> > > Or, would it be advised to only use wildcard 'A' records?
> > 
> > Not valid since there should be SOA and NS records for somewhere.com,
> > the CNAME would conflict with them.
> 
> But wildcards only synthesize records that are actually queried for. If 
> no one ever asks for these SOA and NS records, the conflicts will never 
> occur. They're the DNS equivalent of trees falling in a forest.

Gah, mixed it up, was thinking the other way round.  Sorry.


-- 
Oliver PETER   oli...@opdns.de   0x456D688F
"You need healthy, natural sleep. Chew some Valerian root and get more 
exercise."


signature.asc
Description: Digital signature
___
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: high volume from outside our networks question

2013-01-31 Thread Peter, Oliver
On 1/31/13 7:05 PM, rich carroll wrote:
>
> antispoof log quick for em0 inet
>
> but that did not trigger on any of the requests.
This leads to nowhere in your specific case, check 'pfctl -sr' and the
docs[1] to learn how this rule expands.

[1] http://www.openbsd.org/faq/pf/filter.html#antispoof

-- 
Oliver PETERoli...@peter.de.com 0x456D688F




signature.asc
Description: OpenPGP digital signature
___
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: listen-to clusterIP address

2013-06-05 Thread Peter Andreev
2013/6/5 Phil Mayers 

> On 06/05/2013 07:37 PM, paul wrote:
>
>> Hi. I have a two node active passive cluster serving webpages. When a
>> failover occurs, I have to restart named on the now active node because
>>
>
> You don't have to restart it. "rndc reconfig" will re-check the IPs on the
> machine and re-listen.
>
>
This definitely will not work if BIND dropped privileges after start.


>
>  the cluster Ip was not available when named originally started even
>> though I have listen-to the cluster ip listed in my named.conf. Is there
>> a way to make named listen-to an ip address that is not yet available?
>>
>
The cimplest way, I think is to configure cluster IP on loopback interfaces
and set up routing


>
> No. This has come up before - the bind listen-on statement is an ACL which
> is matched against the list of IPs on the box, not a list of IPs passed to
> the bind() syscall. There are various solutions, but "rndc reconfig" is the
> right one IMO.
>
> __**_
> Please visit 
> https://lists.isc.org/mailman/**listinfo/bind-usersto
>  unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/**listinfo/bind-users
>



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

Forwarding requests when DNS name doesn't exist?

2013-10-10 Thread Peter Olsson
(This is probably a silly question, but I
want to explore every possibility.)

We have a proxy firewall, with no contact
between inside and outside. We have a fake
internal DNS root for zones that we use
internally. This works fine, since lookup
of external names are only made from the
outside of the proxy servers.

We are about to change to a transparent
firewall, which means that we remove the
proxy servers. Then we have to let the
inside get access to real outside DNS.

Is there any way with bind, or any other
DNS product, to keep our internal fake zones
and have them selectively forwarded to external
DNS for all names that don't exist in the
internal fake zones?
Clients would first ask internal DNS, and if
the name exists there they will use that, but
if the name doesn't exist internally they won't
get a negative response. Instead their request
would be forwarded to external DNS.

Thanks!

Peter Olsson
___
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 vs flood

2014-02-26 Thread Peter Andreev
Hi Dmitry,

If your problem is a lot of strange queries, then there is two ways:

1. You operate an open resolver. If you can - restrict it to a limited
scope of clients, otherwise the only way you can lower number of incoming
queries is DPI;
2. You operate a non-open resolver. Then you can find who sending these
queries and ask them to stop.




2014-02-27 9:59 GMT+04:00 Dmitry Rybin :

> Over 2 weeks ago begins flood. A lot of queries:
>
> niqcs.www.84822258.com
> vbhea.www.84822258.com
> abpqeftuijklm.www.84822258.com
> adcbefmzidmx.www.84822258.com
> and many others.
>
> Bind answers with "Server failure". On high load (4 qps) all normal client
> can get Servfail on good query. Or query can execute more 2-3 second.
>
> Recursion clients via "rnds status" 300-500.
>
> I can try to use rate limit:
> rate-limit {
> nxdomains-per-second 10;
> errors-per-second 10;
> nodata-per-second 10;
> };
> I do not see an any improvement.
>
> Found one exit in this situation, add flood zones local.
>
> What can we do in this situation?
> ___
> 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
>



-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
___
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 vs flood

2014-02-28 Thread Peter Andreev
Well, at first glance it looks like malicious activity, so the best action
is to call all users, suspected in sending such requests, and warn them.
The fast and very (very-very-very) dirty solution is to set up zone
84822258.com  on your resolver. This should
supress outgoing queries and thus minimize resolving time.


2014-02-28 12:06 GMT+04:00 Dmitry Rybin :

> On 27.02.2014 09:59, Dmitry Rybin wrote:
>
>  Bind answers with "Server failure". On high load (4 qps) all normal
>> client can get Servfail on good query. Or query can execute more 2-3
>> second.
>>
>
> I have an a mistake, 4'000 QPS.
>
> ___
> 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
>



-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
___
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 vs flood

2014-02-28 Thread Peter Andreev
However, if you choose the second action, then your tech support should be
ready.


2014-02-28 13:36 GMT+04:00 Peter Andreev :

> Well, at first glance it looks like malicious activity, so the best action
> is to call all users, suspected in sending such requests, and warn them.
> The fast and very (very-very-very) dirty solution is to set up zone
> 84822258.com <http://niqcs.www.84822258.com> on your resolver. This
> should supress outgoing queries and thus minimize resolving time.
>
>
> 2014-02-28 12:06 GMT+04:00 Dmitry Rybin :
>
> On 27.02.2014 09:59, Dmitry Rybin wrote:
>>
>>  Bind answers with "Server failure". On high load (4 qps) all normal
>>> client can get Servfail on good query. Or query can execute more 2-3
>>> second.
>>>
>>
>> I have an a mistake, 4'000 QPS.
>>
>> ___
>> 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
>>
>
>
>
> --
> Is there any problem Exterminatus cannot solve? I have not found one yet.
>
>


-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
___
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: All client resolvers support DNSSEC compatible queries ???

2014-04-24 Thread Peter Andreev
2014-04-24 13:46 GMT+04:00 Carsten Strotmann :
> Hello Jeronimo,
>
> "Jeronimo L. Cabral"  writes:
>
>> Dear, we have several hosts in our LAN that ask our BIND DNS: Debian,
>> Windows 7, Red Hat and CentOS.
>>
>> If we implement DNSSEV validation support in our BIND9 server...how
>> can I know if our hosts' resolvers are compatible with DNSSEC queries
>> ???
>>
>
> client host resolvers are usually not DNSSEC aware today. Certain
> applications (Browser with a DNSSEC validator plugin, postfix MTA ...)
> running on a client can be DNSSEC aware.
>
> You can enable DNSSEC validation support on a BIND 9 caching server that
> is used as a resolver by your clients. BIND 9 9.9.x already comes with
> DNSSEC validation enabled, for older versions you need to enable it
> manually in the configuration.
>
> Legacy (non DNSSEC aware) clients will send just regular DNS queries
> towards the BIND 9 caching resolver. BIND 9 will send queries with the
> "DO"-Flag (DNSSEC OK) towards the authoritative DNS server in the
> network. For DNSSEC signed zones, BIND 9 will validate the DNSSEC
> data. If the data is validating without issues, the data is returned to
> the client as normal DNS (no DNSSEC). If the data fails to validate, the
> bad data is not send to the clients, instead a "SERVFAIL" error message
> is send to the client.

Actually a resolver sends to client an answer with AD (authenticated
data) bit set if response from authoritative server is successfully
validated.  If zone in question isn't secured by DNSSec, then client
receives response without AD bit. If validation fails - SERVFAIL.

>
> DNSSEC is backwards compatible in the sense that you can enable DNSSEC
> validation without the need to make changes to legacy clients.
>
> Windows 7 and Windows 8 clients can build a special trust relationship
> with an AD integrated Windows DNS Server to secure the "last mile"
> between the client and the resolving DNS cache. However to my knowledge
> this is not possible with Windows and a BIND 9 DNS.

IPSec, AFAIK.

>
> Best regards
>
> Carsten
> ___
> 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



-- 
Is there any problem Exterminatus cannot solve? I have not found one yet.
___
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: Multi-master (HA)

2014-05-07 Thread Peter Andreev
Well, we use two masters in different locations, w/o DLZ. Files for
signed zones are being generated from databases and uploaded to
servers. What we need here - is propagating of DDNS plus periodical
synchronizing of zones, journals etc.

Regarding zone templates - I'm using it with NSD4 and I'm totally
happy. Actually I don't have words to emphasize how I love those
templates!

2014-05-08 2:06 GMT+04:00 Lawrence K. Chen, P.Eng. :
>
>
> On 05/06/14 13:39, Evan Hunt wrote:
>> On Tue, May 06, 2014 at 06:20:11PM +, Baird, Josh wrote:
>>> Hi,
>>>
>>> For those of you who operate at multiple sites or datacenters, are you
>>> doing any HA for your BIND masters?  Ideally, we would have a master in
>>> each datacenter; maybe not an active one, but one that is standing by in
>>> case your primary master becomes unavailable.
>>>
>>> Do you have multiple "active" masters and list them as master in each of
>>> your slave's zone definitions?  This seems like it could get rather
>>> messy.  One thought is to use a technology like VMWare SRM which will
>>> spin up a master/virtual machine automatically in a second datacenter if
>>> your primary master goes down.  This coupled with Layer2 connectivity
>>> between your sites could make things fairly simple.  The
>>> standby/secondary master would retain the same IP address as your
>>> primary, so everything should just *work*.
>>>
>>> What are others doing?  Any thoughts, ideas or advice is much
>>> appreciated.
>>
>> Thank you for bringing this up.  As it happens, high-availability/
>> multi-master support in BIND is something we've been seriously considering
>> for a future release.  There's been a lot of internal discussion of use
>> cases, requirements, and possible design approaches.
>>
>> I don't want to influence the conversation here by saying too much about
>> the ideas we've had so far, but I wanted to say: if anyone has specific
>> thoughts on how to make this sort of thing easier in BIND -- even just at
>> the level of "boy, it irritates me that I can't make BIND do " --
>> such comments will fall on welcoming ears.
>>
>
> I hadn't thought of doing multi-master...but the issue of promoting a slave to
> master for DR had come up.  At the time the problem was DNSSEC.  Its one thing
> for the slave to become master, its another when it needs to change entries in
> the zone file to redirect key web-services to DR instances. (at the time, it
> was create two signed zone files each time...and secure transfer the second
> one out of bandbut no DR web servers were ever setup, so both were
> identical files and eventually got scrapped. The issue of raw vs text on
> secondaries came up after abandonment.  But, DR comes up now and
> then...recently its using DNS appliances and cloud...
>
> OTOH, the idea of multi-master is intriguing.the only down side I see, is
> that I have one really powerful server for my current master(Sun Fire
> X4170)and my other servers are weak leftoversjust passed EOL last
> year.  And, have all the servers doing full DNSSEC signing could be 
> interesting.
>
> It also raises the question of how does the outside world cope with all the
> servers having identical zones...signed on slightly different times, etc.
> (especially since I'm using unix timestamp for zone serialavoids issues of
> multiple admins incrementing serial without noticing others and/or collisions
> with DNSSEC's incrementing of serials.)
>
> But, it shouldn't be too hard to implement since, our nameservers are managed
> by CFEngine.  And, it makes possible for all my name servers to have both
> internal and external views.  Instead of having to have separate external
> slaves and internal slaves.  (and other issues that I'm still working through
> with having thisnamely my recursive caching servers hitting external
> slaves instead of internal slaves...)
>
> Things have gotten more complicated since we started allowing vanity internal
> namesbefore it was one subdomain that only existed on internal, and
> everybody had to put their host in there, as -host..ksu.edu
> but then certain VIPs wanted host..ksu.edu to work even though its a
> 10.x.x.x address.
>
> It would also mean one of our satellite campuses that refuses to use our
> caching servers (and even sent our server that was providing the service for
> their campus back, which they had firewalled their users from using while it
> was there)...can have their own caching servers work without needing to
> understand that our whois record doesn't list our stealth/internal
> nameservers...which is why they can't resolve any internal services and need
> to track down somebody to give them the 10.x.x.x IP and having their users use
> that, etc.
>
> Wonder if they know about the change in forwarding on my caching resolvers to 
> AD?
>
> --
> Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
> For: Enterprise Server Technologies (EST) -- & SafeZone Ally
> ___

Is it possible to have separate query logs for different views?

2015-03-09 Thread Peter Olsson
Hello!

Is it possible to have separate query logs for different views?

I tried putting this in the view block, but it failed with
"unknown option 'logging'":

logging {
channel logging_query {
file "/var/log/named/query-inside.log" versions 30 size 
5M;
print-time yes;
severity debug;
    };
    };
 
Thanks!

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


  1   2   3   4   >