Re: SRV on multiple subdomains

[Niall O'Reilly]

On 14 May 2024, at 15:20, DEMBLANS Mathieu wrote:

A part of the subdomains are managed by us, others subdomains by an 
other entity.
So we can't configure a generic target for all subdomains as each 
entity has its own target for SRV entries.


-Message d'origine-

De : bind-users bind-users-boun...@lists.isc.org De la part de Matus 
UHLAR - fantoms

Envoyé : mardi 14 mai 2024 15:58
À : bind-users@lists.isc.org
Objet : Re: SRV on multiple subdomains
On 14.05.24 13:08, DEMBLANS Mathieu wrote:

I have a question about configuration simplification for SRV 
configuration (maybe it can be applyed for other entries).


We manage multiple subdomain of a main one (server1.example.com, 
server2.example.com,...).
For A and MX entries, we use a general domain definitions with 
wildcard but is there a way to do so for SRV without having to define 
all subdomains (we have several dizains of it) ?


We have to define some SRV entries with the same target like :
_imap._tcp.server1.example.com IN SRV main.exemple.com
_imap._tcp.server2.example.com IN SRV main.exemple.com


Since a record is needed for each host, I think I would use something 
like this:


imap._tcp.server1.example.com. IN SRV main.example.com.
imap._tcp.server2.example.com. IN CNAME 
imap._tcp.server1.example.com.

...
imap._tcp.servern.example.com. IN CNAME 
imap._tcp.server1.example.com.


The advantage here is that, if ever the target of the SRV record had to
be changed, only one record would have to be updated.

/Niall
-- 
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: State diagram for DNSsec key lifecycle

[Niall O'Reilly]

On 10 Feb 2012, at 00:57, Mark Andrews wrote:

> I recommend "activate" + "publish" at the same time.

Mark,

I'ld appreciate knowing your reasoning for preferring this
approach over publication for later activation.

I suspect I might not be alone.  8-)


    Best regards,
Niall O'Reilly

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

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

Re: Bind bind-9.3.6-16.P1.el5_7.1 - socket.c:4373: unexpected error

[Niall O'Reilly]

On 27 Feb 2012, at 13:18, Rafał Radecki wrote:

> Feb 27 13:44:13 dns1 named[21599]: isc_socket_create: fcntl/reserved:
> Too many open files

It's likely that this isn't specific to BIND, but a consequence
of the (combination of) load(s) on your system.

Results from Googling for "Too many open files" shows the problem
occurring in the context of any of a variety od applications.
You may find this URL helpful:

http://confluence.atlassian.com/display/CONF29/Fix+'Too+many+open+files'+error+on+Linux+by+increasing+filehandles

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: Master/slave configuration

[Niall O'Reilly]

On 8 Mar 2012, at 02:58, Lyle Giese wrote (on bind-users):

> On linux boxes, adding 
> 
> options rotate
> 
> to the /etc/resolv.conf helps.

[cross-posted, reply-to header set]

Is there a DHCP option which expresses that, and which
typical fielded DHCP clients will respect?

As you may guess, I don't have access to those thousands
of client systems out there.

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: Restricting access & keeping identical data across views

[Niall O'Reilly]

On 28 Mar 2012, at 02:16, Jon A. wrote:

> I'm looking for a best practice to keep zone data across multiple views on 
> multiple servers sync

FWIW, you're not alone.

I have three views too, internal, external, and mendacious.  
The last is for coercing unregistered clients connecting to
LANs where registration is required.

What we have works.  It will need a major overhaul for DNSSEC.
I think I know what will be needed, but would find a BP
or HOWTO helpful, provided it met my use-case closely enough.
I'm not averse to contributing some effort to such a project.

    ATB
    Niall O'Reilly

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

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

Re: Restricting access & keeping identical data across views

[Niall O'Reilly]

On 28 Mar 2012, at 13:01, Lightner, Jeff wrote:

> Is signing not done at zone file level?

Yes, but that's not the problem.

> For our views even when the zones are identical I keep separate copies for the
> internaland external views so I would have thought this wouldn't be an issue.

The devil is in the details, which I'll spare you!  8-)

Niall O'Reilly

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

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

Re: erros in logs

[Niall O'Reilly]

On 10 May 2012, at 09:47, Ben wrote:

> I just enable bind as caching name server and when watching logs i got below 
> erros.

You seem to be noticing 3 kinds of error.

"Network unreachable" messages refer only to IPv6 destinations.
Perhaps you have IPv6 enabled on the system where you're running
named, but don't have any external IPv6 connectivity?

"Connection refused" or "format error" (duplicated confusingly as
"FORMERR") indicate that a remote name server has refused to handle
your request or has sent a badly-formed response.  You can expect
to see these all the time when you run a resolver.  There are
broken and misconfigured servers out there!

I hope this helps.

Niall O'Reilly

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

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

Re: Transfer the same zone from a split-view master

[Niall O'Reilly]

On 5 Jun 2012, at 23:01, Carlos Raúl Laguna Mendoza wrote:

> i read something about using TSIG to get this done but so far nothing

Just telling people that you read something doesn't give them
enough information to help you.

You need to explain what you did, what you expected to happen,
and what actually happened.

People won't help unless they believe you're making a serious
effort;  so far, you haven't sent anything which might convince
them.


    Best regards,
Niall O'Reilly
University College Dublin IT Services

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

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

Several (>2) different views

[Niall O'Reilly]

On 15 Jun 2012, at 01:14, Rodrigo Renie Braga wrote:

> I've been trying to find examples on how to use TSIG to replicate several 
> differents views to a slave server, but I could only find with two views, and 
> I just couldn't figure out how to adapt that example to 3 or more views.
> 
> Could you send me example on how to accomplish that?

Something like what follows below may be what you need.
This supports 3 views, keyed on TSIG or by default on
client address.  For more views, no new ideas are needed.

include "/etc/select-tsig.keys";// keep keys in protected file

acl captive-clients {
  // Purpose: triage for "captive" view
  key select-captive.ucd.ie.;   // select on this key
  ! key select-internal.ucd.ie.;// by-pass
  ! key select-general.ucd.ie.; // by-pass

  10.137.0.0/16;// Target networks
  10.193.128.0/19;
  10.193.160.0/20;
};

acl internal-clients {
  // Purpose: triage for "internal" view
  key select-internal.ucd.ie.;  // select on this key
  ! key select-captive.ucd.ie.; // by-pass (redundant)
  ! key select-general.ucd.ie.; // by-pass
  localhost;

  172.16.0.0/16;// Special networks
  10.224.0.0/16;
};

// Clients not otherwise selected are offered "general" view

// special-purpose view: 'captive'
view "captive" {

  match-clients { captive-clients; };

  // view details go here ...

};  // End view "captive"

view "internal" {

  match-clients { internal-clients; };

  // view details go here ...

};

// standard view: 'general'
view "general" {

  match-clients { any; };

  // view details go here ...

};

I hope this helps.

Niall O'Reilly

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

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

Re: Several (>2) different views [SOLVED]

[Niall O'Reilly]

On 3 Jul 2012, at 21:21, Rodrigo Renie Braga wrote:

> Just giving a feedback, this method worked great, but in my case, didn't have 
> no negate the keys in the ACL (like the example below), I created one key for 
> each ACL in my configuration and used that ACL for the "match-clients" 
> directive in the view.

Congratulations!
You seem to have thought of a better (i.e. simpler) way to do it
than I did.  Learning is a two-way process.

ATB
Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: Basic scope question

[Niall O'Reilly]

On 10/07/12 18:07, Bennett, Gary L. wrote:
> No, have that part.  Was just wondering which domain-name-servers parm, 
> global or in DHCP address pool, has precedence.  Thanks.

The more specific specific over-rides the global one.

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

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

Re: recursive-clients recommended values

[Niall O'Reilly]

On 12 Jul 2012, at 03:21, blrmaani wrote:

> I searched earlier posts but noticed that people are recommending it to just 
> increase it to suppress the errors in log.
> 
> Any pointers on this?

If it's set too low for your normal operating circumstances, you do 
need to increase it.
I've never needed to do this, as the default values just works for me.

In abnormal operating circumstances, it's probably neither posssible, 
nor useful to try, to eliminate
the log messages. See, for example, 
https://lists.isc.org/pipermail/bind-users/2009-August/077589.html.

    Best regards,
Niall O'Reilly

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

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

Re: SRV query with no domain?

[Niall O'Reilly]

On 16 Aug 2012, at 15:42, Christopher Cain wrote:

> Of course a dig query will fail without the domain appended.  Dig takes
> you query at face value and will not append domains from your search
> suffix list like nslookup and ping will.  You ALWAYS have to fully qualify
> your requests when using dig.

unless you use the +search option ...
/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: ho to filter hundeds of domains ?

[Niall O'Reilly]

On 30 Aug 2012, at 13:14, fddi wrote:

> I need to implement a bind filter for many hundreds of domains which are 
> considered outlaw and illegal
> by italian government about gamble games.
> 
> If I create a named zone for each illegal domain and configure my nameserver 
> as authoritative
> for those zones, I can catch the DNS resolutions and I can resolve with a 
> local LAN IP with a message for users.
> But it is really complicate to manage such a high number of domains.
> 
> Is there another way I could achieve this ?

Don't waste your time.

This approach is superficial.  It doesn't actually prevent access to the
target sites, and is likely to be a nuisance for intending users of 
legitimate services (web sites or others) which fall in the "shadow" of
the intervention you suggest.

Besides, if you take this approach, you will have to commit resources to
chasing a moving target.

Best regards,

Niall O'Reilly

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

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

Re: question about how a particular dig works ...

[Niall O'Reilly]

On 18 Sep 2012, at 14:45, M. Meadows wrote:

> dig www.careerone.com.au +short @8.8.8.8
> www.careerone.com.au.edgesuite.net.
> a903.g.akamai.net.
> 208.44.23.99
> 208.44.23.121
> 
> Why does the above dig work when 

If you try 

dig +trace www.careerone.com.au

you'll find that the www... subdomain is delegated to a different
set of name servers.

Besides, there's a CNAME at the apex ...

/Niall

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

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

RH release selection (was: Moving from "type forward" to "type static-stub")

[Niall O'Reilly]

On 21 Sep 2012, at 08:55, Adam Tkac wrote:

> Because rc2 was released too late to get it into RHEL 6.3... Btw which is the
> bug that bothers you? Why don't you report it to RH bugzilla?

I don't understand why RH would choose to include a release candidate
rather than a stable release.

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: dhcpd

[Niall O'Reilly]

[ Not sure why this thread started on BIND-users:
  please continue on DHCP-users! ]

On 18 Oct 2012, at 13:42, Dwayne Hottinger wrote:

> I checked the mac addresses of these clients and thus far they are all ipads, 
> ipods or iphones.

We see BOOTP transactions here at UCD (in Ireland, not California!) too.
I was agreeably surprised to see that our latest monthly statistical 
report 
shows these on our copper networks only, not on wireless.

IIRC, it's actually very easy for the user to configure any of the 
iDevices
to use DHCP instead of BOOTP.

Jim Glassford's suggestion seems good enough to me.

On 18 Oct 2012, at 14:28, Jim Glassford wrote:

> We just continue to deny bootp for subnets that have no need for it and 
> ignore them.


Best regards,

Niall O'Reilly
University College Dublin IT Services

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

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

Re: Update view without using 2 ip for each DNS Server

[Niall O'Reilly]

On 4 Dec 2012, at 11:23, manman wrote:

> Is it possible to update the second view when the firstl view is updated 
> without having to assign 2 IPs like now ?

You could use a pair of TSIG secrets instead of a pair of IP addresses.

There has been discussion about this on the list before, which you can
find in the archives.  The following links may help.

https://lists.isc.org/pipermail/bind-users/2009-August/077479.html
https://lists.isc.org/pipermail/bind-users/2012-June/087872.html
https://lists.isc.org/pipermail/bind-users/2012-June/087933.html

The example in the last one is extracted from a live configuration
which I'm responsible for.


Best regards,

    Niall O'Reilly
University College Dublin IT Services

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

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

Re: what do you use for logging?

[Niall O'Reilly]

On 17 Jan 2013, at 20:58, Mike Hoskins (michoski) wrote:

> Syslog as the default is perfectly fine with us.

Please keep that as the default, following the 
principle of least astonishment.

> I do also use the rotated file method a few places, so hoping that doesn't 
> disappear.

I would hope so too, not that we use it.

> Thanks for asking the list.

+1

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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 do you use for logging?

[Niall O'Reilly]

On 18 Jan 2013, at 06:27, Jan-Piet Mens wrote:

>> Could "CLI utility" be man(1) and info(1)?  :-)
> 
> It could, yes, but `b10-msg NNN` isn't going to break BIND 10's
> development budget (I hope),

+1

> and I feel it to be more practical than
> scrolling through a man page with 900+ error-messages in it. ;)

I'm not sure I see the big practical advantage over
'C-S' in info or '/' in the pager invoked by man.

I would see the man page as indispensible, and a bespoke
utility as merely cool.

/N

___
Please visit https://lists.isc.org/mailman/listinfo/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 do you use for logging?

[Niall O'Reilly]

On 17 Jan 2013, at 18:33, Jeremy C. Reed wrote:

> BIND 9 by default has logging using syslog, using its daemon facility, 
> and logging of info or higher.
> 
> Is using syslog a sane default for new installations or when using 
> official vendor packages with their startup scripts?

Definitely.

> Do any packagers provide a configuration with different-than-default 
> logging setup? (What and why?)

I'm sorry; I don't know.  Apart from one exceptional NetBSD
box, I always build from source and avoid whatever the
packager offers.

    Best regards
Niall O'Reilly

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

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

Re: BIND9 statistics-server: JSON?

[Niall O'Reilly]

On 15 Feb 2013, at 05:57, Jan-Piet Mens wrote:

> would there be a chance of ISC adding this to stock
> BIND9? Even better: would ISC take on the work of doing it? ;-)

FWIW: +1

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: Blocking private addresses with a optionq

[Niall O'Reilly]

On 14 Mar 2013, at 15:57, Chris Buxton wrote:

> No, I'm pretty sure the OP wants to strip records from responses if the 
> records are A records referring to private address space (RFC 1918).
> 
> I've no idea how you would do this.

Other than separate views, with a "trimmed" zone in the external view?

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: Blocking private addresses with a optionq

[Niall O'Reilly]

On 14 Mar 2013, at 16:22, Chris Buxton wrote:

> Well, yes, if the server in question is authoritative for all the data in 
> question. But if it's just a resolver, that may be more difficult.

Fair comment.

I was (perhaps naïvely) being led by my aversion to open resolvers
to assume that any externally-facing name server must be authoritative.

Things might not be that simple.

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: Suspecious DNS traffic

[Niall O'Reilly]

On 25 Mar 2013, at 16:21, babu dheen wrote:

> Still not convinced because if i need to allow >1024 port from  our DNS 
> server to external world(internet).. where is the security?
> 
> I beleive we just need to allow TCP and UDP 53 from our DNS server to 
> internet(any) which is already done. Not sure why we have to open non 
> standard port from our DNS server to internet?

Your DNS server will likely need to send queries to other DNS servers.
When it does this, it uses a destination port of 53 and a source port
from the range above 1024.  It is important for security that it not
use a fixed source port, but rather pick one at random for each query.
[Hint: Google "source port randomization" (without the quotes)]

The reply to such a query originates from port 53 on the remote server,
and is destined for the port on your server which was used as the
source of the query.  If you block access to high-numbered UDP ports on
your server, you block these replies.  For TCP, allowing "established"
packet flows is usually sufficient to allow the replies to reach your
    server.


    Best regards,
Niall O'Reilly

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

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

Re: Some Server not Resolving certain address

[Niall O'Reilly]

On 8 Apr 2013, at 14:25, wbr...@e1b.org wrote:

> Try running dig from each server.

And be sure to specify the server address on the dig command line;
otherwise whatever test you intend may be diverted by what is
specified in /etc/resolv.conf.

If you use

dig @127.0.0.1 ...

you can be sure that the server on which your shell session is running
is the one to which dig sends the query.  If this is not what you need,
use the address of the server's network interface.

ATB
    Niall O'Reilly

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

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

Re: Reverse address entries

[Niall O'Reilly]

On Fri, 28 Jun 2013 13:57:44 -0400
"Novosielski, Ryan"  wrote:

> The short answer is "some software once cared." Does it still now, I'm
> not sure. But we do it.

    Some still does

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

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

Re: Slave not creating/updating zones

[Niall O'Reilly]

On 15 Jul 2013, at 12:49, Grace Ingabire wrote:

> The issue is now resolved, my master was not configured properly!

There's something else: LTD.RW seems not to be delegated.

The problem seems to be masked from you because this zone 
and its parent are both hosted on ns{1,2}.ricta.org.rw.

From further away, a query for NS records for LTD.RW
sometimes returns a list of NS records, sometimes NXDOMAIN,
according to which of the parent zone (RW) name servers
is queried for the delegation (zone-cut) records, as shown
below.

I expect you'll need to add NS records for LTD in the RW
zone file.

dhcp-c101a88b(niall)8: dig +trace ltd.rw ns

; <<>> DiG 9.6-ESV-R4-P3 <<>> +trace ltd.rw ns
;; global options: +cmd
.   232678  IN  NS  e.root-servers.net.
.   232678  IN  NS  k.root-servers.net.
.   232678  IN  NS  f.root-servers.net.
.   232678  IN  NS  a.root-servers.net.
.   232678  IN  NS  m.root-servers.net.
.   232678  IN  NS  g.root-servers.net.
.   232678  IN  NS  j.root-servers.net.
.   232678  IN  NS  h.root-servers.net.
.   232678  IN  NS  d.root-servers.net.
.   232678  IN  NS  i.root-servers.net.
.   232678  IN  NS  l.root-servers.net.
.   232678  IN  NS  b.root-servers.net.
.   232678  IN  NS  c.root-servers.net.
;; Received 512 bytes from 137.43.116.19#53(137.43.116.19) in 7 ms

rw. 172800  IN  NS  ns1.ricta.org.rw.
rw. 172800  IN  NS  fork.sth.dnsnode.net.
rw. 172800  IN  NS  sns-pb.isc.org.
rw. 172800  IN  NS  ns-rw.afrinic.net.
;; Received 290 bytes from 2001:dc3::35#53(m.root-servers.net) in 19 ms

rw. 86400   IN  SOA ns1.ricta.org.rw. 
info.ricta.org.rw. 2013071545 86400 7200 604800 86400
;; Received 79 bytes from 2001:500:2e::1#53(sns-pb.isc.org) in 35 ms

dhcp-c101a88b(niall)8: dig +trace ltd.rw ns

; <<>> DiG 9.6-ESV-R4-P3 <<>> +trace ltd.rw ns
;; global options: +cmd
.   232677  IN  NS  m.root-servers.net.
.   232677  IN  NS  f.root-servers.net.
.   232677  IN  NS  a.root-servers.net.
.   232677  IN  NS  l.root-servers.net.
.   232677  IN  NS  i.root-servers.net.
.   232677  IN  NS  h.root-servers.net.
.   232677  IN  NS  k.root-servers.net.
.   232677  IN  NS  c.root-servers.net.
.   232677  IN  NS  g.root-servers.net.
.   232677  IN  NS  j.root-servers.net.
.   232677  IN  NS  d.root-servers.net.
.   232677  IN  NS  e.root-servers.net.
.   232677  IN  NS  b.root-servers.net.
;; Received 512 bytes from 137.43.116.19#53(137.43.116.19) in 1 ms

rw. 172800  IN  NS  ns1.ricta.org.rw.
rw. 172800  IN  NS  fork.sth.dnsnode.net.
rw. 172800  IN  NS  ns-rw.afrinic.net.
rw. 172800  IN  NS  sns-pb.isc.org.
;; Received 290 bytes from 2001:500:3::42#53(l.root-servers.net) in 3 ms

ltd.rw. 86400   IN  NS  ns2.ricta.org.rw.
ltd.rw. 86400   IN  NS  ns1.ricta.org.rw.
;; Received 102 bytes from 41.74.173.250#53(ns1.ricta.org.rw) in 202 ms

dhcp-c101a88b(niall)8: 


/Niall

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

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

Re: BIND 9.8.1-P1: 'make test' fails

[Niall O'Reilly]

On 22 Nov 2011, at 11:24, Niall O'Reilly wrote:

> Since quite a few years, I habitually run 'make test' after building BIND 
> from sources.  I'me seiing a failure with 9.8.1-P1, and wonder whether
> anyone else is also.

[By way of putting this to bed, at last ...]

Updating the Perl module Net::DNS to a recent version seems to be 
what is needed to make the test which was failing (labelled 'xfer') 
run successfully.

I don't know the cut-off point between 'old' and 'recent' version
of Net::DNS.  I've had success with 0.65 and 0.66; current is 0.72.
An 'old' version will cause the 'xfer' test to fail in BIND releases
subsequent to 9.8.1-P1, including current releases.

Best regards,
/Niall

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

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

Re: BIND 9.8.1-P1: 'make test' fails

[Niall O'Reilly]

On 20 Aug 2013, at 15:08, Chris Buxton wrote:

> There is a mailing list for Net::DNS.
> 
> List-Subscribe: , 
> 
> 
> That said, there was a discussion last December about what has changed since 
> Net::DNS was taken over by a new maintainer, meaning post-0.68. A small 
> number of quite disruptive changes were made in 0.69.

Thanks, Chris.

For problem at hand, the break-point of interest is somewhere between 
0.31 and 0.65.  8-)

Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: ISO or virtual appliance

[Niall O'Reilly]

On 22 Aug 2013, at 10:49, Phil Mayers wrote:

> * Make the service name a CNAME into another small dynamic (sub-)zone. This 
> is what most DNS-based LB do e.g. www.example.com CNAME www.lb.example.com, 
> then make "lb.example.com" a small, dynamically-updated zone.

or delegate www.example.com as a tiny dynamic zone and update it 
directly.

    Niall O'Reilly

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

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

Re: packet size

[Niall O'Reilly]

On 11 Sep 2013, at 17:24, Maria Iano wrote:

> What does it mean when the edns0 response to a dig says the overall packet 
> size will be one value

Not "will be one value" but "can be no more than that value".

> but the message size reported is different.

That's the actual size of the response message.
It depends on what you requested, and what data was
sent in the response.

> For example in this reponse the OPT PSEUDOSECTION says udp: 4096 but at the 
> end it says MSG SIZE  rcvd: 275.

I hope this helps.

/Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: use bind 9.8 as caching server and authoritative nameserver

[Niall O'Reilly]

On 28 Oct 2013, at 13:10, bind-ch...@telenet.be wrote:

> Recently our government obligated all ISP's to block access to child-porn, 
> illegal betting sites, illegal file share sites etc...
> I have been asked now to implement this on our caching DNS servers (serve a 
> custom zone to all of our customers that points to an IP from the government 
> that hosts a block-page)

You probably understand that this approach is of limited effectiveness,
and has arguably significant disadvantages.

It may be of interest for you to read the report mentioned at either of
the following URIs (in French, English respectively).

http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/6573/show/le-conseil-scientifique-de-l-afnic-partage-sur-le-filtrage-internet-par-dns.html
http://www.afnic.fr/en/about-afnic/news/general-news/6584/show/the-afnic-scientific-council-shares-its-report-on-dns-based-internet-filtering.html


Best regards,

    Niall O'Reilly
Member of AFNIC's Conseil Scientifique

  PS.   I wan't a significant contributor to this report.  
Credit for that belongs to the colleagues who did the work. /Niall

___
Please visit https://lists.isc.org/mailman/listinfo/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: Recursive DNS server cannot resolve the reverse zone records from my IPv6 private network

[Niall O'Reilly]

On 6 Nov 2013, at 18:30, Listas wrote:

> ;; QUESTION SECTION:
> ;f.1.4.2.0.0.0.0.0.0.0.0.0.0.0.0.7.0.0.0.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa. IN 
> PTR

And placed the following (and more) data at 
http://adminlinux.com.br/recursive-bind.conf

 /etc/bind/named.conf.local-ip6:

zone "5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa" IN {
  type master;
  file "/etc/bind/db.fc";
};


 /etc/bind/db.fc:
$TTL 86400 ; Minimum TTL of 1 day.

@ IN SOA ns1.mydomain.com. dnsmasters.mydomain.com. (
  1   ; Serial.
  10800   ; Refresh after 3 hours.
  3600; Retry after 1 hour.
  604800  ; Expire after 1 week.
  86400 ) ; Minimum TTL of 1 day.

IN NS ns1.mydomain.com.
IN NS ns2.mydomain.com.

10  IN NS ns3.mydomain.com.
IN NS ns4.mydomain.com.

12  IN NS ns5.mydomain.com.
IN NS ns6.mydomain.com.

16  IN NS ns7.mydomain.com.
IN NS ns8.mydomain.com.

20  IN NS ns9.mydomain.com.
IN NS ns10.mydomain.com.


 
The zone file you've chosen to show us has records only for the 
following names:

5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
10.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
12.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
16.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
20.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.

None of these matches the target of your query, so the result is 
NXDOMAIN.
Anything else would be strange.

If you need the server to return some other result for this query, you
must place the corresponding record(s) in the zone file you're using.

    Best regards,
Niall O'Reilly

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

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

Re: missing ‘additional section’

[Niall O'Reilly]

On 18 Dec 2013, at 15:19, houguanghua  wrote:

> Is there any way to enable the Additional Section? Thanks.

The server sends data in the additional section if either
(a) these data are required, or (b) the server supports
and is configured to send data which, although not actually 
required, may somehow be “useful”.

The BIND named configuration option “minimal-responses”
controls case (b). If this is set to “no”, and the server
isn’t sending data in the additional section, it’s because
it doesn’t have anything useful to put there.

As this option is part of the server configuration, there 
isn’t anything you can do with DiG to enable sending of
additional data.

I hope this helps.

Niall O’Reilly

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

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

Re: bad owner name - Unable to add forward map from Nintendo Wii U ... REFUSED

[Niall O'Reilly]

> On 27 Dec 2013, at 06:07, "David C. Rankin"  
> wrote:
> 
> Dec 26 20:55:43 nirvana dhcpd: Unable to add forward map from Nintendo Wii
> U.3111skyline.com to 192.168.6.148: REFUSED

IIUC, your DHCP server seems to be handling the DDNS transaction.
If you can set the configuration of this server, I expect you're in a
position to determine what owner name is passed to the DNS server,
and that this approach might be what you need.

This thread probably belongs better on the dhcp-users list ...

Niall O'Reilly

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

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

Re: intermittent resolving problem for some domains

[Niall O'Reilly]

At Wed, 19 Feb 2014 00:33:11 +0200,
Daniel Dawalibi wrote:
> 
> Kindly note that the number of recursive clients is increasing during
> the problem : recursive clients: 3700/14900/15000

  I think it's likely that you have a connectivity problem.

  I'ld suggest checking whether your server which is giving these
  messages can reach any of the root servers or even any of the
  external Internet.

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

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

Re: How to setup a backup NameServer?

[Niall O'Reilly]

At Tue, 29 Apr 2014 10:24:58 +,
houguanghua wrote:
> 
> Yes, I had asked the same question months ago. 
> I'm designing how to protect DNS for an ISP. The zones are not owned
> by the ISP. The ISP wants to proect the DNS query during attacking.
> So it's not standard DNS solution. During the attacking, the backup
> server will provide the DNS query and it works even if it can't
> refresh zones from primary NS.

  Which (or how many) zones do you expect your backup server to work
  for?

  /Niall
___
Please visit https://lists.isc.org/mailman/listinfo/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: Does bind read /etc/hosts?

[Niall O'Reilly]

At Tue, 15 Jul 2014 10:28:30 +,
houguanghua wrote:
> 
> Before Bind consults authority NS, does it access /etc/hosts? In my
> testing, it does not even seem to access /etc/hosts.

  That's right.  BIND tools (dig, ...) are DNS tools.
  Local files aren't part of the DNS.

  For more information, please see 
http://serverfault.com/questions/498500/why-does-the-host-command-not-resolve-entries-in-etc-hosts
 

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

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

Re: Digging to the final IP

[Niall O'Reilly]

At Tue, 21 Oct 2014 22:31:28 -0500,
Frank Bulk wrote:
> 
> Dave,
> 
> Thanks for the input, but what I was looking for was a dig command that
> returns the IP(s) or a fail.  It looks like the host command is the right
> solution in this case, not dig.

  Doesn't egrep fail on no match?
  Niall
  
___
Please visit https://lists.isc.org/mailman/listinfo/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: Digging to the final IP

[Niall O'Reilly]

At Thu, 23 Oct 2014 15:17:49 +0100,
Sam Wilson wrote:
> 
> In article ,
>  Bob Harold  wrote:
> 
> > Anytime you see 'grep' and 'cut' used together, they can usually be
> > shortened to just 'awk', which requires starting one less process.  And if
> > this case it splits fields the way a users sees them, so the same code
> > works in both cases:
> > 
> > $ dig +noall +answer home.kreme.com in a | awk '/[\t ]A[\t ]/ {print $NF}'
> > 23.24.150.141
> > $ dig +noall +answer  dave.knig.ht in a | awk '/[\t ]A[\t ]/ {print $NF}'
> > 216.235.14.46
> 
> $ dig +noall +answer cancer.ucs.ed.ac.uk | perl -ne ' /\sA\s/ && do { 
> @_=split; print "$_[$#_]\n" }' 
> 129.215.166.13
> 129.215.200.7

  Which makes it easy, in either case, to return a status value, as
  Frank Bulk seemed to want.

  Something like

  '... {print $NF; count++} END {exit ! count}'

  or

  | perl -ane ' /\sA\s/ && do { print "$F[$#F]\n"; $count++ } END
{exit ! $count }'

  might work.

  Niall
  
___
Please visit https://lists.isc.org/mailman/listinfo/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: Digging to the final IP

[Niall O'Reilly]

At Thu, 23 Oct 2014 15:17:49 +0100,
Sam Wilson wrote:
> 
> In article ,
>  Bob Harold  wrote:
> 
> > Anytime you see 'grep' and 'cut' used together, they can usually be
> > shortened to just 'awk', which requires starting one less process.  And if
> > this case it splits fields the way a users sees them, so the same code
> > works in both cases:
> > 
> > $ dig +noall +answer home.kreme.com in a | awk '/[\t ]A[\t ]/ {print $NF}'
> > 23.24.150.141
> > $ dig +noall +answer  dave.knig.ht in a | awk '/[\t ]A[\t ]/ {print $NF}'
> > 216.235.14.46
> 
> $ dig +noall +answer cancer.ucs.ed.ac.uk | perl -ne ' /\sA\s/ && do { 
> @_=split; print "$_[$#_]\n" }' 
> 129.215.166.13
> 129.215.200.7

  Which makes it easy, in either case, to return a status value, as
  Frank Bulk seemed to want.

  Something like

  '... {print $NF; count++} END {exit ! count}'

  or

  | perl -ane ' /\sA\s/ && do { print "$F[$#F]\n"; $count++ } END
{exit ! $count }'

  might work.

  Niall
___
Please visit https://lists.isc.org/mailman/listinfo/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: recursive-clients : recommended value for a high traffic recursive nameserver

[Niall O'Reilly]

At Sun, 23 Nov 2014 21:00:15 -0800 (PST),
blrmaani wrote:
> 
> Our nameservers take upto 10KQPS (mostly NOERROR type most of the time). 
> 
> Twice or thrice a week, I have seen upto 10% of the queries are
> SERVFAIL and we have started exceeding the default value of 2000 for
> recursive-clients settings in BIND 9.9.x.
> 
> Is there a recommended value for recursive-clients option assuming
> huge number of SERVFAIL queries once in a 2/3 days?
> 
> I'm not convinced to increase it to some arbitrary huge number
> 20,000 or 200,000.
> 
> I am looking for answer like - if your peak SERVFAIL queries are
> 2000/second, then your recursive-clients value should be N.

  I wouldn't expect that such an answer could make sense.

  Exhaustion of the active recursive-clients list and the generation
  of responses marked SERVFAIL are most likely different symptoms of
  the same problem.  I think you'll need to identify this problem and
  then determine what action to take.

  Your resolver seems to be dealing with queries which are
  unanswerable and which are arriving in a quantity sufficient to fill
  the recursive-clients list.  This may be due to rogue clients,
  misconfigured authoritative servers, network problems, or some
  combination of these.  Your logs will help identify which.

  I hope this helps.

  Niall O'Reilly
  
  

  

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

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

Re: recursive-clients : recommended value for a high traffic recursive nameserver

[Niall O'Reilly]

At Sun, 23 Nov 2014 21:00:15 -0800 (PST),
blrmaani wrote:
> 
> Our nameservers take upto 10KQPS (mostly NOERROR type most of the time). 
> 
> Twice or thrice a week, I have seen upto 10% of the queries are
> SERVFAIL and we have started exceeding the default value of 2000 for
> recursive-clients settings in BIND 9.9.x.
> 
> Is there a recommended value for recursive-clients option assuming
> huge number of SERVFAIL queries once in a 2/3 days?
> 
> I'm not convinced to increase it to some arbitrary huge number
> 20,000 or 200,000.
> 
> I am looking for answer like - if your peak SERVFAIL queries are
> 2000/second, then your recursive-clients value should be N.

  I wouldn't expect that such an answer could make sense.

  Exhaustion of the active recursive-clients list and the generation
  of responses marked SERVFAIL are most likely different symptoms of
  the same problem.  I think you'll need to identify this problem and
  then determine what action to take.

  Your resolver seems to be dealing with queries which are
  unanswerable and which are arriving in a quantity sufficient to fill
  the recursive-clients list.  This may be due to rogue clients,
  misconfigured authoritative servers, network problems, or some
  combination of these.  Your logs will help identify which.

  I hope this helps.

  Niall O'Reilly
  
  

  

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

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

Re: BIND9 Return different IP address based on subnet

[Niall O'Reilly]

At Sat, 3 Jan 2015 19:24:47 +0100,
Christian Kette wrote:
> 
> I have found a workaround.
> I defined a different zone for every network

  A simpler solution might be to use a sortlist.

  From the ARM:

6.2.16.13 The sortlist Statement

The response to a DNS query may consist of multiple resource records
(RRs) forming a resource records set (RRset). The name server will
normally return the RRs within the RRset in an indeterminate order
(but see the rrset-order statement in Section 6.2.16.14). The client
resolver code should rearrange the RRs as appropriate, that is, using
any addresses on the local net in preference to other
addresses. However, not all resolvers can do this or are correctly
configured. When a client is using a local server, the sorting can be
performed in the server, based on the client’s address. This only
requires configuring the name servers, not all the clients.

  Niall
  
___
Please visit https://lists.isc.org/mailman/listinfo/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 response time is relatively high

[Niall O'Reilly]

At Mon, 26 Jan 2015 21:50:37 +,
Darcy Kevin (FCA) wrote:
> 
> 
> The parameter that is glaringly missing from your list is
> “recursive-clients”. Do you have that set at default value (1000) or
> have you bumped it up higher? Since you say that this happens at “peak
> hours”, recursive-clients is the prime suspect,

  Besides what Kevin suggests, it may be worth checking for swapping
  and/or IO wait using 'top'.

  /Niall
  
___
Please visit https://lists.isc.org/mailman/listinfo/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: lists subdomain not fully working

[Niall O'Reilly]

On Mon, 25 May 2015 11:26:58 +0100,
Lucio Crusca wrote:
> 
> I moved my bind installation to a new server two weeks ago and I
> copied the zones verbatim: on the old server everything was working
> ok. 

  More precisely, you weren't aware of a problem, which is not
  necessarily the same thing.

> The zone lists.granellodisenape.org

  This isn't a zone, as it's not delegated; it's just a host, as can
  be seen by requesting relevant DNS resource records from one of the
  servers (ns{1,2}.virtualbit.it) responsible for the zone
  granellodisenape.org.

; <<>> DiG 9.8.3-P1 <<>> +norec @ns1.virtualbit.it. any 
lists.granellodisenape.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52674
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;lists.granellodisenape.org.IN  ANY

;; ANSWER SECTION:
lists.granellodisenape.org. 12880 INA   136.243.232.142

;; AUTHORITY SECTION:
granellodisenape.org.   12880   IN  NS  ns2.virtualbit.it.
granellodisenape.org.   12880   IN  NS  ns1.virtualbit.it.

;; ADDITIONAL SECTION:
ns1.virtualbit.it.  3600IN  A   136.243.232.142
ns2.virtualbit.it.  3600IN  A   136.243.232.143

;; Query time: 51 msec
;; SERVER: 136.243.232.142#53(136.243.232.142)
;; WHEN: Mon May 25 14:07:24 2015
;; MSG SIZE  rcvd: 141

  Where your new server fits in all of this isn't clear, as you don't
  mention what either its name or its address is.

  It may be useful for you to use a public validation service (such as
  http://zonemaster.net/) to check the name service for your zone.

> hosts a mailing list (mailman). On
> the new server, all mailing list users can use it except two of them:
> they are the only ones with email address @alice.it. When they try to
> write to the mailing list, their SMTP server @alice.it is complainig
> that:
> 
> 550 RCPT address has non-existant domain 

  From where I sit, this problem does not appear.

  If you can confirm that this problem is still present, you'll need
  to look for help with analysing it to someone who has access to the
  name server(s) used by this SMTP server.  Either of the users you
  mention may be able to help.


  Best regards,

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

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

Re: lists subdomain not fully working [SOLVED]

[Niall O'Reilly]

On Wed, 27 May 2015 07:50:12 +0100,
Lucio Crusca wrote:
> 
> I've now fixed the MNAME and I have to wait propagation before testing
> again, but I'm really confident it will solve the problem,

  Fammi sapere, per piacere ...
  Niall
  
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Issue in calling same zone in more than one VIEW

[Niall O'Reilly]

On Fri, 29 May 2015 08:23:55 +0100,
Gaurav Kansal wrote:
> 
> Dear Team,
> 
> I am running BIND 9.10.2 version on CentOS and running roughly 500
> domains and for most of them I am a slave server.
> 
> In few of them, I have different zone file based on Internal and
> External view.
> 
> And for rest of them, I am using a single file for both the View.
> 
> This configuration was working fine till BIND version 9.9.5

  As I understand, this configuration was never supported.

  Each instance (view) of a slave server needs a private file in which
  to write zone data transferred from the master.  Having multiple
  instances use the same file means that they may over-write each
  other's work.  Managing this contention was never a design feature.

> but
> yesterday I updated to 9.10.2 and I am facing the following error.
> 
> May 29 12:43:58 NKN-IPV6-DNS named[17727]:
> /var/named/zonedata/gov-zone.data:3: writeable file
> 'govdomains/xyz.gov.in.fwd': already in use:
> /var/named/zonedata/gov-zone.data:3

  The new version now gives an error message in case you use this
  kind of unsupported configuration.

> This is happening because I am calling same zone file in both view.
> 
> Please help me out what I should do for getting rid of this issue.

  You need to use as many copies of each zone file as you have views
  needing to write to it.
  

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

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

Re: Issue in calling same zone in more than one VIEW

[Niall O'Reilly]

On Fri, 29 May 2015 11:25:48 +0100,
Cathy Almond wrote:
> 
> 
> From 9.10.0 there is a new zone type 'in-view'.  From the release notes:

  Neat!


  Thanks and best regards,
  
  Niall O'Reilly
  
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Issue in calling same zone in more than one VIEW

[Niall O'Reilly]

On Fri, 29 May 2015 11:49:35 +0100,
Gaurav Kansal wrote:
> 
> Now I have to create 2 files with different zone definition (one
> contains definition and the second one contains ‘in-view’ parameter).
> I know that this is not at all tough I but I just need to know if I
> can use same file for including in both the view (by anyhow). 

  You can find some helpful examples in the configuration files
  used by the test suite (.../*.conf below):

dhcp-162(niall)14: tar xzf ~/Downloads/bind-9.10.2.tar.gz

dhcp-162(niall)16: find bind-9.10.2/ -type f -exec fgrep -q in-view {} \; -print
bind-9.10.2//bin/named/server.c
bind-9.10.2//bin/tests/system/checkconf/bad-sharedzone1.conf
bind-9.10.2//bin/tests/system/checkconf/bad-sharedzone2.conf
bind-9.10.2//bin/tests/system/checkconf/good.conf
bind-9.10.2//bin/tests/system/views/ns2/named2.conf
bind-9.10.2//CHANGES
bind-9.10.2//doc/arm/Bv9ARM-book.xml
bind-9.10.2//doc/arm/Bv9ARM.ch06.html
bind-9.10.2//doc/misc/options
bind-9.10.2//lib/bind9/check.c
bind-9.10.2//lib/isccfg/namedconf.c

  You'll also find documentation (in the ARM) of the restrictions on
  which other options can validly be used together with "in-view":
  
  An "in-view" option cannot refer to a view that is
  configured later in the configuration file.

  A "zone" statement which uses the "in-view" option may
  not use any other options with the exception of
  "forward" and "forwarders". (These options control the
  behavior of the containing view, rather than changing
  the zone object itself.)

  An "in-view" zone cannot be used as a response policy
  zone.

  I think you'll find that just one of your views can reference the
  zone file, while the other(s) will have an "in-view" option
  referencing the first view.

  I hope this helps.

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

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

Re: windows client request timed out

[Niall O'Reilly]

On Mon, 22 Jun 2015 12:07:31 +0100,
Zelalem Fanta Woldesemayat wrote:
> 
> Dear all,
> 
> I’ve configured BIND 9.9.4. as a cache only server on our DMZ so that
> it can serve as a DNS server for the internal network. Inside the DMZ
> zone the request time out is very fast and the DNS service resolves
> very quickly. But the problem is from the inside network. When I tried
> nslookup it gives the following message. Would you please help me to
> resolve this issue.

  Perhaps you need to configure named to allow access from the client
  network.  The ISC Knowledge Base has an article which may be useful:
  
https://kb.isc.org/article/AA-00269/0/What-has-changed-in-the-behavior-of-allow-recursion-and-allow-query-cache.html

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

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

Re: Multiple A and PTR and the "main" ones?

[Niall O'Reilly]

On Fri, 11 Sep 2015 15:54:52 +0100,
David Ford wrote:
> 
> [...] satisfy RFC requirements for DNS [...]

  Would you mind citing?

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

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

Re: problem using setuid ("-u" option) with BIND 9.10.3 on RedHat when listening on tun/tap interface

[Niall O'Reilly]

On Sat, 26 Sep 2015 17:27:56 +0100,
Gordon Lang wrote:
> 
> CHANGE: I did not properly characterized the problem in my original
> post, so here is the real situation.
> 
> If the bash shell from which I launch "named" is owned by root, then
> "named" runs perfectly using the "-u" option, even listening on the
> tun/tap interfaces.
> But if I run "named" as a regular user, relying on the SUID file
> setting to elevate privileges, then named fails to listen on any
> addresses.
> I believe the differences I saw before related to tun/tap interfaces
> were due to testing on different RedHat platforms, but this revised
> problem statement describes what is happening on both platforms.
> 
> So the real problem is this: It seems I can use the SUID file bit to
> allow a regular user to launch named, OR I can use the "-u" option of
> "named" to lower the privileges after launch (requiring native root
> privileges to launch), but I can't use both at the same time.
> 
> Can anyone shed any light on this scenario?

  I'm missing some information which might help me understand the
  problem: the user and group to which your named belong.

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

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

Re: problem using setuid ("-u" option) with BIND 9.10.3 on RedHat when listening on tun/tap interface

[Niall O'Reilly]

On Sun, 27 Sep 2015 16:59:14 +0100,
Gordon Lang wrote:
> 
> Here is the file info:
> 
> glang@nstv1:/export/local/ISC> ls -ld bind-9.10.3/sbin
> bind-9.10.3/sbin/named
> drwxrwsr-x. 2 incadmin network 4096 Sep 26 10:39 bind-9.10.3/sbin
> -rwsr-xr-x. 2 root network 10095219 Sep 26 09:16
> bind-9.10.3/sbin/named
> glang@nstv1:/export/local/ISC>
> 
> If I run "named" as user 'glang' without the "-u" option, it works
> fine -- "named" runs as root (due to the suid file bit) and it listens
> on port 53 of the configured ip addresses.

  Real user is unprivileged, but effective user is, so it all works.

> If I run "named" as user 'glang' with the "-u incadmin" option, it
> does not work fine -- it runs with the change of process owner to
> 'incadmin', but it does not listen on any ip addresses.

  Real user is unprivileged. Effective user is briefly privileged,
  and later unprivileged.  In the section of the ARM which contains
  copies of the man pages, I see the following description of the
  -u option.

-u user

  Setuid to user after completing privileged operations, such as
  creating sockets that listen on privileged ports.

  NOTE
  On Linux, named uses the kernel’s capability mechanism to drop
  all root privileges except the ability to bind(2) to a
  privileged port and set process resource limits. Unfortunately,
  this means that the -u option only works when named is run on
  kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since
  previous kernels did not allow privileges to be retained after
  setuid(2).  

  I don't doubt that you're running a new enough kernel.  However, I
  guess that, since the real user didn't have the privileges in
  question, the final effective user can't retain them.  Without
  checking kernel and/or named code, I'm afraid I can't do better then
  guess.

> If I run "named" as user 'root' with the "-u incadmin" option, it
> works fine -- it listens on the configured ip's and it changes the
> owner of the process to 'incadmin'.

  This is the "traditional" way to run a reduced-privilege instance of
  named.  I've used it, and I believe it's widely used.  Are you sure
  it's not adequately secure for your needs?

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

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

Re: dname reverse delegation

[Niall O'Reilly]

On Tue, 13 Oct 2015 21:40:30 +0100,
Paul A wrote:
> 
> I have a few /24 that I want to delegate using DNAME.

  Are you expecting to save yourself trouble by doing so?
  If not, you should probably reconsider.

  If you decide DNAME is a useful trick, bear in mind that what DNAME
  does is not really delegation, but just a trick for the lazy.  I'm
  actually one of those lazy people, so please understand that I don't
  mean the word offensively. Besides, cleverer people than I have
  recognized laziness as a virtue.
  
  I have persuaded the administrator of the
  1.0.0.7.7.0.1.0.0.2.ip6.arpa. zone to use a DNAME rather than a
  delegation for f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa.  Yes, this is for
  IPv6, but it's conveniently to hand, and the principles are the
  same. I have actually had second thoughts about this, and more than
  once, but never felt worried enough that making the change needed
  priority before the other things on my do-list.

  The trouble I save by doing this is that of maintaining two zone
  files for my  and corresponding PTR records.  Instead, I can
  keep both together in one file, like this:

$ORIGIN no8.be.
bode3600IN  2001:770:13f:0:5054:ff:fe00:d978
8.7.9.d.0.0.e.f.f.f.0.0.4.5.0.5.0.0.0.0.f.3.1.0.0.7.7.0.1.0.0.2.ip6 3600 IN PTR 
bode

  Using 'dig', you can explore how it works, and what zones are
  involved, by using commands such as these:

dig bode.no8.be 
dig -x 2001:770:13f:0:5054:ff:fe00:d978
dig +trace -x 2001:770:13f:0:5054:ff:fe00:d978
dig f.3.1.0.0.7.7.0.1.0.0.2.ip6.arpa ns
dig no8.be ns

  You can do the same for your /24's, if the administrator of the
  parent reverse zone is minded to co-operate.  Alternatively,
  you can use a normal delegation and set up your zone as follows,
  filling in the gaps appropriately.

$TTL 3600 ;; or whatever
$ORIGIN 13.168.192.in-addr.arpa.
@ IN SOA ...
  IN NS ...
  IN DNAME whatever.example.net.

  Then, you populate the whatever.example.net. zone with the PTR records:

$TTL 3600 ;; or whatever
$ORIGIN whatever.example.net.
@ IN SOA ...
  IN NS ...
0 IN PTR base-addr.whatever-else.example.net.
1 IN PTR some-host.whatever-else.example.net.
2 IN PTR anor-host.whatever-else.example.net.
;; and so on ...
255 IN PTR bcast-addr.whatever-else.example.net.

> Lets says I have 192.168.13.0/24 how would I go about doing reserve on
> the forwarding server using DNAME.
> 
> Currently on the forwarding server I have 
> 
> NS ns.isp.com
> 
> ;;
> 
> DNAME 0/24

  Don't be distracted by RFC2317.  It describes the trickery you need
  when you're dealing with a longer prefix (fewer addresses) than a
  /24.  If you have "a few /24", you can deal with them without
  needing any of that.

> ;;
> 
> ;;; delegate to server
> 
> 0/24 NS ns.someserver.com.
> 
> On the server handling the PTRs (ns.someserver.com) I have:
> 
> zone "0/24.13.168.192.IN-ADDR.ARPA" {
> 
> type master;
> 
> file "/slvdb/db.13.168.192";
> 
> };
> 
> In the PTR server the zone file looks like a normal PTR file and when
> I query on this server its working, I get the DNAME/CNAME and PTR. 
> 
> However when I query on the forwarding server it’s not working, I just
> keep getting the CNAME over and over again but not actual PTR.

  I'm not sure what in what sense you're using the term "forwarding
  server".

  If you mean the authoritative server where the DNAME record is sitting,
  then I believe that this is normal.  An authoritative server should
  return just the DNAME and synthesized CNAME, as it's not responsible
  for chasing down the CNAME reference.  That's the job of a recursive
  resolver.

> Shouldn’t the forwarding server query the PTR server since it has a
> 0/24 NS RR? It seems like because of the above DNAME RR it expects and
> zone file for the 0/24. However I just want to forward this. 

  I'm sorry.  I don't understand what you think you're trying to achieve.

  I hope this helps.

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

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

Re: subdomain/zone with DHCPD

[Niall O'Reilly]

On 15 October 2015 15:56:42 BST, lejeczek  wrote:
>hi everybody
>
>I'm trying a bind setup which could be talked to by dhcpd.
>I've bind setup with virtual zones and now trying to set up 
>dhcpd so it would be updating DNS, but... but.
>
>In dhcpd.conf I'm trying:

  and what's in your named.conf?
-- 
Sent from Kaiten Mail. Please excuse my brevity.
___
Please visit https://lists.isc.org/mailman/listinfo/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: unalbe-to-query

[Niall O'Reilly]

On Mon, 14 Dec 2015 06:59:12 +,
Ejaz wrote:
> 
> Hi all, 
> 
> We are one of the leading ISP of Saudi Arabia. Installed latest
> version of bind and smbind inorder manage the zones over the Web
> interface. 
> 
> Wonder is that, the zones which configured through smbind cannot be
> seen from the outside world.. locally it is fine. For an example
> arabsat.com. 
> 
> Almost 1500 other zones on the same name server runs through bind 9.9.
> works perfectly internally and externally. Eg. Cyberia.net.sa. 
> 
> From Internally I can query it.. it is ok… 

  I'm not sure that you can safely say this.  From what I can see,
  you seem to be using nslookup, which (in trying to be "helpful")
  hides so much information that you cannot depend on the results
  it gives.

  I suggest you use the zonemaster tool (https://zonemaster.net/) to
  run a comprehensive series of tests against the zone(s) which are
  giving you trouble.

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

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

Re: BIND started replying to queries for .com with .COM

[Niall O'Reilly]

On 1 Apr 2016, at 11:08, Tony Finch wrote:

> Robert Edmonds  wrote:
>> Tony Finch wrote:
>>> Phil Mayers  wrote:

 What is considered the source of the ownername for, say, "com."?
>>>
>>> It should be the root zone master file.
>>
>> Why not the com zone master file?
>
> If you are going to pick a single authority for a particular label, it
> should be the zone that determines whether that label exists or not.

  That seems no less arbitrary a rule of thumb than one which would
  give priority to the zone which contains the authoritative NS records.

  8-)
  /Niall
___
Please visit https://lists.isc.org/mailman/listinfo/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: Request for review of performance advice

[Niall O'Reilly]

On 9 Jul 2020, at 21:25, Havard Eidnes via bind-users wrote:

> 2e#1) Make sure your UDP socket *receive* buffers are big enough.
>   If on BSD, monitor for "dropped due to full socket buffers"
>   count in "netstat -s" output, and tune accordingly.  Note that
>   this may be a symptom of mis-tuning of other parts of BIND,
>   causing excessive CPU usage, which may contribute to this
>   problem.

I'm seeing some instances of "dropped due to no socket" on my FreeBSD
systems where my resolvers run.

I'm wondering

- whether and how I can address this with tuning, and also
- whether I'm wandering out of scope for this list.

Thanks in anticipation and/or apologies.
Niall
___
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: Possible to condition a view based on the interface the query comes in on?

[Niall O'Reilly]

match-destinations ?

⁣---
>From an Android device, using BlueMail, which forces top-posting.​

On 18 Nov 2021, 20:40, at 20:40, Fred Morris  wrote:
>I wanted to provide enhanced recursive DNS to (internal) clients on an
>"opt in" basis, which is to say that clients could choose whether or
>not
>to receive enhanced replies based on what they configured as their
>local
>caching resolver. The enhanced services come in the form of a Response
>Policy Zone (RPZ).
>
>Didn't see any reason that it had to be separate instances of BIND,
>thought maybe I could do it with views, but I've run into a couple of
>roadblocks:
>
>1. listen-on isn't supported in views.
>2. internet wisdom augurs that response-policy isn't supported either.
>
>Is there a way to do this or should I bite the bullet and run two
>copies
>of BIND?
>
>Thanks in advance...
>
>--
>
>Fred Morris
>
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>unsubscribe from this list
>
>ISC funds the development of this software with paid support
>subscriptions. Contact us at https://www.isc.org/contact/ for more
>information.
>
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

dns_dnssec_findzonekeys2: error reading WHATEVER.private: file not found

[Niall O'Reilly]

Hello.

Using BIND 9.16.1-Ubuntu (Stable Release)  because that’s
what’s most simply available on Ubuntu 20.04.3 LTS (Focal Fossa),
I’m seeing messages reporting that private key files can’t be found,
such as the one in the subject line. The files look to me to be
present as expected.

I shall be grateful for any helpful advice.

The relevant part of my configuration is further down.

This appeared to work as expected on a development server running
9.18 from the ISC PPA. For production purposes, we would prefer
to rely, if possible, on what is available without adding a PPA.

Best regards,
Niall O’Reilly


```
dnssec-policy onboarding {
// This policy attempts to match or accommodate what zonefactory did
// YMMV!
dnskey-ttl 3600;
keys {
ksk lifetime 3650d algorithm rsasha256;
zsk lifetime 3650d algorithm rsasha256;
};
max-zone-ttl 3600;
parent-ds-ttl 86400;
parent-propagation-delay 48h;
publish-safety 7d;
retire-safety 7d;
signatures-refresh 5d;
signatures-validity 30d;
signatures-validity-dnskey 30d;
zone-propagation-delay 2h;
};

zone "foo.ie" {
type primary;
update-policy local;
file "/etc/bind/dynamic/foo.ie/db.foo.ie";
key-directory "/etc/bind/dynamic/foo.ie/";
masterfile-format text;

dnssec-policy onboarding;   # Policy under test
// dnssec-policy default;  # triggers retirement of existing keys

// auto-dnssec maintain;   # continues use of existing keys

notify explicit;# Testing: don't propagate confusion! ;-)
also-notify {
downstream-in-house;
};
allow-transfer {
key in-house.ns.my-own.net.;
};
};
```
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: dns_dnssec_findzonekeys2: error reading WHATEVER.private: file not found

[Niall O'Reilly]

On 23 Feb 2022, at 14:32, Niall O'Reilly wrote:

> I shall be grateful for any helpful advice.

Thanks to Josef Moeller and Ondřej Surý.

Niall
-- 
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 prevent gratuitous publication of CDS/CDNSKEY records

[Niall O'Reilly]

Hi.

Clue needed, please.

I’ve managed to migrate a number of zones from cron-driven signing
using homegrown scripts to automatic management by named, while
retaining the respective original KSK for each.

Following migration, ZSK:s have been replaced as might be expected,
since the keys were shorter than is nowadays recommended.
The old ZSK files are still lingering in the key-directory.

I’m seeing that fresh CDS and CDNSKEY are being generated, and
wonder why, as the CDS RDATA matches the parent CD RDATA. I’ve
deleted these using nsupdate, only to find them re-inserted
some time later.

Could it be significant that the parent DS TTL differs from that
of the local CDS?

One of the zones involved is foo.ie.

The server is running BIND 9.16.27-Ubuntu, installed from ppa:isc/bind.

Here below is the relevant dnssec-policy configuration fragment.

```
dnssec-policy persistent {
// This policy attempts to match or accommodate what zonefactory did
// and gives keys unrestricted lifetime
dnskey-ttl 3600;
keys {
ksk lifetime unlimited algorithm rsasha256;
zsk lifetime unlimited algorithm rsasha256;
};
max-zone-ttl 3600;
parent-ds-ttl 86400;
parent-propagation-delay 48h;
publish-safety 7d;
retire-safety 7d;
signatures-refresh 5d;
signatures-validity 30d;
signatures-validity-dnskey 30d;
zone-propagation-delay 2h;
};
```

Thanks in anticipation.

Niall
-- 
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 prevent gratuitous publication of CDS/CDNSKEY records

[Niall O'Reilly]

On 14 Apr 2022, at 13:22, Matthijs Mekking wrote:

these records may also stay in the zone. BIND chooses to keep them in 
the zone


Thanks, Matthijs. That fills the gap for me.

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

Unexpected extra care needed for building BIND 9.18.8

[Niall O'Reilly]

Building BIND 9.18.8 from source seems to need

./configure; LD_RUN_PATH=/usr/local/lib make; sudo make install

instead of the traditional

./configure; make; sudo make install

Using the traditional recipe, I obtained the run-time error message

named: error while loading shared libraries: libisc-9.18.8.so: cannot 
open shared object file: No such file or directory


Is this as intended?

I would have expected that ./configure (or the machinery
it invokes) would take care of propagating ${exec_prefix}/lib
to LD_RUN_PATH at the relevant stage.

/Niall
--
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: Unexpected extra care needed for building BIND 9.18.8

[Niall O'Reilly]

Thanks for replying so promptly, Ondřej.

On 6 Nov 2022, at 15:34, Ondřej Surý wrote:

Nope, that’s local to your system. Hard to tell what’s wrong from 
just a single message, but either there’s cruft somewhere in the 
path with more priority


That was it. Rebuilding the cache cleared the problem.

/Niall


--
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 introduce automatic signing for existing signed zones?

[Niall O'Reilly]

I have a couple of zones which I want to migrate from CLI-driven
signing to BIND9 automatic signing, while avoiding any change to
the respective parent-zone DS RR.

Status quo ante:

- https://dnsviz.net/d/no8.be/dnssec/
  separate KSK, ZSK; both using alg 13
- https://dnsviz.net/d/jamm.ie/dnssec/
  2048-bit KSK, 2x 1024-bit ZSKs (live and spare); all using alg 8

Preparation:

- Set up minimal stand-alone instance of BIND9 named,
  configured with a **dnssec-policy** for each algorithm,
  matching properties of existing DNSSEC keys, and with
  `lifetime unlimited`;
- Deliver current key files and recently-signed copy of
  zone files to this instance.

Expected behaviour on starting named:

- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other keys for each zone are accepted and retained;
- A CDS RR is generated for each zone, matching the current DS RR.

Observed behaviour:

- `named -v` shows `BIND 9.18.8 (Stable Release) `;
- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other RSA/SHA-256 keys (for jamm.ie) are accepted and retained;
- A CDS RR is published for jamm.ie, matching the current DS RR;
- ECDSAP256SHA256 keys (for no8.be) are not accepted;
- New ECDSAP256SHA256 keys are created for no8.be;
- No CDS RR is generated for no8.be.

Unless I'm missing something, there seems to be a discrepancy
according to key type between the handling of RSA/SHA-256 and
ECDSAP256SHA256 keys respectively.

/Niall

// Based on 
https://bind9.readthedocs.io/en/latest/chapter3.html#primary-authoritative-name-server

// authoritative primary named.conf file
// options clause defining the server-wide properties
options {
  // all relative paths use this directory as a base
  directory "/usr/local/var/named";
  listen-on { 127.0.0.1; };
  listen-on-v6 { ::1; };
  allow-query { 127.0.0.1; ::1; };
  allow-query-cache { none; };
  recursion no;
};
// logging clause
// log to /var/log/named/example.log all events from info UP in severity (no 
debug)
// uses 3 files in rotation swaps files when size reaches 250K
// failure messages that occur before logging is established are
// in syslog (/var/log/messages)
//
logging {
  channel example_log {
// uses a relative path name and the directory statement to
// expand to /var/log/named/example.log
file "example.log" versions 3 size 250k;
// only log info and up messages - all others discarded
severity info;
  };
  category default {
example_log;
  };
};

acl local-requesters {
localhost;
};

dnssec-policy "persistent-rsasha256" {
keys {
ksk lifetime unlimited algorithm rsasha256;
zsk lifetime unlimited algorithm rsasha256 1024;
};
};

dnssec-policy "persistent-ecdsa256" {
keys {
ksk lifetime unlimited algorithm 13;
zsk lifetime unlimited algorithm 13;
};
};

// We are a standalone test server for jamm.ie
zone "jamm.ie" {
type primary;
update-policy local;
file "jamm.ie/db.jamm.ie";
key-directory "jamm.ie/";
masterfile-format text;
dnssec-policy persistent-rsasha256;
notify explicit;
allow-transfer {
local-requesters;
};
};

// We are a standalone test server for no8.be
zone "no8.be" {
type primary;
update-policy local;
file "no8.be/db.no8.be";
key-directory "no8.be/";
masterfile-format text;
dnssec-policy persistent-ecdsa256;
notify explicit;
allow-transfer {
local-requesters;
};
};
managed-keys-zone: loaded serial 0
zone no8.be/IN: loaded serial 2022110700 (DNSSEC signed)
zone jamm.ie/IN: loaded serial 2022110700 (DNSSEC signed)
zone no8.be/IN: reconfiguring zone keys
keymgr: DNSKEY no8.be/ECDSAP256SHA256/42593 (KSK) created for policy 
persistent-ecdsa256
keymgr: DNSKEY no8.be/ECDSAP256SHA256/5030 (ZSK) created for policy 
persistent-ecdsa256
Fetching no8.be/ECDSAP256SHA256/42593 (KSK) from key repository.
DNSKEY no8.be/ECDSAP256SHA256/42593 (KSK) is now published
DNSKEY no8.be/ECDSAP256SHA256/42593 (KSK) is now active
Fetching no8.be/ECDSAP256SHA256/5030 (ZSK) from key repository.
DNSKEY no8.be/ECDSAP256SHA256/5030 (ZSK) is now published
DNSKEY no8.be/ECDSAP256SHA256/5030 (ZSK) is now active
zone no8.be/IN: next key event: 07-Nov-2022 12:17:13.995
zone jamm.ie/IN: reconfiguring zone keys
keymgr: retire DNSKEY jamm.ie/RSASHA256/3078 (ZSK)
DNSKEY jamm.ie/RSASHA256/17103 (ZSK) is now active
Removing expired key 3078/RSASHA256 from DNSKEY RRset.
DNSKEY jamm.ie/RSASHA256/3078 (ZSK) is now deleted
CDS for key jamm.ie/RSASHA256/47680 is now published
CDNSKEY for key jamm.ie/RSASHA256/47680 is now published
zone jamm.ie/IN: next key event: 07-Nov-2022 10:17:14.023
all zones loaded
running
managed-keys-zone: Initializing automatic trust anchor management for zone '.'; 
DNSKEY ID 20326 is now trusted, waiving the normal 30-day waiting period.
resolver priming query complete: success
zone jamm.ie/IN: reconfiguring zone keys
zone jamm.ie/IN: next key event: 07-Nov-2022 11:17:14.026
zone jamm.ie/IN: reconfigur

Re: How to introduce automatic signing for existing signed zones?

[Niall O'Reilly]

Thank you for your speedy response, Matthijs.

On 7 Nov 2022, at 13:10, Matthijs Mekking wrote:


Ignore that, I saw too late there were attachments.


Perhaps I ought to have mentioned them explicitly.

Are you able to share the public key and key state files with me so I 
can investigate why BIND thinks the existing keys cannot be used?


Off list, and PGP-protected, yes.

This will mean I'll end up having to change the parent DS RRs later on.
That seems a reasonable cost for getting to the root of the problem.

I have no key state files, except after starting named, and then only
for the RSA/SHA-256 and **newly-generated** ECDSA keys.  My current
signing process uses ldns-signzone, which seems not to use such files.


Also, the log file looks like an excerpt.


No; that's everything named, as configured, writes.


A full debug (level 3) log would be useful too.


I'll set up for that, and follow up off list.

Thanks and best regards,
Niall

-- 
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 introduce automatic signing for existing signed zones?

[Niall O'Reilly]

On 7 Nov 2022, at 11:40, Niall O'Reilly wrote:

> Preparation:
>
> - Set up minimal stand-alone instance of BIND9 named,
>   configured with a **dnssec-policy** for each algorithm,
>   matching properties of existing DNSSEC keys, and with
>   `lifetime unlimited`;
> - Deliver current key files and recently-signed copy of
>   zone files to this instance.

I needed an additional stage of preparation, before delivering
the key files; specifically, I needed to edit the .private
files to 'Private-key-format: v1.3' and add missing lifecycle
metadata.

After doing this, named behaved exactly as expected.

Thanks, Matthijs, for steering me in the right direction,
and for being ready to give me additional help.

/Niall

-- 
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 introduce automatic signing for existing signed zones?

[Niall O'Reilly]

On 8 Nov 2022, at 7:54, Matthijs Mekking wrote:

Thanks for reporting back. This is an omission in our KB article that 
I will fix.


Thanks, Matthijs.
I think that will be useful.

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

Documentation suggestion for Ubuntu PPA http://ppa.launchpad.net/isc/bind/ubuntu

[Niall O'Reilly]

Hi.

With "APT-Sources: http://ppa.launchpad.net/isc/bind/ubuntu focal/main 
amd64 Packages",

the file /usr/share/doc/bind9/README.Debian recommends:

Zones subject to automatic updates (such as via DHCP and/or nsupdate) 
should be

stored in /var/lib/bind, and specified with full pathnames.


Do I understand correctly that this advice also applies to zones for 
which
a dnssec-policy and inline-signing (rather than update-policy) are 
specified?


If so, it might be well to extend the parenthesis "(such as ...)" to 
mention

this case also.

Best regards,
Niall O'Reilly
--
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: [KASP] setup KASP in master / slave architecture

[Niall O'Reilly]

On 16 Dec 2022, at 15:59, adrien sipasseuth wrote:

> - on the slaves: files .db
>
> I don't understand why there is no .db.signed file on my slave
> knowing that a dig from a slave does return RRSIG.

The secondary (slave) only needs one file to hold whatever zone
data the primary provides when transferring the zone.

It doesn't actually matter what you call this file, but something
based on the name of the zone will likely make it easier to
understand months later.

The primary uses additional files to contain the keys and to
hold both DNSSEC and NSUPDATE state. These files aren't needed
on the secondaries.

On a secondary, I actually prefer to use a suffix distinct from
any used on the primary (eg. ".bk"), so that I don't have to worry
about filename collisions in case, in an emergency, I might need
to import the primary files from backup and reconfigure what is
normally a secondary as a primary instead.

I hope this helps.

Niall
-- 
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: Zone not showing us as authority

[Niall O'Reilly]

On Sun, 2008-11-16 at 10:33 -0800, Steve Koon wrote:
> We have moved a zone from UltraDNS to our DNS server 1 week ago and it
> is still not showing us as authority. Can anyone help me as to why
> this might be happening and how to fix it? I have included a dig below
> using a public dns server (4.2.2.1) and our dns server (69.25.129.117)
> where is shows no authority as well as the zone file contents on our
> dns server 69.25.129.117.

I'm not sure what you think is broken.

Each of the queries you send using 'dig' asks for the list of
authoritative name servers for 'discoversunriver.com'.  In each
case, the server involved returns the list in the answer section
of the response.  This list includes the server you seem to be
concerned about.  In addition, the server at 69.25.129.117 has 
the 'AA' flag set, indicating that is is aware of its own
authority.

Were you expecting something else?

Best regards,

Niall O'Reilly
University College Dublin IT Services


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

Re: nsupdate ACL based on a key AND ip-subnet

[Niall O'Reilly]

On Fri, 2008-11-14 at 17:35 -0800, Chris Buxton wrote:
> Use a firewall (with deep packet inspection) to restrict by subnet.  
> Then use the TSIG key in the allow-update statement.
> 
> Unfortunately, to my knowledge, that's the only way to do this.

Wouldn't using a BIND view to restrict by subnet work instead
of a firewall?

/Niall


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

Re: Is it possible to use one KSK for multiple domains?

[Niall O'Reilly]

On Wed, 2008-11-19 at 21:55 +0100, Adam Tkac wrote:
> does anyone know if is it possible to sign multiple domains with one
> KSK?

Adam,

I suspect your question may need to be more specific.

Are you asking about the signing process itself, or rather 
about how certain aspects of this process need to be exposed
in the DNS?

The RFC-fragment you cite seems to me to require that each 
signed zone needs its set of [KZ]SK exposed in the DNS, but 
to be silent on whether a single key can be reused by appearing
as RDATA in the DNSKEY RRsets of multiple zones.

I haven't read 4033/4034 thoroughly, so it's possible I may 
have misunderstood completely.

Best regards,

    Niall O'Reilly


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

Re: Is it possible to use one KSK for multiple domains?

[Niall O'Reilly]

On Thu, 2008-11-20 at 14:15 +0100, Adam Tkac wrote:
> It isn't possible to validate myzone1.tld. with key from other zone,
> for example myzone2.tld., is it?

No, but Chris explained better than I did what I had in mind.

On Thu, 2008-11-20 at 11:43 +, Chris Thompson wrote:
> the DNSKEY records for the KSK(s) (or ZSK(s), for that matter) could
> have identical rdata in different zones: i.e. they could specify the
> same
> encryption key. Whether this would be a *good* thing to do is
> doubtful:

/Niall


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

Re: Zone not propogating to slaves

[Niall O'Reilly]

On Wed, 2008-11-19 at 19:36 -0800, Steve Koon wrote:
[ ... ] 
> Anyone know why I am getting this “not authoritative” message and no
> zone file on .118 all of a sudden?
[ ... ]
> This is the log message in the 69.25.129.118 slave
> 
> client 69.25.129.117#1304: received notify for zone
> 'manzanitavacation.com': not authoritative

118 is telling you that it won't act on a notify from 117
because ...

[ ... ]
> =[3]== named.conf for 69.25.129.118 Slave ==
[ ... ]
> zone manzanitavacation.com. in {
> 
> type slave;
> 
> file "c:\windows\system32\dns\etc\named\zones
> \db.manzanitavacation.com.zone";
> 
> masters { 69.25.129.119; };
> 
> allow-notify {69.25.129.117;69.25.129.118; };
> 
> };

... you've told it to accept only 119 as a master. 

[Log message might better say this more plainly.]

You have a few options.

 1. Read the ARM and work out how to avoid sending useless
NOTIFY messages, while keeping the useful ones.

 2. Leave things the way they are, and live with noisy logs.

 3. Allow one or other (but not both -- you need to avoid
loops in your update-propagation graph!) slave to act
as intermediate master for the other.

Beir bua!
/Niall



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

Re: BIND and ENUM NAPTR...

[Niall O'Reilly]

On Tue, 2008-12-02 at 23:32 -0800, Gregory Hicks wrote:
> SIP (NAPTR and ENUM) uses a DNS like structure.  

You put that so compactly that people may be confused.

SIP uses URLs, sometimes truncate to "SIP addresses".

ENUM is a system for advertisement and discovery of the
URLs associated with a given phone number.  It uses the
DNS as its database.

NAPTR is the DNS record type used by ENUM for storing URLs.

> Does BIND support these data types?  

Current and recent versions of BIND support NAPTR records.

> Are there any references?

Lots: RFC3761; Google "ENUM tutorial"; RIPE-46.

I hope this helps.

    Best regards,

Niall O'Reilly


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

Re: 512 byte limit

[Niall O'Reilly]

On Wed, 2009-01-21 at 11:47 -0500, Todd Snyder wrote:
> I was under the (likely mistaken) impression that over 512 wasn't
> allowed, but there it is ...
> 
> I could very well be completely messed up regarding the rules, so
> please
> forgive my ignorance.  If you know my answer is in TFM, please batter
> me
> about the head and tell me which FM at least :)

The magic word is 'EDNS0'.  I don't know nearly as much 
about it as I ought to, but Googling for this word, 
I found a  short and readable explanation, with some 
suggestions for correcting badly-configured firewalls:

http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html

IHTH

/Niall


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

Re: denied NS/IN

[Niall O'Reilly]

On Wed, 2009-01-21 at 12:44 +1100, Mark Andrews wrote:
> You should talk to your ISP to chase the traffic back to
> its source and get BCP 38 implemented there.  BCP 38 is ~10
> years old now.  There is no excuse for not filtering spoofed
> traffic.

Absolutely.

Putting myself at the other end of the telescope, I'm wondering
what tools (if any) are available for verifying that the ingress
filtering actually in place is indeed compliant with BCP 38.

I try to be conscientious, but drawing valid conclusions from 
visual inspection of the ACLs is already a challenge for my 
domestic network (3 LANs and an upstream).  Enterprise (even 
with only one upstream) or ISP networks are likely more 
difficult to verify.

Pointers for my next RTFM binge are welcome.  Further discussion
is probably off-topic for the bind-users list.

/Niall


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

Re: denied NS/IN

[Niall O'Reilly]

On Thu, 2009-01-22 at 10:25 +1100, Mark Andrews wrote:
> One way to test is to have a test box that sends spoofed traffic
> to a machine you control.

Thanks, Mark.

That tells me pretty well what I needed to know, but
hoped not to hear: I have to build my own bot-net.  8-)

/Niall


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

Re: rndc halt -p behavior

[Niall O'Reilly]

On Wed, 2009-01-21 at 19:14 -0600, Jeremy C. Reed wrote:
> Maybe we should just remove the "immediately" part.
> 
> Any suggestions would be appreciated.

If you're going to make a change, adding a little more
information wouldn't hurt, would it?  Perhaps:

s/immediately/cleanly (which may take a little time)/

IHTH
/Niall




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

Re: Open Ports in BIND

[Niall O'Reilly]

[ Copied to list to let other know 
  that this question has been answered ]

On Sun, 2009-02-01 at 18:08 +0330, Bind wrote:
> # netstat -an |grep 53 |wc
>  3911223   20656
> 
> is first number the total queries which asked from my server on port
> 53 or 
> number of sessions that stablished?

None of what you suggest.

You need to read the documentation for the commands 
involved.  Try

# man netstat
# man grep
# man wc

Best regards

/Niall


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

Re: Caching-only Name server does Zone Updates

[Niall O'Reilly]

On Mon, 2009-02-02 at 17:25 +0530, Ashish wrote:
> Our DNS is configured as Caching-only Name server.

How do you know?

>  However, it's still
> performing Zone updates like a Slave Name Server.

How many 'zone' sections are in your configuration?

Why not post your configuration file to the list,
so that we can see?

/Niall


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

Re: Pruning the reverse zone tree

[Niall O'Reilly]

On Wed, 2009-02-04 at 16:57 +, Chris Thompson wrote:
> I would welcome feedback on
> 
>   http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones
> 
> which describes a scheme we are experimenting with for reverse
> lookup. (Executive summary: take RFC 2317 and carry the ideas
> to their [possibly] logical conclusion.)

Way to go!
I've been doing it like this for quite a while, with
the co-operation of my LIR/NREN.  For example:

% dig -x 2001:770:98:200::35:1

/Niall


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

Re: Microsoft Exchange Installer.

[Niall O'Reilly]

On Thu, 2009-02-05 at 15:13 +, Dean, Barry wrote:
> One of my colleagues is convinced my DNS config is "broken",

[ ... ]

Barry,

There are some details you neglected to mention.  In particular,
it's left to the reader's best guess that your colleagues 
exchange server is given a name belonging to the livad.liv.ac.uk
zone.  If that's actually the case, then the SOA record for
livad.liv.ac.uk is indeed the record whence the negative cache 
timer for the Exchange server's name is obtained.

It's also not clear who is the zone admin for the livad... zone:
you, your colleague who deals with Exchange, or someone else.

Two options occur to me for you.  You could have the zone admin
for livad... shorten the negative cache timer.  Alternatively,
you could have your internal resolving servers act as stealth
slaves for livad...  Your servers won't then cache RRs 
belonging to livad... and will be kept up to date by NOTIFY
from the master (provided, of course, that the master can ...).

Without client access to your internal recursive servers, I 
can't say whether they're broken or not.  However, my first 
impressions from what you wrote are that they're very likely 
doing "what it says on the tin".

If you feel some off-list follow-up would help, I would be
interested, as the experience may help me anticipate and/or
forestall potential problems of a similar nature.

Best regards,

Niall O'Reilly
University College Dublin IT Services
(just a ferry-ride away!)



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

Re: How to create the TSIG?

[Niall O'Reilly]

On Thu, 2009-02-05 at 16:58 -0800, Chris Buxton wrote:
> Use a different key for each slave.

Definitely, if each of your slaves is under distinct
administration.

If some organization is managing more than one of your
slaves for you, I'ld suggest using a distinct key only
for each cluster of commonly-administered servers.
This may cut down on key-management effort.

Do take care to use a secure channel for distributing
the keys!

/Niall


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

adb.c:1526: INSIST(find->adbname == ((void *)0)) failed

[Niall O'Reilly]

joe(user)8: uname -a
Linux marlay.no8.be 2.6.9-1.667 #1 Tue Nov 2 14:41:31 EST 2004 i586 i586 i386 
GNU/Linux
joe(user)9: named -v
BIND 9.4.2-P1
joe(user)10: grep INSIST /var/log/messages.1
Feb 13 14:12:57 marlay named[2226]: adb.c:1526: INSIST(find->adbname == ((void 
*)0)) failed
joe(user)11: 

If this assertion failure is covered by the following entry in the
CHANGES file, I just need to upgrade.  

2139.   [bug]   dns_view_find() was being called with wrong type
in adb.c. [RT #16670]

I'ld appreciate it if someone would confirm.

Thanks in advance.

/Niall


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

Re: max open files & max sockets

[Niall O'Reilly]

On Sun, 2009-02-15 at 14:34 +0700, budsz wrote:
> 
> I need to know, how to resolve this problem.

It's not clear that there is a problem.

If you're sure to need more than 3405 concurrent
connections to your name server, you may well need more 
headroom than a socket limit of 4096 will allow.  It's 
only an extra 20%.  

Either way, I expect you need to find out how to tune 
per-process resource quotas in FreeBSD.  I don't know 
the details.

/Niall


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

Re: adb.c:1526: INSIST(find->adbname == ((void *)0)) failed

[Niall O'Reilly]

On Mon, 2009-02-16 at 12:17 +1100, Mark Andrews wrote:
> It should be unrelated.  I would however still upgrade.

Thanks, Mark.

If I don't see the same assertion failure with
the current release, I guess that's closed.

One advantage of upgrading is getting all those nice
log entries reporting EDNS faults.  8-)

/Niall



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

Re: adb.c:1526: INSIST(find->adbname == ((void *)0)) failed

[Niall O'Reilly]

On Tue, 2009-02-17 at 14:09 -0600, David Forrest wrote:
> To get rid of all those "nice" log entries, I have this in my
> named.conf:

Thanks, David.
For now, they're not so frequent as to be a nuisance.

/Niall


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

Re: Catch ALL Setup

[Niall O'Reilly]

On Wed, 2009-02-18 at 16:19 +1100, Mark Andrews wrote:
> 
> $ORIGIN .
> @ 0 SOA ...
> @ 0 NS ...
> * 0 A 1.2.3.4

That may be too minimal.
I found I needed a few couple of extra wildcard records.

$ORIGIN .
@   IN  SOA . bit-bucket.ucd.ie. (
2009021302  ; serial
14400   ; Refresh - 4 hours 
7200; Retry - 2 hours
1209600 ; Expire - 14 days
1800 )  ; Neg. Caching - 30 minutes
;
@   IN  NS  captive.ucd.ie.
;
; Over-ride wildcard for captive.ucd.ie
captive.ucd.ie. IN  TXT "Unaddressable"
;
; Target for all name resolution
netreg.ucd.ie.  IN  A   137.43.116.32
;
; Wildcard alias
*   IN  CNAME   netreg.ucd.ie.
;
; Wildcards otherwise masked by empty non-terminals
*.ie.   IN  CNAME   netreg.ucd.ie.
*.ucd.ie.   IN  CNAME   netreg.ucd.ie.

/Niall


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

Re: Question re separating caching and authoritative servers

[Niall O'Reilly]

On Fri, 2009-02-20 at 13:07 -0500, John Wobus wrote:
> 
> Any especially good or bad practices? Things that have worked well
> or poorly? Right now, I'm leaning toward having the caching server
> transfer key zones.

Works for me.

    Niall O'Reilly
University College Dublin IT Services


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

Re: Multiple masters and multiple TSIG keys

[Niall O'Reilly]

On 29 Sep 2010, at 09:34, Anand Buddhdev wrote:

> Now, I have been given 2 keys, t1 and t2, to use for transferring z1 and
> z2 respectively.

[Wandering off topic, perhaps]

That seems to me a back-to-front way to do things.

If the organization running the master is concerned to identify
responsibility for purported slave access, the key needs to be
provided by the organization responsible for running the slave,
and accepted (or not) at the master end.

That's what I expect from my slaves.
None has revolted yet. 8-)

One way or the other, using multiple keys to express what is
intrinsically a single trust relationship seems to be both likely
to increase the risk of compromise and certain to add administrative
burden.  Why do it?

ATB
/Niall

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

Re: Multiple masters and multiple TSIG keys

[Niall O'Reilly]

On 29 Sep 2010, at 15:53, Anand Buddhdev wrote:

> Anyway, I discussed this with my colleague here, and we came up with a
> solution that works. We have created 2 views of the master name servers:

Nice one, and useful to have in the mailing-list archive!
/Niall

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

Re: DNS Redundancy

[Niall O'Reilly]

On 21 Oct 2010, at 12:32, Martin McCormick wrote:

>   The normal procedure on internet-connected systems is to
> set the resolv.conf file to include at least 2 domain name
> servers. Example:
> 
> nameserver139.78.100.1
> nameserver139.78.200.1
> 
>   Last night, I had to take down our primary DNS for
> maintenance and lots of FreeBSD and Linux systems began having trouble of 
> various
> kinds.
> 
>   While I expected the FreeBSD system I was on to hang for
> a couple of seconds and then start using the second DNS, it
> basically froze while some Linux boxes also began exhibiting
> similar behavior.
> 
>   I finally manually changed the resolv.conf on the system
> I was using to force the slave DNS to be first in the list and
> that helped, but loosing the primary DNS was not the slight
> slowdown one might expect. It was a full-blown outage.

It's a good idea to keep your authoritative name service
(for announcing DNS records for your part of the DNS) separate
from your resolver name service (for mediating name service 
to the clients on your network).

/etc/resolv.conf (or equivalent on other platforms) specifies
where the client should look for resolver service.  The
addresses in there should best not be those of the master
or slave server for your DNS zone(s).

Without more detail, it's difficult to say exactly what chain
of cause and effect led to your "full-blown outage".

It's well to bear in mind that the typical (Unix-like) client
will always step through the nameserver addresses in the order
in which they appear in /etc/resolv.conf.  If you're planning to
take one of them down for maintenance, and wish to avoid
client-side delays, you need either to configure the clients
in advance (for example, by using DHCP) with a different 
/etc/resolv.conf.  Alternatively, you might instantiate the
first address in the list on the second server.  There is no
"one true way".

On the other hand, dedicated resolver servers (at least those
running BIND named) keep track of the state of the authoritative
servers for the names for which they are processing queries, and
automagically ignore any that are unreachable.  This allows my
customers (for example) to be spared delay when you take one of
your authoritative servers down.

Best regards,
Niall O'Reilly

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

Re: Dynamic DNS with secondary nameserver?

[Niall O'Reilly]

On 01/12/10 20:09, Sean Thomas Caron wrote:
> ** server can't find
> sph-2006-0090-test.ddns.sph.umich.edu.sph.umich.edu: SERVFAIL

With NOTIFY enabled on master and slave, what you are
trying to do should "just work".

Do you mean to have ".sph.umich.edu" repeated?
If not, something is confused, and tracking it
down will be useful.  Perhaps a trailing dot is
inadvertently omitted.  Experience is not always
enough to protect one from this error, as I know.
8-)

Apart from that, what serial number is active on
each server, and what's showing in your logs?

With default logging (I've never done any tuning),
the master should have log entries like this:

sending notifies (serial xx)

On the slave, you should see corresponding ones:

received notify for zone

IHTH

Niall O'Reilly
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: nslookup Got recursion not available from... trying next server

[Niall O'Reilly]

On 05/01/11 21:36, vr wrote:
> I'm having a query problem and hope I'm at the right mailing list...

Formally, probably not, since what you describe isn't a BIND
issue.  That said, the people on this list are likely among
those who can best give you helpful advice.

> I get a "recursion not available" message intermittently when using
> nslookup.

The short answer is, "Yes indeed: that's how DNS works."
A longer answer follows below.

I should mention first that I have no experience using
'nslookup'.  I understand that it has a reputation for masking
the information actually needed for troubleshooting by trying
too hard to be "helpful".  I don't actually know whether this
reputation is deserved.

I suggest you use 'dig' instead.  I count myself lucky that
this was the first DNS troubleshooting tool I was introduced to
by our then "Internet expert" nearly 20 years ago. [Thanks,
Mike!]  I've never felt the need to use another, and probably
haven't even yet discovered all of its features.

> The message will appear on the first query, presumably to
> un-cached IP/hostname and subsequent queries to the same IP/hostname
> will succeed without the message.

It is normal, and actually good practice, for any authoritative
name server (the master or slave for a given zone) to be
configured to refuse to provide recursive name service.
I guess that 'nslookup' is by default making a recursive query,
happens to send that query to an authoritative server, receives
a response in which the "recursion not available" flag is set,
and duly displays a message which appears at first sight to be
disturbing.

As it happens, 'dig' also makes a recursive query by default,
although it's easy to tell it not to.  Besides, 'dig' just
    shows the flags; it doesn't convert them into potentially
disturbing messages.

I hope this helps.


Best regards,

Niall O'Reilly
University College Dublin IT Services
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind slave not get DNS update

[Niall O'Reilly]

On 05/01/11 01:50, Steve Zeng wrote:
> I don't have NS record for both of the slaves (windows DNS slave and
> Linux DNS slave). I use "also-notify" and it works for Windows DNS
> slave. But not for BIND/Linux.

On 05/01/11 19:56, Steve Zeng wrote:
> Rndc transfer (initialized at the slave side) works fine...

Good.  Manual intervention works.

I suggest you try to determine the following from your logs
on both master and (Linux) slave.

Whether the master is sending the NOTIFY.
Whether the slave is receiving the NOTIFY.
Whether the slave is acting on the NOTIFY.

That should make it clear what's not happening without
manual intervention.


    Best regards,
Niall O'Reilly
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users